14.3.1. logcheck を使ったログ監視
logcheck プログラムはデフォルトでは毎時間ログファイルを監視します。logcheck は不審なログメッセージを電子メールで管理者に送信し、さらなる解析を促します。
監視対象ファイルのリストは /etc/logcheck/logcheck.logfiles に保存されています。/etc/rsyslog.conf ファイルが完全に書き換えられていない限り、デフォルト値でうまく動作します。
logcheck の動作モードには 3 種類あり、そのうちの 1 つを選びます。具体的に言えば、paranoid、server、workstation から 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 つによってシステムイベントが無視されなかった場合を除いて、常にシステムイベントは通知されます。もちろん、ここで考慮されるディレクトリは選択された動作モードの冗長性レベル以上の冗長性レベルに対応するディレクトリです。
top は現在実行中のプロセスのリストを表示する対話型ツールです。デフォルトでは現在のプロセッサ使用量に基づいてソートされ、P キーを押すことで内容を更新することが可能です。他のソート基準として、専有メモリ量 (M キー)、総プロセッサ時間 (T キー)、プロセス ID (N キー) などがあります。k キーに続けてプロセス ID を入力することで、識別子に対応するプロセスを殺すことが可能です。r キーを使ってプロセスの renicing を行うことが可能です、つまり優先度を変更することが可能です。
システムの負荷が高過ぎる場合、top はプロセッサ時間を奪っていたりメモリを大量に消費しているプロセスを調査する素晴らしいツールになります。特に、リソースを消費しているプロセスがそのマシンでホストされる本物のサービスにふさわしいものであるか否かを確認することは興味深い作業と言えます。www-data ユーザとして実行されている不明なプロセスは特に警戒して調査するべきです。なぜなら、その不明なプロセスはウェブアプリケーションの脆弱性を利用してシステムにインストールおよび実行されたソフトウェアのインスタンスかもしれないからです。
top はとても柔軟性の高いツールで、top のマニュアルページでは表示をカスタマイズする方法とそのカスタマイズの結果を個人的なニーズや習慣に反映させる方法が詳細に説明されています。
gnome-system-monitor グラフィカルツールは top とよく似ており、大ざっぱに言って top と同じ機能を備えています。
プロセッサの負荷、ネットワークトラフィック、空きディスク領域などの情報は絶えず変化します。これらの情報の経時変化を保存しておけば、コンピュータの使われ方を明らかにする際に役立ちます。
時間変化する情報の保存には専用のツールがたくさんあります。多くのツールは、この種の情報を一元管理するために、SNMP (Simple Network Management Protocol) を介してデータを取得します。SNMP を使うことで、汎用的なコンピュータを除くネットワーク要素 (たとえば専用ネットワークルータやスイッチ) からデータを取得することが可能になるという恩恵があります。
本書では、
第 12 章: 「高度な管理」の中で Munin が詳細に取り上げられています (
第 12.4.1 節「Munin のセットアップ」を参照してください)。さらに Debian には類似のツールである
cacti が含まれます。cacti の配備は Munin よりも少し複雑です。なぜなら cacti は SNMP だけに基づいているからです。cacti にはウェブインターフェースが用意されていますが、設定に必要な概念を理解するには少し努力が必要です。事前に HTML 文書 (
/usr/share/doc/cacti/html/index.html) を読んでおくことを推奨します。
システムのインストールと設定が完了したら、セキュリティアップグレードを行わない限りデータ以外のほとんどのファイルとディレクトリが変化する理由はありません。このため、ファイルが変化していないことを確認することは興味深いです。すなわち、ファイルに対する予想外の変化は調査に値します。この節では、ファイルに対する予想外の変化に備えて、ファイルを監視して管理者に警告する (または単純に変更をリストする) いくつかのツールを紹介します。
14.3.3.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.3.2. パッケージの監査、debsums とその限界
debsums は dpkg -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 コマンドが使われている点に注意してください。
AIDE ツール (Advanced Intrusion Detection Environment、aide パッケージに含まれます) を使うことで、ファイルの完全性を確認したり、事前に保存された正当なシステムのイメージに対する変更を検出したりすることが可能です。このイメージはシステムのすべてのファイルに対して関連する情報 (指紋、パーミッション、タイムスタンプなど) を記録するデータベース (/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 に保存されます。そして、すべての記録された変更が正当ならば、参照データベースを新しいデータベースに置き換えることが可能です。
suricata (同名の Debian パッケージに含まれます) は NIDS すなわち
ネットワーク型侵入検知システムです。NIDS の機能はネットワークをリッスンして侵入試行および敵対行為 (サービス妨害攻撃も含まれます) を検出しようとします。すべてのイベントは
/var/log/suricata 内の複数のファイルに記録されます。収集されたすべてのデータを閲覧するためのサードパーティツール (Kibana/logstash) が存在します。
suricata を設定するには /etc/suricata/suricata-debian.yaml をよく読んで編集します。それぞれのパラメータはこのファイルの中で詳細に説明されているため、このファイルはとても長いものです。最低限の設定を行うには、HOME_NET パラメータでローカルネットワークのカバーするアドレス範囲を指定する必要があります。実際のところ HOME_NET パラメータは潜在的に攻撃される可能性を持つすべてのネットワークを意味しています。しかし設定パラメータのほとんどを理解するには、パラメータの説明をすべて読み、パラメータをそれぞれの状況に適応させることが必要です。
加えて、監視対象のネットワークインターフェースを定義して init スクリプトを有効化する (RUN=yes と設定する) ために、/etc/default/suricata を編集するべきです。また、管理者は LISTENMODE=pcap のように設定したいと思うかもしれません。なぜなら、デフォルト設定である LISTENMODE=nfqueue を適切に動かすためには、さらに設定を行う必要があるからです (netfilter ファイアウォールの NFQUEUE 動作を使って suricata が取り扱う一部のユーザ空間キュー宛のパケットを通過するように、ファイアウォールを設定しなければいけません)。
不正行為を検出するためには、suricata に一連の監視規則を設定する必要があります。いくつかの監視規則は snort-rules-default パッケージに含まれています。snort は IDS エコシステムにおける歴史的な基準ソフトウェアで、suricata は snort 向けに書かれた監視規則を再利用することが可能です。残念なことに snort-rules-default パッケージは Debian Jessie には含まれません。このため、snort-rules-default パッケージを入手するにはテスト版か不安定版などの他の Debian リリースを使ってください。
代案として、oinkmaster (同名のパッケージに含まれます) を使って外部ソースから Snort の監視規則をダウンロードすることも可能です。
