開発者ドキュメント

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

getdocs

序章

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

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

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

前提条件

このチュートリアルを完了するには、次のものを用意する必要があります。

また、SQLの基本的な知識と、Linuxシステムのセキュリティに関する基本的な知識も必要です。

ステップ1-サーバーへのosqueryのインストール

osqueryは、ソースからコンパイルするか、パッケージマネージャーを使用してインストールできます。 公式のUbuntuリポジトリにはインストール可能なパッケージがないため、プロジェクトの公式のUbuntuリポジトリをシステムに追加する必要があります。

まず、リポジトリの公開鍵を追加します。

  1. sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B

次に、リポジトリを追加します。

  1. sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"

パッケージデータベースを更新します。

  1. sudo apt-get update

最後に、osqueryをインストールします。

  1. sudo apt-get install osquery

箱から出して、osqueryは信じられないほど便利ではありません。 プラグアンドプレイアプリケーションではありません。 対話型シェルまたはデーモンのどちらを使用する場合でも、コマンドラインまたは構成ファイルを介して、いくつかのフラグとオプションを渡す必要があります。 デーモンで使用可能なフラグとオプションを表示するには、次のように入力します。

  1. osqueryd --help

出力には、数十のコマンドラインフラグと構成オプションが含まれます。 以下に示すのは、この記事で使用したテストサーバーからの部分的な出力です。

Output
osquery 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

対話型シェルでのみ使用可能な追加のコマンドラインフラグを表示するには、次のように入力します。

  1. osqueryi --help

osqueryiを実行することは、箱から出して利用可能なosqueryテーブルを一覧表示およびクエリするための最も簡単な方法です。 例として、次のコマンドを使用して起動します。

  1. osqueryi --verbose

これにより、インタラクティブシェルに配置され、次のような出力が表示されます。

Output
I0105 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 ;などの他のクエリは、次のようなメッセージを返します。これは、実行する必要のある作業がまだあることを示します。

Output
W1202 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

この問題を解決するために、サーバーの構成にいくつかの変更を加えます。

次のように入力して、コンソールを終了します。

  1. .exit

次のセクションでは、osqueryが正しく機能するために必要なオペレーティングシステムの側面を変更します。

ステップ2–osqueryがシステムログにアクセスできるようにする

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

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

  1. sudo nano /etc/rsyslog.conf

どのパイプに書き込むか、どのsyslogパラメーターをそのパイプに書き込むかをRsyslogに指示する構成行をいくつか追加する必要があります。 デフォルトでは、パイプは/var/osquery/syslog_pipeです。 次に、osqueryは、そのパイプに書き込まれた情報からsyslogテーブルにデータを入力します。

次の行をファイルに追加します。

/etc/rsyslog.conf
template(
  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デーモンを再起動します。

  1. sudo systemctl restart rsyslog

次に、いくつかのデフォルトオプションを設定し、いくつかのクエリをスケジュールする構成ファイルを作成しましょう。

ステップ3–osquery構成ファイルの作成

構成ファイルを作成すると、osqueryiの実行が簡単になります。 osqueryiは、多くのコマンドラインオプションを渡す代わりに、/etc/osquery/osquery.confにある構成ファイルからそれらのオプションを読み取ることができます。 そしてもちろん、構成ファイルはデーモンでも利用できます。

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

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

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

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

osqueryiおよびosquerydで使用できるすべてのコマンドラインフラグと構成オプションを表示する方法はすでに説明しましたが、このサーバーでosqueryを実行するには上記のオプションで十分です。

次のコマンドを使用して、構成ファイルを作成して開きます。

  1. 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"
  }
}

ファイルを保存して閉じ、次のコマンドを使用して検証します。

  1. sudo osqueryctl config-check

出力は次のようになります。

Output
I0104 11:11:46.022858 24501 rocksdb.cpp:187] Opening RocksDB handle: /var/osquery/osquery.db

エラーが発生した場合は、エラーの場所が出力に表示されるため、修正できます。

有効な構成ファイルを入手したら、ファイルの整合性の監視に必要なosqueryパックの構成に進むことができます。

ステップ4–osqueryファイル整合性監視パックの設定

サーバー上のファイルの整合性を注意深く監視することは、サーバーのシステムセキュリティを監視する上で重要な側面です。 この目的のために、osqueryはすぐに使えるソリューションを提供します。

前のセクションで構成に追加したパックは、箱から出して出荷されます。 このセクションでは、リストにもう1つのパックを追加します。このパックには、ファイルの整合性の監視に使用されるクエリとディレクティブが含まれています。 この演習では、ファイルをfim.confと呼びます。

このファイルを作成し、エディターで開きます。

  1. 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の最後にあるパックリストでそのファイルを参照します。 編集用にファイルを開きます。

  1. 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"
  }

ファイルを保存して閉じます。 また、ファイルに間違いがないことを確認するために、もう一度検証してください。

  1. sudo osqueryctl config-check

それでは、osqueryiを使用してシステムにクエリを実行してみましょう。

ステップ5–osqueryiを使用してアドホックセキュリティチェックを実行する

osqueryが役立つ場所はたくさんあります。 このセクションでは、インタラクティブシェルであるosqueryiを使用して、システムでさまざまなセキュリティチェックを実行します。 この時点では、まだosqueryデーモンを起動していないことに注意してください。 これがosqueryの優れた点です。デーモンがアクティブでない場合でも、環境を構成するために作成した構成ファイルを使用しながら、osqueryiを使用してクエリを実行できます。

構成ファイルを使用してosqueryを起動するには、次のように入力します。

  1. sudo osqueryi --config_path /etc/osquery/osquery.conf --verbose

注：osqueryiおよびosqueryd verbose オプションを渡すと、osqueryの問題を示す可能性のあるエラーまたは警告を確認できるため、良い習慣です。 。 通常、osqueryiはroot権限なしで実行できますが、デーモンの構成ファイルを指定して呼び出す場合は、rootとして実行する必要があります。

基本的なセキュリティチェックから始めて、そこから上に進んでいきましょう。 たとえば、あなた以外の誰が今システムにログインしていますか？ このクエリで調べてください：

  1. 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テーブルをクエリすることで確認できます。

  1. 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      |
+----------+-------+------+------+------------+------------------+

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

  1. select * from iptables ;

出力がない場合は、IPTablesファイアウォールが構成されていないことを意味します。 インターネットに接続するサーバーの場合、これは良くないことなので、ファイアウォールを構成する方が適切です。

次のように、特定の列でフィルタリングするように変更された前のコマンドを実行できます。

  1. 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ではどのような種類のジョブがスケジュールされていますか？ それらをスケジュールしましたか？ このクエリは、特定の間隔で実行するようにスケジュールされているマルウェアを見つけるのに役立ちます。

  1. 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サーバーにはかなりの数がありますが、どれがそれらであり、システム上にあるはずのないものはありますか？ これらの質問への回答は、バックドアされたバイナリを検出するのに役立ちます。 このクエリを定期的に実行し、その結果を古い結果と比較して、追加を監視できるようにします。 そのクエリは次のとおりです。

  1. 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           |

ロードされたカーネルモジュールのリストを表示するには、次のクエリを実行します。

  1. select name, used_by, status from kernel_modules where status="Live" ;

これは、定期的に実行し、その出力を古い結果と比較して、何かが変更されているかどうかを確認するためのもう1つのクエリです。

サーバー上のバックドアを見つけるのに役立つさらに別の方法は、すべてのリスニングポートを一覧表示するクエリを実行することです。 これを行うには、次のクエリを実行します。

  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      |         |
+-------+------+----------+--------+---------+

サーバー上で、サーバーがリッスンする必要があることがわかっているポートのみが出力に含まれている場合は、心配する必要はありません。 ただし、他のポートが開いている場合は、それらのポートが何であるかを調査する必要があります。

サーバー上のファイルアクティビティを確認するには、次のクエリを実行します。

  1. 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    |
+---------------------------+---------+------+

考えられるセキュリティの問題を把握するためにサーバーで実行できるクエリのようなものはたくさんあります。

テーブルのスキーマがわからない場合は、次のコマンドを使用して調べてください。

  1. .schema name-of-table

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

  1. .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は、起動時に構成ファイルの存在を確認し、構成ファイルが見つからない場合は警告します。 構成ファイルがなくても実行されたままになりますが、何の役にも立ちません。

ただし、すでに構成ファイルを設定しているので、ここで行う必要があるのはデーモンを起動することだけです。

  1. sudo systemctl start osqueryd

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

  1. sudo osqueryctl start

デーモンを起動してから数分で、/var/log/osquery/osqueryd.results.logのサイズが大きくなるはずです。 次のコマンドを入力して繰り返すことで、それが起こっていることがわかります。

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

ファイルのサイズが大きくなっているということは、スケジュールされたクエリの結果がディスクに書き込まれていることを示しています。 残念ながら、osqueryには OSSEC のようなアラート機能がないため、結果ファイルを表示しない限り、スケジュールされたクエリの結果を表示することはできません。 これは、tailコマンドを使用して行うことができます。このコマンドは、そのファイルの最後の10行を画面に継続的にストリーミングします。

  1. 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/を参照してください。

モバイルバージョンを終了