Product SiteDocumentation Site

14.3. 監督、防止、検出、監査

監視はいくつかの理由によっていかなるセキュリティポリシーにおいても不可欠な要素になっています。最たる理由はセキュリティの目標には通常データの機密性を保証するだけでなく、サービスの可用性を保証することも含まれているという理由です。そのため、すべてが想定通りに稼働しているかを確認したり、さまざまな逸脱した挙動や提供しているサービス品質の変化をタイミング良く検出したりすることが不可欠です。監視活動のおかげで、危機的状況に陥る前に不正侵入の試行を検出し迅速に対応することが可能です。この節では、Debian システムのさまざまな側面を監視するために使えるいくつかのツールを概説します。この節は第 12.4 節「監視」を補完する節です。

14.3.1. logcheck を使ったログ監視

logcheck プログラムはデフォルトでは毎時間ログファイルを監視します。logcheck は不審なログメッセージを電子メールで管理者に送信し、さらなる解析を促します。
監視対象ファイルのリストは /etc/logcheck/logcheck.logfiles に保存されています。/etc/rsyslog.conf ファイルが完全に書き換えられていない限り、デフォルト値でうまく動作します。
logcheck の動作モードには 3 種類あり、そのうちの 1 つを選びます。具体的に言えば、paranoidserverworkstation から 1 つ選びます。paranoid モードはとても詳細で、paranoid モードを使うのはファイアウォールなどの特定のサーバに限定するべきです。server モードはデフォルトで、多くのサーバでは server モードを使うことを推奨します。workstation モードはワークステーション用に設計されており、かなり簡潔です (より多くのメッセージを除外します)。
どの動作モードを選んだ場合でも、管理者は毎時間のバッチ処理のたびに長くてつまらない電子メールを受け取ることを本当に望むのでなければ、logcheck を (インストール済みサービスに基づき) カスタマイズしていくつかの余分なメッセージを除外するべきです。メッセージ選択ルールはかなり複雑なので、もし挑戦するなら /usr/share/doc/logcheck-database/README.logcheck-database.gz を読むと良いでしょう。
メッセージに対して適用されるルールは以下に示す種類に分類されます。
  • クラッキングの試行として分類するメッセージのルール (/etc/logcheck/cracking.d/ ディレクトリ内のファイルに保存します)。
  • クラッキングの試行として分類されたメッセージの分類を解除するメッセージのルール (/etc/logcheck/cracking.ignore.d/ ディレクトリ内のファイルに保存します)。
  • セキュリティ警告として分類するメッセージのルール (/etc/logcheck/violations.d/ ディレクトリ内のファイルに保存します)。
  • セキュリティ警告として分類されたメッセージの分類を解除するメッセージのルール (/etc/logcheck/violations.ignore.d/ ディレクトリ内のファイルに保存します)。
  • その他のメッセージに適用するルール (システムイベントとして分類されます)。
/etc/logcheck/ignore.d.{paranoid,server,workstation}/ ディレクトリ内のルールの 1 つによってシステムイベントが無視されなかった場合を除いて、常にシステムイベントは通知されます。もちろん、ここで考慮されるディレクトリは選択された動作モードの冗長性レベル以上の冗長性レベルに対応するディレクトリです。

14.3.2. 監視活動

14.3.2.1. リアルタイム監視

top は現在実行中のプロセスのリストを表示する対話型ツールです。デフォルトでは現在のプロセッサ使用量に基づいてソートされ、P キーを押すことで内容を更新することが可能です。他のソート基準として、専有メモリ量 (M キー)、総プロセッサ時間 (T キー)、プロセス ID (N キー) などがあります。k キーに続けてプロセス ID を入力することで、識別子に対応するプロセスを殺すことが可能です。r キーを使ってプロセスの renicing を行うことが可能です、つまり優先度を変更することが可能です。
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
top はとても柔軟性の高いツールで、top のマニュアルページでは表示をカスタマイズする方法とそのカスタマイズの結果を個人的なニーズや習慣に反映させる方法が詳細に説明されています。
gnome-system-monitor グラフィカルツールは top とよく似ており、大ざっぱに言って top と同じ機能を備えています。

14.3.2.2. 履歴

プロセッサの負荷、ネットワークトラフィック、空きディスク領域などの情報は絶えず変化します。これらの情報の経時変化を保存しておけば、コンピュータの使われ方を明らかにする際に役立ちます。
時間変化する情報の保存には専用のツールがたくさんあります。多くのツールは、この種の情報を一元管理するために、SNMP (Simple Network Management Protocol) を介してデータを取得します。SNMP を使うことで、汎用的なコンピュータを除くネットワーク要素 (たとえば専用ネットワークルータやスイッチ) からデータを取得することが可能になるという恩恵があります。
This book deals with Munin in some detail (see 第 12.4.1 節「Munin のセットアップ」) as part of 第 12 章: 「高度な管理. Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

14.3.3. Avoiding Intrusion

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log in to an unauthorised software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force atack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attemps to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban:
  • fail2ban.conf. Global configuration (such as logging).
  • filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
  • action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.
  • jail.conf. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime  = 10m
[...]
maxretry = 5
[...]
[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths_common.conf. If Fail2Ban detects five failed login attempts in a row, it will ban the IP address where those attempts originated.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. 変更検出

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.1. dpkg --verify を使ったパッケージ監視

dpkg --verify (または dpkg -V) は興味深いツールで、(潜在的には攻撃者によって) 変更を加えられたインストール済みファイルを見つけることが可能です。しかしながら、dpkg --verify の結果は疑ってかかるべきです。なぜなら dpkg --verify は変更されたファイルを検出するために dpkg 自身のデータベースに保存されたチェックサムを使っており、このデータベースはハードディスク上 (/var/lib/dpkg/info/package.md5sums) に保存されているからです。このため、完璧主義の攻撃者なら改竄したファイルに対応する新しいチェックサムを使ってデータベースファイルを更新するでしょう。
dpkg -V を実行すると、すべてのインストール済みパッケージが検証され、テストに失敗したファイルが行ごとに表示されます。出力フォーマットは rpm -V が採用しているフォーマットと同じで、行頭の各文字は特定のメタデータに対するテストの結果を意味しています。残念なことに dpkg は多くのテストに必要なメタデータを保存しません。これらのメタデータを必要とするテストの結果は常に疑問符が出力されることになります。今のところ実行できるテストはチェックサムテストだけで、チェックサムテストに失敗した場合、左から 3 番目の文字が「5」になります。
# dpkg -V
??5??????   /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
上の例では、dpkg は Debian パッケージから提供された SSH の service ファイルが直接編集されていることを報告しています。一般に管理者は Debian パッケージから提供された設定ファイル以外のファイルを直接編集するべきではありません。今回の場合ならば、もう一度 /etc/systemd/system/ssh.service を作成し、これを編集するべきです (このファイルは一般に設定変更を配置すべき場所である /etc ディレクトリの下に配置されます)。さらに、dpkg は設定ファイルとみなされた複数のファイルが修正されていることを報告しています (この場合、左から 2 番目のフィールドが「c」という文字になります)。設定ファイルに対する修正は合法的と言えます。

14.3.4.2. パッケージの監査、debsums とその限界

debsumsdpkg -V の祖先です。このため、debsums はほとんど使われていません。debsums と dpkg は同じ制限に悩まされています。幸いなことに、debsums はいくつかの制限を回避することが可能です (一方で dpkg には同様の回避策がありません)。
ディスク上のデータは信頼できないため、debsums は dpkg データベースではなく .deb ファイルに基づいてテストを行う機能を提供しています。すべてのインストール済みパッケージに対応する信頼できる .deb ファイルをダウンロードするには、APT の認証付きダウンロード機構を使います。この操作は遅くて退屈ですから、この操作を定期的かつ積極的に使う手法として考えるべきではありません。
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
この例の中で、デフォルトではインストールされない dctrl-tools パッケージに含まれる grep-status コマンドが使われている点に注意してください。
debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpuse or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. ファイル監視、AIDE

AIDE ツール (Advanced Intrusion Detection Environmentaide パッケージに含まれます) を使うことで、ファイルの完全性を確認したり、事前に保存された正当なシステムのイメージに対する変更を検出したりすることが可能です。このイメージはシステムのすべてのファイルに対して関連する情報 (指紋、パーミッション、タイムスタンプなど) を記録するデータベース (/var/lib/aide/aide.db) に保存されます。このデータベースは最初に aideinit を使って初期化されます。そして毎日、関係のある情報が何も変更されていないことを確認するために、このデータベースは /etc/cron.daily/aide スクリプトから使われます。変更が検出されたら、AIDE は変更内容をログファイル (/var/log/aide/*.log) に記録し、検出された変更内容を管理者にメールで送信します。
/etc/default/aide に含まれる多くのオプションを使って aide パッケージの挙動を微調整します。AIDE 設定は /etc/aide/aide.conf/etc/aide/aide.conf.d/ に保存されています (実質的に言えば、これらのファイルは update-aide.conf/var/lib/aide/aide.conf.autogenerated を生成するためだけに使われます)。設定は確認する必要のあるファイルの属性の種類を指定します。たとえば、ログファアイルの内容は定期的に変わりますが、この種の変更はファイルのパーミッションが同じなら無視することが可能です。しかし、実行プログラムの内容とパーミッションの両方は必ず同じでなければいけません。設定の構文は、とても複雑というわけではありませんが、十分に直感的というわけでもありません。aide.conf(5) マニュアルページを読むことを推奨します。
データベースの新しいバージョンは毎日生成され、/var/lib/aide/aide.db.new に保存されます。そして、すべての記録された変更が正当ならば、参照データベースを新しいデータベースに置き換えることが可能です。

14.3.5. 侵入検知 (IDS/NIDS)

suricata (in the Debian package of the same name) is a NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.
suricata を設定するには /etc/suricata/suricata-debian.yaml をよく読んで編集します。それぞれのパラメータはこのファイルの中で詳細に説明されているため、このファイルはとても長いものです。最低限の設定を行うには、HOME_NET パラメータでローカルネットワークのカバーするアドレス範囲を指定する必要があります。実際のところ HOME_NET パラメータは潜在的に攻撃される可能性を持つすべてのネットワークを意味しています。しかし設定パラメータのほとんどを理解するには、パラメータの説明をすべて読み、パラメータをそれぞれの状況に適応させることが必要です。
加えて、監視対象のネットワークインターフェースを定義して init スクリプトを有効化する (RUN=yes と設定する) ために、/etc/default/suricata を編集するべきです。また、管理者は LISTENMODE=pcap のように設定したいと思うかもしれません。なぜなら、デフォルト設定である LISTENMODE=nfqueue を適切に動かすためには、さらに設定を行う必要があるからです (netfilter ファイアウォールの NFQUEUE 動作を使って suricata が取り扱う一部のユーザ空間キュー宛のパケットを通過するように、ファイアウォールを設定しなければいけません)。
To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.
代案として、oinkmaster (同名のパッケージに含まれます) を使って外部ソースから Snort の監視規則をダウンロードすることも可能です。