gen2

Know Your Enemy:

GenII Honeynets

Easier to deploy, harder to detect, safer to maintain.

Honeynet Project

http://www.honeynet.org/

Last Modified: 12 May, 2005

Translated by SHIBUYA Yoshihiro

Original document is here

GenⅡ(第2世代)ハニーネットはハニーネット技術の発展における次なるステップである。古今の技術の組み合わせに基づいて、GenⅡハニーネットは柔軟性、管理性そして実装上のセキュリティ性を増強することができる。このペーパはGenⅡハニーネットのアーキテクチャで使用された技術を紹介する。しかしながら、先に進む前にあなたはすでにKnow Your Enemy: Honeynetsに記載されているコンセプト、リスクそして概要を読破し、すべて理解していると見なしての話である。あなたは技術の詳細部分をカバーする前にハニーネットの基本的なコンセプトとリスクを理解することが重要である。

このペーパはGenⅡハニーネットの概要を端から端まで記載したものである。あなたは以下に議論される方法を使ってあなた独自の手作りのハニーネットを構築することができる。しかしながら、我々はその代わり(手作りのハニーネットを構築する代わり)に、以下に議論される機能(またはそれ以上の機能)を自動化したHoneywall CDROMを使用することを提案する。最初のセクションではネットワークの管理能力に焦点を当てることになる管理のメカニズムであるHoneywallのコンセプトについて紹介する。データコントロールのセクションでは我々のネットワークにおける攻撃者の行動を制限するプロセスについて議論する。3番目のセクションであるデータキャプチャでは、ホストとネットワークの双方のレベルにおいて攻撃者の行動をキャプチャする方法について詳細を網羅する。自動アラートのセクションでは攻撃成功の可能性の高い事象を管理者に気づかせる方法についてカバーする。最後に、テストのセクションでは様々なステップにおけるテスト構成の方法を公表する。我々が記述する装備はx86アーキテクチャ上のLinuxカーネル2.4.xで動作するHoneywallに基づいている。あなたにはここで議論されるツールや方法が要求されるのではなく、同じ機能が提供されるのであればあなたが最も使いやすいと感じるどの技術でも使うことができるのである。

The Architecture

我々がKYE: Honeynetsで議論したとおりハニーネットは本物の攻撃者を封じ込めて分析するのに利用される高度にコントロールされたネットワークのアーキテクチャである。アーキテクチャの装備の仕方はあなた次第である。我々はまた、ハニーネット装備に必要なものの概要を記載したドキュメントであるHoneynet Definitions, Requirements, and Standardsで議論してきた。このペーパではこれら要求を総合する特定の方法について詳細を述べる。Honeywall CDROMはこれらのツールと技術が使われており、データ分析等の新しい機能が加えられている。どのハニーネットにおいてもキーとなる要素はゲートウェイであり、ハニーネットの被害者(生け捕りされた攻撃者)を分離する。ゲートウェイは壁として動作し、実際我々はゲートウェイのことをHoneywallと呼んでいる。これはハニーネットの指揮統制センターとなり、すべてのマジックはここで起こる。あなたはハニーネットのアーキテクチャの例をFigure Aで確認することができる。この例では、ゲートウェイはレイヤ2ブリッジである。レイヤ3のルーティングゲートウェイも使用できるが、ブリッジの方が(攻撃者に)検知されにくく好まれている。図では、ハニーネットは内部ネットワークの192.168.1.0/24で装備されている。従来はほとんどのハニーネットは外部または防御されたネットワークに装備されていた。レイヤ2ゲートウェイを使用することにより、ハニーネットは我々のように内部ネットワークに統合することができる。このことにより、外部の脅威のみならず、内部に潜在する脅威についても探知し、学習することができる。

Honeywall(ブリッジゲートウェイ)は実用システムをハニーネットネットワークから分離し、犠牲にしているターゲット(おとり)の中に実在している。ゲートウェイの外部インターフェース(eth0)は実用システムのネットワークに接続している。そして内部インターフェース(eth1)はハニーネットのネットワークに接続している。ブリッジであるため、内部、外部のネットワークともに同じIPネットワークに存在する。我々はまた第3のインターフェース(eth2)も持っている。このインターフェースの目的は中央集積部へのログまたはキャプチャしたデータの移動を含めたゲートウェイの遠隔管理のためである。内部及び外部インターフェースはIPアドレスを付与されないブリッジモードで動作している。しかしながら第3のインターフェース(eth2)は、例えばIPアドレス10.1.1.1のようにIPスタックが割り当てられている。このネットワークは管理目的で使用されるために分離され、保護されたネットワークである。このアーキテクチャの長所は、ゲートウェイはルーティングホップがなく、TTLの減値がなく、MACアドレスが割り当てられていない等、検知するのが困難なところである。また、単一のゲートウェイ上でデータコントロールとデータキャプチャの双方を組み合わせて単純にハニーネットを装備することができる。次のステップはこのアーキテクチャをサポートするためにゲートウェイを構築することである。ゲートウェイにはLinuxの最小でセキュリティを施したセットアップを実施する。これはいかなる攻撃者もゲートウェイにアクセスすることができない信頼できるシステムには重要なことである。次に、ゲートウェイの機能を確実にするためにIPTablesのファイアーウォールをブリッジモードにする。ほとんどのLinuxディストリビューションはデフォルトでこの設定になっている。もしあなたのシステムがそのような設定になっていない場合、http://ebtables.sourceforge.net/からブリッジ用のカーネルを取得することができる。IPTablesは、ゲートウェイをセキュアにするだけではなく、データコントロール(後述)に使用するためにも重要である。ファイアーウォール能力はHoneywallゲートウェイをセキュアにするだけではなく、データコントロールのために使用することに対しても重要である。

Data Control

KYE: Honeynetのペーパで議論したように、データコントロールの目的は攻撃者がハニーネットを攻撃したり、他のハニーネット以外のシステムに被害を及ぼすことを妨げることである。データコントロールはリスクを軽減するものであり、取り除くものではない。データコントロールにより、あなたはどれだけの外部への行動をコントロールすることができるであろうか?攻撃者に行動を許可すればするほどあなたはより多くのことを学習することができる。しかしながら攻撃者に行動を許可すればするほど彼らが危害を加える可能性が大きくなる。そのため、彼らが他に危害を加えることができないよう彼らの行動を十分に封じ込めなければならないが、十分に封じ込むことができなければ学習することも最低限のものになる。あなたが攻撃者に許可する行動量は最終的にはあなたが請け負うリスクの量である。さらなる挑戦は、攻撃者に封じ込められていることを悟られずに封じ込めることである。これを完遂するために、我々は接続カウントとNIPSの2つの技術を実装する。接続カウントはハニーポットから外部へ出る接続の回数を制限する。NIPS(Network Intrusion Prevention System)は既知の攻撃をブロック(または無効)にする。これら2つの技術を結合することにより冗長で柔軟性のあるデータコントロールのメカニズムを作り出す。我々は双方の技術をレイヤ2ゲートウェイに実装する。我々はすべての外部または内部へのトラフィックが通らなければならず、攻撃者の行動を阻止するポイントであるためにゲートウェイにデータコントロールを実装するのである。

Part 1に記述したようにゲートウェイを構成したら、次のステップは攻撃者がハニーポットから外部へ接続する回数を制限することである。この目的は外部への接続をカウントし、制限数に至ったときにはそれ以上の接続をブロックすることである。これは主として大量スキャン、攻撃またはDoS攻撃のような大量の外部接続を必要とする行動のリスクを軽減するために使用される。我々はこのためにハニーネットCD-ROMに収録される予定のrc.firewallに組み込まれ、実装されるIPTablesを利用している。IPTablesでは、攻撃者が起こすことができるTCP、UDP、ICMPまたはその他の外部への接続回数を設定する。許可する接続回数はどれだけのリスクを負うかによる。外部への接続回数を制限することにより、攻撃者がハニーネットから他のシステムに対し大量のスキャンをしたり、DoS攻撃をしたりするリスクを妨げる。あなたが許可した回数に制限に達したとき、ダメージを与えることは困難になる。しかしながらこのことは痕跡になることは心に止めておかなければならない。攻撃者は単に外部接続を開始して制限回数に至り、ブロックされたことによりハニーネットを検知するかも知れない。Honeywall CD-ROMのデフォルトの制限は次のとおりである。ちなみに、OTHERとはTCP、UDP、ICMP以外のIPプロトコル(IPsec、IPv6トンネリング、ネットワークボイスプロトコル等)のことである。

### Set the connection outbound limits for different protocols.

SCALE="day"

TCPRATE="15"

UDPRATE="20"

ICMPRATE="50"

OTHERRATE="15"

以上がIPTablesの実装による接続制限である。攻撃者がハニーポットに押し入ったとき、様々な理由でネットワーク外部への接続が発生するかも知れない(ツールキットをダウンロードしたり、自動Botをセットアップしたり、IRCチャット、メール送信等)。これらの接続が外部へ出るときはいつでも、ファイアーウォールでカウントが行われる。制限回数に達したら、IPTablesはハニーポットを起点とする接続をすべてブロックする。その時IPTablesは自動的にリセットされ、それまでと同様の外部への接続が許可される。例えば、TCPの外部への接続を1日当たり25回にセットしている。攻撃者がハニーポットに押し入ったとき、彼らには25回の外部へのTCP接続が許可されている。外部へのTCP接続が25回の制限回数に達したとき、彼らはそれ以上何も始めることができなくなる。IPTablesはそのときさらに25回の外部接続を許可するようにリセットされ、このケースでは次の24時間に25回の接続であり、1時間当たり1回の接続である。もし規模を1時間単位にすれば、制限に至ったら次の1時間に25回の接続が許可され、2.4分当たり1回の割合となる。実際の記録例は、these IPTable logsにおける、Windows 2000ハニーポットがCode Red Ⅱワームに侵され、外部へスキャンをかけたものを参照されたい。IPTablesの優れた特徴の一つは、TCPの制限回数に至ってもUDP、ICMPまたはその他のトラフィックがそれらの制限に至るまでは影響を与えないことである。

接続制限を設けたら、次のステップはNIPS機能の実装である。おさらいすると、NIPSの目的は既知の攻撃の発見とブロックである。これはゲートウェイを通過するすべてのパケットを検査する。もしパケットがIDSルールのどれかにマッチしたら、従来のNIDSのようにアラートを発するだけではなく、パケットをドロップ(攻撃をブロックする)したり修正(攻撃ができないようにする)したりする。この利点は外部への既知の攻撃の成功に対するリスクを劇的に低減するところである。欠点は既知の攻撃にしか働かないところである。回数制限のケースでは、デフォルトで1日当たりの外部へのTCP接続は15回許可している。もしハニーポットがワームに侵され、最初の15回に外部接続の間に他のシステムを侵したら何が起こるであろうか? 回数制限はシステムが侵される数を低減するが、依然としてリスクは存在するのである。NIPSのアイデアは最初の15回の接続の間に認められた既知の攻撃をブロックするか無効にすることである。このため、我々はSnortの新バージョンに組み入れられた機能である Snort_inlineを用いる。

Snort_inlineは、パケットを何かしらルーティングするNIPS(ゲートウェイモード)として動作するため、ルータ(IPフォワード)としてどのように動作するのか分かっていない。そのため、Snort_inlineにパケットをルーティングし、ルーティングプロセスにおいてSnort_inlineにパケットが解析のために渡るようにしている。Snort_inlineにパケットが渡ってしまえば、ルーティングプロセスに戻る。そのプロセスはIPTablesである。我々はIPTablesを、パケットをフォワードし、Snort_inlineに解析されるようにユーザスペースにそれら(パケット)を置き、IPTablesがパケットをルーティングするように設定する。このIPTablesの特徴はIp_queueモジュールをカーネルにロードすることが要求される、ユーザスペースキューイングと呼ばれている。Snort_inlineとIPTablesのカウント能力を統合するときに気をつけなければならないのは、IPTablesはSnort_inlineがパケットを通そうがブロックしようが関係なく外部への接続をカウントするということである。その理由は、すべてのパケットはSnort_inlineで解析される前に最初に内部インターフェースを通過するからである。接続はSnort_inlineに着く前にカウントされるのである。

もしあなたがSnort_inlineの機能を使えるようにするならば、Snort_inlineを起動させなければならない。もしSnort_inlineを起動させなかったり、何かしらの理由で作動していなかったときには、パケットはIPTablesを通過することはない(これはバグではなくフェールセーフ機能である)。このように、我々の次なるステップはSnort_inlineを設定することである。これは異なるルールベースを使用する点以外はSnortに非常によく似ている。ここで心に止めておくべきことは、我々の目標はすべての外部への通信をドロップすることではなく、攻撃のみをドロップすることである。あなたはICMPのpingのような情報のクエリ、フィンガのクエリまたは単なるHTTPのGETコマンドをブロックされたくはない。もし我々がSnortのルールをすべて使ったならば、攻撃者は外部へは何もできなくなる。このように、我々はSnortルールの実際の攻撃の部分だけを使用する。どの組織においてもどれが攻撃に当たるのかということは異なる定義をしているため、我々はSnort_inlineのルールベースを使う前に一度変更することを薦める。また、我々のルールセットは内部向けの攻撃に焦点を当てている普通のSnortのルールベースとは逆である。Snort_inlineを使うことによって外部への攻撃に焦点を当てたいのである。目標はハニーネット外の世界を防御することである。最後に、我々は行動をアラートさせないといったようにルールは異なっているが、攻撃は実際にドロップされるか無効にされている。drop rulesetの目的はパケットを解析し、もし外部への攻撃を確認したら、攻撃を含むパケットをブロックまたはドロップすることである。Code Red IIをドロップしたときの具体的な例を見るのが早い。replace rulesetは攻撃をブロックしない。その代わり、実際の攻撃内容を書き換え、利用できなくする。これは攻撃者が(ハニーネットを)検知することをさらに難しくする管理方法である。彼らは攻撃が意図したところに到達するのを確認するが、なぜ攻撃が失敗したかは分からないだろう。snortconfigは、drop、sdrop、replace等のSnort_inlineの能力に通常のSnortルールを組み合わせる柔軟性のあるスクリプトである。このツールはSnort_inlineのルールセットを管理するのに非常に重要である。

Data Capture

データコントロールを装備したら、今度はデータキャプチャを装備することができる。データキャプチャの目的は攻撃者のすべての行動を記録することである。これ(情報収集すること)はハニーネット全体の目的である。データキャプチャがなければハニーネットの価値はない。データキャプチャのカギはできるだけ多くのレイヤで情報収集することである。単一のレイヤだけではすべての情報は得られない。例えば、たいていの人々が必要と感じるのは攻撃者のキーストロークであるがそれは正しくない。攻撃者がツールを発動したとき、ツール自体またはネットワークトラフィックをキャプチャしていない場合どのようにしてそのツールが働くかを知るのか。ハニーネットプロジェクトはデータキャプチャに重要な3つのレイヤを定義している;ファイアーウォールのログ、ネットワークトラフィックそしてシステム動作である。これからこれら3つすべての実装の詳細について述べることとする。

ファイアーウォールのログはとてもシンプルで、我々は既にその部分で実施している。IPTablesのファイアーウォールスクリプトを実行することにより、我々は既にすべての出入りする接続を /var/log/messages にロギングしている。この情報は攻撃者の行動を我々に最初に示すために重要である。また、外部への攻撃が開始されたときの最初の警告でもある。我々の経験に基づくと、ファイアーウォールのログは新しいもしくは未知の行動の「早期発見に重要であることを立証している。Honeywall CD-ROMでは4タイプのトラフィックすなわちTCP、UDP、ICMPその他を定義している。ちょうどデータコントロールのところで説明したように、「その他」とはIPではないプロトコル1、6、17番を表している。これはまたとてもおもしろい傾向があり、誰かがIP以外のトラフィックを使う時は、以前 Scan of the Month 22で見られたバックドア用チャンネルのように新規の攻撃または未知の攻撃のようである。

第2の要素はすべてのパケット及びハニーネットを出入りするぺイロードをキャプチャすることである。Snort_inlineのプロセスはこれを行うものと考えられ、我々はすべての卵をバスケットに入れたくはない。その代わり、我々はすべての行動をキャプチャする第2のプロセスを構成し、走らせるのである。我々はIPのタイプにかかわらず、すべてのIPトラフィックをキャプチャする通常のSnortのプロセスを使うことによってこれを行う。スタートアップスクリプトには内部インターフェースであるeth1にスニッファを結合した。これは重要である。もし誤ってスニッファを外部インターフェース(eth0)に組み込んでしまった場合、ハニーネットのデータをロギングすることができないだけではなく、外部ネットワークの他のトラフィックにも影響してしまう。これはキャプチャするデータを汚染してしまうであろう。内部インターフェースからスニッフィングすることにより、本当に欲しいハニーネットに出入りするトラフィックのみをキャプチャするのである。

第3の要素は最も挑戦的なことで、ハニーポット独自で攻撃者の行動をキャプチャすることである。数年前はほとんどのリモートインタラクションはFTP、HTTP、Telnetのようなクリアーテキストのプロトコルであり単純だった。あなたは単にキーストロークをキャプチャするためにスニッフィングするだけでよかった。しかしながら攻撃者は暗号化を採用しているのである。最近は侵入したコンピュータとの通信にSSHや3DESを使用する。我々はもはやキーストロークを線上からキャプチャするのではなく、その代わりにシステム自体から彼らを捕まえるのである。ハニーポットの利点の一つは、ほとんどの暗号化された通信はシステムのエンドポイントで復号されることである。ハニーポット上で復号されたデータをキャプチャすることができたならば、我々は暗号化通信を回避することができる。Sebekはそれが可能となるように設計されたツールである。Sebekは攻撃者の行動をロギングすることができる隠されたカーネルモジュール(またはパッチ)である。ハニーポットに一旦インストールされたら、Sebekクライアントはカーネル上で起動する。Sebekクライアントにおいて収集された情報は攻撃者に発見されるであろうハニーポット上には蓄積されない。その代わり、SebekクライアントはそれらのデータをUDPを使って監視用マシン(Honeywallゲートウェイまたは他のネットワーク上のリモートログシステム等)に移動させる。攻撃者はハニーポット上のSebekクライアントがパケットを隠すため、スニッフィングされたパケットを見ることはできない。たとえ攻撃者が独自のスニッフィングツールをダウンロードし使用しても、Sebekは彼らからは隠されているはずだ。これはあらかじめ指定されたUDPポートへのスニッフィングされたパケットは見えないようにハニーポットが修正されることによってなされる。Sebekはゲートウェイにおいて集積された攻撃者の情報を線上からダンプするだけである。すべてのハニーポットはSebekによって管理されているため、線上でダンプされるキーストロークをスニッフィングすることはできない。注意点は、もしあなたがSebekがインストールされていないハニーポットを持っている場合(またはSebekの設定が正しくない場合)、攻撃者はそのシステムの管理権を握り、他のシステムからやってくる隠されていないパケットをスニッフィングすることができるようになってしまう。

Sebekはカーネルの中で動作するけれども、ハニーポットでは特定のOS及びカーネルのバージョンでコンパイルしなければならない。異なるOSでは異なるクライアントバージョンであるが、同じ設定ファイルが付いてくる。設定ファイルの目的はその情報を収集し、どうやってその情報を線上にダンプするかを決定づけることである。デフォルトでは、Sebekはシステム上のすべての動作をキャプチャするようになっているが、あなたにはキーストローク動作をキャプチャするオプションしかない。Sebek特有の数字とdest UDPポート番号の組み合わせはどのパケットを隠すかを決定づける。同一グループのすべてのハニーポットは効果的に動作させるためには同じ組み合わせにした方がよい。一度設定したら、Sebekはネットワーク上のすべてのシステムの行動をダンプする。これらのパケットは攻撃者の行動及びシステムへの影響を再構成するのに使われる。Sebekについてのさらなる情報は、Know Your Enemy: Sebekを参照されたい。

Alerting

ハニーネットの話を締めくくる前にあなたが考慮しなくてはならない最後の要素はアラートである。誰かがハニーネットに侵入することは、あなたがその侵入に気づかないということがなければ多大なる体験学習である。あなたが利用されたことに気づき、それに反応することを保証するということは、ハニーネットの成功に重要なことである。熟練した管理によって24時間完全に監視することである。しかしながら、組織は四六時中スタッフをサポートできないため、代替方策の一つとして自動アラートがあるのである。自動監視のオプションの一つにSwatch, the Simple Watcherがある。Swatchはハニーネットにおける攻撃成功の可能性があるものを管理者にアラートする自動監視ツールである。Swatchは設定ファイルに記述されたパターンでログファイルを監視する。そのパターンが発見されたら、アラートを電子メール、システムベル、電話そして他のコマンド及びプログラムにまで送ることができる。簡単なSwatchルールは取るべき行動のリストにより監視するパターンを含んでいる。デフォルトのSwatchは与えられたルールにマッチしたログファイルの行を電子メールでアラーとする。以下にそのメールの例を示す。

To: admin@honeynet.org From: yourdatacontrol@yourdomain.org Subject: ------ ALERT!: OUTBOUND CONN -------- Apr 6 17:19:05 honeywall FIREWALL:OUTBOUND CONN UDP:IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth2 SRC=192.168.1.101 DST=63.107.222.112 LEN=123 TOS=0x00 PREC=0x00 TTL=255 ID=43147 PROTO=UDP SPT=5353 DPT=79 LEN=103

データコントロールのセクションで自動ツールについて記述したが、効果的なハニーネットは継続監視を必要としている。適切に設定されたSwatchはネットワーク上で行われるイベントを早急に管理者に知らせてくれる。しかしながら、アラートによる外部への接続情報のみに頼っては行けない。例えば、攻撃者はシステムを乗っ取ったものの外部へ接続をしないかも知れない。Sebekクライアントでキーストロークを収集する等、他の要素の情報を確実に収集すること。さらに進歩した検知、通知そしてアラートのメカニズムは作成中のHoneywall CD-ROMに収められている。

Testing

データコントロールとデータキャプチャを設定したら、次のステップはゲートウェイのテストである。装備をテストするために、以下に取るべき基本的なステップを示す。Honeywall CD-ROMのドキュメントセクションにはさらに詳細なテストプランが付いてくる。ゲートウェイをテストするために、テスト用システムと呼んでいる外部インターフェースが必要である。Figure Aをベースに、テスト用システムの192.168.1.20を使用する。我々は最初にデータコントロールのテストをする。ハニーネットは出入りする行動を捉えることに成功するであろうか?最初にテスト用システムからハニーネットの中のハニーポットの一つに接続を起こす。ルールセットに基づいてこの接続は許可されるべきである。もしそのようになれば、/var/log/iptablesのようにエントリされる。

Mar 23 20:55:09 honeywall kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=192.168.1.20 DST=192.168.1.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=48699 DF PROTO=TCP SPT=36797 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

内部への接続がうまくいっていることを確認したら、次のステップは外部への接続である。ゲートウェイの内部にあるハニーポットの一つからアクセスすることから始める(SSHのようにハニーポットはローカルにログをためるが、コンソールからハニーポットにアクセスすることを薦める)。ここからテスト用システムに対し複数の接続が行われる。このことはハニーポットの一つに侵入され、攻撃者が外部へ接続を試み、攻撃する可能性があることを模写する。その接続はHoneywall CD-ROMの/var/log/iptablesに収録されているはずである。我々の場合、複数のFTP接続を実用ネットワーク上のテスト用システムに対して試みた。15回の接続制限に至ったとき、「Drop TCP」というエントリがロギングされる。以下のようなエントリがあなたにも記載されるであろう。

Mar 23 17:45:36 laptop kernel: OUTBOUND CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=36399 DF PROTO=TCP SPT=1026 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

Mar 23 21:14:07 laptop kernel: Drop TCP after 15 attempts IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63391 DF PROTO=TCP SPT=1030 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

次に、NIPS技術であるSnort_inlineが動作していることを確認したい。幸運にも、Snort_inlineにはテスト用に特別に設計されたテスト用ルールが付いてきている。Snort_inlineをテストする前にこれらのルールを使用可能にしておくこと。あなたが走らせようとしているルールベースはまた、あなたが走らせているどれをテストするかを決定づける。もしあなたがドロップ用のルールセットを走らせるならば、あなたは単にデフォルトのテスト用ルールを使用可能にすればよく、スタート用スクリプトでSnort_inlineを再起動すると外部へのTelnet接続が試みられる。 Snort_inlineは検知し、ドロップし、そしてロギングを試みる。あなたが試みるTelnetは機能せず、タイムアウトするはずである。もしあなたが修正したルールセットを走らせるならば、デフォルトの修正テスト用ルールを使用可能とし、Snort_inlineを再起動し、簡単なHTTP GETコマンドを試みる。Snort_inlineは検知し、修正し、ロギングを試みるはずである。修正事項を確認するために、外部インターフェースであるeth0をスニッフィングすること。内部インターフェースであるeth1をスニッフィングしないこと。GETコマンドは内部インターフェースを通過するまでは修正されないが、外部インターフェースに到達するまでには修正される。テストが終わったら、ルールを無効にすること(さもない悪人がデフォルトのテストを簡単に走らせてしまう)。

03/23-21:21:05.915340 [**] [1:0:0] Dropping Telnet connection [**] [Priority: 0] {TCP} 192.168.1.101:39528 -> 192.168.1.20:23

03/23-21:21:24.054533 [**] [1:0:0] Modifying HTTP GET command [**] [Priority: 0] {TCP} 192.168.1.101:38533 -> 192.168.1.20:80

データコントロールを確認したらデータキャプチャが正常に働いているか確認したい。思い出して欲しいのは、もしハニーネットがすべての行動をロギングしなければハニーネットとしての価値はない。データキャプチャをログを見ることによって確認し、ハニーネットがデータコントロールのテストで作動したかを確認する。このテストは簡単で、我々の接続のすべてが/var/log/iptablesにロギングされるはずである。特に、テスト用システムからハニーポットへの内部への接続を始めに確認するはずである。第2に、我々はハニーポットからテスト用システムへの外部接続を確認するべきである。最後に我々は外部接続が制限回数に至ったとき、それ以上の接続はドロップされることを確認するべきである。我々は既にデータコントロールの確認の時にこれをテストしている。次にネットワークのログを確認する。我々はキャプチャした出入りするすべてのパケット及びすべての接続におけるペイロードを確認したい。経験によると一日を基準にログをローテーションするのがベストのようだ。我々が主に関心を持っているログは、snort.logと呼んでいるキャプチャしたバイナリログである。それに加え、IPアドレスに作り出す様々なディレクトリを発見するかも知れない。これらはFTPコマンドやhtmlページのようにASCIIコンテンツも含まれている。あなたはSnortがバイナリログファイルを解析することによってすべてのパケットをロギングすることを以下のとおり確認することができる:

honeywall #snort -vdr snort.log.*

最後にSebekログを確認する。これらはSebekカーネルモジュールによってネットワーク上でダンプされたキーストロークをキャプチャしたものである。これらのパケットはネットワークスニッファ(Snort)でキャプチャされたはずである。Sebekのすべての丘移籍には、Honeywall CD-ROMに付いてくるGUIインターフェースであるWAlleyeを使用することを強く薦める。もしあなたが収集したデータを解析することができたなら、あなたのデータキャプチャはうまく働いていることになる!また、電子メールをチェックすると、あなたが走らせているテストに対するアラートが届いているはずである。Swatchはあなたが独自に走らせているテストをアラートしているはずである。あなたが正規のセキュリティの専門家だからあなたがハニーネットゲートウェイを再起動し、データコントロールとデータキャプチャの機能を確実に確認するため、テストを再度実施することを知っている。また、我々はHoneywall CD-ROMのドキュメントセクションに記載されているように、組織に対してはさらに広範囲なテストを薦める。

Conclusion

我々はLinuxを用いてブリッジゲートウェイに基づいたGenⅡハニーネットの構築及び装備方法の概要を述べてきた。この装備はハニーネット技術のさらに発展した特徴を表している。しかしながら、心に止めておいてもらいたいのは、情報セキュリティは、我々が攻撃者の行動をキャプチャする新しい技術をリリースすれば、彼らの対抗手段が同じような脅威になるといったように、軍拡競争に似ているということである。もしあなたが独自のハニーネットを装備することに関心を持っているのであれば、我々は Honeywall CDROMを強く推奨する。