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
独立したツールです。 それらは通信せず、一方を他方なしで使用できます。 それぞれを実行するために必要なフラグとオプションのほとんどは同じであり、起動できます osqueryi
を使用して osqueryd
の構成ファイル。これにより、多くのコマンドラインスイッチを使用せずに環境をカスタマイズできます。
このチュートリアルでは、次のことを行います。
- 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
. - 実行するようにスケジュールされたクエリのリストと、それらをいつ実行する必要があるか。
- より具体的なスケジュールされたクエリを実行するために使用されるパックのリスト。
以下は、構成ファイルに使用するオプション、それらの意味、およびそれらに設定する値のリストです。 このオプションのリストは、実行するのに十分です osqueryi
と osqueryd
Ubuntu16.04およびその他のLinuxディストリビューション。
- 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形式を使用します。 次のコンテンツをファイルにコピーします。
{
"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"
},
構成ファイルの次の部分は、スケジューリングセクションです。 各クエリは、ファイル内で一意である必要があるキーまたは名前で識別され、その後に実行するクエリと、クエリを実行する間隔(秒単位)が続きます。 を調べるスケジュールされたクエリを追加します crontab
300秒ごとにテーブル。
次の行を構成ファイルに追加します。
"schedule": {
"crontab": {
"query": "SELECT * FROM crontab;",
"interval": 300
}
},
クエリはいくつでも記述できます。 正しい形式を維持してください。 そうしないと、ファイルの検証に失敗します。 たとえば、さらにいくつかのクエリを追加するには、次の行を追加します。
"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とユーザーのユーザー名を付加します。
次の行をファイルに追加します。
"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
ディレクトリ。
これらの行をファイルに追加して、ファイルを完成させます。
"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"
}
}
ファイルの最初の行の開始中括弧と一致する、最後の終了中括弧に注意してください。 完成した構成ファイルは次のようになります。
{
"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 ;
ポートでSSHのみが実行されている新しいサーバー 22
、出力は次のようになります。
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
と呼ばれるファイルに書き込まれます osqueryd.results.log
の中に /var/log/osquery
ディレクトリ。 箱から出して、そのファイルは存在しません。 デーモンが開始され、結果の生成を開始したときにのみ作成されます。
始めることができます 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/を参照してください。