過去数年に渡り、The Honeynet Projectはブラックハットの行動の情報を収集、アーカイビングしてきた。私たちはHoneynetへ来る全ての接続や攻撃、エクスプロイト作成のログ記録や収集を行おうとしてきた。これらの生のデータは非常に高い可能性を持つ。私たちはこのデータをセキュリティコミュニティと共有しその価値を証明することにした。私たちは二つの領域にフォーカスするつもりだ。1 つ目はブラックハットコミュニティがどれだけ精力的かを証明するため。あなたがどのような人であろうと、あなたは安全ではない。私たちの目標はあなたにその脅威を気づかせることである。2つ目は早期の検知と予測のコンセプトをテストすることである。傾向を手法を特定することで、事が起こる前に攻撃を予測し対応ができるかもしれない。私たちはこれをThe Honeynet Projectが収集してきたデータを用いて試してみる。

収集されたデータ

The Honeynet Projectは高度にコントロールされぴったりと監視された8つのIPネットワークを管理している。私たちは2000年4月から2001年2月までも11ヵ月間このネットワーク上の全ての攻撃を収集し、アーカイブした。このHoneynetは8つのIPアドレスが含まれていて、これらは地方のISPから提供された単純なISDN接続である。使用した接続は多くの自宅のユーザや小規模ビジネスユーザと同じ種類のものである。事実このHoneynetはあるプロジェクトメンバの予備のベッドルームに置かれているものだった。このHoneynetには通常1つから3つのシステムが存在していた。ここには以下のオペレーティングシステムが稼働していた。Solaris Sparc、WinNT、Win98、Linux RedHatである。

データを取得するためのこのHoneynetネットワークは、最初の設定ではRedHat LinuxやWindows NTなと一般的に使用されるオペレーティングシステムのネットワークであった。Honeynetであることは公にしていないし、攻撃者を魅了するようなものも何も作成していない。私たちは何ののサービスもシステムも宣伝していないから、理論的にはこのサイトはまったく目立たないはずである。しかし攻撃は行われた、それも頻繁に。

Honeynetのデータがより価値のあるものにしているのは、多くの組織の共通の問題であるfalse positiveとfalse negativeの両方を削減することにある。False positiveは実際には何も悪いことがないのに怪しい行為があったと警告するものである。組織の人たちは繰り返しfalse positiveが発生してくると、警告システムと収集されたデータを気に止めなくなってきて、システムが役に立たないものにしてしまう。例えばある侵入検知システムは既知のエクスプロイトであっても、管理者へ攻撃に遭っているとメールをする。しかしこの警告はユーザのeメールで起こった可能性があった。中にはセキュリティ管理者への既知の脆弱性に関するもので、そのソースコードが含まれていたというものである。またSNMPやICMPなどのネットワーク監視プロトコルが警告メカニズムの誤りを引き起こすかもしれない。Honeynetは実際のトラフィックを用いることなくこの問題を削減している。Honeynetは実際の用途はなく、許可されない行為を取得するためのネットワークである。これはHoneynetを行き来するパケットは本当に怪しいものであることを意味している。このデータ取得の単純さと分析のプロセスが、false positiveを削減しているのである。

False negativeは多くの組織が直面しているもう1つの問題である。False negativeは実際の怪しい行為や許可されていない行為の検知を失敗することである。多くの組織は侵入検知システムやファイアウォールログ、システムログ、プロセスアカウンティングなど、適切な攻撃検知のメカニズムを持っている。これらのツールの目的は怪しくて許可されていない行為の発見である。しかしfalse negativeが引き起こすデータオーバロードと新たな脅威という2つの大きな問題がある。データオーバロードは組織が全てを見られないほど多くのデータを取得 しすぎたとき、それによって攻撃が見逃されることである。例えば多くの組織のファイアウォールやシステムのギガバイトのログである。その情報の全てのレビューと怪しい行為の特定は非常に困難である。2つ目の問題は組織やセキュリティソフトウェアが気づいていない脅威、新規の攻撃である。もしその攻撃が未知のものであったら、どのように検知するのだろうか? Honeynetは Honeynetを出入りの全てを完全にとらえることで、false negative(攻撃の見落とし)を引き下げている。Honeynetには作られた行為は少ししか、または全くないことを思い 出してほしい。これは取得された全ての行為はおそらく怪しいものであることを示している。もし私たちが最初の攻撃の検知を逃したとしても、すでに記録されているのである。例えば管理者へリアルタイムに警告がないままに2度ハニーポットが被害を受けていた。私たちはハニーポットが外部へ接続をはじめるまで攻撃の成功を検知することはできなかった。いったんそれらの試みが検知されると、私たちは全ての取得した行為をレビューし、攻撃とそれらがどのように成功して、なぜ私たちが気づかなかったかを特定した。調査目的にはHoneynetはfalse negariveの削減に寄与している。

データのレビューに関しては、false negativeとfalse positiveの両方が劇的に減少することに価値がある。私たちが以下で述べる結果は私たちのネットワークに特有のことで、読者の組織で同じトラフィックパターンやふるまいが見られるわけではないということを念頭に置いてほしい。私たちは収集されたデータを使ってブラックハットの現状と、攻撃の早期検知と予測の可能性を示す。

過去の分析 
ブラックハットコミュニティを調査する一方で、the Honeynet Projectはブラックハットがどれほど精力的かに驚かされた。その結果は恐ろしいものである。以下は私たちがデータを収集した11ヵ月間から特定した集計結果である。これの目的はブラックハットコミュニティの活動を示すためである。これらは何の宣伝も行わずブラックハットを魅了しようともしていない強い小さなホームネットワークの集計結果であることを念頭におくように。非常に知名度や価値のある大規模な組織はおそらくよりたくさん接続や攻撃があるだろう。

攻撃の分析の結果:

• 2000年4月から12月の間、7台のデフォルトインストールのRedHat 6.2の サーバがインターネットから3日いないに攻撃を受けた。この結果から、私たちはRedHat 6.2の生存見込みは72時間以下と推定した。これを検証しようとした最後のときは、このシステムは8時間以内に被害を受けるようになった。これまでシステムが被害を受けた最短の時間は15分である。これはシステムがインターネットからスキャンされ、接続され、攻撃されたことが15分以内であることを示している。
• 2000年10月31日にデフォルトのWindows 98がインストールされた。ファイル共有を有効にしている。これは多くの家や組織でよく組織でよく見られる設定である。このハニーポットは24時間以内に被害を受けた。次に述べる3日間では別に4回被害を受けた。4日以内に計5回これらが発生した。
• 2000年5月、Snort侵入検知システムの警告をアーカイブした最初の1ヵ月に、このHoneynetは157件警告が記録された。2001年2月、このHoneynetは1398件の警告を記録した。890パーセントの増加になる。この増加はSnort IDSの設定ファイルの変更が作用していると考えられる。しかしながら、ファイアウォールログでも増加が見られた。2000年5月はファイアウォール警告を記録した最初の1ヵ月であり、Honeynetファイアウォールは103の独立したログ(NetBiosの集計を除く)が記録された。2001年2月にはHoneynetは206件のスキャン(NetBiosの集計を除く)を記録した。これは100パーセントの増加率になる。この数字はブラックハットの活動が増え続け、おそらくよりアグレッシブになり、自動スキャニングツールが広く出回りつつあることを示している。
• 2000年9月20日から10月20日の30日間、Honeynetは524のユニークな NetBiosスキャンをうけた。これは1日平均17件受けたことになる。
• 2001年2月には、計27件のX86エクスプロイトがHoneynetへ届いた。X86はインテルベースのアーキテクチャを用いたシステムにデザインされた攻撃を意味する。この中で、8件はSolaris Sparcシステムに届いた。それらのエクスプロイトはSparcシステム上では動作できない、これはシステムアーキテクチャに互換性がないためである。このことは何人かのブラックハットはオペレーティングシステムや動作しているサービスのバージョンを確認していないことを示している。何人かのブラックハットは特定のサービスを調査するための自動的なスキャニングプロセスを持っている。もし彼らがそのサービスを発見したら、彼らはシステムが脆弱か、さらには正しいシステムなのかさえ最初に見ることなくエクスプロイトを実行するのである。この行動アプローチはブラックハットがより短い時間でより多くのシステムをスキャンし攻撃することを可能にしている。
• 2000年4月より現在まで、通常のスキャン以外のほとんどの偵察方法は DNSクエリや、下で述べるRPCサービスへのクエリであった。
• ほとんどのよく見られる攻撃はIntelベースのシステムへのrpc.statdに関連するものであった。
• 検知されたほとんどのスキャン方法は、特定のポートでIPの範囲全体を調査するためのSYN-FINスキャンであった。これは単一の脆弱性にフォーカスして、その脆弱性をより多くのシステムでスキャンする戦術が反映されている。多くのブラックハットは彼らが使用法を知っていたり、より効果的な単一のツールやエクスプロイトのみを使用しているのである。

将来の予測
調査を目的としたHoneynetのもう1つの領域が攻撃の早期検知と予測である。将来の攻撃を予測することで、Honeynetがより高い価値を持つことを意図している。この論理は新しいものではなく、現在も優れた他の組織が追求しているものである。私たちの望みはこの調査が他の組織の具現化の役に立つことにある。私たちの手法を解説する前に、私たちの現状はまだ途上で、さらなる調査が必要であることを述べておきたい。

• 私たちは単一のHoneynetで、単一のセンサからの視点で、さらに非常に小さなデータセットに関して述べる。以下の手法は今後複数のHoneynetで世界中に分散した企業環境で調査する予定である。
• 私たちは同じ攻撃者を見分けることは考えていない。これは単純にスプーフィングの技術が知れ渡っているためである。
• 私たちは計算機が攻撃される前に最初に接続されるという仮定のもとで作業を行っている。もちろん2つのイベントが関連がなく、偶然に発生するかもしれない。それでも私たちは以下の手法は攻撃者が先の事を行という前提で示す。

予測動向における努力において、the Honeynet Projectの2人のメンバは異なる2つのアプローチをとった。しかしながらその結果は類似していて、大部分の攻撃は2、3日前に検知ができた。

統計的工程管理(SPC)を用いた早期検知:

はじめは非常に基本的な統計手法であり、これは製造業界における工場での欠陥調査で使用される統計的工程管理手法に類似している。この手法は非常に単純であるが、短期間(3日以内)のうちにHoneynetで攻撃が差し迫っている警告の通知を非常に正確に証明している。基本的な流れは次のようなものである。

• 2000年4月から2001年1月までのSnortログを分解する。
• 上位10件のSnortルールごとに、日毎の出現数を計算する。
• \item ルールごとに3日移動平均(3DMA)を計算する。その後管理チャート上に警告の出現数と3DMAをプロットする
• 管理限界は段階ごとの標準偏差から算出する。さらに値を2倍する(2シグマ管理限界)
• 全ての時点で3MDAは2シグマ管理限界の下である。もし動きがあれば(3かそれ以上の増減)、それを警告とみなす。最低限攻撃前に情報の収集を行い、その後ポートが開いているかどうかをチェックすることを私たちは見てきた。

全ての計算は攻撃の試みや成功などの事前の通知無しに行った。管理チャートが計算できた後に、試行されたり成功した攻撃を時間毎にプロットした。全てのデータはHoneynetサイトにある。以下は我々のいくつかの結論である

1. Honeynetは2000年4月9日から2000年12月31日の間、8つの攻撃成功を記録した。この期間1つを除く全ての攻撃は上で示した方法を用いることにより、事前の警告インジケータを得た。
2. 時間軸全体と記録された全ての攻撃によって、2シグマ管理限界を越える3DMAは全ての時間(1つを除く)で攻撃試行ごとの3日分の警告を提供した。(除いた1つは7日分の警告になる)単純な統計的工程管理は、最低限3日それぞれの攻撃についての警告を引きだした。以下はいくつかの例である。
• RPC : RPCの活動は180日間で記録された(1日目は2000年4月1日からはじまる)61日目から68日目の間に3DMAはチャートで上昇する動きを見せた。これは異常であることを示している。68日目にはrpc.statdを使用したアクセスの試行が記録された。さらに153日目と170日では異常な行為が111番ポートで記録され、続いて177日目に侵入が成功した。rpc.statdオーバーフローを用いている。以下はこのモデルのグラフィカル表示である。X軸はサンプルの日付、Y軸は頻度である。

• DNS/named : namedサービスの問い合わせで、81日目から85日目が管理限界より上にあった。85日目に、namedサービスは許可されていない攻撃を受けた。

2番目の方法は最初の結果を確認するために使用する。私たちはSnortのrpcルール違反とシステム破壊までの日数に関連があるかを調べる方法に使えると考えた。より正確な時系列モデルが必要であるのと同時に、システムが破壊されるまでの日々においてrpcルール違反の回数を回帰させる単純な予測回帰モデルを用いることで、すばやく予備的な調査が可能である

図1はこのモデルからrpc.statdによるシステム破壊までの日数予測を表したものである。水平方向の軸は日付で、1から180までのサンプル日数である。下方向のとげは重要な状況、攻撃が切迫しているのを予測していることを示す。この状況では、68日目ではおよそ10日前に実際の攻撃が発生することが見られる。チャートの終わりに3つの「脅威のとげ」があるが、177日目に再び同じrpc攻撃でシステムが破壊された。上がって行くとげについては、私たちはまだ正確に確認をしていないけれど、「静かな期間」または安全な期間を連想させる。

このモデルにはいくつかの統計的な問題が存在することを述べておかなければならない。これは大規模なDurbin-Watson検定を含む。このモデルから取り除く必 要のある重大な相関が存在する。予備的な調査は差し迫った攻撃をそれが起こる前に警告する方法が存在することを示唆している。他のデータと共にこのデータのより洗練された時系列解析が早期検知のアイデアの将来的なサポートに有効だろう。

ARIMAモデルを用いた攻撃前シグナルの特徴の調査

別の調査領域は、攻撃および接続の確かな特徴を判別することである。次の例はHoneynetの''Scans of the Month''の一つである。下のグラフは30日間のポートスキャン数である。様々な接続や事前攻撃に関して、私たちが答えたい疑問のひとつは、``将来の攻撃や接続、停止などが観測できるような典型的な間隔はどれくらいか''ということである。このような場合、このデータには単純時系列ARIMA(Auto Regression integrated with Mobing Averages)モデルが適合する。ARIMAは一定の期間集められたデータを調査するための時系列解析に使用される基本的なモデルである。下のグラフは11月のポートスキャンの回数を示したものである。

 

• 攻撃パターンおよび関連の良いアイデアを得るために、より多くのデータの取得が必要である
• より柔軟にSnortが取得する他の形式のデータの追加は、侵入プロセス発見の理解に役立つだろう
• イベント履歴分析のような、異なる分析手法

私たちはこれらの手法を開発しテストすることや私たちの統計手法を提案することでコミュニティを支援している。私たちは特に分析の他の種類や発見をしてくれる人達を探すことに興味を持っている。私たちがここで提案したことはやり尽くしているわけでなく、むしろ初期的なものである。The Honeynet Projectによって収集され使用されたデータは下にリンクをしている。個のデータは2000年4月から2001年2月までの11ヶ月間収集されたデータである(honeynet\_data.tar.gz)。honeynet_data.tar.gz

まとめ
11ヵ月の間 the Honeynet Projectはここに来るすべての接続や攻撃、エクスプロイトの収集を行ってきた。このデータは2種類の目標のために分析が行われた。最初の目標はブラックハットがどれほど精力的か示すためである。我々が直面している悪意のあるいくつかの脅威を示した。Honeynet は生産的でなく攻撃者の興味を引く宣伝をしないシステムで構成され、情報を収集するために使用される。もしあなたの組織がなんらかの価値を持ちまた宣伝されているならば、あなたはおそらく大変な脅威にさらされているだろう。2つ目の目標は攻撃の早期検知と予測である。私たちは将来の攻撃予測に可能性があると考えている。Honeynetはデータなどを収集することだけを行っているが、false positiveとfalse negativeを削減する利点を持っている。データ収集と統計解析の武器をもつことで、組織にとってはブラックハットコミュニティに対する十分な準備ができる可能性がある。