Ubuntu16.04でosqueryを使用してシステムセキュリティを監視する方法
序章
osquery は、オペレーティングシステムを取得し、SQLのようなステートメントを使用してクエリできるテーブルを備えた1つの巨大なデータベースに変換するオープンソースのセキュリティツールです。 これらのクエリを使用すると、ファイルの整合性を監視したり、ファイアウォールのステータスと構成を確認したり、ターゲットサーバーのセキュリティ監査を実行したりできます。
これは、macOS、Windows 10、CentOS、およびUbuntuの最新バージョンをサポートするクロスプラットフォームアプリケーションです。 これは、「SQLを利用したオペレーティングシステムのインストルメンテーション、監視、および分析」フレームワークとして公式に説明されており、Facebookから発信されました。
osqueryを使用すると、サーバーに対してselect * from logged_in_users ;
などのコマンドを実行し、次のような結果を返すことができます。
Output+-----------+----------+-------+------------------+------------+------+ | type | user | tty | host | time | pid | +-----------+----------+-------+------------------+------------+------+ | login | LOGIN | ttyS0 | | 1483580429 | 1546 | | login | LOGIN | tty1 | | 1483580429 | 1549 | | user | root | pts/0 | 24.27.68.82 | 1483580584 | 1752 | | user | sammy | pts/1 | 11.11.11.11 | 1483580770 | 4057 | | boot_time | reboot | ~ | 4.4.0-57-generic | 1483580419 | 0 | | runlevel | runlevel | ~ | 4.4.0-57-generic | 1483580426 | 53 | +-----------+----------+-------+------------------+------------+------+
これが魅力的な場合は、サーバーのシステムセキュリティ監視および侵入検知ツールとしてosqueryを使用することをお勧めします。
osqueryをインストールすると、次のコンポーネントにアクセスできます。
osqueryi
:アドホッククエリを実行するためのインタラクティブなosqueryシェル。osqueryd
:バックグラウンドでクエリをスケジュールおよび実行するためのデーモン。osqueryctl
:osqueryのデプロイメントまたは構成をテストするためのヘルパースクリプト。 オペレーティングシステムのサービスマネージャーの代わりに使用して、osqueryd
を開始/停止/再起動することもできます。
osqueryi
とosqueryd
は独立したツールです。 それらは通信せず、一方を他方なしで使用できます。 それぞれを実行するために必要なフラグとオプションのほとんどは同じであり、osqueryd
の構成ファイルを使用してosqueryi
を起動できるため、多くのコマンドラインスイッチを使用せずに環境をカスタマイズできます。
このチュートリアルでは、次のことを行います。
- osqueryをインストールします。
- osqueryが正しく機能するために必要なRsyslogなどのオペレーティングシステムの側面を構成します。
osqueryi
とosqueryd
の両方で使用できる構成ファイルを設定します。- スケジュールに追加できる事前定義されたクエリのグループであるosquerypacksを操作します。
osqueryi
を使用してアドホッククエリを実行し、セキュリティの問題を探します。- デーモンを起動して、クエリを自動的に実行できるようにします。
デーモンであるosqueryd
によって生成されたログは、適切にセットアップして使用するために追加の専門知識を必要とする外部ログエンドポイントに送信されることを目的としています。 このチュートリアルではその構成については説明しませんが、デーモンを構成して実行し、結果をローカルに保存する方法を学習します。
前提条件
このチュートリアルを完了するには、次のものを用意する必要があります。
- sudo権限とファイアウォールを持つroot以外のユーザーで構成されたUbuntu16.04サーバー。 Ubuntu 16.04の初期セットアップガイドに従って、これをセットアップします。
また、SQLの基本的な知識と、Linuxシステムのセキュリティに関する基本的な知識も必要です。
ステップ1-サーバーへのosqueryのインストール
osqueryは、ソースからコンパイルするか、パッケージマネージャーを使用してインストールできます。 公式のUbuntuリポジトリにはインストール可能なパッケージがないため、プロジェクトの公式のUbuntuリポジトリをシステムに追加する必要があります。
まず、リポジトリの公開鍵を追加します。
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B
次に、リポジトリを追加します。
sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"
パッケージデータベースを更新します。
sudo apt-get update
最後に、osqueryをインストールします。
sudo apt-get install osquery
箱から出して、osqueryは信じられないほど便利ではありません。 プラグアンドプレイアプリケーションではありません。 対話型シェルまたはデーモンのどちらを使用する場合でも、コマンドラインまたは構成ファイルを介して、いくつかのフラグとオプションを渡す必要があります。 デーモンで使用可能なフラグとオプションを表示するには、次のように入力します。
osqueryd --help
出力には、数十のコマンドラインフラグと構成オプションが含まれます。 以下に示すのは、この記事で使用したテストサーバーからの部分的な出力です。
Outputosquery 2.1.2, your OS as a high-performance relational database Usage: osqueryd [OPTION]... osquery command line flags: --flagfile PATH Line-delimited file of additional flags --config_check Check the format of an osquery config and exit --config_dump Dump the contents of the configuration --config_path VALUE Path to JSON config file --config_plugin VALUE Config plugin name --config_tls_endpoint VALUE TLS/HTTPS endpoint for config retrieval --config_tls_max_attempts VALUE Number of attempts to retry a TLS config/enroll request --config_tls_refresh VALUE Optional interval in seconds to re-read configuration --daemonize Run as daemon (osqueryd only) ... ... osquery configuration options (set by config or CLI flags): --audit_allow_config Allow the audit publisher to change auditing configuration --audit_allow_sockets Allow the audit publisher to install socket-related rules --audit_persist Attempt to retain control of audit --aws_access_key_id VALUE AWS access key ID --aws_firehose_period VALUE Seconds between flushing logs to Firehose (default 10) --aws_firehose_stream VALUE Name of Firehose stream for logging --aws_kinesis_period VALUE Seconds between flushing logs to Kinesis (default 10) --aws_kinesis_random_partition_key Enable random kinesis partition keys --aws_kinesis_stream VALUE Name of Kinesis stream for logging --aws_profile_name VALUE AWS profile for authentication and region configuration --aws_region VALUE AWS region
対話型シェルでのみ使用可能な追加のコマンドラインフラグを表示するには、次のように入力します。
osqueryi --help
osqueryi
を実行することは、箱から出して利用可能なosqueryテーブルを一覧表示および照会するための最も簡単な方法です。 例として、次のコマンドを使用して起動します。
osqueryi --verbose
これにより、インタラクティブシェルに配置され、次のような出力が表示されます。
OutputI0105 01:52:54.987584 4761 init.cpp:364] osquery initialized [version=2.1.2] I0105 01:52:54.987808 4761 extensions.cpp:351] Could not autoload extensions: Failed reading: /etc/osquery/extensions.load I0105 01:52:54.987944 4761 extensions.cpp:364] Could not autoload modules: Failed reading: /etc/osquery/modules.load I0105 01:52:54.988209 4761 init.cpp:606] Error reading config: config file does not exist: /etc/osquery/osquery.conf I0105 01:52:54.988334 4761 events.cpp:886] Error registering subscriber: socket_events: Subscriber disabled via configuration I0105 01:52:54.993973 4763 interface.cpp:307] Extension manager service starting: /home/sammy/.osquery/shell.em Using a virtual database. Need help, type '.help' osquery>
出力にエラーメッセージと情報メッセージがあるため、osqueryのすべての部分が正しく機能していないことは明らかです。 select * from yara ;
などの特定のクエリは何も返さず、テーブルにデータが入力されていないことを示します。
select time, severity, message from syslog ;
などの他のクエリは、次のようなメッセージを返します。これは、実行する必要のある作業がまだあることを示します。
OutputW1202 15:44:48.600539 1720 virtual_table.cpp:492] Table syslog is event-based but events are disabled W1202 15:44:48.600587 1720 virtual_table.cpp:499] Please see the table documentation: https://osquery.io/docs/#syslog
この問題を解決するために、サーバーの構成にいくつかの変更を加えます。
次のように入力して、コンソールを終了します。
.exit
次のセクションでは、osqueryが正しく機能するために必要なオペレーティングシステムの側面を変更します。
ステップ2–osqueryがシステムログにアクセスできるようにする
このステップでは、オペレーティングシステムのsyslogアプリケーションを変更して、osqueryがシステムログを消費およびクエリできるようにします。 Ubuntu 16.04では、これはRsyslog構成ファイルを変更することを意味します。 また、必要な変更は、構成ファイルに数行のコードを追加することだけです。
まず、/etc/rsyslog.conf
ファイルを開きます。
sudo nano /etc/rsyslog.conf
どのパイプに書き込むか、どのsyslogパラメーターをそのパイプに書き込むかをRsyslogに指示する構成行をいくつか追加する必要があります。 デフォルトでは、パイプは/var/osquery/syslog_pipe
です。 次に、osqueryは、そのパイプに書き込まれた情報からsyslog
テーブルにデータを入力します。
次の行をファイルに追加します。
/etc/rsyslog.conftemplate( name="OsqueryCsvFormat" type="string" string="%timestamp:::date-rfc3339,csv%,%hostname:::csv%,%syslogseverity:::csv%,%syslogfacility-text:::csv%,%syslogtag:::csv%,%msg:::csv%\n" ) *.* action(type="ompipe" Pipe="/var/osquery/syslog_pipe" template="OsqueryCsvFormat")
ファイルを保存して閉じます。 変更を適用するには、syslogデーモンを再起動します。
sudo systemctl restart rsyslog
次に、いくつかのデフォルトオプションを設定し、いくつかのクエリをスケジュールする構成ファイルを作成しましょう。
ステップ3–osquery構成ファイルの作成
構成ファイルを作成すると、osqueryi
の実行が簡単になります。 osqueryi
は、多くのコマンドラインオプションを渡す代わりに、/etc/osquery/osquery.conf
にある構成ファイルからそれらのオプションを読み取ることができます。 そしてもちろん、構成ファイルはデーモンでも利用できます。
構成ファイルには、スケジュールどおりに実行する必要のあるクエリも含まれています。 ただし、スケジュールどおりに実行できるクエリのほとんどは、パックと呼ばれるものとして出荷されます。 パックは、/usr/share/osquery/packs
ディレクトリにあるファイルです。
osqueryには構成ファイルは付属していませんが、/etc/osquery
にコピーして変更できるサンプル構成ファイルがあります。 ただし、そのファイルには、UbuntuなどのLinuxディストリビューションで実行するために必要なすべてのオプションが含まれているわけではないため、独自のファイルを作成します。
構成ファイルには3つのセクションがあります。
- デーモンオプションと機能設定のリスト。 これらは
osqueryi
でも読み取ることができます。 - 実行するようにスケジュールされたクエリのリストと、それらをいつ実行する必要があるか。
- より具体的なスケジュールされたクエリを実行するために使用されるパックのリスト。
以下は、構成ファイルに使用するオプション、それらの意味、およびそれらに設定する値のリストです。 このオプションのリストは、Ubuntu16.04およびその他のLinuxディストリビューションでosqueryi
およびosqueryd
を実行するのに十分です。
- config_plugin :osqueryに構成を読み取らせる場所。 デフォルトでは、ディスク上のファイルから読み取られるため、この値は
filesystem
です。 - logger_plugin :osqueryがスケジュールされたクエリの結果を書き込む場所を指定します。 ここでも、
filesystem
を使用します。 - logger_path :これは、スケジュールされたクエリの情報、警告、エラー、および結果を含むファイルを見つけるログディレクトリへのパスです。 デフォルトでは、これは
/var/log/osquery
です。 - disable_logging :これの値を
false
に設定することにより、ロギングを有効にします。 - log_result_events :これを
true
に設定すると、結果ログの各行が状態変化を表します。 - schedule_splay_percent :これは、サーバーへのパフォーマンスへの影響を制限するために、同じ間隔で多数のクエリがスケジュールされている場合、それらを分散して実行することをosqueryに通知します。 デフォルト値は
10
で、これはパーセンテージです。 - pidfile :osqueryデーモンのプロセスIDを書き込む場所。 デフォルトは
/var/osquery/osquery.pidfile
です。 - events_expiry :秒単位で、サブスクライバーを保持する時間はosqueryバッキングストアになります。 箱から出して、これは
3600
に設定されています。 - database_path :osqueryのデータベースへのパス。 デフォルトの
/var/osquery/osquery.db
を使用します。 - verbose :ロギングが有効になっている場合、これは詳細な情報メッセージを有効または無効にするために使用されます。 これを
false
に設定します。 - worker_threads :クエリの処理に使用されるワークディスパッチスレッドの数。 これはデフォルトで
2
に設定されているので、そのままにしておきます。 - enable_monitor :スケジュールモニターを有効または無効にするために使用されます。 有効にするので、値は
true
になります。 - disable_events :osqueryのパブリッシュ/サブスクライブシステムを規制するために使用されます。 これを有効にする必要があるため、ここでの値は
false
になります。 - disable_audit :オペレーティングシステムの監査サブシステムからのイベントの受信を無効にするために使用されます。 有効にする必要があるため、ここで使用される値は
false
になります。 - audit_allow_config :監査パブリッシャーが監査構成を変更できるようにします。 デフォルトは
true
です。 - audit_allow_sockets :これにより、監査パブリッシャーはソケット関連のルールをインストールできます。 値は
true
になります。 - host_identifier :これはosqueryを実行しているホストを識別するために使用されます。 複数のサーバーから結果を集約する場合、特定のログエントリがどのサーバーからのものであるかを簡単に判断するのに役立ちます。 値は
hostname
またはuuid
のいずれかです。 箱から出して、hostname
に設定されているので、その値を使用します。 - enable_syslog :osqueryがsyslog情報を消費するには、これを
true
に設定する必要があります。 - schedule_default_interval :スケジュールされたクエリの間隔が設定されていない場合は、この値を使用します。 数秒で、
3600
に設定します。
osqueryi
およびosqueryd
で使用できるすべてのコマンドラインフラグと構成オプションを表示する方法はすでに説明しましたが、このサーバーでosqueryを実行するには上記のオプションで十分です。
次のコマンドを使用して、構成ファイルを作成して開きます。
sudo nano /etc/osquery/osquery.conf
構成ファイルはJSON形式を使用します。 次のコンテンツをファイルにコピーします。
/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" },
構成ファイルの次の部分は、スケジューリングセクションです。 各クエリは、ファイル内で一意である必要があるキーまたは名前で識別され、その後に実行するクエリと、クエリを実行する間隔(秒単位)が続きます。 300秒ごとにcrontab
テーブルを参照するスケジュールされたクエリを追加します。
次の行を構成ファイルに追加します。
/etc/osquery/osquery.conf
"schedule": { "crontab": { "query": "SELECT * FROM crontab;", "interval": 300 } },
クエリはいくつでも記述できます。 正しい形式を維持してください。 そうしないと、ファイルの検証に失敗します。 たとえば、さらにいくつかのクエリを追加するには、次の行を追加します。
/etc/osquery/osquery.conf
"schedule": { "crontab": { "query": "SELECT * FROM crontab;", "interval": 300 }, "system_profile": { "query": "SELECT * FROM osquery_schedule;" }, "system_info": { "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;", "interval": 3600 } },
スケジュールされたクエリの後に、装飾者と呼ばれる特別なクエリを追加できます。これは、他のスケジュールされたクエリの前にデータを追加するクエリです。 ここに示すデコレータクエリは、スケジュールされたすべてのクエリの前に、osqueryを実行しているホストのUUIDとユーザーのユーザー名を付加します。
次の行をファイルに追加します。
/etc/osquery/osquery.conf
"decorators": { "load": [ "SELECT uuid AS host_uuid FROM system_info;", "SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;" ] },
最後に、osqueryに、より具体的なクエリを含むパックのリストを指定できます。 osqueryのすべてのインストールには、/usr/share/osquery/packs
ディレクトリにあるデフォルトのパックセットが付属しています。 パックの1つはmacOS用で、残りはLinuxシステム用です。 パックはデフォルトの場所から使用できますが、/etc/osquery
ディレクトリにコピーすることもできます。
これらの行をファイルに追加して、ファイルを完成させます。
/etc/osquery/osquery.conf
"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" } }
ファイルの最初の行の開始中括弧と一致する、最後の終了中括弧に注意してください。 完成した構成ファイルは次のようになります。
/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" }, "schedule": { "crontab": { "query": "SELECT * FROM crontab;", "interval": 300 }, "system_profile": { "query": "SELECT * FROM osquery_schedule;" }, "system_info": { "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;", "interval": 3600 } }, "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": { "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" } }
ファイルを保存して閉じ、次のコマンドを使用して検証します。
sudo osqueryctl config-check
出力は次のようになります。
OutputI0104 11:11:46.022858 24501 rocksdb.cpp:187] Opening RocksDB handle: /var/osquery/osquery.db
エラーが発生した場合は、エラーの場所が出力に表示されるため、修正できます。
有効な構成ファイルを入手したら、ファイルの整合性の監視に必要なosqueryパックの構成に進むことができます。
ステップ4–osqueryファイル整合性監視パックの設定
サーバー上のファイルの整合性を注意深く監視することは、サーバーのシステムセキュリティを監視する上で重要な側面です。 この目的のために、osqueryはすぐに使えるソリューションを提供します。
前のセクションで構成に追加したパックは、箱から出して出荷されます。 このセクションでは、ファイルの整合性の監視に使用されるクエリとディレクティブを含むパックをリストにもう1つ追加します。 この演習では、ファイルをfim.conf
と呼びます。
このファイルを作成し、エディターで開きます。
sudo nano /usr/share/osquery/packs/fim.conf
/home
、/etc
、および/tmp
ディレクトリ内のファイルイベントを300秒ごとに監視するパックを作成します。 パックファイルの完全なセットアップは、次のファイルリストに示されています。 それをファイルにコピーします。
/usr/share/osquery/packs/fim.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/%%" ] } }
ファイルを保存して閉じます。
新しいファイルとそのルールをosqueryで使用できるようにするには、/etc/osquery/osquery.conf
の最後にあるパックリストでそのファイルを参照します。 編集用にファイルを開きます。
sudo nano /etc/osquery/osquery.conf
次に、packsセクションを変更して、新しいファイルを含めます。
/etc/osquery/osquery.conf ... "packs": { "fim": "/usr/share/osquery/packs/fim.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" }
ファイルを保存して閉じます。 また、ファイルに間違いがないことを確認するために、もう一度検証してください。
sudo osqueryctl config-check
それでは、osqueryi
を使用してシステムにクエリを実行してみましょう。
ステップ5–osqueryiを使用してアドホックセキュリティチェックを実行する
osqueryが役立つ場所はたくさんあります。 このセクションでは、インタラクティブシェルであるosqueryi
を使用して、システムでさまざまなセキュリティチェックを実行します。 この時点では、まだosqueryデーモンを起動していないことに注意してください。 これがosqueryの優れた点です。デーモンがアクティブでない場合でも、環境を構成するために作成した構成ファイルを使用しながら、osqueryi
を使用してクエリを実行できます。
構成ファイルを使用してosquery
を起動するには、次のように入力します。
sudo osqueryi --config_path /etc/osquery/osquery.conf --verbose
注:osqueryi
およびosqueryd
verbose オプションを渡すと、osqueryの問題を示す可能性のあるエラーまたは警告を確認できるため、良い習慣です。 。 通常、osqueryi
はroot権限なしで実行できますが、デーモンの構成ファイルを指定して呼び出す場合は、rootとして実行する必要があります。
基本的なセキュリティチェックから始めて、そこから上に進んでいきましょう。 たとえば、あなた以外の誰が今システムにログインしていますか? このクエリで調べてください:
select * from logged_in_users ;
出力は次のようになります。
Output+-----------+----------+-------+------------------+------------+------+ | type | user | tty | host | time | pid | +-----------+----------+-------+------------------+------------+------+ | boot_time | reboot | ~ | 4.4.0-57-generic | 1483580419 | 0 | | runlevel | runlevel | ~ | 4.4.0-57-generic | 1483580426 | 53 | | login | LOGIN | ttyS0 | | 1483580429 | 1546 | | login | LOGIN | tty1 | | 1483580429 | 1549 | | user | root | pts/0 | 11.11.11.11 | 1483580584 | 1752 | | user | sammy | pts/1 | 11.11.11.11 | 1483580770 | 4057 | +-----------+----------+-------+------------------+------------+------+
この出力では、マシンにログインしている2つの実際のユーザーアカウントがあり、どちらも同じIPアドレスからのものです。 そのIPアドレスは既知のIPアドレスである必要があります。 そうでない場合は、そのログインがどこから来たのかを調査する必要があります。
前のクエリは、誰が今ログインしているかを示していますが、以前のログインはどうですか? 次のように、lastテーブルをクエリすることで確認できます。
select * from last ;
出力は異常なことを何も示さなかったので、他の人は最近マシンにログインしていません:
Output+----------+-------+------+------+------------+------------------+ | username | tty | pid | type | time | host | +----------+-------+------+------+------------+------------------+ | reboot | ~ | 0 | 2 | 1483580419 | 4.4.0-57-generic | | runlevel | ~ | 53 | 1 | 1483580426 | 4.4.0-57-generic | | | ttyS0 | 1546 | 5 | 1483580429 | | | LOGIN | ttyS0 | 1546 | 6 | 1483580429 | | | | tty1 | 1549 | 5 | 1483580429 | | | LOGIN | tty1 | 1549 | 6 | 1483580429 | | | root | pts/0 | 1752 | 7 | 1483580584 | 11.11.11.11 | | sammy | pts/1 | 4057 | 7 | 1483580770 | 11.11.11.11 | +----------+-------+------+------+------------+------------------+
ファイアウォールが構成され、アクティブ化されていますか? ファイアウォールはまだ実行されていますか? 疑わしい場合は、次のクエリを実行して以下を確認してください。
select * from iptables ;
出力がない場合は、IPTablesファイアウォールが構成されていないことを意味します。 インターネットに接続するサーバーの場合、これは良くないことなので、ファイアウォールを構成する方が適切です。
次のように、特定の列でフィルタリングするように変更された前のコマンドを実行できます。
select chain, policy, src_ip, dst_ip from iptables ;
そのクエリは、次のような出力を提供するはずです。 構成していない異常な送信元および宛先IPアドレスを探します。
Output+---------+--------+---------+-----------+ | chain | policy | src_ip | dst_ip | +---------+--------+---------+-----------+ | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 127.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | INPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0 | | FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0 | | OUTPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | | OUTPUT | ACCEPT | 0.0.0.0 | 0.0.0.0 | +---------+--------+---------+-----------+
crontabではどのような種類のジョブがスケジュールされていますか? それらをスケジュールしましたか? このクエリは、特定の間隔で実行するようにスケジュールされているマルウェアを見つけるのに役立ちます。
select command, path from crontab ;
そして、出力はこの形式を取る必要があります。 疑わしいと思われるコマンドは、さらに調査する必要があります。
Output+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+ | command | path | +----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+ | root cd / && run-parts --report /etc/cron.hourly | /etc/crontab | | root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) | /etc/crontab | | root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) | /etc/crontab | | root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) | /etc/crontab | | root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi | /etc/cron.d/mdadm | | root test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest --crond | /etc/cron.d/popularity-contest | +----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+
setuid対応のファイルがシステムにありますか? Ubuntu 16.04サーバーにはかなりの数がありますが、どれがそれらであり、システム上にあるはずのないものはありますか? これらの質問への回答は、バックドアされたバイナリを検出するのに役立ちます。 このクエリを定期的に実行し、その結果を古い結果と比較して、追加を監視できるようにします。 そのクエリは次のとおりです。
select * from suid_bin ;
このクエリからの部分的な出力は次のようになります。
Output+-------------------------------+----------+-----------+-------------+ | path | username | groupname | permissions | +-------------------------------+----------+-----------+-------------+ | /bin/ping6 | root | root | S | | /bin/su | root | root | S | | /bin/mount | root | root | S | | /bin/umount | root | root | S | | /bin/fusermount | root | root | S | | /bin/ntfs-3g | root | root | S | | /bin/ping | root | root | S | | /sbin/mount.ntfs-3g | root | root | S | | /sbin/mount.ntfs | root | root | S | | /sbin/unix_chkpwd | root | shadow | G | | /sbin/pam_extrausers_chkpwd | root | shadow | G | | /usr/bin/chage | root | shadow | G | | /usr/bin/locate | root | mlocate | G | | /usr/bin/chfn | root | root | S | | /usr/bin/chsh | root | root | S | | /usr/bin/newuidmap | root | root | S | | /usr/bin/write | root | tty | G | | /usr/bin/mlocate | root | mlocate | G | | /usr/bin/at | daemon | daemon | SG | | /usr/bin/sg | root | root | S |
ロードされたカーネルモジュールのリストを表示するには、次のクエリを実行します。
select name, used_by, status from kernel_modules where status="Live" ;
これは、定期的に実行し、その出力を古い結果と比較して、何かが変更されているかどうかを確認するためのもう1つのクエリです。
サーバー上のバックドアを見つけるのに役立つさらに別の方法は、すべてのリスニングポートを一覧表示するクエリを実行することです。 これを行うには、次のクエリを実行します。
select * from listening_ports ;
ポート22
でSSHのみが実行されている新しいサーバーでは、出力は次のようになります。
Output+-------+------+----------+--------+---------+ | pid | port | protocol | family | address | +-------+------+----------+--------+---------+ | 1686 | 22 | 6 | 2 | 0.0.0.0 | | 1686 | 22 | 6 | 10 | :: | | 25356 | 0 | 0 | 0 | | +-------+------+----------+--------+---------+
サーバー上で、サーバーがリッスンする必要があることがわかっているポートのみが出力に含まれている場合は、心配する必要はありません。 ただし、他のポートが開いている場合は、それらのポートが何であるかを調査する必要があります。
サーバー上のファイルアクティビティを確認するには、次のクエリを実行します。
select target_path, action, uid from file_events ;
出力には、サーバー上の最近のすべてのファイルアクティビティと、アクティビティを担当するユーザーIDが表示されます。
Output+---------------------------+---------+------+ | target_path | action | uid | +---------------------------+---------+------+ | /home/sammy/..bashrc.swp | CREATED | 1000 | | /home/sammy/..bashrc.swp | UPDATED | 1000 | | /home/sammy/..bashrc.swp | UPDATED | 1000 | | /home/sammy/.bashrc | UPDATED | 1000 | | /home/sammy/..bashrc.swp | DELETED | 1000 | | /home/sammy/..bashrc.swp | CREATED | 1000 | | /home/sammy/..bashrc.swp | UPDATED | 1000 | | /home/sammy/..bashrc.swp | UPDATED | 1000 | | /home/sammy/.bashrc | UPDATED | 1000 | | /home/sammy/.bashrc | UPDATED | 1000 | | /home/sammy/.bashrc | UPDATED | 1000 | | /home/sammy/..bashrc.swp | DELETED | | | /etc/test_file.txt | DELETED | | | /home/sammy/.bash_history | UPDATED | 1000 | | /home/sammy/.bash_history | UPDATED | 1000 | | /etc/secret_file.md | CREATED | 0 | | /etc/secret_file.md | UPDATED | 0 | | /etc/secret_file.md | UPDATED | 0 | +---------------------------+---------+------+
考えられるセキュリティの問題を把握するためにサーバーで実行できるクエリのようなものはたくさんあります。
テーブルのスキーマがわからない場合は、次のコマンドを使用して調べてください。
.schema name-of-table
そして、あなたは利用可能なテーブルをリストすることができます:
.tables
osqueryに同梱されているパックにはさらに多くの例があり、その多くはosqueryd
によって定期的に実行されるように設計されています。 次のセクションでは、デーモンを起動してこれらのクエリを実行する方法を学習します。
ステップ6–osquerydを実行する
デーモンであるosqueryd
を使用すると、osqueryは設定された間隔でクエリを実行できます。 これらのクエリには、ステップ4で構成したもの、そのステップで指定したパック内のクエリ、およびステップ5で構成したFIMパック内のクエリが含まれます。 まだ勉強していない方は、/usr/share/osquery/packs
の内容をご覧ください。
osqueryd
によって生成された結果は、/var/log/osquery
ディレクトリのosqueryd.results.log
というファイルに書き込まれます。 箱から出して、そのファイルは存在しません。 デーモンが開始され、結果の生成を開始したときにのみ作成されます。
osqueryd
は、systemctl
またはosqueryctl
のいずれかを使用して開始できます。 どちらも同じことを行うので、どちらを使用してもかまいません。 osqueryd
は、起動時に構成ファイルの存在を確認し、構成ファイルが見つからない場合は警告します。 設定ファイルがなくても実行されたままになりますが、何の役にも立ちません。
ただし、すでに構成ファイルを設定しているので、ここで行う必要があるのはデーモンを起動することだけです。
sudo systemctl start osqueryd
または、次のように入力できます。
sudo osqueryctl start
デーモンを起動してから数分で、/var/log/osquery/osqueryd.results.log
のサイズが大きくなるはずです。 次のコマンドを入力して繰り返すことで、それが起こっていることがわかります。
ls -lh /var/log/osquery/osqueryd.results.log
ファイルのサイズが大きくなっているということは、スケジュールされたクエリの結果がディスクに書き込まれていることを示しています。 残念ながら、osqueryには OSSEC のようなアラート機能がないため、結果ファイルを表示しない限り、スケジュールされたクエリの結果を表示することはできません。 これは、tail
コマンドを使用して行うことができます。このコマンドは、そのファイルの最後の10行を画面に継続的にストリーミングします。
sudo tail -f /var/log/osquery/osqueryd.results.log
CTRL+C
を押して、ログのテーリングを停止します。
長期的には、クエリ結果ログを、操作可能な外部分析プラットフォームに送信することをお勧めします。 実行可能なオープンソースオプションには、 Doorman 、 Zentral 、およびElasticSearchが含まれます。
結論
osqueryは強力なツールであり、使い慣れたSQL構文を使用して1回限りのスケジュールされたクエリを実行するのに役立ちます。 osqueryi
は1回限りのクエリを作成するためのosqueryコンポーネントであり、osqueryd
はクエリをスケジュールするためのコンポーネントです。 スケジュールされたクエリの結果を理解するには、それらを外部のログ分析プラットフォームに送信する必要があります。 osqueryの詳細については、https://osquery.io/を参照してください。