セキュリティのジレンマ、パート1：侵入検知

執筆：Matt Frye

はじめに

自分のLinuxシステムがセキュリティ侵害を受けたとき、あなたはどうしますか？ まず何から始めますか？ 誰に連絡しますか？ 侵入されたことが分かったとき、これらの、そしてさらに多くの質問をされると、狼狽してしまうかも知れません。往々にして、我々の最初の反応は「ありえない。まさか自分に限って」というものです。そう、まず否定から始まるのです。その後にパニックがやってきます。「データは消えてないか？ ルートキットを仕込まれたのでは？ こいつは誰なんだ？」 2部構成でお送りするこの記事の第1部では、あなたのLinuxシステムが誰かに不正アクセスされたことが分かったとき、すべきこととすべきでないこと、考えるべきこと、そしてどこから始めれば良いかという点にスポットを当てます。

兆候の判定

システムに侵入されたことに気づくためには、まずその前に、兆候を判定する方法を知っていなければなりません。多くの場合、「データベースサーバに入れない」、「サイトがダウンしている」などといったように、兆候は明らかです。しかし、時には兆候がそれほど明白ではない場合もあります。不正アクセスの兆候が、そもそも兆候だと分からない場合さえあります。

システムに侵入されたことに気づくためには、まずその前に、兆候を判定する方法を知っていなければなりません。

Clifford Stollがクラッカーとの戦いの経験を詳しく記した『The Cuckoo's Egg』（Doubleday; 1989、邦訳は『カッコウはコンピュータに卵を産む（上・下）』、草思社）を読むと、一見無関係に見えるちょっとした情報だけが唯一の手がかりという場合もあることが分かります。Stollの例では、犯人への道のりは長く厳しいものであり、攻撃者はUNIXに関する高度な知識を持っていました。しかし常にそうとは限らず、幸いにも（不幸にして、かも知れませんが）あの例ほど高度な攻撃は、最近ではまれになっています。

最近の攻撃は、スクリプトキディによるものが多くなっています。スクリプトキディというのは、人のシステムをかき乱したり、場合によってはほとんど何もできていないのに、自分たちが何か巧妙なことをしていると考える、スキルの低い連中のことです。昨今では、実際にスキルの高い攻撃者に出くわした場合、システムをより大きな何かのための踏み台に使われたり、何らかの分散型サービス拒否（DoS）攻撃のコマに使われる可能性があります。良いニュースとしては、そうした攻撃はいくつかの法医学的パターンを示す傾向があります。たとえば、代替アクセスを探す攻撃者は、非標準ポート上でSSHを動作させたり、ファイアウォールやサービスの構成を変更したりします。監視によってこれらの変更を明るみに出すことが可能なので、認識（アウェアネス）が重要になります。

認識のための監視

監視は、適切に運用されているすべてのサイトにとって重要であり、侵入があった後は特に重要になります。とはいえ、セキュリティを守るために数多くのサーバを監視するのは気の重い作業かもしれません。日常的なシステム管理の一部に組み込むことが可能であり、かつ組み込むべきものとしては、攻撃されやすい分野を監視するというのが良いやり方です。

侵入のあと、徹夜でシステムを監視するというのは誰しも避けたいでしょうから、自動化が不可欠であり、それによって仕事がずっと簡単になります。「兆候の判定」の節で検討したように、典型的な攻撃は法医学的なパターンを生成します。このパターンを明らかにするのは、自動化された監視による出力であり、ほとんどの攻撃はネットワークサービスから生じるので、それらのサービスに関連するログから作業を始めるのが一番です。

Linuxの典型的なインストールには、監視を容易にするためにログを収集するlogwatchなどのツールが含まれています。いつでもすべての場所に立ち会っているわけには行きませんが、データ収集を自動化してそれをメールキューに送ったり、必要ならポケベルに送るといったことは可能です。さらに、sarのようなUnixコマンドや、その他のパフォーマンスおよびシステム監視ツールは、創造的に使用すればセキュリティ監視にうってつけです。監視は、想像力に富むものにしてください。いつも決まった答えでは、新しい問題は決して解けません。

攻撃対象の特定

攻撃の兆候が判定できたら、攻撃対象の特定はずいぶん楽になります。たとえば、攻撃者がサービスに変更を加えていたにも関わらず、同じシステム上のデータベースにはアクセスしていなかったという場合、データベースは攻撃の対象ではなかったという結論を下しやすくなります。

攻撃対象の特定によって、システムの浄化とセキュリティ確保のためにどんな行動を取るべきかという指標も恐らく与えられます。性能面が攻撃目標だと明確に特定できるような材料がないなら、性能低下の可能性を考慮して侵入後に何時間もかけて測定を行う必要はありません。システムのリスクとダメージを評価する際には、焦点を絞ることが鍵になります。

攻撃対象の特定によって、システムの浄化とセキュリティ確保のためにどんな行動を取るべきかという指針も恐らく与えられます。

侵入の後は、常にアフターアタックすなわちブービートラップの可能性があります。攻撃が行われた場合、侵入後の最初の14日間がシステムの挙動を観察すべき最重要期間です。システムの利用量の変動を探してください。CPU、メモリ、あるいはネットワークのスループットが過度に高いのは、マシンからの警告です。I/Oウェイトやネットワークレイテンシの増加といったさらに微妙な変化も、何かが変わったことを示す典型的な兆候です。もし日常的にそのシステムにログインして数時間を過ごしているなら、マシンの性能がどんな感じか自分の実感として良く分かっていることでしょう。

攻撃者が選んだ対象からは、システムの修正/修復に際して遭遇が予想されるその他の問題や、その攻撃が最近の傾向に沿ったものかどうかについても洞察が得られます。前述したように、ブービートラップの可能性があり、それらはシステム環境またはユーザ環境の変化によって察知できます。攻撃の後始末をするときには、全ユーザの初期プログラムとログインシェルをチェックしてください。また、cronやatのジョブキューに何か溜まっていないかという点にも、特に注意してください。攻撃者があまりシステムに損害を与えずに立ち去った場合でも、悪意のある at ジョブを残しておくことでデータを破壊する可能性があります。

システムの評価でもう1つ鍵になる領域は、損害の範囲に対する考察です。攻撃者の意図がシステムに損害を与えることにあった場合は、単純にバックアップからシステムを再構築する方が簡単であり、時間もかからず、より安全だと思われます。何かしら侵害を受けたシステムを引き続き稼働させると、弱点が残って将来また攻撃される可能性があります。ダウンタイムと将来の攻撃と、どちらが高く付くか考えてください。

ここで取り上げるもう１つの、そして非常に重要な領域は、システムに与えられた損害に対して何ができるかという問題です。すなわち、侵入が発生したとき、システム管理者が怒りに燃えて、不相応な時間をかけて攻撃者に対する入念な「報復ベースの」罠を仕掛けることがあります。しかし実際には、最近の攻撃者はめったに現場には戻らず、もし帰ってきても、監視されているとか捕捉されているような気配を少しでも感じると、永久に姿を隠してしまいます。そうなれば願ったりかなったりだと思うかも知れませんが、場合によっては、侵入者を捕捉できないリスクが失われたデータのコストより高く付くことも考えられます。このリスクを評価するためには、自分の「処置のリスク」を計算する必要があります。

処置のリスクに対する評価

攻撃の対象が特定できたら、すべてにしっかり鍵をかけ終わるまでの間、システム全体を完全に閉じてしまいたいと思うでしょう。しかし、まだ疑問が残っています。自分の「処置のリスク」とは何でしょう？ 処置のリスクとは、侵入者を捕らえる前にシステムを閉じることの相対的なリスクです。平均的なLinuxのホームユーザが修復を行う場合、答えは簡単で、ドアを閉じるべきです。しかし、様々な状況では、この質問に対する答えはデータの価値とともに変化します。しかし、自分の処置のリスク（rA）を計算することによって誤差の範囲を小さくすることが可能です。

処置のリスクとは、侵入者を捕らえる前にシステムを閉じることの相対的なリスクです。

rA は、データ損失の価値と将来の侵入のリスクとの数学的な比較です。rA は簡単な等式で計算されます：

rA = rI - vD

すなわち、処置を行うことのリスク（rA）は、侵入のリスク（rI）からデータの価値（vD）を引いたものに等しくなります。以下の架空シナリオを考えてみましょう：

米国政府が暗号化アルゴリズムの案出に使用しているシステムで侵入が発生したとします。システムの所有者は、侵入者を捕らえないリスクの方がデータの価値よりも高いという結論に達しました。データ自体は学術コミュニティ全体に渡って広く利用可能なものであるのに対し、米国外の特定人物が所有することによって、我々が破ることのできない暗号の開発につながる可能性があるからです。この場合、rA はプラスの値になります。rA がプラスの場合は、システムを開いたままにしておき、侵入者が帰ってきて、彼/彼女/彼等についてより多くの情報を収集できることを期待するのが最善の行動になります。

ここまで読んで、心の中でこう言っているかも知れません。それってハニーポットじゃないか。それがなんでしょう？ 違いは、rA を使うことによって、目立たない方法で監視しながらシステムを侵入されやすい状態のままにしておくべきか否かについての、情報に基づく、十分に考慮された決定に達することができるという点です。データの価値を可能な限り下げることによって、システムの再構築が必要になるリスクを軽減したいと思うでしょう。Clifford Stollもそれと同じようなことをしました。侵入者に盗ませるための、まったくのニセ情報を用意して、侵入者がそれに興味を持ったのです。

逆に、もしrA がマイナスの値なら、可能な限り速やかにシステムを閉じるべきです。たとえば、製薬会社で侵入が発生した場合、データを入手することで誰が得をするかについては、ほとんど疑問の余地がありません。データ自体が非常に高い価値を持っているわけです。したがってシステム所有者は、データの価値が常に侵入のリスクを上回るという結論を出すことが考えられます。この場合、rA はマイナスであり、ダウンタイムのコストを払ってでもそれ以上のデータ損失を防ぐことになるという認識のもと、所有者は自信を持ってシステムへのすべてのドアを閉じることができます。

もちろんrA がグレーの領域もあります。顧客の信用情報を格納したシステムがクラックされた（またはソーシャルエンジニアリングで侵入された）最近のニュースを見ると、データの価値が非常に高いものの、侵入の政治的価格も同様に高いことが分かります。この場合、rAの等式はあまり役に立ちません。この記事の第2部では、システムのrA値に対する予防的な評価について検討します。

ここで、ハイゼンベルクの不確定性原理について考えてみましょう。侵入者を監視する際には、メモリ、プロセス、およびファイルが急速に変化する可能性があり、システムの動作に大きな支障を与えることなく変化を正確に記録することは不可能であることから、間違いなく不確定性が作用します。こうした理由から、「揮発性の順序」（Order of Volatility：OOV）に従うのが有効です。『Forensic Discovery』（Farmer & Venema, 2005）の中で、著者らはOOVすなわち予測されるデータの寿命を示しています。侵入の調査を行う際にOOVに従うことで、データ収集そのものによって破壊される恐れのある詳細情報を保護できる可能性が高まります。データ収集の副作用ではなく、問題のインシデントに関するデータを収集できるようになるわけです。表1「揮発性の順序」を参照してください。

データの種類	寿命
レジスタ、周辺メモリ、キャッシュ等	ナノ秒以下
主記憶	10ナノ秒
ネットワーク状態	ミリ秒単位
実行中プロセス	秒単位
ディスク	分単位
フロッピー、バックアップメディア等	年単位
CD-ROM、印刷物等	10年単位

システムの弱点

攻撃の兆候を判定し、対象を明確に特定し、処置のリスクを評価したら、弱点の領域を決定したことになります。弱点とは、特定のポートや脆弱性を具体的に指すものではなく、侵入の特徴的な手法を指すものです。全般的な侵入ポイントと言ってもいいでしょう。

これらの侵入ポイントは、特定のシステムの脆弱性を引き起こす同時条件になっているのが普通です。たとえば、MTAとファイアウォールソフトウェアの脆弱性の組み合わせなどです。侵入ポイントを分類することで、システム内の脆弱性の傾向と領域を特定できます。これは、攻撃の直後はあまり役に立たないかも知れませんが、将来に備えて効果的にシステムを評価する準備が整うことになります。すなわち弱点が強みになるわけです。

弱点とは、特定のポートや脆弱性を具体的に指すものではなく、侵入の特徴的な手法を指すものです。

結論

システム管理者は、毎日のかなりの部分を、自分たちのシステムを監視したり、セキュリティアップデートをインストールしたり、セキュリティ上の予防テクニックをユーザに教えたりして過ごします。彼等の目標は絶対に侵入の発生を防ぐことです。しかし、実際に発生しまった場合は、認識と集中が修復プロセスの鍵となります。

何が起こったかだけでなく、いつ、どのように、なぜシステムがクラックされたかを特定するために奮闘すべきです。これが分かれば、さらなる侵入を防ごうとする際に力と洞察が与えられます。「痛い目にあって賢くなる」のは仕方ありませんが、「次回」はない方が良いでしょう。復旧は決して報復であってはならず、システム管理者としての我々自身のスキルの延長と考えるべきです。

来月はシリーズの第2部として、侵入の防止を目指して予防的手段を講じる方法にスポットを当てます。

参考図書

『Cuckoo's Egg』、Clifford Stoll著（Doubleday, 1989）
（邦訳：『カッコウはコンピュータに卵を産む（上・下）』、草思社）
『Forensic Discovery』、Dan Farmer & Wietse Venema共著（Addison Wesley, 2005）

著者について

Matt Fryeは、ノースカロライナに住むUnix/Linuxのシステム管理者です。彼はNorth Carolina System Administrators の会長であり、Triangle Linux User Groupの活動的メンバーでもあります。余暇にはフライフィッシングと精神的カンフーを楽しんでいます。