Product SiteDocumentation Site

14.3. 監督: 防止、検知、監査

監視は幾つかの理由によってセキュリティポリシーの不可欠な要素になっています。中でも、セキュリティの目標には、通常データの機密性を保証するだけでなく、サービスの可用性を保証する事も含まれています。そのため、すべてが思った通り稼働しているかを確認したり、様々な逸脱した挙動や提供しているサービス品質の変化をタイミング良く検知したり、する事が不可欠です。監視活動のお陰で、危機的状況に陥る前に、不正侵入の試行を検知し迅速に対応する事が可能です。この節では、Debian システムの様々な側面を監視するために使える幾つかのツールを概説します。この節は 12章高度な管理内の一般的なシステム監視について書かれた節を補完するものです。

14.3.1. logcheck を使ったログ監視

logcheck プログラムはデフォルトでは毎時間ログファイルを監視します。logcheck はログメッセージを電子メールで管理者に送信し、さらなる解析を促します。
監視されるファイルのリストは /etc/logcheck/logcheck.logfiles に保存されています; /etc/syslog.conf ファイルが完全に書き換えられていなければ、デフォルト値で上手く動作します。
logcheck の動作モードは 3 種類の内の 1 つから選ぶ事が可能です: paranoidserverworkstation です。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 つによってシステムイベントが無視されなかった場合を除いて、常にシステムイベントは通知されます。もちろん、ここで考慮されるディレクトリは、選択された動作モードの冗長性レベル以上の冗長性レベルに対応するディレクトリです。

14.3.2. 監視活動

14.3.2.1. リアルタイム監視

top は現在実行中のプロセスのリストを表示する対話型ツールです。デフォルトでは現在のプロセッサ使用量に基いてソートされ、 P キーを押すことで内容を更新する事が可能です。他のソート基準として、占有メモリ量 (M キー)、総プロセッサ時間 (T キー)、プロセス識別子 (N キー) などがあります。k キーに続けてプロセス識別子を入力することで、識別子に対応するプロセスを殺す事が可能です。r キーを使ってプロセスの renicing を行う事が可能です、つまり優先度を変更する事が可能です。
システムの負荷が高過ぎる場合、top という素晴らしいツールを使って、プロセッサ時間を奪っていたりメモリを大量に消費しているプロセスを調査します。特に、リソースを消費しているプロセスがそのマシンでホストされている事を知られている本物のサービスに一致しているか否かを確認することは興味深いです。www-data ユーザとして実行されている不明なプロセスは特に警戒して調査するべきです。なぜなら、その不明なプロセスはウェブアプリケーションの脆弱性を利用してシステムにインストールおよび実行されたソフトウェアのインスタンスかもしれないからです。
top はとても柔軟性の高いツールで、マニュアルページは表示をカスタマイズする方法とそのカスタマイズの結果を個人的なニーズや習慣に反映させる方法を詳細に説明しています。
gnome-system-monitorqps グラフィカルツールは top とよく似ており、大まかに言って同じ機能を備えています。

14.3.2.2. 歴史

プロセッサの負荷、ネットワークトラフィック、空きディスク領域などの情報は絶えず変わります。これらの情報の時間変化を保存しておくと、コンピュータの使われ方を明らかにするためには便利です。
このタスクには専用のツールが沢山あります。ほとんどのツールは、この種の情報を中央に集めるために、SNMP (Simple Network Management Protocol) を介してデータを取得します。SNMP を使うことで、汎用コンピュータ以外のネットワーク要素、例えば専用ネットワークルータやスイッチ、からデータを取得する事が可能になるという恩恵があります。
この本では、第12章: 「高度な管理 の中で Munin を詳細にを取り上げています (「Munin のセットアップ」参照)。Debian は類似のツール cacti を提供しています。cacti の配備は Munin よりも少し複雑です。なぜなら cacti はもっぱら SNMP に基いているからです。ウェブインターフェースを持つにも関わらず、設定に必要な概念を理解するには少し努力が必要です。HTML 文書 (/usr/share/doc/cacti/html/index.html) を読了している事が前提条件として求められます。

14.3.3. 変更検知

システムのインストールと設定が完了したら、セキュリティアップグレードを行わない限りデータ以外のほとんどのファイルとディレクトリが変化する理由はありません。このため、ファイルが変化していない事を確認することは興味深いです。このため、ファイルに対する予想外の変化は調査に値します。この節では、ファイルに対する予想外の変化に備えて、ファイルを監視して管理者に警告する (または単純に変更をリストする) 幾つかのツールを紹介します。

14.3.3.1. パッケージの監査: debsums とその限界

debsums は興味深いツールで、(潜在的には攻撃者によって) 修正されたインストール済みファイルを見つける事が可能ですが、その結果は疑ってかかるべきです。第一に、すべての Debian パッケージが debsums プログラムが要求する指紋を提供しているわけではないからです (指紋が提供されているならば、指紋は /var/lib/dpkg/info/package.md5sums に保存されています)。 備忘録的になりますが: ここで指紋とは、ファイルの内容に対するある種のシグネチャを含む値、通常は数 (実際は 16 進数表記です)、です。このシグネチャはあるアルゴリズムを使って計算されます。指紋計算に使われるアルゴリズムはファイルに対して行われた小さな変化により指紋が変化する事がおおよそ保証されているものです (MD5 や SHA1 がよく知られている例です); これは「アバランシェ効果」として知られています。アバランシェ効果のお陰で、簡単な数字で表される指紋がファイルの内容の変化を検出するためのリトマス試験として機能する事になります。指紋計算に使われるアルゴリズムは不可逆です; 言い換えれば、ほとんどの場合、指紋からその指紋が得られる内容を発見することは不可能である事が知られています。最近の数学的な進歩により、アルゴリズムの原理の絶対性が揺らいでいるように見えます。しかしこれはアルゴリズムを使うことに対して疑問を投げかけるものではありません。なぜなら、同じ指紋を持つ異なる内容を作成することはまだかなり難しい作業だからです。
加えて、md5sums ファイルはハードディスク上に保存されます; そのため几帳面な攻撃者なら md5sums ファイルの中の指紋を改竄したファイルに対応する新しい指紋で置き換えるでしょう。
最初の欠点は debsums が確認を行う際に md5sums ファイルを参照するのではなく .deb パッケージを参照すれば避ける事が可能です。しかしこの場合、先に対応する .deb ファイルをダウンロードする事が必要になります:
# apt-get --reinstall -d install `debsums -l`
[ ... ]
# debsums -p /var/cache/apt/archives -g
注目すべき点として、デフォルト状態の debsums は APT を使ってパッケージがインストールされていた場合でも存在しない md5sums ファイルを自動的に生成します。
次の問題も同様のやり方で避ける事が可能です: この確認は本来の .deb ファイル に基づかなければいけません。この方法の前提条件は、すべてのインストール済みパッケージに対するすべての .deb ファイルを取得すること、 .deb ファイルの完全性が保証されていること、です。これを満足させる最も簡単な方法は Debian ミラーから .deb ファイルを取得する事です。この操作は遅くて退屈ですから、この操作を定期的かつ積極的に使うべき手法として考えるべきではありません。
# 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 コマンドが使われている点に注意してください。

14.3.3.2. ファイル監視: AIDE

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 に保存されます; すべての記録された変更が正当ならば、参照データベースを新しいデータベースに置き換える事が可能です。

14.3.4. 侵入検知 (IDS/NIDS)

snort (同名の Debian パッケージに含まれます) は NIDS ネットワーク型侵入検知システム です。NIDS の機能はネットワークをリッスンして侵入試行および敵対行為 (サービス妨害攻撃も含めて) を検知しようとします。すべてのイベントは記録され、過去 24 時間のイベントをまとめた電子メールが管理者宛に毎日送信されます。
snort の設定にローカルネットワークをカバーするアドレス範囲を追加します。具体的に言えば、アドレス範囲とは潜在的に攻撃対象となりうるすべてのアドレス意味します。他の重要なパラメータは dpkg-reconfigure snort を使って設定します。これには監視するネットワークインターフェースが含まれます。監視対象のネットワークインターフェースは通常イーサネット接続用の eth0 ですが、他の可能性も存在します。例えば ADSL や PSTN (Public Switched Telephone Network、かなり古いダイヤルアップモデム) 用の ppp0、無線ネットワークカード用の wlan0 などです。
snort 設定ファイル (/etc/snort/snort.conf) はとても長く、コメントを使ってそれぞれの指示文がとても詳しく説明されています。設定項目を最大限に活用するには、コメントを全部読んで、現場の状態に適用する必要があります。例えば、マシンとそのマシンがホストするサービスの対応関係を表しておく事により、snort が報告する事故の数を制限する事が可能です。なぜなら、デスクトップマシンへのサービス妨害攻撃は DNS サーバへのサービス妨害攻撃に比べて致命的な問題ではないからです。さらに別の興味深い指示文を使えば、IP アドレスと MAC アドレス (一意的にネットワークカードを識別するもの) 間の対応付けを保存する事が可能です。こうすることで、不正侵入されたマシンが他の慎重に扱うべきサーバのような他のマシンになりすますという、ARP spoofing 攻撃を検知する事が可能になります。