TOC

Ubuntu 16.04でosqueryを使用してシステムセキュリティを監視する方法

前書き

osqueryは、オペレーティングシステムを1つの巨大なデータベースに変換し、SQLのようなステートメントを使用してクエリを実行できるテーブルを備えたオープンソースのセキュリティツールです。 これらのクエリを使用すると、ファイルの整合性を監視し、ファイアウォールのステータスと構成を確認し、ターゲットサーバーのセキュリティ監査を実行できます。

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 `は独立したツールです。 彼らは通信しません、そして、あなたは他なしで1つを使うことができます。 それぞれの実行に必要なフラグとオプションのほとんどは同じであり、 ` osqueryd `の設定ファイルを使用して ` osqueryi +`を起動できるため、多くのコマンドラインスイッチを使用せずに環境をカスタマイズできます。

このチュートリアルでは、次のことを行います。

  • osqueryをインストールします。

  • osqueryが適切に機能するために必要な、Rsyslogなどのオペレーティングシステムの側面を構成します。

  • `+ osqueryi `と ` osqueryd +`の両方で使用できる設定ファイルを設定します。

  • osquery _packs_は、スケジュールに追加できる定義済みクエリのグループです。

  • `+ osqueryi +`を使用してアドホッククエリを実行し、セキュリティの問題を探します。

  • デーモンを起動して、クエリを自動的に実行できるようにします。

デーモンである `+ osqueryd +`によって生成されたログは、適切に設定して使用するために追加の専門知識を必要とする外部ロギングエンドポイントに出荷されることを目的としています。 このチュートリアルではその構成については説明しませんが、デーモンを構成して実行し、結果をローカルに保存する方法を学習します。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • sudo特権とファイアウォールを持つ非rootユーザーで構成されたUbuntu 16.04サーバー。 これを設定するには、https：//www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [Ubuntu 16.04の初期セットアップガイド]に従ってください。

また、SQLの基本的な知識とhttps://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps[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; + wのような特定のクエリは何も返さず、テーブルにデータが入力されていないことを示します。

「+ select時間、重大度、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がシステムログにアクセスできるようにする

このステップでは、osqueryがシステムログを消費および照会できるように、オペレーティングシステムのsyslogアプリケーションを変更します。 Ubuntu 16.04では、Rsyslog構成ファイルを変更することを意味します。 必要な変更は、構成ファイルに数行のコードを追加することだけです。

まず、 `+ / etc / rsyslog.conf +`ファイルを開きます：

sudo nano /etc/rsyslog.conf

Rsyslogに書き込むパイプ、およびそのsyslogに書き込むsyslogパラメーターを指示する構成行をいくつか追加する必要があります。 デフォルトでは、パイプは `+ / 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 +`にある設定ファイルからそれらのオプションを読み取ることができます。 そしてもちろん、構成ファイルもデーモンで利用可能になります。

構成ファイルには、スケジュールに従って実行する必要があるクエリも含まれています。 ただし、スケジュールに従って実行できるクエリのほとんどは、_packs_と呼ばれるものとして出荷されます。 パックは、 `+ / usr / share / osquery / packs +`ディレクトリにあるファイルです。

osqueryには設定ファイルは付属していませんが、 `+ / etc / osquery +`にコピーして変更できるサンプルの設定ファイルがあります。 ただし、そのファイルには、UbuntuなどのLinuxディストリビューションで実行するために必要なすべてのオプションがないため、独自のファイルを作成します。

構成ファイルには3つのセクションがあります。

  • デーモンオプションと機能設定のリスト。 これらは `+ osqueryi +`でも読むことができます。

  • 実行するスケジュールされたクエリと実行するタイミングのリスト。

  • より具体的なスケジュールされたクエリを実行するために使用されるパックのリスト。

以下は、構成ファイルに使用するオプション、それらの意味、および設定する値のリストです。 このオプションのリストは、Ubuntu 16.04およびその他のLinuxディストリビューションで + osquery`および + osquery`を実行するのに十分です。

  • * 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

設定ファイルはhttps://www.digitalocean.com/community/tutorials/an-introduction-to-json[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
   }







 },

スケジュールされたクエリの後に、* decorators *と呼ばれる特別なクエリを追加できます。これは、他のスケジュールされたクエリの前にデータを追加するクエリです。 ここに示すデコレータクエリは、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": {

    "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

基本的なセキュリティチェックから始めて、そこから先に進みましょう。 たとえば、現在システムにログインしているのはあなた以外の誰ですか？ このクエリで調べる：

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      |      | pts/0 |       | 1483580584 | 1752 |
| user      |     | pts/1 |       | 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 |                  |
|      | pts/0 | 1752 | 7    | 1483580584 |       |
|     | pts/1 | 4057 | 7    | 1483580770 |       |
+----------+-------+------+------+------------+------------------+

ファイアウォールは構成され、アクティブ化されていますか？ ファイアウォールはまだ実行されていますか？ 疑わしい場合は、次のクエリを実行して確認してください。

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

そして、あなたは利用可能なテーブルをリストすることができます：

.tables

osqueryに同梱されているパックにはさらに多くの例があり、多くは `+ osqueryd +`によって定期的に実行されるように設計されています。 次のセクションでは、これらのクエリを実行するためにデーモンを起動する方法を学びます。

ステップ6 – osquerydの実行

デーモンである `+ osqueryd `を使用すると、osqueryは設定された間隔でクエリを実行できます。 これらのクエリには、手順4で構成したクエリ、その手順で指定したパック内のクエリ、および手順5で構成したFIMパック内のクエリが含まれます。 それらをまだ学習していない場合は、今が ` / usr / share / osquery / packs +`の内容を見る良い機会です。

`+ osqueryd `によって生成された結果は、 ` / var / log / osquery `ディレクトリの ` osqueryd.results.log +`というファイルに書き込まれます。 デフォルトでは、そのファイルは存在しません。 デーモンの起動時にのみ作成され、結果の生成を開始します。

`+ systemctl `または ` osqueryctl `を使用して、 ` osqueryd `を起動できます。 どちらも同じことを達成するため、どちらを使用しても問題ありません。 ` osqueryd +`は起動時に設定ファイルの存在を確認し、見つからない場合は警告します。 構成ファイルなしで実行されたままになりますが、何の役にも立ちません。

ただし、すでに構成ファイルをセットアップしているため、ここで必要なことはデーモンを開始することだけです。

sudo systemctl start osqueryd

または、次のように入力できます。

sudo osqueryctl start

デーモンの起動後数分で、 `+ / var / log / osquery / osqueryd.results.log +`のサイズが増加するはずです。 次のコマンドを入力して繰り返すことで、その発生を確認できます。

ls -lh /var/log/osquery/osqueryd.results.log

ファイルのサイズの増加は、スケジュールされたクエリの結果がディスクに書き込まれていることを示しています。 残念ながら、osqueryにはhttps://www.digitalocean.com/community/tutorials?q=ossec[OSSEC]のようなアラート機能がないため、結果ファイルを表示しない限り、スケジュールされたクエリの結果を表示できません。 `+ tail +`コマンドでそれを行うことができます。これは、そのファイルの最後の10行を画面に連続的にストリーミングします：

sudo tail -f /var/log/osquery/osqueryd.results.log

ログの末尾を止めるには、 `+ CTRL + C +`を押します。

長期的には、作業できる外部分析プラットフォームにクエリ結果ログを出荷する必要があります。 実行可能なオープンソースオプションには、https：//github.com/mwielgoszewski/doorman [Doorman]、https：//github.com/apfelwerk/Zentral/wiki [Zentral]、およびhttps://www.elastic.co/products/が含まれます。 elasticsearch [ElasticSearch]。

結論

osqueryは強力なツールであり、使い慣れたSQL構文を使用して1回限りのスケジュールされたクエリを実行するのに便利です。 `+ osqueryi `は1回限りのクエリを記述するためのosqueryコンポーネントであり、 ` osqueryd +`はクエリをスケジュールするためのものです。 スケジュールされたクエリの結果を理解するには、それらを外部のログ分析プラットフォームに出荷する必要があります。 osqueryの詳細については、https：//osquery.io [https://osquery.io/]を参照してください。

Related