14.3.1. logcheck
を使ったログ監視
logcheck
プログラムはデフォルトでは毎時間ログファイルを監視します。logcheck
はログメッセージを電子メールで管理者に送信し、さらなる解析を促します。
監視されるファイルのリストは /etc/logcheck/logcheck.logfiles
に保存されています。そして /etc/rsyslog.conf
ファイルが完全に書き換えられていなければ、デフォルト値でうまく動作します。
logcheck
の動作モードは 3 種類のうちの 1 つから選ぶことが可能です。具体的に言えば、paranoid、server、workstation から 1 つ選びます。paranoid モードはとても詳細で、このモードを使うのはファイアウォールなどの特定のサーバに限定するべきです。server モードはデフォルトで、ほとんどのサーバではこのモードを使うことを推奨します。workstation モードはワークステーション用に設計されており、かなり簡潔です (より多くのメッセージをフィルタします)。
管理者は毎時間のバッチ処理のたびに長くてつまらない電子メールを受け取ることを本当に望むのでなければ、3 つのモードすべてで 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 キー)、プロセス識別子 (N キー) などがあります。k キーに続けてプロセス識別子を入力することで、識別子に対応するプロセスを殺すことが可能です。r キーを使ってプロセスの renicing を行うことが可能です、つまり優先度を変更することが可能です。
システムの負荷が高過ぎる場合、top
という素晴らしいツールを使って、プロセッサ時間を奪っていたりメモリを大量に消費しているプロセスを調査します。特に、リソースを消費しているプロセスがそのマシンでホストされていることを知られている本物のサービスに一致しているか否かを確認することは興味深いです。www-data ユーザとして実行されている不明なプロセスは特に警戒して調査するべきです。なぜなら、その不明なプロセスはウェブアプリケーションの脆弱性を利用してシステムにインストールおよび実行されたソフトウェアのインスタンスかもしれないからです。
top
はとても柔軟性の高いツールで、マニュアルページは表示をカスタマイズする方法とそのカスタマイズの結果を個人的なニーズや習慣に反映させる方法を詳細に説明しています。
gnome-system-monitor
グラフィカルツールは top
とよく似ており、大ざっぱに言って同じ機能を備えています。
プロセッサの負荷、ネットワークトラフィック、空きディスク領域などの情報は絶えず変わります。これらの情報の時間変化を保存しておくと、コンピュータの使われ方を明らかにするために役立ちます。
このタスクには専用のツールがたくさんあります。ほとんどのツールは、この種の情報を中央に集めるために、SNMP (Simple Network Management Protocol) を介してデータを取得します。SNMP を使うことで、汎用的なコンピュータを除くネットワーク要素、たとえば専用ネットワークルータやスイッチ、からデータを取得することが可能になるという恩恵があります。
本書では、
第 12 章: 「高度な管理」の中で Munin を詳細に取り上げています (
第 12.4.1 節「Munin のセットアップ」を参照してください)。Debian は類似のツール
cacti を提供しています。cacti の配備は Munin よりも少し複雑です。なぜなら cacti はもっぱら SNMP に基づいているからです。ウェブインターフェースを持つにも関わらず、設定に必要な概念を理解するには少し努力が必要です。HTML 文書 (
/usr/share/doc/cacti/html/index.html
) を読了していることが前提条件として求められます。
システムのインストールと設定が完了したら、セキュリティアップグレードを行わない限りデータ以外のほとんどのファイルとディレクトリが変化する理由はありません。このため、ファイルが変化していないことを確認することは興味深いです。このため、ファイルに対する予想外の変化は調査に値します。この節では、ファイルに対する予想外の変化に備えて、ファイルを監視して管理者に警告する (または単純に変更をリストする) いくつかのツールを紹介します。
14.3.3.1. dpkg --verify
を使ったパッケージ監視
dpkg --verify
(または dpkg -V
) は興味深いツールで、(潜在的には攻撃者によって) 変更を加えられたインストール済みファイルを見つけることが可能ですが、その結果は疑ってかかるべきです。なぜなら 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 はパッケージから提供された SSH のサービスファイルが直接変更されていることを報告しています。一般に管理者はパッケージから提供された設定ファイル以外のファイルを直接編集するべきではありません。今回の場合ならば、改めて /etc/systemd/system/ssh.service
を作成し、これを編集するべきです (このファイルは一般に設定変更を配置すべき場所である /etc
ディレクトリの下に配置されます)。さらに、dpkg は設定ファイルとみなされた複数のファイルが修正されていることを報告しています (この場合、左から 2 番目のフィールドが「c」文字になります)。設定ファイルに対する修正は合法的と言えます。
14.3.3.2. パッケージの監査、debsums
とその限界
debsums
は dpkg -V
の祖先で、従ってほとんど使われていません。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) を使うことで、ファイルの完全性を確認したり、前回保存された正当なシステムのイメージに対する変更を検知したり、することが可能です。このイメージはデータベース (/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 の監視規則をダウンロードすることも可能です。