OSQUERYは、実行中のプロセス、ロードされたカーネルモジュール、アクティブなログインユーザー、アクティブなリスニングポートなど、マシンの状態に関連するさまざまな情報をクエリするためにFacebookによって開発されたオープンソースツールです。効率的かつ直感的な監視。 OSQUERYは、オペレーティングシステムを高性能の仮想リレーショナルデータベースとして公開します。これにより、SQLクエリを記述して、オペレーティングシステムデータを探索し、エンドポイント（Windows、OS X、Linux、およびFreeBSD）にクエリを実行して、さまざまな種類の脅威を識別、調査、および排除できます。 。 OSQUERYは、従来のHIDS/IPSとは異なります。ここでは、クエリのテーブルにあるデータを確認し、これらのデータに基づいてクエリを設計する必要があります。また、ファイルの整合性を監視し、ネットワーク接続とプロセスを監査し、ハードウェアデバイスの変更をリアルタイムでログに記録する機能も組み込まれています。この記事では、ubuntu 16にOSQUERYをインストールし、osqueryiとosquerydを介してその使用法を確認します。
1。 OSQUERYをインストールする
OSQUERYリポジトリ情報をaptデータベースに追加し、システムを更新します。
# sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80Badd-apt-repositoryを使用するには、Pythonソフトウェアのプロパティをインストールする必要があります。
# sudo apt-get install software-properties-common python-software-propertiesリポジトリデータをapt-databaseに追加します
# sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"システムを更新し、OSQUERYをインストールします
# sudo apt-get update
# sudo apt-get install osqueryOSQUERYは、対話型シェルを介して、またはデーモンモードとして実行できます。最初に、OSQUERYシェルインターフェイスを介してそれを使用する方法を探り、その後、デーモンモードを確認します。 osqueryシェルを取得するには、ターミナルでosqueryiと入力して、すぐに使用できるosqueryテーブルをクエリします。
# osqueryi
osquery>システムにログインしているすべてのユーザーを一覧表示するには、次のクエリを実行します。
osquery> select * from logged_in_users ;クエリに使用できるすべてのテーブルを検索します。
osquery> .tablesテーブルのスキーマを説明するには、次のコマンドを実行します。
osquery> .schema table-nameシェルを終了します
osquery> .exitコマンドラインフラグを渡してOSQUERYを実行することもできます。例
# osqueryi --disable_events=false --worker_threads=2 --logger_plugin=filesystem --pidfile=/var/osquery/osquery.pidfileOSQUERYインタラクティブシェルで使用できるその他のコマンドラインフラグを見つけるには、ターミナルから次のコマンドを実行します。
# osqueryi --help別のセクションでさらにクエリを検討しますが、OSQUERYを構成してみましょう。
2。 OSQUERYを構成する
構成ファイルを使用してOSQUERYを実行する方が簡単です。 osqueryインタラクティブシェルを実行するために多くのコマンドラインパラメーターを渡すのではなく、これらのパラメーターをosquery構成ファイルに書き込むことができます。 OSQUERYインタラクティブシェル（osqueryi）は、osqueryiを実行するとこれらのパラメーターを読み取ります。 OSQUERYには構成ファイルは付属していません。むしろ、コピーできるサンプル構成ファイル（/usr/share/osquery/osquery.example.conf）があります。 /etc/osquery/osquery.confで構成ファイルを探します。構成ファイルが存在しない場合、osqueryiはデフォルトのオプションで実行されます。また、構成ファイルはOSQUERYデーモンで使用できます。
OSQUERY構成ファイルには、次の3つのセクションが含まれています。
→osqueryiとosqueryデーモン（osqueryd）の両方で読み取られるオプションと設定のリスト
→クエリスケジュール：SQLクエリと間隔のセット。
→より具体的/ターゲットを絞ったクエリを含むパックのリスト。例：ファイル変更監視パック：監視対象のファイルとディレクトリのカテゴリとパス
2.1オプションと設定
オプションと設定の完全なリストは、このwikiにあります。この記事で使用するオプションと設定については、以下で説明します。
config_plugin： 構成プラグイン名。構成取得のタイプであるデフォルトのファイルシステムプラグインは、ディスクから構成JSONを読み取ります。
logger_plugin： ロガープラグイン名。デフォルトのロガーはファイルシステムです。これにより、さまざまなログタイプがJSONとして特定のファイルパスに書き込まれます。複数のロガープラグインを同時に使用して、ログを各インターフェイスに効果的にコピーできます。構成を指定するときは、プラグイン名をコンマで区切ります（--logger_plugin =filesystem、syslog）。
logger_path： ERROR / WARN/INFOおよび結果ログのディレクトリパス。
disable_logging： ERROR / WARNING / INFO（ステータスログと呼ばれる）とクエリ結果のログを無効にします。
schedule_splay_percent： 設定時間を表示する割合。クエリスケジュールには、同じ間隔の複数のクエリが含まれることがよくあります。多くの場合、スケジュール作成者は、これらのクエリをその間隔で一緒に実行することを意図していません。むしろ、各クエリはほぼ間隔で実行する必要があります。構成がロードされると、デフォルトのスケジュールスプレイ10％が各クエリに適用されます。
pidfile： デーモンpidfilemutexへのパス。このファイルは、複数のosquerydプロセスが開始されないようにするために使用されます。
events_expiry： バッキングストアからのイベントパブリッシュパブリッシュサブスクライブの結果を期限切れにするタイムアウト。この有効期限は、結果が照会された場合にのみ適用されます。たとえば、-events_expiry =1の場合、イベントは、サブスクライバーからの1回の選択に対してのみ実際に存在します。選択が発生しない場合、イベントはバッキングストアに無期限に保存されます。
database_path： ディスクベースのバッキングストアを使用している場合は、パスを指定します。 osqueryは、デフォルトでRocksDBを使用する「バッキングストア」を使用して状態を保持します。この状態は、スケジュールに従って後で照会できるようにイベント情報を保持します。スケジュール内の各クエリの最新のクエリの結果を保持します。この最後にクエリされた結果により、クエリ差分ロギングが可能になります。
詳細： 詳細な情報メッセージを有効にします。
worker_threads： クエリの処理に使用される作業ディスパッチスレッドの数。
enable_monitor： スケジュールモニターを有効または無効にするために使用されます。
disable_events： osqueryオペレーティングシステムのイベントパブリッシュサブスクライブAPIを無効にします。これにより、ログに記録されたイベントに基づいてレポートするいくつかのテーブルが暗黙的に無効になります。
disable_audit： オペレーティングシステムの監査サブシステムからのイベントの受信を無効にするために使用されます。
audit_allow_config： 監査発行者が監査構成を変更できるようにする
host_identifier： osqueryを実行しているホストを識別するために使用されるフィールド：ホスト名、uuid、エフェメラル、インスタンス。
enable_syslog： syslog取り込みイベントパブリッシャーをオンにします。これは、rsyslogまたはsyslog-ngの外部構成が必要なため、「明示的」に有効です。
audit_allow_sockets： これにより、監査発行者はソケット関連のルールをインストールできます。
schedule_default_interval： オプションで、デフォルトの間隔値を設定します。これは、間隔を定義しないクエリをスケジュールする場合に使用されます。
# sudo vi /etc/osquery/osquery.conf
"options": {
"config_plugin": "filesystem",
"logger_plugin": "filesystem",
"logger_path": "/var/log/osquery",
"disable_logging": "false",
"log_result_events": "true",
"schedule_splay_percent": "10",
"pidfile": "/var/osquery/osquery.pidfile",
"events_expiry": "3600",
"database_path": "/var/osquery/osquery.db",
"verbose": "false",
"worker_threads": "2",
"enable_monitor": "true",
"disable_events": "false",
"disable_audit": "false",
"audit_allow_config": "true",
"host_identifier": "hostname",
"enable_syslog": "true",
"audit_allow_sockets": "true",
"schedule_default_interval": "3600"
},
...........
...........
...........2.2クエリスケジュール
スケジュールセクションには、一意のキーで識別されるクエリが含まれ、その後に間隔でクエリの頻度が秒単位で指定されます。使用するスケジュールセクションの構成は次のようになります-
...........
...........
{
"schedule": {
"crontab": {
"query": "SELECT * FROM crontab;",
"interval": 300
},
"largest_process": {
"query": "select pid, name, uid, resident_size from processes order by resident_size desc limit 10;",
"interval": 60
},
}
...........
...........最初のクエリは300秒ごとにcrontabテーブルを検索し、2番目のクエリは10秒ごとにロードされたカーネル拡張機能をスニッフィングします。クエリの結果は、RocksDBを使用してディスクにキャッシュされます。最初のクエリ実行時に、すべての結果がRocksDBに保存されます。以降の実行では、結果セットの違い（変更）のみがRocksDBに記録されます。
デコレータと呼ばれる別の特別なクエリは、他のスケジュールされたクエリの前にデータを追加するために使用されます。次のデコレータは、osqueryを実行しているホストのUUIDとユーザーのユーザー名を、スケジュールされているすべてのクエリの前に付加します。
..........
..........
"decorators": {
"load": [
"SELECT uuid AS host_uuid FROM system_info;",
"SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
]
},
..........
..........2.3クエリパック
構成は、スケジュールの定義に役立つクエリのセットと呼ばれるパックをサポートします。パックはosqueryで配布され、幅広いカテゴリの情報と可視性に基づいてラベル付けされます。たとえば、「コンプライアンス」パックには、ロックダウンされたオペレーティングシステムの機能とユーザー設定の変更をチェックするクエリが含まれます。 「脆弱性管理」パックは、パッケージおよびソフトウェアのインストール変更に関するイベントログを作成する一般的な資産管理クエリを実行する場合があります。 / usr / share / osquery/packsフォルダーにあるデフォルトのパックセット。これらのパックを構成ファイルに追加します。
..........
..........
"packs": {
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
}2.4ファイル整合性監視用のカスタムパックを作成する
前のセクションで追加したパックは、箱から出して出荷されます。次に、file_pathsを介して構成されたフォルダーのファイル整合性を監視するタスクを持つ独自のパックを追加します。 / usr / share / osquery / packs /内にfims.confという名前のファイルを作成し、次のセクションを追加します。
# vi /usr/share/osquery/packs/fims.conf
{
"queries": {
"file_events": {
"query": "select * from file_events;",
"removed": false,
"interval": 300
}
},
"file_paths": {
"homes": [
"/root/.ssh/%%",
"/home/%/.ssh/%%"
],
"etc": [
"/etc/%%"
],
"home": [
"/home/%%"
],
"tmp": [
"/tmp/%%"
]
}
}file_eventsクエリは、file_pathsで指定されたパス内の任意のファイルで5分間隔で発生したすべてのFIMイベントを収集するようにスケジュールされています。大まかに言うと、これはイベントがosquery内でバッファリングされ、5分ごとに構成済みのロガーに送信されることを意味します。
上記のファイルを含めるようにosquery.confのpacksセクションを変更します。
# sudo vi /etc/osquery/osquery.conf
.................
"packs": {
"fim": "/usr/share/osquery/packs/fims.conf",
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
}最終的なOSQUERY構成ファイルは次のようになります-
{
"options": {
"config_plugin": "filesystem",
"logger_plugin": "filesystem",
"logger_path": "/var/log/osquery",
"disable_logging": "false",
"log_result_events": "true",
"schedule_splay_percent": "10",
"pidfile": "/var/osquery/osquery.pidfile",
"events_expiry": "3600",
"database_path": "/var/osquery/osquery.db",
"verbose": "true",
"worker_threads": "2",
"enable_monitor": "true",
"disable_events": "false",
"disable_audit": "false",
"audit_allow_config": "true",
"host_identifier": "hostname",
"enable_syslog": "true",
"syslog_pipe_path": "/var/osquery/syslog_pipe",
"audit_allow_sockets": "true",
"schedule_default_interval": "3600"
},
"schedule": {
"crontab": {
"query": "SELECT * FROM crontab;",
"interval": 300
},
"largest_process": {
"query": "select pid, name, uid, resident_size from processes order by resident_size desc limit 10;",
"interval": 60
}
},
"decorators": {
"load": [
"SELECT uuid AS host_uuid FROM system_info;",
"SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
]
},
"packs": {
"fim": "/usr/share/osquery/packs/fims.conf",
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf",
"hardware-monitoring": "/usr/share/osquery/packs/hardware-monitoring.conf"
}
}構成ファイルの有効性を確認してください。
# sudo osqueryctl config-checkOSQUERYインタラクティブシェルを冗長モードで実行します。
# osqueryi --verbose3。 syslog-ngログを消費するようにOSQUERYを構成します
このステップでは、syslogを使用するようにOSQUERYを構成します。 Ubuntuにはsyslogを生成するデフォルトのrsyslogアプリケーションがありますが、この記事では、syslog-ngによって生成されたログがOSQUERYによって消費されるようにsyslog-ngを構成する方法について説明します。 OSQUERYクエリのsyslogテーブルは、適切に構成されたsyslog-ngデーモンから名前付きパイプを介して転送されます。 syslogがosqueryに取り込まれると、バッキングストア（RocksDB）に書き込まれ、クエリに使用できるようになります。したがって、syslog-ng構成は、OSQUERYがログを消費する名前付きパイプを作成します。
syslog-ngをインストールします
# sudo apt-get install syslog-ngsyslog-ngによって作成されたファイルのグループをsyslogに変更します。 syslog-ngのメイン構成ファイルを編集し、グループをadmに変更します。
# vi /etc/syslog-ng/syslog-ng.conf
.........................
.........................
options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
owner("root"); group("adm"); perm(0640); stats_freq(0); bad_hostname("^gconfd$"); threaded(yes); }; ......................... .........................次に、OSQUERYのsyslog-ng構成を作成します。次のセクションでは、システムログのsyslog-ngを設定し、これらのログをCSV形式で書き換える方法を示します。次に、テンプレートを使用してメッセージ/ログをフォーマットし、ログフィールドがOSQUERYのsyslogテーブルとブレンドされるようにします。最後に、OSQUERYが使用するために、ログが名前付きパイプにプッシュされます。パイプの権限には、少なくともsyslog-ngが読み取り/書き込みを許可し、osqueryが読み取りを許可する必要があります。
# vi /etc/syslog-ng/conf.d/osquery.conf
source s_osquery {
system();
};
rewrite r_csv_message {
set("$MESSAGE", value("CSVMESSAGE") );
subst("\"","\\\"", value("CSVMESSAGE"), flags(global) );
};
template t_csv {
template("\"${ISODATE}\", \"${HOST}\", \"${LEVEL_NUM}\", \"${FACILITY}\", \"${PROGRAM}\", \"${MESSAGE}\"\n");
template_escape(no);
};
destination d_osquery {
pipe("/var/osquery/syslog_pipe" template(t_csv));
};
log {
source(s_osquery);
rewrite(r_csv_message);
destination(d_osquery);
};以前に作成したosquery構成ファイル（/etc/osquery/osquery.conf）は、syslog-ngを少し調整する必要があります。 logger_pluginをファイルシステムからsyslogに変更するか、両方を保持します。
"logger_plugin": "syslog" or "logger_plugin": "filesystem,syslog"次のオプションは、syslogの取り込みにも必要です。
.................
.................
"enable_syslog": "true",
"syslog_pipe_path": "/var/osquery/syslog_pipe",
"disable_events": "false",
.................
.................したがって、前に作成した/etc/osquery/osquery.confのlogger_pluginオプションのみを編集する必要があり、残りの3つのオプションはすでに構成ファイルにあります。
次に、syslog-ngを再起動し、パイプが適切な権限で作成されているかどうかを確認します。
# sudo systemctl start syslog-ng
# ls -l /var/osquery/syslog_pipe
prw-r----- 1 root adm 0 Apr 27 14:29 /var/osquery/syslog_pipeパイプを流れるログを確認してください
# cat /var/osquery/syslog_pipe
"2017-04-27T14:42:33+00:00", "ubuntu", "6", "auth", "sshd", "Accepted password for root from 117.227.81.214 port 61849 ssh2"
"2017-04-27T14:42:33+00:00", "ubuntu", "6", "authpriv", "sshd", "pam_unix(sshd:session): session opened for user root by (uid=0)"
"2017-04-27T14:42:41+00:00", "ubuntu", "5", "local3", "osqueryi", "severity=0 location=options.cpp:61 message=Verbose logging enabled by config option"
...................................
...................................OSQUERYインタラクティブシェルを起動します。
# osqueryi
I0427 14:32:07.981422 3730 options.cpp:61] Verbose logging enabled by config option
I0427 14:32:08.085734 3730 syslog.cpp:97] Successfully opened pipe for syslog ingestion: /var/osquery/syslog_pipe
I0427 14:32:08.101172 3730 file_events.cpp:68] Added file event listener to: /etc/**
....................
I0427 14:32:08.101784 3730 audit.cpp:226] Adding audit rule: syscall=59 action=2 filter=''
....................
I0427 14:32:08.278990 3737 events.cpp:749] Starting event publisher run loop: syslog
I0427 14:32:08.279242 3736 events.cpp:749] Starting event publisher run loop: inotify
I0427 14:32:08.279353 3735 events.cpp:749] Starting event publisher run loop: audit
osquery>次に、syslogテーブルをクエリします。
osqueryi> select * from syslog;上記のクエリは、名前付きパイプ/ var / osquery / syslog_pipe
を介してosqueryによって消費されたsyslogを表示します。4。 OSQUERYiによる脅威の検出とDFIR
このセクションでは、osqueryインタラクティブシェルによるいくつかの基本的なセキュリティチェックについて説明します。
a）次のクエリを実行して、現在システムにログインしているユーザーを見つけます。
osquery> select * from logged_in_users ;b）以前のログインをすべて検索します
osquery> select * from last ;c）ファイアウォールルールを見つけるには、次のクエリを実行します。次のクエリで出力が生成されない場合は、ファイアウォールが構成されていないことを意味します。
osquery> select * from iptables ;d）crontabによってスケジュールされたすべてのジョブを検索するには、次のクエリを実行します。このクエリを使用すると、特定の間隔で実行するようにスケジュールされているマルウェアがあるかどうかを確認できます。
osquery> select command, path from crontab ;e）setuidが有効になっているファイルを見つけます。デフォルトでは、Ubuntu 16でsetuidが有効になっているファイルはほとんどありませんが、これらを除いて、setuidが有効になっている他のファイルは何ですか。これは、バックドアバイナリの検出に役立ちます。
osquery> select * from suid_bin ;f）ロードされたカーネルモジュールのリストを見つけます。
osquery> select name, used_by, status from kernel_modules where status="Live" ;g）すべてのリスニングポートを見つけて、システムへのバックドアがあるかどうかを確認します。構成していない開いているポートがある場合は、このポートを開いたプロセスを調べる必要がある場合があります。
osquery> select * from listening_ports ;h）次のクエリを実行して、サーバー内のファイルアクティビティと責任のあるユーザーを見つけます。
osquery> select * from file_events ;i）常駐メモリサイズで上位10の最大プロセスを見つけます。
osquery> select pid, name, uid, resident_size from processes order by resident_size desc limit 10;j）実行中のすべてのプロセスを検索します。
osquery> select * from processes;k）プロセス数を見つけ、最もアクティブなプロセスのトップ10に名前を付けます。
osquery> select count(pid) as total, name from processes group by name order by total desc limit 10;l）通常、マルウェアはポートをリッスンし、リバースシェルを攻撃者に転送します。次のクエリを実行して、システムの以前の既知の安全な状態との違いを見つけます。
osquery> SELECT DISTINCT process.name, listening.port, listening.address, process.pid FROM processes AS process JOIN listening_ports AS listening ON process.pid = listening.pid;m）多くの場合、攻撃者は悪意のあるバイナリファイルをシステムで実行した後に削除します。このようなプロセスを見つけるには、次のクエリを実行します。
osquery> SELECT name, path, pid FROM processes WHERE on_disk = 0;n）次のクエリを実行して、攻撃者に転送されたbashリバースシェルがあるかどうかを確認します。
osquery> SELECT * FROM processes WHERE cmdline LIKE '/bin/bash -i >& /dev/tcp/%';5。デーモンモードのOSQUERY
これまで見てきたように、OSQUERYはOSの状態の結果をリアルタイムで返し、後の段階で照会できます。ただし、脅威を検出するために常にクエリを実行することはできません。これとは別に、OSQUERYにはアラートメカニズムも含まれていません。解決策は、OSQUERYをデーモンとして実行し、構成ファイルに含まれているスケジュールされたクエリとパックを定期的に実行し、結果をファイルに書き込むことです。 / usr / share / osquery / packs内に独自のパックを作成し、監視用のパックをOSQUERY構成ファイルに含めます。スケジュールされたクエリとパックの結果は、ファイル/var/log/osquery/osqueryd.results.logに書き込まれます。このログファイルは、OSQUERYがデーモンモードとして開始され、OSQUERYDが結果の送信を開始した場合にのみ作成されます。 OSQUERYデーモンは、同じ構成ファイル/etc/osquery/osquery.confを読み取ります。以前に「syslog」に変更した場合は、logger_pluginの値を/etc/osquery/osquery.confのファイルシステムに戻すことを忘れないでください。
デーモンを起動するには、次のコマンドのいずれかを使用します。
# sudo systemctl start osqueryd
OR
# sudo osqueryctl startOSQUERYDがスケジュールされたクエリとパックを実行すると、結果は短時間で利用できるようになります。 tailコマンドを使用して、結果がファイル/var/log/osquery/osqueryd.results.log
に書き込まれていることを確認します。# tail -f /var/log/osquery/osqueryd.results.logこれで、結果ログをELKスタックなどの外部アプリケーションに転送して、ログ分析やアラート生成を行うことができます。
結論
OSQUERYは、OSデータを仮想リレーショナルデータベースに公開し、SQLを使用してシステムデータをクエリできる優れたツールです。 osqueryiは、バックドア、マルウェア、ゾンビプロセスを検索したり、ログインしているユーザーを検索したりするために1回限りのクエリを実行するのに役立ちます。一方、osquerydは、スケジュールされたクエリやカスタムパックを実行して、結果を長期間保存し、外部アプリケーション。