Linux Auditで社内からの脅威を検出する
したがって、外部からの脅威を念頭にネットワークの周囲に侵入検出システムやファイヤウォールやウィルス・スキャナーを張り巡らせただけで安心してはならず、認可した利用者についても監視すべきだ。Linux Auditデーモンは、その際に必要となるセキュリティー・ポリシー違反の検出に有効だ。
「監査（audit）」という言葉は、情報セキュリティー分野ではいろいろな意味で使われている。「セキュリティー監査」は企業のセキュリティー状況を評価することを指し、侵入テスト、セキュリティー・ポリシーの点検、システム構成などに基づいて実施される。これに対して、システム・レベルでは、ユーザーの行動やシステム内にあるプログラムの動作を記録することを指す。Linux Auditデーモンが行うのは後者の意味での監査で、セキュリティーを確保するための受動的な方法の一つだ。ここで、受動的というのは、セキュリティー・ポリシーに対する違反を検出するだけで、ポリシーへの準拠を求めることはないという意味だ。この点で、ネットワーク・ベースやホスト・ベースの侵入検出システムに似ている。
Linux Auditデーモンの基礎は、カーネルに対して発行されるシステム・コールのすべてを監視することにある。システム・コールというのはユーザー空間で動作しているプログラムがカーネルの機能を利用するための手段で、アプリケーションは直接または間接にこのシステム・コールを介してカーネルの提供するシステム資源への低レベル・アクセスを利用する。Linux Auditデーモンは、この仕組みを利用しているわけだ。このLinux AuditデーモンをSecurity-Enhanced Linux（SELinux）に組み込むと、SELinuxポリシーに対する違反を記録することができる。
Linux AuditデーモンはLinuxカーネルの一部であるため、広く使われているLinuxディストリビューションであれば、そのほとんどにデフォルトで含まれている。カーネルの一部であることからオーバーヘッドが少なく回避されにくいという特徴がある。ただし、この種のソフトウェアなら通常持っているはずの機能が欠けている。これは、厳密なセキュリティー評価による認証を受けるためには簡素に作る必要があり、そのように設計されているからだ。
| コラム：コモン・クライテリア |
|---|
|
Linux Auditデーモンは、コモン・クライテリアの評価保証レベルEAL4コモン・アクセス・プロテクション・プロファイルの厳密な要件を満たすように設計されている。
コモン・クライテリアというのは、情報システムのセキュリティーを評価するための枠組みだ。評価はセキュリティー要件の一覧表ではなく、セキュリティーの前提と要件を記述したプロテクション・プロファイルに基づいて実施され、製品が所定のプロテクション・プロファイルに準拠しているかどうかを問う。 評価保証レベル（EAL）は、情報システムがセキュリティー要件に対して準拠している程度を表す尺度だ。最低レベルはEAL1で、製品の機能がテストされていることが確認される。一方、最高レベルのEAL7では、設計が形式的表現で確認され、テストされていることも確認される。EAL7の認証にはコスト的にも時間的にも負担が大きいため、EAL7の認証を受けている製品は極めて少ない。 実用的には、EAL4が最も厳しいレベルだ。このレベルでは、組織的な設計、テスト、製品の点検が確認される。EAL4認証取得には最長25か月かかり、コストは0,000（原文ママ）程度必要だ。そのため、Linuxベンダーでは、NovellとRed Hatだけが、コモン・アクセス・プロテクション・プロファイルの下で自社のオペレーティング・システムのEAL4認証を取得している。 |
何を監査すべきか
システム・コールは何百とあり、そのすべてを監視すべきではない。（セキュリティーの観点から）注意すべきシステム・コールは、ファイルのオープンとクローズ、ファイルのパーミッションとオーナーの変更、ファイル・システムのマウントとアンマウント、システム時刻の変更を伴うものだ。Linux Auditデーモンにはファイルへのアクセスの監視機能が組み込まれており、該当するシステム・コールを監視する必要はない。
監査すべき対象は各企業の要件に応じて指定する。デフォルトのままの場合、SELinuxポリシー違反を記録することになる。Linux Auditサブシステムのソース・パッケージには、あらかじめ、監査構成ルールが含まれており、重要なシステム・ファイルへのアクセス、ファイル・パーミッションの変更、ファイルの位置の変更、ファイル・システムのマウントとアンマウントを監視するルールが記述されている。これを基にして指定するとよいだろう。
ルールは、このように構成ファイルに直接書き加えることができるほか、運用中にもコマンドラインから追加することができる。Linux Auditデーモンのルールは、デフォルトでは、/etc/auditd/audit.rulesにあり、実行時にロードされる。ルールは1行に1つずつ記述する。一例を挙げれば、「-w /var/log/audit/audit.log」というルールは、audit.logファイルへのアクセスを監視することを表す。ルール構成ファイルを変更せずに運用中にルールを追加するときは、コマンドライン・ツールauditctlを使う。なお、このツールのマニュアルには、監査ルールが詳述されている。
監査インベントの利用
Linux Auditデーモンは、イベントが発生すると、それを/var/log/audit/（デフォルト）にある監査ログ・ファイルに記入する。監査ログ機能は、多くの点でシステム・ログ機能に似ている。どちらも、ログ・ファイルを/var/logディレクトリーに置き、ログをリモートsyslogサーバーに送ることができる。ログ・ファイルを使い回せる点も同じだ。違いは、監査ログの生成にはユーザー空間のプログラムが関わっていないこと。これはLinux Auditデーモンがカーネルの一部であることを意味し、rootkitを使わない限り、監査を回避するのは困難だ。
監査ログ・ファイルを解析するコマンドライン・ツールが2種類用意されている。ausearchは指定した条件に従って監査ログを検索し、条件を満たすログを抽出する。aureportは、失敗したログイン、構成の変更、監視対象ファイルなど、注意すべきイベントについて報告書を作成する。こうしたツールに他のコマンドを組み合わせることで、強力なシェル・スクリプトを作ることができる。
監査ログをさらに詳しく解析したいときは、監査イベントを構文解析するAudit Event Parsing Libraryを使ってプログラムを書くこともできる。C用とPython用があり、パッケージはaudit-libsとaudit-libs-pythonだ。お使いのディストリビューションのパッケージ・マネージャーを使ってダウンロードすることができる。
また、Linux AuditシステムにはAudit Dispatcherという機能がある。これを使うと侵入検出システムなどの外部アプリケーションからLinux Auditデーモンにリアルタイムにアクセスできる。したがって、OSSECなど、ホスト・ベースの侵入検出装置からLinux Auditデーモンを利用して侵入検出を強化することもできる。
サードパーティー製のSystem iNtrusion Analysis and Reporting Environment（Snare）という興味深いツールがある。監査ルールを構成したりリポートを作成したりできるGUIがあるだけでなく、他のオペレーティング・システム向けの製品もあるため、異なるプラットフォームの監査ログを共通のサーバーに記録することができる。
ところで、監査を実施するときは、（米国の場合）監査ログの保存期間に関するポリシーを定めておく必要がある。監査ログを法的手続きで使うには、それが標準の業務手続きに含まれていなければならないからだ。監査ログが定常業務になっていない場合、法的手続きでは業務記録とは見なされず伝聞証拠扱いとなる。また、ログ・サーバーを置いて複数のマシンの監査記録を一括して保存することも検討すべきだ。こうすれば、複数のマシンの監査ログを同時に解析することもできる。
まとめ
監査はあまり面白い仕事ではない。しかし、コンピューター・ネットワーク・アーキテクチャーでは重要な防衛線だ。セキュリティー・ポリシー違反を検出できるし、セキュリティー対策を調整するためのツールとしても有用だ。これに、ネットワーク・ベースの侵入検出機器、セキュア・システム構成、能動的セキュリティー対策を組み合わせれば、監査は内部および外部の脅威からLinuxを守る一助になるだろう。
