Internet Infrastructure Review(定期発行技術レポート) | Internet Infrastructure Review(定期発行技術レポート) | IIJ(情報元のブックマーク数)

小野寺さん経由

IIJのInternet Infrastructure Review(定期発行技術レポート)が出ていますが、通信業者としてのセキュリティ面の視点で物凄く良い資料です。

株式会社インターネットイニシアティブ (IIJ) から、興味深いレポートが公開されました。
http://www.iij.ad.jp/development/iir/

ISPの視点で、顧客であるインターネット利用者を保護するために、インシデントにどの様に対応していったかがまとめられています。 攻撃を受けたサーバー側や全体的で魏略的なレポートは今までも多くありましたが、ISPの立場で詳解されたレポートはあまり多くなく興味深い内容でした。
それにしても、ISPが回線や利用者を守っていくために、これ程までの労力(血と汗?)を費やしている事は知らない訳ではないつもりですが、レポートとして見てみると改めて驚かされます

http://blogs.technet.com/jpsecurity/archive/2008/10/07/3133293.aspx

これは、興味深い。ちゃんとP2Pな人も当てているということか。

IIJでは、この期間の7 月初旬に、突発的な通信量の減少を観測しました。これは、7月のマイクロソフトのOS アップデートで再起動を必要としたため、常時通信を行うP2Pファイル共有アプリケーション等を利用している端末において、通信が停止したためではないかと判断しています。

http://blogs.technet.com/jpsecurity/archive/2008/10/07/3133293.aspx

DDoSはネタに敏感、DDoSは実際に起きている、1日あたり3件とは、、、結構知らないあなぁ・・・

最近の傾向として、社会的に重要な出来事や、歴史的な事件に連動して、ネットワーク上でもインシデントが
発生しやすくなっています。本レポートの対象期間である2008 年6月から8 月までの3ヵ月間には、洞爺湖
サミットと北京オリンピックが開催され、その間インシデント監視体制を強化し万一の事態に備えました。
これらのイベントに対しては幸いにして目立った攻撃は観測されませんでしたが、8月にグルジアで武力衝突
が発生した際には、それに関連すると思われるDDoS 攻撃が観測されています。
IIJが攻撃対策を担っているサイトへのDDoS 攻撃は、期間中に272 件(一日あたり3件)発生し、過去最大の
2Gbpsを超える攻撃を観測しました。うち、77%がサーバに対する攻撃、10%が回線容量に対する攻撃でした。
さらに、IIJ 内に設置されたハニーポットで捕獲したマルウェアの解析では、全体の約7 割がDDoS攻撃にも利用
されるボット型であることが明らかになる等、より大規模な攻撃の発生を示唆しています。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

OpenProxyですか・・・やっぱり

■データベースサーバに対して過負荷を与える試み
情報を検索する命令等を送付してデータベースサーバに負荷を与えたり、その処理を停止させたりすることで、
データベースやWeb サーバに対するDoS 攻撃*25 を成立させようとする試みです。データを盗む試みと同
様に、少数特定のWebサーバが標的となっていますが、今回の調査では、この攻撃については比較的長い時間
継続する傾向にありました。攻撃元は国内外の複数のIP アドレスとなっていますが、その分布の規模は大き
くなく、Open Proxy*26 等を利用しているものと判断しています。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

IIJさんがP2Pソフトウエアの通信挙動を見るため専用環境をつくって実験されたそうです!

P2P ネットワークにおいて、ノード管理が適切に行われていればこのようなことは発生しませんが、現実には、P2P
ソフトウェアの実装は様々です。そこで、実際にこの事象が発生するかどうかを検証するために、専用の環境を構築しました。
まず、データセンタに観測用のサーバとP2P ソフトウェアを稼働させるホストを用意し、
過去にP2Pソフトウェアを利用していないことが分かっているIP アドレスを利用しました。実装の調査はSkype
(3.6.0.248)、Winny(2b71)、Share(ex2)の3 つを対象としています。これらを24 時間稼働させて終了
させ、その後、送られて来るパケットを記録しました

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

Skypeは基本的には再接続はほとんどないそうですが、WinnyやShareは長期間にわたって再接続があるとのこと

まぁキャッシュに残っているので、それで再接続要求があるんでしょうね、Skypeはスーパーノードに聞きに行くので比較的早く消えてしまうと。

Skypeの観測結果
Skypeでは終了後、12 時間程度の間TCP SYN*31
の到着を観測しましたが、5 分あたり4 個程度の頻度であり、P2P を利用しないでも到着する不要な通信
とほぼ同程度の数となりました。5 日後にあるホストからの接続を受信したものの、その後は6ヵ月以上に
渡り、新しいTCP SYN を観測していません。
Winnyの観測結果
Winny では終了後、9 時間程度は5 分あたり20 個と多くのTCP SYN を観測しました。その後も2 週
間程度は断続的に5 分あたり3 個程度のTCP SYNを観測しました。25 日後に最後のTCP SYN を受信
した後、5ヵ月以上に渡って新しいTCP SYN を観測していません。
■ Shareの観測結果
Shareでは終了後、24 時間程度は5 分あたり10 〜30 個と多くのTCP SYN を観測しました。その後徐々
に頻度は減っているものの、長期に渡って5 分あたり2〜6個程度のTCP SYNを断続的に受信しています。
利用終了から6ヵ月経った現在でも、月に2 個程度ではあるもののTCP SYN を観測しています。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

今回の条件では、Skype は比較的早く収束しましたが、Winny やShare では終了後も長期に渡って接続
要求を受信しました。これにはP2Pノードのノードリストの管理方法の違いが関連しています。Winny
やShare では、再起動時には前回の終了時に保存された他のノードの情報を手がかりにP2P ネットワー
クへの参加を試みるため、長期にわたって接続要求が観測されたと考えられます。つまり、すべてのノー
ドの保存情報からノード情報が削除されるまでは、継続的に接続要求を受信する可能性があるのです。
今回の調査ではP2Pソフトの利用終了後も接続要求を受信することが分かりました。特にP2P ソフトの
実装や利用方法の違いによって、利用終了直後に接続要求が活発に到着する期間があることや、少量で
はあるものの、長期に渡って到着する様子が明らかになっています。このような現象が、インターネット
に接続した際に身に覚えのないパケットを受信する原因の一つとなっていると言えるでしょう。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

続いて迷惑メール

2006 年には業界に先駆けて、受信時の認証機能の導入及びその認証結果によるフィルタリングサービスを提供しました。
これらの実績を元に、現在のSPFの対応状況について分析します。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

実際にメールを受けてみたら、SPF実装しているものが20%〜30%程度とのこと。

IIJのあるサービスでのメール受信時のSPFの認証結果の推移を図-5 に示します。
受信メールのうち、送信側がSPF に対応している数自体は概ね増加傾向にありますが、受信メール全
体のSPF 対応の割合については2007 年6 月の約30%から徐々に減少傾向にあり、最新の2008 年8
月では26.4%でした。別のIIJのサービスでは、6月から8 月までの間ではあまり変化がなく、平均する
と約21.4%となり、いずれも20%台という結果になりました。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

上の30%とかは、迷惑メールも含んでいるということ。ってことは、100:26.4=(1-85):x .........96%の精度か!!!SPF!!!

こっちをアピールしてください!>IIJさん

日本のISP や携帯電話事業者等、よくメールに利用される主要なドメインがほとんどSPF を宣言していることと、
静的な調査結果の宣言率を考えると、実際の流量ベースではもっとSPFの宣言率が高くても良いはずですが、
そうはならない原因は、85%を超える迷惑メールにあると考えています。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

もはやSPFは必須。自分を証明するためにもSPFは実装しましょう。DNSに書くだけだよ!

通常メールの96.04%程度はSPFを定義されているということです!!!

もはやSPF を宣言していないドメイン名自体を怪しいメールと判断しても良
い時期にさしかかっているのかもしれません。自分のメールが迷惑メールと誤判定されないためには、まず
自分が使っているドメインSPFレコードの宣言をする、またはSPF宣言されているメールサービスを
正しく利用することをお勧めいたします。

http://www.iij.ad.jp/development/iir/pdf/iir_vol01.pdf

screenshot