タグ別アーカイブ: Geekなぺーじ

Geekなぺーじ:BGPフルルートは必要か?GREEの事例

次に、経路数の増加ですが、インターネットの経路数は、インターネットの誕生から現在まで常に増え続けています。最近は、インターネットの普及だけではなく、IPv4アドレス在庫枯渇による個々のネットワーク規模が縮小することで経路の数が増加しているという要因も加わっています。

www.cidr-report.orgで公開されているフルルートの経路数を見てみると、2008年頃には約25万経路だったものが、今は50万経路を超えているのがわかります。経路数の増加は今なお続いており、どこまで増えるのかは現時点では、まだ不明であると思えます。

引用元: Geekなぺーじ:BGPフルルートは必要か?GREEの事例.

Geekなぺーじ:BGPフルルートは必要か?GREEの事例

GREEのビジネスモデル上、同社ASに対するアクセスの99%がモバイル網からです。日本国内モバイルキャリア3社との通信が、GREEへのアクセスの99%なのです。要は、日本国内モバイルキャリア3社との通信に極端に偏ったトラフィックを扱うという運用だったわけです。

フルルートを持つというのは、世界中の全てのネットワークへの経路を持つということですが、GREEにとってはフルルートは特に必要なものとは言えない状況です。たとえば、地球の裏側に到達するための経路を持っていたとしても、GREEはそれを使うことはなかったのです。

そういった背景もあり、GREEは、日本国内モバイルキャリア3社のパーシャルルート(Partial Route)と、デフォルトルート(Default Route)だけをトランジット提供者から受け取ることによって経路数を削減するという選択をしました。この変更によってGREEのBGPルータが扱う経路数が劇的に減少しました。2012年夏の障害当時40万経路だったものが、パーシャルルート+デフォルトルートに変えたことによって約2600経路まで減りました。2014現在は、さらに経路数が減って約1800になっているとのことでした。

フルルートをやめたことによって、ハイスペック機器にリプレースすることなく、運用し続けられているそうです。

引用元: Geekなぺーじ:BGPフルルートは必要か?GREEの事例.

Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策

攻撃したい名前の存在しないサブドメインに対する問い合わせを、標的となるキャッシュDNSサーバーに対して実行します。サブドメインの部分は毎回変更するため、ここでは($random)で表します。カミンスキー氏の発表資料では、www.example.comに対する攻撃の場合、($random)www.example.comという名前を攻撃対象としています(ただし、この資料に記載された通りの方法では毒は入りません)。

存在しない名前であるため、キャッシュDNSサーバーはこの名前に対する名前解決を実施します。この場合、通常はexample.comの権威DNSサーバーに対し、名前検索が実施されることになります。

攻撃者は、example.comの権威DNSサーバーからの応答であると偽装した偽の応答の注入を図ります。

偽の応答の付随情報として、www.example.comの情報を乗っ取るための「毒」を仕込みます。(ここが大きなポイントです。)

この場合、example.comの正当な権威DNSサーバは「その名前は存在しない(NXDOMAIN)」という応答を返します。もし、この応答が偽の応答よりもキャッシュDNSサーバに先に到達した場合、攻撃は失敗であり、その攻撃に使った($random)ではしばらくの間、攻撃できなくなります(DNSでは、名前が存在しなかったという検索結果もキャッシュされます)。

しかし、攻撃者は($random)の部分を変更することにより、事実上無限に攻撃を継続できます。

引用元: Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策.

Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策

典型的なDNSキャッシュポイズニングの例を示します。

以下では、偽の応答を本物よりも先に注入するという手法が使われていますが、偽の応答をキャッシュさせる方法は他にも存在します。

攻撃対象となるキャッシュDNSサーバに対して問い合わせを行う

攻撃対象となるキャッシュDNSサーバが権威DNSサーバに対して問い合わせを行う

権威DNSサーバの正当な応答よりも先に偽の応答をキャッシュDNSサーバに送りつける

キャッシュDNSサーバが、偽の応答を本物と信じ込んで受け入れたら毒入れ成功

この形のDNSキャッシュポイズニングを成功させるためには、偽のDNS応答の送信元IPアドレスを本物と一致させておく(偽装する)必要があります(*1)。

インターネットで使われているIPのうちWebなどで使われているTCPでは通信開始時に相手との接続を確認するため、送信元IPアドレスを偽装してデータを送りつけることは困難です。 しかし、DNSでは通信にかかる負荷や遅延を抑えるため、事前に接続を確認しないUDPが使われています。UDPでは、送信元IPアドレスの偽装をTCPよりも容易に行うことができます(*2)。

引用元: Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策.

Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策

JPRSの発表によれば、JP DNSサーバにアクセスがあったIPアドレスのうち、約10%が未だに固定ポート番号で運用されているとあります。 これらのキャッシュDNSサーバは、数秒から数分でDNSキャッシュポイズニングが可能であり、非常に危険な状態です。 まずはそれらを減らすことが重要であるということで「緊急注意喚起」を公開した、ということのようです。

DNSキャッシュポイズニングは、キャッシュDNSサーバが偽パケットを正規の回答であると誤認してしまうことが原因です。 この誤認が成立するためには、以下の要素が重要となります。

キャッシュDNSサーバが偽パケットを受け取るタイミング。キャッシュDNSサーバが権威DNSサーバへの問い合わせを行い、権威DNSサーバから正規の回答を受け取る前に偽パケットを注入しなければならない。

キャッシュDNSサーバからの問い合わせに対応した回答であること。たとえば、キャッシュDNSサーバがwww.example.comに対するAレコードの問い合わせを行っているときに、別の名前であるmail.example.comや別の型(たとえばIPv6アドレスを示すAAAAレコード)の回答を偽造しても駄目。

キャッシュDNSサーバからの問い合わせメッセージと同じTXID(トランザクション識別子)であること。TXIDフィールドは16ビットなので、ランダム化されていれば、偽パケットがたまたま同じ値になる確率は65536分の1となる(TXIDは16ビットしかないため、TXIDのみが異なる65536個の応答を同時に送るという、総当たり攻撃が可能になります)

キャッシュDNSサーバから送信されたUDPパケットと同じポート番号であること。権威DNSサーバのUDPポート番号は53番になるので常に固定される。キャッシュDNSサーバの送信元UDPポートがランダム化されていれば、偽パケットが注入される確率が65535分の1になる。

これらの要素からわかるように、TXIDとUDPポート番号が両方ともランダム化されていれば、偽パケットが正規のものであると誤認される確率は約43億分の1となります。 現時点では、非常に限られた時間内に、この確率を突破するのは困難です(確率の問題ですので、長時間の攻撃により突破することは理論的には可能です。ただし、そうした攻撃を仕掛けた場合、攻撃が露見する可能性が高くなります。)。

引用元: Geekなぺーじ:DNSキャッシュポイズニングの基本と重要な対策.

Geekなぺーじ:FreeBSDのTCPスタックに脆弱性、カーネルメモリを抜き取られる可能性

FreeBSDのTCPスタックに含まれる脆弱性に関する情報が公開されました。 現在サポートされている全てのFreeBSDバージョンに影響があるようです。

The FreeBSD Project Security Advisory: TCP reassembly vulnerability

TCPセグメントの並び替えを行うコードに不具合があり、カーネルをクラッシュさせることによるDoS攻撃が可能とあります。 また、非常に難易度が高いとしつつも、今回の脆弱性を突くための工夫を凝らしたTCPセグメントを駆使することで、カーネルが保持するメモリを、接続されたソケット経由で取得できてしまう可能性もあるとのことでした。 FreeBSDのセキュリティアドバイザリでは、カーネルがメモリに保持するものの例として「ログイン認証情報など」とあります。

FreeBSDは家庭用PCや各種サーバで利用するだけではなく、SOHOルータやNASなど、様々な機器を制御するためのOSとしても使われています。 今後、そういった機器に含まれるソフトウェアのアップデートが必要になるかも知れません。

引用元: Geekなぺーじ:FreeBSDのTCPスタックに脆弱性、カーネルメモリを抜き取られる可能性.

Geekなぺーじ:8.8.8.8に対するBGPハイジャックの話

今回のポイントは、BGPハイジャックが発生したということそのものではなく、8.8.8.8に対してAS7908(BT LATAM Venezuela,S.A.)が何かをしてそうだ、という点です。 AS7908は、ラテンアメリカ及びカリブ海地域のRIR(Regional Internet Registry)であるLACNICのwhoisにおいて、ベネズエラと記載されているBritish Telecomの子会社です。 ベネズエラとありますが、その他の南米地域においてもサービスを提供しています。

そのAS7908から8.8.8.8/32が広告されたということは、AS7908内部で8.8.8.8/32に対して「何か」をしていることを示してそうです。 「8.8.8.8はコッチですよーーー!」と言われた先に居るのが、AS7908内部(もしくは関連するAS内部)の偽キャッシュDNSサーバではないかと推測しています。 偽8.8.8.8は、監視や検閲などを行うためにMan-In-The-Middleを行ってそうです。 AS7908内部、またはAS7908を経由してインターネットに接続しているユーザは、Google Public DNSの8.8.8.8に対して直接通信を行っているつもりでも、間に偽8.8.8.8が挟まった状態で通信を行っているという状況じゃないかという感じです。

ネット検閲そのものは世界各国で行われており、ベネズエラに限らず、世界各地で同様のことが行われているのではないかとも思います。 ということで、ただ単に、南米地域でサービスを提供しているISPにおいてそういったことが行われているということが表面化しただけなんだろうなぁというのが、現時点での感想です。

引用元: Geekなぺーじ:8.8.8.8に対するBGPハイジャックの話.