ボットネット実態調査結果 - black hat | home...ゾンビpc、botnet...

Copyright©2004 Telecom-ISAC Japan. All Rights Reserved.

ボットネット実態調査結果ボットネット実態調査結果Our security depends on your securityOur security depends on your security

（（ISPISPととMalwareMalwareの戦いの戦い EpsodeEpsodeⅠⅠ~~ⅣⅣ））

2005年 10月18日Telecom-ISAC Japan

小山覚（NTTコミュニケーションズ株式会社）

2Copyright©2004 Telecom-ISAC Japan. All Rights Reserved.

本日のアジェンダ本日のアジェンダ

●● Telecom-ISAC Japanのご紹介

●● ボットネット実態調査結果ボットネット実態調査結果（（EpisodeEpisodeⅣⅣ））●● ISPとMalwareとの戦い（～2005）

• EpisodeⅠ ： CodeRedⅡ/Nimda/Slammer （2001～）

• EpisodeⅡ ： Blaster/Sobig F （2003 Summer）

• EpisodeⅢ ： Antinnyシリーズ（2004）

• EpisodeⅣ ：ボットネット（2005）

●● ISPとMalwareとの次の戦い（2006～）–– Our security depends on your securityOur security depends on your security


●● Telecom-ISAC Japanのご紹介


TTelecomelecom--ISAC JapanISAC Japanのご紹介のご紹介情報通信インフラの安全性確保を広義の目的として、通信サービスの提供を妨げる各種インシデントを収集・分析し、その分析結果を会員間で共有することにより、インシデントに対する強固な情報通信基盤の提供を目指して2002年7月に設立された組織。現在、財団法人日本データ通信協会の内部組織に編入。


重点対応した脅威・取組姿勢の変化重点対応した脅威・取組姿勢の変化

重点対応した脅威

～2003年ネットワーク感染型ワーム

2004年～特定目的型攻撃、国境を越えた攻撃

2004年～ゾンビPC、Botnet

情報通信インフラの安全・安心の確保

安全・安心を脅かす脅威の継続的な低減到達目標

2003年～(2) ネットワーク感染型ワームへの対応

2004年(4)ゾンビPC対策（黎明期）

2005年～(5) ISP連合・異業種（SOC、AV)連合によるゾンビPC対策（試行・発展期）

2002 年(1) T-ISAC-J発足当初

活動区分 2004年～

(3) DDOS攻撃対応

対応決定の基準（当初）会員総意ISP運用を損なうほど、深刻な脅威

「連携のための情報共有」「情報共有のための連携」

対応決定の基準への追加

１社では手に負えない規模

取組姿勢の変化

Blaster騒動Blaster亜種騒動

Sobig-F騒動(2003)

ネットワークセキュリティの概念の変化ネットワークセキュリティの概念の変化


●● ボットネット実態調査結果

EpisodeⅣボットネット（2005）


Internet

ボットネットとゾンビボットネットとゾンビPC PC とはとは

◆ ロボットのように遠隔から自由に操作できるゾンビPC（ボット）◆ 多数のゾンビPCを同時に遠隔操作可能（ロボットネットワーク）◆ ワームや不正ツールでゾンビ化


電子メール利用者

SPAMSPAMメールメール

ゾンビPC

Web

メール送信

Webビジネスサイト

ゾンビPCを活用したSPAMメールビジネス

①②

③

④


● 2004年の春に、大量のSPAMメールが送信された。メールのあて先（ユーザ名）が総当りであったため、大量のエラーメールが発生し、ISPのメールサーバに大きな負荷をかけた。

●海外から飛んできた大量の日本語メールが問題になった。ソースIP数が、数百～数千であり、従来のSPAMとは明らかに異なる様態であったため、Telecom-ISAC Japanで調査を行ったところ、ボットネット（Zombie Cluster)を使ったSPAM送信が行われている可能性が濃厚になった。

SPAMSPAMメールメール

① 「$$$.jp」ユーザに偽装したメールを「¥¥¥.jp」ユーザに送信

メール送信指示

Mail Mail¥¥¥.jp $$$.jp不達通知（エラーメール）

③ 大量のエラーメールが「$$$.jp」に届く

ボットネット問題が表面化したきっかけボットネット問題が表面化したきっかけ

② 一部メールは正規のユーザに届く

ゾンビPC（数百~数千）


当時の状況

● ボットネットも脅威だがまだ時間はある、ISPのDNSサーバを倒す威力を持つAntinny対策が先決（ EpisodeⅢ参照）

● 当時ボットネットの実態に関する情報が不足– 警察庁（@Police）がGaobotの解析レポート H16.7.13

● 独自に調査すると、– ボットネットはブラックマーケットで売られているらしい

– 悪さはSPAMだけではない

– かなり組織的な運用が可能であり悪意を持つ人間が操作すると、Antinnyと同程度以上の攻撃が出来る可能性がある

– 無防備なPCインターネットユーザが踏み台になっており、これは何とかしなければならない。しかも、ユーザPCが悪の元凶に近い状態

– ボットネットに関してISPが知りたい情報が世の中に存在しない（ネットワーク目線での動的解析情報）

● 2005年1月以降、本格的に調査(計画)開始– メンバが各々コストを負担しつつ取り組みを開始


JPCERT/CCJPCERT/CC

ISPISP

MSSPMSSP

AVAV

インターネットサービス・プロバイダ

マネージドセキュリティサービス・ベンダ

アンチウィルスソフト・ベンダ

ボットネットボットネット実態把握プロジェクトの体制実態把握プロジェクトの体制


ボットネットとはボットネットとは？？

ボットネット実態調査の仮説と実施状況ボットネット実態調査の仮説と実施状況

調査結果調査結果

•• AgAgobotobotソースコードの解析結果多くの事実が判明ソースコードの解析結果多くの事実が判明

•• Honey pot Honey pot でのボット捕獲調査でのボット捕獲調査•• ISPISPへのヒアリング調査等へのヒアリング調査等

•• 4040～～5050人に「ひとり」の割合でボットに感染人に「ひとり」の割合でボットに感染•• 未対策未対策PCPCをネットに繋ぐと４分で感染をネットに繋ぐと４分で感染•• ボットに占領されている帯域は日本だけでボットに占領されている帯域は日本だけで数数GbpsGbps

ボットネット対策と課題ボットネット対策と課題

ボットネット実態調査結果概要ボットネット実態調査結果概要


ボットネットとは？ボットネットとは？ボットネットとは？

agobotagobotソースコードの解析結果ソースコードの解析結果＋＋

各種情報収集により、各種情報収集により、

推測されるボットネットの仕組み推測されるボットネットの仕組み＝


ボットネットの基本的な構成

Internet

TARGET

IRC SV

感染したボット

HERDER

IRCを使った通信経路（攻撃指示、情報種集）

通常のクライアントでは接続できない場合も多い

指令によるDDoS攻撃SPAMにも利用される

（ただし、Redirectを利用）

ボットネットの所有者（HERDERと呼ばれる）

複数のIRCサーバが利用される場合もあるHERDERが侵入したシステムに構築する場合が多い

家庭のPCや、組織内のPC

DDoS!

Agobotのソースコード解析＋各種情報収集の結果判明した事実


ソースコードの入手と解析ソースコードの入手と解析

● WORM_AGOBOT.GENのソースコードをインターネットより入手、解析を実施


Botの基本的な機能(Agobot)

いつでも変更可能 BOT

自己防衛自己防衛

感染活動感染活動

コントロールコントロール

攻撃攻撃情報収集情報収集

DDoSDDoS

踏み台踏み台

SPAM中継SPAM中継

独自チャネル独自チャネル

ＩＲＣＩＲＣ

認証・暗号化認証・暗号化

ﾃﾞﾊﾞｯｶﾞ/VM対策ﾃﾞﾊﾞｯｶﾞ/VM対策

AV対策AV対策

ポリモーフィックポリモーフィック

メンテナンスメンテナンス

ﾊﾞｰｼﾞｮﾝｱｯﾌﾟ機能ﾊﾞｰｼﾞｮﾝｱｯﾌﾟ機能

BOTジェネレータBOTジェネレータ

ソースの流通ソースの流通

脆弱性の利用脆弱性の利用

ネット共有の利用ネット共有の利用

ウィルスの利用ウィルスの利用

アカウントFTP, IRC, PAYPAL、AOL

アカウントFTP, IRC, PAYPAL、AOL

E-Mail, プロダクトキーE-Mail, プロダクトキー

脆弱な通信相手脆弱な通信相手

WindowsWindowsLinuxLinuxHERDER

※もっともアブナイ機能は「情報収集」機能


メンテナンス機能（GUI付）

● IRCに関連するパラメータ– IRCサーバー/Port番号、バックアップサーバー、接続パスワード

● 動作に関連するパラメータ– Anti-AVの有無、起動時自動実行の有無

● パフォーマンスに関連するパラメータ– 感染活動/DDoS攻撃/Proxy動作を行うスレッドの最大生成数

● IRCに関連するパラメータ– IRCサーバー/Port番号、バックアップサーバー、接続パスワード

● 動作に関連するパラメータ– Anti-AVの有無、起動時自動実行の有無

● パフォーマンスに関連するパラメータ– 感染活動/DDoS攻撃/Proxy動作を行うスレッドの最大生成数


ボットのコマンドの例

コマンドグループコマンド数備　　考

bot 19 ボット自身に関するコマンド

commands 1 ボットがサポートしているコマンド一覧の表示

cvar 5 設定値に関するコマンド

ddos 8 各種DDoSコマンド

ftp 3 ｆｔｐを使ったダウンロード・アップデート

harvest 6 情報収集に関するコマンド

http 5 httpを使ったダウンロード・アップデート

inst 4 自動実行・Serviceに関するコマンド

irc 14 ircに関するコマンド

logic 2 コマンドの選択的な実行

mac 2 ボットへのログイン・ログアウト

ｐｃｔｒｌ 5 プロセスコントロール

redirect 7 Redirect(Proxy)に関するコマンド

rsl 3 感染ホストに関するコマンド

scan 12 スキャナ・感染活動

Phatobotコマンド概要


コントロール機能 – 暗号化・認証

• IRC over SSL (IRCS)

• 最大3つのパスワード認証

IRCサーバー群SSL

1. サーバー接続PW

チャンネルBot

Bot

Bot

Bot

2. チャンネル接続PW

3. Herder認証PW

Bot


自己防衛機能

● ポリモーフィック– ランダムに選択した鍵で実行ファイルをエンコード、デコーダを実行ファイルに付加

– プログラムのエントリポイントをデコーダの先頭にセットする

● 対アンチウイルス– プロセスリストを監視、AVプロセスを強制終了

• 監視対象プロセスは、約600件（AV、HIDS、他のMalware、etc.）

– Hostsファイルを改ざんしてパターン更新を妨害する

● 対デバッガ– デバッガを検出、自プロセスを終了させる

• IsDebuggerPresent API

• メモリサーチによるブレークポイントの検出

● 対VMWare– VMWareを検出し自プロセスを終了させる


感染活動

● 脆弱性の利用（結構古い脆弱性を使う?→ウソ）従来のWormと異なり複数の脆弱性を利用することが多い– MS01-059（UPnPの脆弱性）

– MS03-007（WebDAVの脆弱性）

– MS03-026（RPC DCOMの脆弱性）

– MS03-039（RPCSSの脆弱性）

– MS03-049（Workstationサービスの脆弱性）

– 他のワームが作成したPCのバックドアを利用

● 脆弱なパスワード（今後要注意!）内蔵の辞書を利用して辞書攻撃を行う– MS-SQL Server

– Windowsのネットワーク共有

• 匿名接続を利用して事前に共有リソース、アカウントを列挙


ボットネット実態調査の

仮説と実施状況

ボットネット実態調査のボットネット実態調査の

仮説と実施状況仮説と実施状況


秘

Worm

SPAM

DoSDDoS

？？

③指令者（Haerder）

④制御ch

⑤中継者（IRCサーバ）

⑥実施命令

⑦ボット（ZombiePC）

⑧不正通信

①犯罪組織等 ②報酬

秘情報漏洩

【【ボットネットの枠組ボットネットの枠組】】

技術的には追跡困難

技術的に実態把握が可能

下図の下図の③④⑤⑥⑦⑧③④⑤⑥⑦⑧の状況を調査し解明する。の状況を調査し解明する。1. 1. ボット感染ボット感染 PC PC ユーザの立場での調査（ユーザの立場での調査（⑦⑦ 実際に感染し実態を調査）実際に感染し実態を調査）2. 2. ボットネットの攻撃の被害者の立場で調査（ボットネットの攻撃の被害者の立場で調査（⑧⑧ 実際に攻撃を受けた内容を解析）実際に攻撃を受けた内容を解析）3. ISP3. ISPへのヒアリング調査。へのヒアリング調査。

上記「上記「1.1.」「」「2.2.」の分析結果を」の分析結果を ISP ISP に情報提供し、に情報提供し、ISPISPが把握しているボットネットの実態が把握しているボットネットの実態をヒアリングする。をヒアリングする。

ボットネット実態把握方法ボットネット実態把握方法


Worm

SPAM

DDoS

③指令者（HERDER）

④制御ch

⑤中継者（IRCサーバ）

⑥実行命令⑦ ボット

（ZombiePC） ⑧不正通信

InternetInternet

HoneyPot

DNSDNS

メールメールサーバサーバ

トラヒックモニタ

BB

CC

AA

A : ボットネットの観察による調査B : ハニーポットによる調査C : ISPが把握しているノイズ分析

※A&Bの情報をISPが独自に調査・分析

メールメールサーバサーバ ISPにヒアリング


調査結果調査結果調査結果


A : ボットネットの観察による調査


A : 調査内容と結果

③指令者

④制御ch

⑤中継者（HERDER）

⑥実行命令⑦ボット

（ZombiePC）

AA

調査結果● 平成17年1月17日警察庁調査「ボットネットのご注意」と同様の現

状が確認できた。http://www.cyberpolice.go.jp/detect/pdf/H170127_botnet.pdf


B : ハニーポットによる調査


感染等動作解析機能

ISP

ISP

ISP 攻撃通信集約機能

ハニーポット機能

マルウェア解析機能

② セキュリティベンダの協力により、

不正通信内容を分析

③ AVVの協力を得て解析

④ NW上での動作解析

•不特定多数向けの通信をルーティングし集約

IDSIDSでも検知でも検知

① ISPの協力により不特定多数向けの通信を集約

構築したハニーポットの概要


ハニーポットでの観測内容

Internet

DDNS SV

IRC SV

DNS SV

①検体収集＋初期動作

②検体解析

③DNS名前解決のトラフィックおよび、その他のトラフィック

④IRCとのやりとり

⑤UP Date/download

⑥SPAM送信

⑦DoS等の攻撃

4

3

6

SV

5

7

Super Honey

ボット解析チーム

検体

URLIP情報

1

2

次項以降で①～⑦についてワンポイント解説


① 検体収集　

• 検出数 4月1日～5月12日 (42日間）

• 同一ファイルサイズで異なるハッシュ値を持つ検体の増加– WORM_POEBOT.Iなど

トータル平均/日

件数種類件数種類

検出数 31,846 3705 758.2 88.2

既知 28,309 767 674.0 18.3

未知 3,537 2,938 84.2 70.0

　


① 検体の分類（種の同定）

● 収集した検体の80%はボット

– 収集した検体のうち、80%はボットに分類されるものであった。

– Malwareのトレンドが、ワームからボットに推移していることを反映しているものと思われる

● ボットのトレンド（上位3つで95%）

– 検出したボットの内訳では、RBOT, POEBOT, SDBOTの上位３種で、ボット全体の95%を占めている。

– これらのボットが、一部空間において、きわめてポピュラーであることをうかがわせる。

80%

20%

ボット

その他

60%24%

11%5%

RBOT

POEBOT

SDBOT

その他


① 検体取れ高 TOP15

8550

4644

1808

1765

1727

1346

1189

736

651

620

516

467

464

402

343

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

WORM_POEBOT.I

WORM_RBOT.AYO

WORM_RBOT.KZ

WORM_RBOT.GEN

WORM_RBOT.GEN

BKDR_SDBOT.DP

BKDR_SDBOT.GAA

WORM_RBOT.GEN

TROJ_SMALL.AOH

WORM_NACHI.A

WORM_DABBER.C

BKDR_RBOT.S

PE_PARITE.A-1

WORM_RBOT.AQT

WORM_RBOT.XQ

検体取れ高 TOP15分析対象期間： 2005/03/31 - 2005/05/31


① ボット収集実績の推移

● ハニーポットでのボットの収集実績をみると、かなりの増減があることが判明

– 常時20種程度のボットが感染活動を行っている

– 20～100種の新種・亜種が感染活動を行っている

– 活発な活動が行われる期間がある

検体数の推移

0200400600800

10001200140016001800

3/31 4/

7

4/14

4/21

4/28 5/

5

5/12

5/19

5/26

既知未知

検体(種類数)の推移

0

20

40

60

80

100

120

140

160

3/31 4/

7

4/14

4/21

4/28 5/

5

5/12

5/19

5/26

既知未知


① ボット感染時の初期動作

脆弱性検出数割合

MS03-026 371142 31.5%

MS04-011 313754 26.7%

Share Access 278586 23.7%

MS03-039 212503 18.1%

MS04-007 1046 0.1%

MS02-045 24 0.0%

MS03-043 12 0.0%

感染開始

脆弱性の利用

TFTPによる本体のダウンロード

IRC通信の開始

IRCサーバへの接続

HTTPを使ったダウンロード命令

近接IPスキャン開始

ﾀﾞｳﾝﾛｰﾄﾞ開始を通知

待機感染

感染時の動作感染時に利用する脆弱性(Windowsの場合）

16, 67%

7, 29%

1, 4%

TFTP-GET

Reverse Connect

Backdoor

本体の取得方法


②検体からIRCサーバ等を抽出● 抽出方法

– BOT検体中から、FQDNやIPアドレスと思われる文字列を抜き出す。

• イメージは、strings 検体

– しかし、BOTは難読化が行われており、簡単には抜き出せない

• 難読化の解除を行った後、上記処理を行うのだが、現状では手作業で行うしかないため、非常に時間のかかる作業となった。

● 抽出結果

分析の対象としたボット 100

複数のIRCチャネルを持つボット 19

分析の対象としたIRCサーバ(FQDN) 68

複数のボットに参照されるIRC 15

複数のIPを持つIRCサーバ 13

名前解決ができないFQDN 23

到達できないIPが割り当てられたFQDN 10

正引きと逆引きが異なるFQDN 22

ボットの分析

IRCの分析


③ DNS名前解決のトラフィック

● DNSに対する　A for A Query– ハニーポットから、DNSに対して　A for Aと呼ばれるQueryが連

続して観測された

– A for Aとは、DNSに対して IPアドレスをFQDNとして問い合わせるもの

• gethostbyname(“192.168.1.1”);→　A for Aは送信されない

• DnsQuery(“192.168.1.1”, …);→　A for Aが送信される

– ボットやウイルスなどに感染したIPを調べる際に、A for Aがひとつの手がかりとなる可能性がある。

• 特定のOSに依存する仕様である可能性もあるので要注意


ボット IRC接続の動き

ISP-A ISP-B

ISP-C ISP-D

DDNS SV

IRC SV

DNS SV

①DNS名前解決のトラフィック

②IRCSVに対する接続　（TCP/UDP)

③IRCのやり取り 1

1

23

④　ボットとIRCとのやりとり


④　ボットとIRCとのやりとり

• ボットが利用するIRCサーバは、6667/TCPが約半数を占めるが、他にも様々なポートを利用している

• 観測をしてみると、– 感染直後にボットの更新を行う

動きがある

– 頻繁にボットの更新が行われている

– 複数のIRCチャネルに接続する場合が多い

出現数

48.2%

29.3%

7.6%

5.7%2.1%1.3%1.3%1.1%0.5%0.3%0.3%

6667

5562

5122

65348

4150

6663

65267

10362

31337

50657

50478

IRCサーバのポート

IRCのサマリ

5/145/14 5/155/15 5/165/16 5/175/17 5/185/18 5/195/19

100100 Update/downloadUpdate/download

ScanScan

DDoSDDoS


⑤UP Date/download

• 頻繁なダウンロードは次のような目的があるものと推測

– IRCチャネルの変更

– ボットネットの構成の変更

– SPAM送信用のRedirectポートの変更

– 機能の追加

– 目的に応じたボットネットのチューニング

ダウンロードURL ファイル種類

http://HostA/freecontent.exe freecontent.exe 不明

http://HostA/screensaver.exe screensaver.exe 不明

http://HostB/Hearts.exe Herts.exe gaobot.gen.d

http://www.HostB/jalbout.exe jabou.exe sdbot.gen.bh

http://www.HostC/df.exe df.exe Generic.QLowZones.a

http://HostD/df.exe df.exe Generic.QLowZones.a

ダウンロードの例

5/145/14 5/155/15 5/165/16 5/175/17 5/185/18 5/195/19

100100 Update/downloadUpdate/download

ScanScan

DDoSDDoS


ボット攻撃(SPAM)時の動き

The Internet

TARGETMail SV

　

IRC SV

DNS SV

①メール指示（Redirect)

②DNS参照（Aレコード)

③メール送付

④メール取得

1

2 34

SPAM送信時は、IRCサーバは経由しないようだ

⑥SPAM送信


SPAM送信時のシーケンスSPAMMERSPAMMER ZombieZombie Victim MTAVictim MTA VictimVictim

CONNECT情報送信CONNECT 67.28.113.14:25 HTTP/1.0

TCP 3186に接続

TCP25に接続SYNSYN/ACKACK

TCP25接続OK情報送信HTTP/1.0 200 Connection established

220 domain ESMTP

220 domain ESMTP

HELO HELO

250 OK reply250 OK reply

MAIL FROM: MAIL FROM:


ACK

RCPT TO: RCPT TO:


DATA DATA

354 Start mail input; end with .354 Start mail input; end with .

文面文面

..


QUIT QUIT

250 OK reply250 OK reply送信

ACK

SYNSYN/ACKACK

• SPAMは、Redirectを通じて、左図の手順で送信が行われる。

• Redirectのコマンド中に、送付先のメールサーバが含まれているため、ボットは、Aレコードとして、このアドレスを参照し、MXレコードを参照することはない。


Redirect Port

3186

36%

6329

36%

3104

12%

24853

6%

47257

4%

7430

3%

7785

3%

3704

0%

1868

0%

2232

0%

SPAM送信(リダイレクトポート)

• SPAMの送信はRedirectが利用され、IRCチャネルは利用されない

• Redirectポートは、頻繁に変更されている


SPAMSPAMメール送信パターンとボットネットの関係メール送信パターンとボットネットの関係

●●ISPISPののMTAMTAを使用する場合を使用する場合（ボットは無関係）（ボットは無関係）

x.x.x.x

SMTP(spam mail)

SPAMER(ISP-Aユーザ) MTA SPAM reciever

ISP-A

ISP C

SPAM reciever

ISP BMTA

MTASMTP(spam mail)

SMTP(spam mail) SMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)

対策自MTAにおける流量制限


通常のメール送信と同様に見える



x.x.x.x

SMTP(spam mail)

SPAMER(ISP-Aユーザ) MTA SPAM reciever

ISP-A

ISP C

SPAM reciever

ISP BMTA

MTA

SMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)

対策Outbound TCP25 block


SMTP(spam mail)



●● Direct To MX Direct To MX （ボットは無関係）（ボットは無関係）各ISPのアカウントへ直接メール送信



x.x.x.x

SMTP(spam mail)SPAMER

（ISP-Aユーザでも以外でもOK）

MTA SPAM reciever

ISP-A

ISP C

SPAM reciever

ISP BMTA

MTASMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)

SMTP(spam mail)



TCP25以外(spam mail)

TCP25 blockは効かない。

第三者通信のイメージ

●● ボットネットを活用したボットネットを活用したRedirect Redirect 送信送信 1/31/3



●● ボットネットを活用したボットネットを活用したRedirect Redirect 送信送信 2/32/3

x.x.x.x

SMTP(spam mail)

MTA SPAM reciever

ISP-A

ISP C

SPAM reciever

ISP BMTA

MTA

SMTP(spam mail)

SMTP(spam mail)SMTP(spam mail)

SMTP(spam mail)対策Outbound TCP25 block




TCP25以外(spam mail)

※zombie自体がsubmission(tcp587)、SPF等の技術を使用する場合もあるためTCP25 blockが有効ではなくなる可能性あり

SMTP(spam mail)

第三者通信のイメージ

SPAMER（ISP-Aユーザでも以外でもOK）



●● ボットネットを活用したボットネットを活用したRedirect Redirect 送信送信 3/33/3攻撃者はどこにいてもあらゆる制限をかいくぐってspam送信できる。

x.x.x.x

SMTP(spam mail)

ISP X

user

ISP A

SMTP(spam mail)

SMTP(spam mail)

ISP B

MTA

MTA

MTA

TCP25TCP25以外以外 (spam mail)(spam mail)

user

user

Zombie

Zombiec

Zombie

TCP25 (spam mail)TCP25 (spam mail)


Honey pot Honey pot 長時間解析結果（長時間解析結果（SPAMSPAM））

●ボット端末１台あたりのspam送信数１時間あたり平均　6890通（最大11679通）１秒で　 1.94通（最大3.24通）

●流量制限に引っかからないように1MTAあたり数通～数十通にとどめ、利用するMTAを順々に変えていく。- botnetは数千台のZombieをコントロール可能

●ボットはsubmissionやSPF、sender auth等も利用できるらしい。・outbound tcp25 blockは効かない

●日本の多くのユーザPCが、Botnetに組み込まれたり、欧米のメール送信業者にredirector/proxyと登録されている。


⑦ ボット攻撃(DoS)時の動き

ISP-B

TARGET

IRC SV

DNS SV

①攻撃指示（ＩＰアドレス指定）

②攻撃指示の転送（ＩＰアドレス指定）

③攻撃

1

2

3


攻撃者（実行者）

ISP X

DoSDoS命令命令victim

Zombiec

Zombie

攻撃者（依頼者）

DoS攻撃（Syn等）

ISP-C

Zombie

ISP A

ISP B



攻撃者はどこにいてもターゲットの攻撃ができる。


Ｃ: ISPへのヒアリング調査

ISPが把握しているノイズ分析


ISPISPへのヒアリング調査結果へのヒアリング調査結果

●複数のISPに対して、調査 A・B で得られた、ボットネットの通信特性に関する調査データを提供

●ユーザのプライバシと通信の秘密に配意し、ISP独自の手法でボットの存在を分析。そしてその結果のみをヒアリング

●結論：日本のISPユーザの 22～～22.5.5％％がボットに感染していることが判明。– 40～50人にひとりが感染。（学級にひとり）

– 複数のISPで想定感染率が近似。

– BBユーザが2000万契約とすると40～50万人(台)が感染。


調査結果のまとめ


ボットネットのフィードバックループ

BOT

機能追加・変更

通信手段の変更

ﾊﾞｰｼﾞｮﾝｱｯﾌﾟ

各種指示

ボットネットの維持

感染活動（数秒間）

　増えすぎると困るので

自己防衛・ｽﾃｨﾙｽ機能

攻撃機能：最終目的

DDoS・スパム

踏み台(Proxy)

　攻撃目標を参照？

攻撃目標の収集

ステータスの収集

その他収集

IRC,P2P等ネットワーク

拡張可能、ﾌﾟﾗｸﾞｲﾝあり

接続BOT数の制限（3000程度）

ｽﾃｨﾙｽ化：認証、暗号化

IRC等のｺﾝﾄﾛｰﾙ


ボットの代表的な感染パターン

• 現在の主流– OSの脆弱性を突いて感染

– パスワードのないファイル共有を利用して感染

– メール添付型ウィルスにて感染

• 最近は一部の企業狙いのウィルス（トロイの木馬）が流行

• 一部では– Webページ閲覧時にダウンロード

• 今後は– P2P経由

– MSメッセンジャー

– Skypeなどのメッシュ系アプリ


数値化できる調査結果

• インターネットの現状

– ボットやウィルス等によるトラフィックは、0.3kbps/IPに達する• 国内に割り当てられたIPに換算すると10Gbpsに相当する

– ボット経由のSPAMメールのトラフィックなどは含まれていない

– 国内でのボットの感染率は 2%~2.5%程度

– 未対策のPCをインターネットに接続すると、平均４分で感染する

– 一日平均70種以上の亜種が確認された


ソースコードの解析結果

• ボットについて（解析結果より）

– 多くのボットはソースコードが流通している

– VMware等の擬似環境やDEBGUERの下では動作しない

– 感染すると、アンチウイルスソフトの機能停止を試みる

– 感染には比較的古い脆弱性と共有設定が行われる

– 感染時には自己複製を行なう場合が多い（多くはTFTP）

– それぞれの感染行為は、限定されたIPレンジで行われる


ハニーポット等の解析結果

• ボットネットの実態– 専用と思われるIRCサーバが利用されている（公開IRCではない）

– SPAM送信は、IRCチャネルではなくRedirect/Proxyを利用する

– 攻撃だけではなく情報収集に利用されている• 感染したPC内部の情報と、周辺に存在するPCの脆弱性等の情報

– サーバのFQDNは、DDNSを利用している場合が多い

– DNSサービスを利用して複数のIPを割り当てているケースがある

– IRCサーバのDNSエントリーを操作することで、休眠状態？の場合がある

– サイトへのDDoSやSPAM送信を行うには、数百台のボットネットで十分

– ボットのアップデートは頻繁に行われている

– イントラネットに侵入しているケースも確認


考察：浮かび上がった事実

• 社会的な問題– ボットネットのDDoS攻撃により任意のタイミングで、インターネッ

トバックボーンに影響を与えることが可能• SQL Slammerが発生した際の韓国インターネット

– レンタルや販売により、技術力がなくともボットネットを利用可能

• ボットネットの乗っ取りと考えられる通信も観測されている

– SPAM送出のインフラストラクチャとして機能しており、健全なインターネットの発展を阻害する要因になっている

• コンテンツ配布の問題

• メールトラフィックの問題


●● ISPとMalwareとの戦い（～2005）•EpisodeⅠ ： CodeRedⅡ/Nimda/Slammer （2001～）•EpisodeⅡ ： Blaster/Sobig F （2003 Summer）•EpisodeⅢ ： Antinnyシリーズ（2004）•EpisodeⅣ ：ボットネット（2005）


EpisodeⅠCodeRedⅡ / Nimda / Slammer （2001～）


CodeRedCodeRedについてについて

世界中にある600万以上のIISサーバが攻撃対象に…

時間経過


Code Red Code Red の活動状況の活動状況

■ 2001年6月18日 ISAPIエクステンション「idq.dll」の弱点が報告

■ 2001年6月19日マイクロソフトから日本語版パッチと解説が公開

■ 2001年7月13日弱点をつくワームウィルス「Code Red」発見

■ 2001年7月30日被害は2828万万以上に拡大■ 2001年8月1日活動再開！2626万万以上に拡大■ 2001年8月3日 CodeRedＩＩが発見。国内では影響が甚大!!

■ 2001年9月9日 CodeGreen や Blue も登場

被害の爆発的拡大が特徴被害の爆発的拡大が特徴

2001年9月18日 Code Red再発と思いきや「NimdaNimda」登場


CodeRedCodeRedの特徴の特徴

●● #80#80ポート（ポート（httphttp））の脆弱性を狙った感染活動の脆弱性を狙った感染活動WebWebシステムを持つ、ルータも影響を受けたシステムを持つ、ルータも影響を受けた

●● IISIIS（（英語版）の英語版）のWebWebサーバのコンテンツを改ざんサーバのコンテンツを改ざん

●● ハッカーが後から楽に侵入できる「バックドア」を作成ハッカーが後から楽に侵入できる「バックドア」を作成

●● 他の他のIISIISサーバ向けに大量の感染攻撃パケットを出すサーバ向けに大量の感染攻撃パケットを出す

●● ホワイトハウスにホワイトハウスにDDoSDDoS攻撃を仕掛ける（失敗）攻撃を仕掛ける（失敗）

●● 活動のスケジュールが決まっていた。活動のスケジュールが決まっていた。1 1 --1919日日感染活動感染活動・・ 2020--2727日日 DDoSDDoS攻撃攻撃・・ 2828--月末月末活動休止活動休止

●● 20012001年年1010月で死滅月で死滅


CodeRedのインターネットへの影響 1/2

IIS IIS IIS IIS

InternetRouterRouter

IIS IIS IIS IIS

InternetRouterRouter

■ 一般的なインターネット・トラフィック ■ CodeRed ワーム等が出すトラフィック

ランダムに大量な感染行動を起こすトラフィックに、ISPの収容ルータのメモリ（アドレスキャッシュ）が圧迫される。


定期的に Clear ip cacheを実施たルータの Largest Memory

定期的に実施しなかったルータの Largest Memory

CodeRedのインターネットへの影響 2/2


パンドラの箱を開けてしまったワーム型ウィルスパンドラの箱を開けてしまったワーム型ウィルスNimdaNimda（（ニムダニムダ））

Nimda 2001/09/18～NimdaNimda 2001/09/182001/09/18～～

Code Red 2001/07～Code Red Code Red 2001/072001/07～～

Apost 2001/09～ApostApost 2001/092001/09～～

Magistr 2001/03～MagistrMagistr 2001/032001/03～～

Code Blue/ Green 09～Code Blue/ Green Code Blue/ Green 0909～～

sadmind/IIS 2001/05～sadmindsadmind/IIS /IIS 2001/052001/05～～SirCam 2001/07～SirCamSirCam 2001/072001/07～～

悪意の集大成

悪意の集大成

単品の悪意単品の悪意

ハイブリッドされたハイブリッドされた悪意悪意

Nimda （ニムダ）について

その後その後NimdaNimdaを真似た、新手のワーム「を真似た、新手のワーム「KlezKlez」「」「BugBearBugBear」」が続々登場が続々登場


NimdaNimdaの感染経路の感染経路

１．直接感染インターネットをスキャンし脆弱なIISサーバを探して直接感染する。･･･Code Red/Blue/Green, sadmind/IIS

２．Webページ経由の感染JavaScriptやActiveXを使って、Webページから悪質なコードを広める手法。大規模成功事例は少なかった。

３．ファイルコピー（共有）経由の感染オープンなネットワーク共有ドライブを探し感染を拡大。･･･Magistr

４．メール経由の感染大量に添付ファイル付き電子メールを送信し感染を拡大する。･･･SirCam,Apost(readme.exe)

インターネットにダメージを与えるために設計された悪意のワーム


IIS

IIS

IIS

IIS

IIS

IIS IIS

IIS

IIS

感染感染

スキャンスキャン ○○

××○○

感染感染

- CodeRed II が作ったバックドア- 脆弱なIISサーバ（セキュリティ総合パッチ未適用）

攻撃のパターン50％ → 210.1.*.*25％ → 210.*.*.*25％ → 完全なランダム

210.1.2.3

（1） Code Red/Blue/Green, sadmind/IISと同様の手法で直接感染拡大を図る。

１．直接感染のイメージ


InternetIIS

感染感染

改ざん改ざんWebWebページページ

PCPC PC

IE＋Outlookセキュリティ対策済み

IE＋Outlookセキュリティ対策未実施

Mac

○○ ××感染感染 ○○

２．Webページ経由の感染イメージ


脆弱性のあるInternet Explorer / Outlook（Outlook Express）の組み合わせでは、ユーザーが明示的にダウンロードや実行を指示しなくても、プレビューするだけで自動的に実行してしまうというバグがある。

● クライアントPC（IInternet EExplorer）の脆弱性を突いて侵入① 脆弱性のあるInternet Explorerでニムダに感染したWebページを

見る又はプレビューすると自動的に感染。

② 悪意のJAVAスクリプトにより、（readme.eml）をダウンロードする際のポップアップWindowが見えないのでユーザも気付かない。

? window.open("readme.eml", null, "resizable=no,top=6000,left=6000")

③ そして自動的に実行されてしまう。CONTENT-TYPEを“content-Type: audio/x-wav;”に偽装。


サーバの共有ディレクトリ経由でNimadaが流布され感染する方法

共有フォルダ経由で自分自身のコピーを配布し、他のユーザーがそれをプレビューしたり、起動したりするのを待つのである。メールやインターネットへアクセスしなくてもNimdaに感染し他のマシンへの感染が拡大。

PCPC PC PC

共有フォルダ

３．ファイルコピー（共有）経由の感染


PC???

メールアドレスを抽出[email protected]@[email protected]@[email protected]@[email protected]@[email protected]

Internet

Intranet

• 脆弱性のあるOutlook/Outlook Expressではプレビューを見ただけで感染。• 他のメールソフトの場合は、添付ファイルをダブルクリックすると感染。

PC

PC

PC

PC

４．メール経由の感染イメージ


出展：アンラボ社（http://ahnlab.co.jp/virusinfo/view.asp?seq=329）

【参考】Ｓｌａｍｍｅｒによるネットワーク帯域の消費

●日本時間2003年1月25日14:30頃、 MS SQLサーバの脆弱性（セキュリティホール）を狙ったワームが中国（香港）、韓国、米国を中心に発生。

●コンピュータに感染するとメモリ上に常駐、ランダムなIPアドレスを生成し376バイトのUDPパケットを1434ポートに継続的に送信。（80 M byte/sec ≒ 640 Mbit/sec）

●このWormに感染したコンピュータが増えることによって、ネッワークトラヒックを増大させ、世界規模でのネットワーク障害となった。

● １０分間で世界中の脆弱性をもつサーバーの９０％（7.5万台）に感染と推定

SQL Slammerについて


1/20 1/21 1/22 1/23 1/24 1/25 1/26 1/27

◆発生日時　　：平成１５年１月２５日　１４：３０　◆サービス影響：韓国向け通信については一時的にトラフィックが「０」

になった。実はトラフィックが減っていた!!１４：３０～１６：３０の約２時間（勝敗は最初の5分）


ネットワーク感染型ワームの全盛期

● ADSLなど常時接続BBインターネットが本格化BBインターネットがワームの感染活動をトラヒックの暴力に変えてしまった。

1.5Mbps

64Kbps個人の主流個人の主流

企業の主流企業の主流

128 kbps

1 1 MbpsMbps～～100100MbpsMbps

20012001年頃年頃 20032003年～年～

数百倍のパワー！数百倍のパワー！


トラヒックの暴力に備える術はない？

ISPのルータ ISPのルータ

平常時ワームやDDoS発生時

Router

Internet

Router

Firewall


課題と教訓

CodeRedⅡ / Nimda / Slammer （2001～）

愉快犯だから助かった・巧みな感染手法（Nimda）、永久に続くMalwareの脅威

MalwareのNW上での動作に関する解析情報が不足・ISP目線での解析情報が不足・ホワイトハウスはCodeRedを解析し、DDoS攻撃を未然に防いだ。

ISPもMalwareの悪影響を受けないためにはNW目線の解析情報の共有が重要

トラヒックの暴力の時代・もはやISP単独で対処できる状況では無くなった・攻撃の流入口での対処が重要


EpisodeⅡBlaster / Sobig F （2003 Summer）


ワーム等発生の時系列変化ワーム等発生の時系列変化

脆弱性情報の公開

Exploit Code公開

ワーム等の出現

大規模な蔓延

突如セキュリティ関連Webに登場前触れとして、UGサイトに出ることも

脆弱性情報が公開されてから、早ければ数日から10日程度で登場

Exploit公開から、早ければ数日程度で登場

未対策ユーザが多く、ワームの設計が巧妙であれば被害は必至

ISPの動き：事後対応中心から変化追従型に進化


BlasterBlasterの対応例の対応例

BlasterBlasterとはとは●●MS03MS03--026026を狙ったワーム型ウィルスを狙ったワーム型ウィルス

・・Windows 2000Windows 2000ととWindows XPWindows XPが感染対象が感染対象OSOS・・135/TCP135/TCPにアクセスし「にアクセスし「RPC DCOMRPC DCOMのバッファオーバーフロー」の脆弱性のバッファオーバーフロー」の脆弱性(MS03(MS03--

026)026)を利用してコンピュータに侵入。を利用してコンピュータに侵入。・自・自IPIPアドレスに近いアドレスにランダムな感染活動を仕掛ける。アドレスに近いアドレスにランダムな感染活動を仕掛ける。・・20032003年年88月月1616日になるとマイクロソフト社の「日になるとマイクロソフト社の「Windows UpdateWindows Update」の」のWebWebサイトにサイトに対して対してDoSDoS攻撃を仕掛ける。攻撃を仕掛ける。

••感染した感染したPCPCは悲しいカウントダウンを繰り返す。（リブート祭り）は悲しいカウントダウンを繰り返す。（リブート祭り）

●● Blast‐D・Nachi・Welchiaと呼ばれる亜種も猛威・感染対象のIPアドレスにpingを打ち、「MS03-026」を利用して侵入を試みる。

Blasterが使わない「MS03-007」脆弱性も利用する。・オリジナルのBlasterを駆除し、対策パッチを当てるという変わった挙動をする「親切な?」ウィルス


脅威の時系列変化と脅威の時系列変化とISPISPの対応の対応


Exploit Code公開

ワーム等の出現

大規模な蔓延

MS03-026 2003 07-17（JST）情報共有開始

BugTraq（2003 07-27）“DCOM RPC exploit”が投稿

08-05

08-11

MS03-026を狙うトロイの木馬発見

MS03-026を狙うBlaster発見

08-12

08-14

ISACとNIRTとの情報連絡体制構築

緊急対応体制へ


緊急対策会議 08-14

01:00

ISP-NWへの影響度合いの分析と、対応策の検討を行う（マイクロソフトと協議）

全ユーザへの注意喚起メール発出（OCNの例）

09:00 監視及びユーザ対応体制強化（OCNの例）

緊急対策実施08-15

17:00 対応策決定、対策実施※Windowsupdate.comへのDDoS対策含む

23:00 重点監視体制へシフト

マイクロソフトがDNSのAレコード削除


BlasterBlaster亜種亜種ICMP急増

BlasterBlaster亜種の対応亜種の対応

Blast‐D・Nachi・Welchia


Blaster亜種（ Blast‐D・Nachi・Welchia ）

ネットワークの異常を検出

・ICMPパケットの急増を確認。インシデント情報を調査するも原因不明

・一部ユーザのネットワークが輻輳（緊急対策実施）

08-1810:30

08-18夜AVソフトベンダの

情報発信08-19

日本や韓国のAVソフトベンダがBlaster亜種の情報を発信

欧米のAVソフトベンダがBlaster亜種の情報を発信

08-19 各社が対応ISPユーザ周知

日本独自の情報分析力保有の必要性を痛感


SobigSobig--F F の対応例の対応例◆ 約1.8Mbyteの巨大ワーム。

ダミーワームも内包し動作解析に時間を要した。

◆ 世界中のホスト（20）からプログラムをダウンロードし、第三者の指令で何らかの動作を行う仕様。

◆ 世界中の関係者の協力で20台のホストは閉鎖された。日本でも複数のISPが連携し当該ホストへの通信をブロックした。

◆ SPAMメールの発射台やDoS攻撃の発射台などワームが明らかな意図や目的を持ったプログラムに変化。

◆ Sobig-FはSPAMメール送信ビジネスのツールとして開発されていた？


SobigSobig--F F ワームの検知数ワームの検知数

★ Sobig-Fは9/10で終息している。※ 通常を１とした相対的なグラフ


SobigSobig--FFの対応例の対応例

Sobig-Fの出現欧米で感染が拡大との情報08-19

ISPユーザ周知

・日本でもAVシステムで急速な感染を確認（パターンファイル更新と同時）

08-19夜

各社対応08-20

Sobig-F 解析情報入手

08-22・トロイの木馬機能の活性化が23日早朝にプ

ログラムされているとの情報

緊急対応 08-23・トロイがダウンロードするサーバIPアドレス20を

遮断。（攻撃は不発のため後日対策解除）


Blaster/Blaster/SobigSobig--FFの教訓の教訓

●● インシデント情報の収集と分析の重要性インシデント情報の収集と分析の重要性–– 予兆情報の収集（ワームの挙動分析）予兆情報の収集（ワームの挙動分析）–– トラヒックの異常を観測するシステムトラヒックの異常を観測するシステム–– 国内に分析機関が複数必要国内に分析機関が複数必要–– 関係機関との連携の重要性関係機関との連携の重要性（（ISPISP単独では無力）単独では無力）

●● お客様システム対応の重要性お客様システム対応の重要性–– トラヒックの暴力でネットが混乱トラヒックの暴力でネットが混乱

•• 磐石のシステムを構築しても利用できなきゃ無意味磐石のシステムを構築しても利用できなきゃ無意味•• 自分が感染しても「気づかない」ユーザが多い自分が感染しても「気づかない」ユーザが多い•• バッチがダウンロード出来ないバッチがダウンロード出来ない

–– ISPISPにとって顧客対応コストが膨大にとって顧客対応コストが膨大


●：●：ISPISPとしてなすべきこととしてなすべきこと / / ○：誰かと一緒にやりたいこと○：誰かと一緒にやりたいこと


Exploit Code公開

ワーム等の出現（トロイ含む）

大規模な蔓延

○ 影響度合の分析（パッチ有効性確認）● ユーザ周知（メール＆Web）

○ 情報共有・監視体制・動作確認

○ ワームの挙動分析○ 監視体制の強化・監視情報共有● ISPネットワークでの対策検討

○ 緊急対策指示（避難勧告？国防モード？）● ISPユーザ再周知● ISP-NWでの対策実施

お祭りの後に○ 顛末（分析）整理と、類似事案発生を考慮し

た「政府・ISP・ベンダ」のアクションプラン作成

Blaster/Blaster/SobigSobig--FFの教訓の教訓


EpisodeⅢAntinnyシリーズ（2004～）


AntinnyAntinnyの対応例の対応例

AntinnyAntinnyとはとは●●P2PP2Pソフト「ソフト「WinnyWinny」に感染し、」に感染し、P2PP2Pネットワークを利用してネットワークを利用して

感染拡大するワーム型ウィルス感染拡大するワーム型ウィルス

●●感染した感染したPCPCの情報を漏洩させ、多くの個人情報漏洩や企の情報を漏洩させ、多くの個人情報漏洩や企業情報の流失事件を起こしている業情報の流失事件を起こしている

●●AntinnyAntinnyの亜種の一部は、「社団法人コンピュータソフトウェの亜種の一部は、「社団法人コンピュータソフトウェア著作権協会」のホームページに過剰なアクセスを行うア著作権協会」のホームページに過剰なアクセスを行う

•• 毎月第一月曜日・ゾロ目の日等にアクセスを集中毎月第一月曜日・ゾロ目の日等にアクセスを集中


• 2004年4月5日突然ISPが運用するDNSの負荷が急上昇

• クエリが平常時の6倍以上に跳ね上がる異常事態発生

AntinnyワームのISPネットワークへの影響

2004.4.5 Mon


ISP

WEBサーバ

DNSサーバ

Wormに感染したエンドユーザ

DNSサーバ

①WebｻｰﾊﾞのFQDNに対する　名前解決要求(Wormが頻繁に繰り返す)

②WEBｻｰﾊﾞのFQDNに対する　再帰的な名前解決要求　(TTLが経過する都度発生)

③「そんなAﾚｺｰﾄﾞはない」

④「NXDOMAIN」

通常の6倍以上発生

DDoS攻撃

被攻撃Webｻｲﾄ

DNS

DNS

Web

高負荷

アクセス集中（DDoS攻撃）から救われる

大量のクエリが発生した背景大量のクエリが発生した背景

あるWebサイトへのDoS攻撃が発端となった


ACCS殿へのコンタクト開始

• Antinnyウイルスの情報http://www.trendmicro.co.jp/vinfo/virusencyclo/default5.asp?VName=WORM_ANTINNY.Ghttp://www.symantec.com/region/jp/sarcj/data/w/w32.antinny.k.html

– Winny利用者に感染

– 特定日に特定サイトに個人情報をアップロード

• 外部機関からの情報と観測情報– Antinny ウイルスがアップロード先をDNS解決できるまで無限ループする

• 2004年4月26日 telecomISAC Japanとして ACCS殿にコンタクト– Aレコードを消すとISPのDNSに影響がある

– telecomISAC Japan側から代替対策案を提案


ISP

WEBサーバ

DNSサーバ

ワームに感染したエンドユーザ

DNSサーバ②WEBｻｰﾊﾞのFQDNに対する　再帰的な名前解決要求　(TTLが経過する都度発生)

③「AﾚｺｰﾄﾞはブラックホールIPです」

④「AﾚｺｰﾄﾞはブラックホールIPです」

DDoS攻撃

ブラックホールIP

破棄！

正式にBlackhole用IPｱﾄﾞﾚｽを応答する被攻撃Webｻｲﾄ

DNS

DNS

Web

高負荷から救われる

アクセス集中（DDoS攻撃）から救われる

①WebｻｰﾊﾞのFQDNに対する　名前解決要求

ブラックホールIPによる攻撃回避策


パケット破棄は各ISPで設定した

DDoS攻撃

DDoS攻撃

DDoS攻撃

ブラックホールIPで破棄

DNSサーバ WEBサーバ

被攻撃Webｻｲﾄ

DNS情報が伝播

DNS WebブラックホールIPで破棄

ブラックホールIPで破棄

Telecom-ISAC Japanが中心となり大手ISPが連携


DNS query バーストの防止およびDDoS 通信の排除

• 6月、7月: 結果としてDNSは救われた

• Blackholeアドレス利用による通信破棄によりネットワーク上の状況も変化なし

2004/06のあるDNSサーバの状況

2004/04のあるDNSサーバの状況


対策結果と分析

• ACCS殿– 依然としてACCS殿のWebサーバはアクセスできない

• telecomISAC Japan 側– ISPのDNSサーバは救われたがDDoSには対応できていない

– 日本国内のみのDDoS事案で比較的調整が容易

– 定期的に再現するDDoSは世界的にみても珍しい

• ACCS殿からの依頼に基づき通信状況の調査を行う– DDoS通信の様態を詳細に観測する

– ACCS殿の現状を打開するための方策検討の基礎データとして利用する

– 可能であれば一般的なDDoS対策手法を確立したい

• telecomISAC Japan会員内で実施方策を応募– 8月: 既存の環境で通信の様子を直接観測(IIJ)


更なる実態調査１

• 接続構成

ISPバックボーン

ルータ

観測システム

ACCSサーバ


ACCSサーバへの通信TCPフラグの様子,80/tcp(2004/08)

①データ欠損: synfloodの兆候②8/1開始: 通常のGET(?)③8/2第一月曜日: synflood(?)④8/8ゾロ目の日: POST(?)⑤8/5: connection floodの兆候

①データ欠損: synfloodの兆候②8/1開始: 通常のGET(?)③8/2第一月曜日: synflood(?)④8/8ゾロ目の日: POST(?)⑤8/5: connection floodの兆候

①

② ③

① ①

④⑤


更なる実態調査２

• DDoSに対して資源(接続回線、サーバ)を

できるだけ用意して受けてたとう！

• telecomISAC Japan会員内で実施方策を応募

– 9月: 十分な回線容量とサーバ量を用意して、通信の様子を直接観測(SoftbankBB)

• 方法

– 大容量回線

– 大規模サーバ

– POSTなど個人情報の含まれる通信の可能性を排除した

Webサーバのコピーを作成

– 攻撃開始を確認後ACCSサーバのAレコードをこの環境に向ける


L4スイッチ

バックボーンルーター

バックボーンルーター

Webサーバー群

物理構成

L2スイッチ

2 x GigE


①

②

①　第一月曜日発症のAntinnyによるDoS攻撃と想定されるポイント

②　ゾロ目の日に発症するAntinnyによるDoS攻撃と想定されるポイント

Antinnyの吐き出すトラヒック量

月額3000円のWebホスティングユーザが攻撃されたらどうしよう700Mbps以上の攻撃を受けて平気な人はどれだけいるだろうか？

月額3000円のWebホスティングユーザが攻撃されたらどうしよう700Mbps以上の攻撃を受けて平気な人はどれだけいるだろうか？


• 観測結果– 第一月曜日発症のAntinnyによるDoS攻撃の想定日

• トップページへのGETを繰り返すもの

• 最大で700Mbps程度のトラフィックが発生

– ゾロ目の日に発症するAntinnyによるDoS攻撃の想定日• データのPOSTを行おうとする為かトラフィックパターンが反転

• 結論– ACCS殿のコンテンツの配信は維持できた

– 現実的な費用で対応できるものではない

– 通信量はISPとしても脅威である


今回の問題と更なる取り組み

• ACCSで発生していることは、他のWebサイトでも発生する可能性がある。

• インターネットコミュニティ全体の問題となりうる可能性もある。

• 現在市販されているDDoS対応機器がどこまで有効に動作するか確認し、ISPとしてDDoS攻撃防止サービスが提供できるか検討してみよう！– ありがとう Ciscoさん!

• 今回はOCNさんが受けて立った！


ACCSWeb-Site

FirewallFirewall Block!Block!

※DDoS対応NW型FirewallはCisco社の協力を得て借用した

攻撃の99.6%をブロックしWebを守ることが出来た。が、課題も多い

DDoS対策トライアルのイメージ図● ISPのBBネットワークの中に、DDoS対応のNW型Firewall※を導入し、

攻撃トラヒックの軽減効果を確認した。

結論：結論：DDoSDDoS対策は簡単ではない。エンドユーザの理解、とサー対策は簡単ではない。エンドユーザの理解、とサービス提供に関わる全ての関係者の連携が不可欠ビス提供に関わる全ての関係者の連携が不可欠


DDoS経験者の主張(1)

• 攻撃の内容分析に基づく技術的な対策については現在検討中であるが、技術的にも資金的にも常識の範囲での対策は難しいと想定される。

• 並行して技術に頼らない対策が必要である。– 攻撃者の意図の有無に関わらず本人へのアクセスが必要– 意図を持たない脆弱PC所有者には重点的な対応が必要

• で、何を対応するのか– PCのセキュリティ対策をユーザに勧奨– 何度言っても聞かないユーザは解約？– そして、攻撃リスクがある一定限度に保てるインターネット環境を維持しつづける。

– SPAMメール対策と同様に厳しいユーザ対策が必要。


●● ISPとMalwareとの次の戦い（2006～）

Our security depends on your securityOur security depends on your security..


ISPISP（通信事業者）（通信事業者）として何を守るべきかとして何を守るべきかボットネットやワーム等によるトラヒックの暴力（ボットネットやワーム等によるトラヒックの暴力（DDoSDDoS・・SPAM SPAM etcetc）がセキュリティの概念を変化）がセキュリティの概念を変化させた。させた。

●● ISPISPのの商用設備の安定運用商用設備の安定運用○○ お客様システム（お客様システム（PCPC・・サーバ・サーバ・NWNW機器）機器）●● お客様情報お客様情報

商用商用設備設備

お客様お客様ｼｽﾃﾑｼｽﾃﾑ

？

Our security depends on your security.Our security depends on your security.


ボットネットを例にしたMalware対策

• 攻撃を受けた際の対策

– DDoS• IRCサーバを特定し停止する

• FQDNの参照をブロックすることで新しいIRCサーバの利用を防止する

– DDNSサービスを提供しているサイトに対して、FQDNの削除などを要求

– ISPのDNSキャッシュを書き換える

– SPAM• IRCサーバを利用しないため、DDoS対策と同様のIRCサーバ潰しではSPAM

をとめることはできない

– ただし、ボットネットが崩壊するので影響は受けるはず

• 地道な対策として

– OPEN REALYが可能なメールサーバを低減する

• 25/TCP以外でのメールコマンドを監視し必要に応じてブロックする


ボット感染ユーザの対策と、感染しないための仕組み● ボット感染ユーザの対策

– ボット感染ユーザの発見

• ハニーポットに通信する Src IP ユーザに対する注意喚起– 計画的且つ地道な取り組みを「今から」実施する必要がある

• ボットがアクセスするFQDNを検索するユーザへの注意喚起– IRC等のFQDNを抽出

» ボットの検体を取得し、ハードコードされたFQDNなどを抽出する» HoneypotでモニタしたFQDNなどを抽出する

• ボット系メール添付型ウィルス感染ユーザや検知（駆除）ユーザへの注意喚起

– ユーザのセキュリティ対策の推進

• ボット感染の大半は、脆弱性がターゲットなっている。• 基本的なITリテラシーなどの教育が重要• 感染したボットを駆除しPCを元通りに修復するツールが不足している

– アンチウィルスベンダではすべてのボットの実態を把握していないため別途の対策が必要


ユーザへの注意喚起を行う

ISP

ISP

ISP 攻撃捕捉装置

ISP管理者

ISP管理者

攻撃や迷惑メール送信元情報

攻撃や迷惑メール送信元情報

対策推奨

対策推奨


– IRCサーバの対策• 上記FQDNに対して、ループバックアドレスなどを返すようにDNSキャッシュを操作

する。

• これにより、そのDNSを参照しているボットは、IRCへの参加ができなくなり、結果として DDoS攻撃が行えず、また、SPAMのPROXYリストに載ることもない。

– TFTPのブロック• イントラネットとインターネットの境界で、TFTPをブロックする。

• ISPレベルでTFTPのブロックが行えれば、より効果的

– ブロードバンドルータの義務化• 主にADSL等において、TA型の終端装置ではなく、ルータ(FW)型の終端装置を利

用することを義務付ける。

• これにより、

– ワーム型の感染を防ぐことが可能になる

– TFTPのブロックを確実に行える

– 攻撃時にネットワークからの切断などの対処が可能


• 継続的な現状把握

– ボットネットの推移の早さへの追従

• ボットネットは、セルフメンテナンス機能を持っていることから、バージョンアップや更新が頻繁に行われており、短時間で形態が変化する。

• ソースコードが流通していることから、形態や機能を容易に追加・変更することが可能

• このため、観測とボットの研究を常に続けていないと、ボットネットの現状を的確に捉えることができず、攻撃が発生した際の対処が適切に行えないばかりでなく、リスク低減策が効果的かどうかが判断できない。


[email protected]

ボットネット実態調査結果 � Our security depends on your security��（ISPとMalwareの戦い EpsodeⅠ~Ⅳ）本日のアジェンダ● Telecom-ISAC Japanのご紹介● ボットネット実態調査結果ボットネット問題が表面化したきっかけ当時の状況ボットネットの基本的な構成ソースコードの入手と解析Botの基本的な機能(Agobot)メンテナンス機能（GUI付）ボットのコマンドの例ハニーポットでの観測内容① 検体収集　① 検体の分類（種の同定）① 検体取れ高 TOP15① ボット収集実績の推移① ボット感染時の初期動作②検体からIRCサーバ等を抽出③ DNS名前解決のトラフィックボット IRC接続の動き④　ボットとIRCとのやりとり⑤UP Date/downloadボット攻撃(SPAM)時の動きSPAM送信時のシーケンスSPAM送信(リダイレクトポート)⑦ ボット攻撃(DoS)時の動きISPへのヒアリング調査結果ボットネットのフィードバックループボットの代表的な感染パターン数値化できる調査結果ソースコードの解析結果ハニーポット等の解析結果考察：浮かび上がった事実● ISPとMalwareとの戦い（～2005）AntinnyワームのISPネットワークへの影響ACCS殿へのコンタクト開始パケット破棄は各ISPで設定したDNS query バーストの防止およびDDoS 通信の排除対策結果と分析更なる実態調査１更なる実態調査２Antinnyの吐き出すトラヒック量今回の問題と更なる取り組みDDoS経験者の主張(1)● ISPとMalwareとの次の戦い（2006～）��Our security depends on your security.�ボットネットを例にしたMalware対策

ボットネット実態調査結果 - black hat | home...ゾンビpc、botnet...

Documents