Route53のトラフィック乗っ取り AmazonのRoute53がトラフィック乗っ取りの被害に遭った、と聞くとぎょっとした人が多いのではないでしょうか。AWSの利用者は多いですからね。攻撃の仕組みについて解説します。 www.itmedia.co.jp AWSのクラウドベースのDNSサービスである「Route 53」のDNSトラフィックが何者かに乗っ取られ、「MyEtherWallet.com」のユーザーが仮想通貨を盗まれる事件が発生した。 解説 まず、この問題に関して利用された攻撃手法は「BGPハイジャック」という名前であることをおぼえてください。BGPとはネットワークの中で、ルーティング情報（経路情報）を交換するためのプロトコルです。BGPにて世界中のルーターが会話をすることによって、世界中どんなところにでも、インターネットがつながっていればパケットを届けることができるのです。例えば
#1. はじめに SoftLayerのVyOS/VyattaでGRE接続の続きです。 前回は、Static IPで接続してみましたが、これではあまり面白くない（とはいっても、2ノードならばこれで十分でしょうが）、OSPFで構成してみます。 構成図を再掲します。 #2. OSPFについて OSPFを前回構成したGRE上でマルチキャストで実行します。とはいえ、そもそも途中経路のルーターが利用者で管理できない時点で、論理的に隣同士のVyOSでルーティングせざるを得ませんが・・・。 static routes, OSPF, BGPは、それぞれ独自にテーブル管理されており、これらの独自テーブルから最終的にIPルーティングテーブルが決まります。つまり、以下のような感じです。 static routes table --> IP routing table OSPF table --> IP routi
先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。 大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。 ネットワーク障害 グーグルが設定誤りで謝罪 グーグルが謝罪 大規模ネット障害、装置の誤操作が原因 ニュース解説 - 米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？：ITpro BGP leak causing Internet outages in Japan and beyond 8月25日に発生した大規模通信障害をまとめてみた 今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。 ここでは、その理由を紹介します。 ネットワークのネットワ
08/25の通信障害概説 Matsuzaki ‘maz’ Yoshinobu <maz@iij.ad.jp> maz@iij.ad.jp 1 観測されている概要 • 2017/08/25 12:22JST頃 • AS15169が他ASのIPv4経路をトランジット開始 • ⽇頃流通しない細かい経路が⼤量に広報 • これによりトラヒックの吸い込みが発⽣ • 国内の各ASで通信障害を検知 • 2017/08/25 12:33JST頃 • AS15169がトランジットしていた経路を削除 maz@iij.ad.jp 2 観測された問題のBGP経路概要 • 経路数 • 全体で約11万経路 (⽇本分が約25000経路) • /10から/24まで幅広い経路(半数程度が/24) • 通常流れていない細かい経路が多かった • AS PATHは概ね “701 15169 <本来のAS PATH>” • 広報元A
2017/08/25 12:30 (JST) ごろ、日本国内で大規模な通信障害が観測されました。 通信障害の内容について、とても詳細にまとめられている記事があります。 d.hatena.ne.jp 障害の内容はさておき、このエントリでは障害のしくみについて探ってみようと思います。 MRT Dump から見るBGP Update 数の急増 MRT Dump をもとに、該当時刻のBGP Update 数(毎分) をバーチャートにしました。 横軸: 時刻(UTC) 縦軸: BGP Update されたのべPrefix 数 正: NLRI 負: Withdraw 単純にBGP Update の回数をカウントしているため、Path Attribute だけの変更だったり、NLRI → Withdraw → 同じNLRI の場合でも すべて1回と数えています。 普段と比べるとUpdate 数が激増して
BGP leak causing Internet outages in Japan and beyond. Posted by Andree Toonk - August 26, 2017 - BGP instability - No Comments Yesterday some Internet users would have seen issues with their Internet connectivity, experiencing slowness or parts of the Internet as unreachable. This incident hit users in Japan particularly hard and it caused the Internal Affairs and Communications Ministry of Japan
2017年8月25日、NTTコミュニケーションズ（NTTコム）のインターネット接続サービス「OCN」で発生した通信障害に関して、インターネット通信関連の識者は誤った経路情報が大量に流れたことが原因ではないかとの見方を示した。ここでいう経路情報はルーターがBGP（Border Gateway Protocol）というプロトコルを使って交換するものだ。 日本ネットワークインフォメーションセンター（JPNIC）の岡田雅之氏は、NTTコムは複数の組織と対等な関係でネットワークの経路情報をやり取りしているが（これを「ピアリング」という）、そのうちのある組織が誤った経路情報を大量に流したのではないかと話す。その結果、「NTTコムを介してインターネットに接続していた企業のルーターが、大量の経路情報を受け取り高い負荷がかかり、一部はフリーズしたような状態に陥るなどして通信障害につながったのではないか」（岡
Designed from scratch for modern environment so implemented in the Go programming language. Multicore CPUs GoBGP is designed to exploit todays multicore processors. Golang makes it extremely easy and simple to write concurrent code. Automation Friendly GoBGP is designed to be easily integrated with other software with its RPC APIs instead of manually changing its config via CLI. GoBGP also support
「ネットワーク運用の自動化」として、BGP経路監視を考察してみたいと思います。 NetOpsCoding Advent Calendar 2015 12/12分のエントリーです qiita.com ◾️ ”BGP運用”という言葉から想定されるイメージ BGP運用というと、なんとなく「BGP職人さん」という言葉を連想してしまうのは、私だけでしょうか？ BGP職人さんは、事前に策定されたBGP運用ポリシーに従って、ポリシー・ルーティングに関わるルートマップ等コンフィグを投入することができる存在であり、想定どおり、ポリシー・ルーティングが動作されているかを確認するため、ベンダ固有のCLIコマンドを駆使して細かなBGP制御を確認することを日々の業務として実施する。 そんなイメージを、「BGP運用」からは、連想してしまいます。 さらに、不測な事態としてNWトポロジが安定動作していないことが判明した際
OSPF, RIPと合わせてBGPも試してみた。 BGPは内部ルーターとの接続ではなく、外部との接続(インターネット接続など)に使用し、かつ普通の使い方だとISPのルーターをデフォルトゲートウェイに指定するだけでルーティングが出来てしまうため、使うことが無い。。 ただ、複数のISPと契約してWAN回線の冗長化を行うような時にはBGPを使うことがあるらしいため、そちらを意識して構成してみた。 vyattaでのBGPのマニュアルはこちらになる。 http://www.vyatta.com/downloads/documentation/VC6.1/Vyatta_BGPRef_R6.1_v02.pdf 構成図は次のようになる。 BGPではAS番号の異なる組織間で接続を行うのだが、ここではどちらもプライベートASである64600, 64601を使用している。 セグメントごとの用途としては、192.
ということでOpenFlow、なんですが、仮想化・抽象化されたネットワークにおけるサービスの提供といった、いわゆるSDNの手法として導入されるケースが一般的かと思います。 しかし本稿でご紹介するのはそうした事例とは全く異なるもので、OpenFlowならではのクリーンなAPIとハードウェアスイッチの処理能力を生かした、効果的なDDoSアタック防御の手法です。 以下の内容は、ネットワークエンジニア向け情報サイト、Packet Pushersのコミュニティブログに寄稿した3本の記事をさくらのナレッジ向けに書き直したものです。 お題目 大規模DDoSアタックが発生すると、さくらインターネットのネットワーク網（以下：当社ネットワーク）への複数の入口から攻撃パケットが一気に流入してきます。 こうした大量のパケット流入によるネットワーク帯域輻輳を防ぐために、以前から当社ではd/RTBHという手法で対応し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
