『インターネットのカタチ もろさが織り成す粘り強い世界』あきみち
- 作者: あきみち,空閑洋平
- 出版社/メーカー: オーム社
- 発売日: 2011/06/25
- メディア: 単行本(ソフトカバー)
- 購入: 8人 クリック: 185回
- この商品を含むブログ (28件) を見る
20150418開始,同日読了
雑感
どう作られてるか,という解説もあるけどどちらかというと仕組みを解説しつつどんな不具合・事件・攻撃があって「インターネットが壊れた」のか,という事例に力を入れており非凡.よい.
メモ
インターネット = ネットワークのネットワーク
1988年のD.D.Clark論文.インターネットワークがどんな思想で設計されたか.
DARPAでの研究は,バラバラに存在していた複数のネットワークを相互接続することを目的とした.
一部が壊れても動き続けること.分散管理.誰も全体像を知らない.
AS(Autonomous System: 自律システム)こそがネットワーク
パケット交換方式.パケット単位で送ることで回線を共有.
ルーティングテーブルの宛先はネットワーク.テンゼロ,スラで区切ることになる.
BGP -- 長い経路がベストパスなことも.Path Vector型のルーティングプロトコル.
実は到達不能なネットワーク,到達不能なAS同士が存在する.bogan filterという,1.x.x.xを「不正な値」とする設定が,2010年より(正しいアドレスとして)利用開始された当該アドレスをうまく処理できなかった事件.
BGP障害は毎月のように発生.たまたま報道されると「大事件だ!」となる
RFCとIETF.Internet Engineering Task Force: インターネットの仕様策定組織.IETFで策定される文書がRFC(Request For Comments).ISOとかはまず「決まり」から入るけど,RFCは使われてデファクトスタンダードになってきたら標準化するという順序.
RFCは「標準」ではない.みんなが使っているために事実上の標準となったものを記している.
;; RFCの温度感というか見方が変わる
IETFのD.D.Clark氏(また君か)の発表で「おおまかな合意rough consensus」というものが有名に.
We reject: kings, presidents and voting. We believe in: rough consensus and running code.
ATMというほぼ使われてないプロトコルとその標準化をしたOSIを批判しつつ.
IETFは特許技術を長年避けてきたが,だんだん難しくなってくる.
SPF, Sender IDまわりも特許でもめた.Sender IDはMicroSoftの特許を含んでた.今では両方RFC文書になってる.
DNSルートサーバ13系統.過去に3回IPアドレス変わったことがある. http://root-servers.org を見ると日本にはF, G, I, J, K, Mの6系統がある.
DNS毒入れ
再帰検索結果を一定時間記憶するキャッシュ機能.ここにニセの情報をキャッシュさせるのがキャッシュポイズニング(毒入れ).やりかたはかなりタイミングシビアだけど次のようにする
攻撃者はDNSキャッシュサーバに名前解決を依頼します.DNSキャッシュサーバはUDPを利用して再帰検索を行いますが,正規の結果が返るよりも前に,攻撃者は偽装したUDPパケットをDNSキャッシュサーバに送ります.(p.81)
最近ではDNSキャッシュサーバが組織外にサービス公開することも稀だしそうそう起こらんだろう... と思いきや,
2008年カミンスキー型攻撃(Dan Kaminsky氏が発表),手間だったDNSキャッシュポイズニングが簡単に行えることが明らかに.
カミンスキー型攻撃のキモは,存在しないFQDNの問い合わせであるためキャッシュ切れを待たずに計算資源の許す限り攻撃チャンスを増やせて,成功率が上がる.
カミンスキー型攻撃の発表に対する対策は,
- (以前からあった) TXIDランダム ... 1/65535 の確率でヒット
- (今回追加) UDP送信元ポートランダム化
の掛け合わせによる成功率低下,という形.
この衝撃によりDNSSECが20年の埃を払いのけ実運用まで出てくる.2010年7月にはルートサーバがDNSSEC対応.
いまあるDNS空間とは別に自分たちのための名前空間を作ろう運動.Alternate Root. ICANNが集中的にTLDを管理してることを不満として.とはいえぜんぜん実運用されてない.
Akamaiはインターネットトラフィックの15%ほどを配信しているレベル.TCPも改造してる.サーバ間でコネクションを維持することで3way handshakeの手間を節約,あとは輻輳(ふくそう)制御機構にも手を入れて,多少パケット喪失してもスループット低下しないようにしてる.
DDoS,単にWebサーバ狙うだけでなくルータを狙ったりもある
DDoS防御.完全ではないもののいくつかの対抗策は提唱されている.
- Reverse Path Forwarding. パケット送信元へのユニキャスト経路を参照しつつ,正しい経路から来ているか確認しながら転送する (RFC2827)
- 限定的な組織でのみ運用
- ありえない送信元IPをはじくという「何もしないよりマシ」程度のRFC3704がのちに制定,こっちは広く使われてる
- ブラックホール技術.経路を制御してどこにもつながってない別機器へ流す.ルータに負荷が集中しないようにその前の段階でやる.全部ブラックホールに叩きこむと正常リクエストも通らなくなるので,途中で監視・制御するルータを挟んでやる. ;; 結局監視ルータがすべて受けることになるじゃん
- 有料DDoS防御サービス
変化するインターネットインフラ...ビデオトラフィックが急激に増えてる.
付録
- ICMPプロトコル利用のtracerouteはTTL(打ち切るホップ数)を1から順々に増やしながら経路を探索
- ネットワークトポロジが複雑化してる現代においてはping, tracerouteは参考程度にすべき
- 最近は mtr というping + tracerouteな今風ツールが出てる. brewで入る.My Traceroute, らしい.nslookupに対するdigみたいなもんか.
- yet another 新しいtraceroute, paris traceroute.
- IPアドレスがどのASに属しているか調べる ... CYMRUの提供するサービスを利用.
実例
$ dig asana.com
;; ANSWER SECTION:
asana.com. 60 IN A 23.23.208.20
... (Aレコード3行出て来る)
この情報を使って
$ whois -h whois.cymru.com " -v 23.23.208.20"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
14618 | 23.23.208.20 | 23.22.0.0/15 | US | arin | 2011-09-19 | AMAZON-AES - Amazon.com, Inc.,US
AS名がAmazonだ.なるほど