腐ったILVドメインでのサイトのブロックに関するValdikSS の記事の後、レジストリが非常に多くのIPv4アドレスに解決し始めたらどうなるかという考えに悩まされました。 本格的な「指導」を行うことは、私には疑わしい問題のようです。 彼らは偶然にRunetの接続性の故意の違反に変わる可能性があります。 したがって、私は自分自身を2つの質問に対する答えを見つけることに限定しました。
- プロバイダーはDNSからIPv4アドレスをルーティングテーブルに自動的に追加しますか？
- このような大規模なRIB補充システムは、数千のレコードを含む大規模なDNS応答を正しく処理しますか？
私は行き詰まって リストからいくつかの空きドメインを登録し、DNSサーバーを上げて、pcapに書き込まれるようにトラフィックを設定しました...
登録用のドメインは、次のように選択されました。httpsリンクを含むアップロードに存在する2つのドメイン、httpリンクを含む2つのドメイン、およびリンクのない2つの裸のドメイン。 これは、フィルターの前にあるすべてのドメインの等価性の仮説をテストするために行われます。 これらのドメインが指すIPv4アドレスは、フィルターの負荷を増加させないように、レジストリに存在するものから選択されました。 レジストリにないアドレスは現在仮想マシンに割り当てられているため、この実験ではDoS攻撃はありません。
さまざまなプロバイダーのルッキンググラスの オープン リストを調べて、ルーターのレジストリからアドレスへの/ 32マスクのルートがある大規模なロシア近郊のプロバイダーを確認できます。 これらのプロバイダーは、オーバーフロールーティングテーブルに対する攻撃の危険にさらされています。 そのようなプロバイダーはそれほど多くありません： Equant別名GIN aka Orange Business Services 、 Beeline 、 Rostelecom 、 Transtelecom 、 Obit 、そして少し面白い、 ロシアの連邦大学コンピューターネットワーク （学問の自由と大学の独立に関するジョーク） 。
「ブロックの下」に入力する予定のIPアドレスが、同じLGのルーティングテーブルに存在しないことを確認します：1、2、3、4、5、6。 誰かがこの実験を非常にきれいに再現する場合、テーブルに追加する予定のすべてのIPv4アドレスとIPアドレスをチェックすることも価値があります。 それらの状況は似ていると思います。
6月14日、モスクワ時間の15:00に、一部のサーバーのアドレスをDNSゾーンファイルに追加し、リゾルバーがレコードを更新している間にpcapファイルで何が起こっているかを観察し始めました。
バラエティ
合計で、1.5時間の自律システムからのリゾルバへのリクエストが16時間でログに記録されました。 これらは、ドメイン解決に関してかなり多様な行動のバリエーションを示しています。
netup.ruの abuse-contactを使用したネットワークからは、URLとともにリストされているドメインのみがリストされ、2048レコードのドメインは約5倍のリクエストを受信します。 同じ連絡先のAS FSUE Telecommunicationsは、8分ごとにすべての「小さな」ドメインのDNSに定期的にアクセスしますが、 イジェフスク無線リンクのように、何らかの理由で「大きな」ドメインに単一のリクエストを送信しません。 Tele2は、httpsと「ダミー」のDNSを解決しますが、httpを解決しません。おそらく、すべてのhttpはプロキシにラップされます。 反対に、 Zheleznogorsk SignalとYekaterinburg Miralogicは、 httpのみです。 Sergiev PosadのSPNet -URLはまったく解決せず、「裸の」ドメインのみを解決します。 モスクワシティテレコム -それどころか、httpsのみ、および連邦国家統一企業Electrosvyazのように、「大」ドメインの解決すらしません。これは、事前に解決されたアドレスを持つブラックリストを配布する代替方法を示唆します。
| HTTPS | HTTP | Domain-only asn | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp ------+------+--------+--------+------+--------+--------+------+--------+------- 50317 | 903 | 1416 | 1030 | 285 | 1295 | 1012 | 0 | 0 | 0 57835 | 207 | 0 | 0 | 200 | 0 | 0 | 200 | 0 | 0 38959 | 29 | 0 | 0 | 56 | 0 | 0 | 39 | 0 | 0 39475 | 155 | 217 | 217 | 0 | 0 | 0 | 151 | 209 | 209 42514 | 0 | 0 | 0 | 120 | 136 | 13 | 0 | 0 | 0 12668 | 0 | 0 | 0 | 95 | 103 | 18 | 0 | 0 | 0 43826 | 0 | 0 | 0 | 0 | 0 | 0 | 13 | 33 | 12 56705 | 415 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
最初の16時間のリクエスト数の完全な統計は要点で見ることができますが、私はすべてのASNがロシアのプロバイダーに属するわけではないという事実に注目します。
EDNSおよびTFO
pcapでは、 EDNSクライアントサブネットオプションを使用したリクエストは実質的になく、そのようなリクエストは1％未満です。 これはそれほど驚くことではありません。 google（このようなクエリのほぼ唯一の「プロバイダー」）は、このオプションのサポートを明示的にアナウンスする DNSサーバーにのみクライアントアドレスを公開しますが、私のDNSサーバーは公開しませんでした。 示されているごく一部のリクエストは、EDNSクライアントサブネットのサポートを自動的に決定する試みであると考えられます。GoogleASからのリクエストの4つごとにこのオプションがありました。
Googleのクライアントサブネットに加えて、 ビット0x20のハックを使用してリゾルバーからブラジルから4つのリクエストがありました：
ts | src | query | client4 ---------------------------+---------------+----------------------+-------------- 2017-06-14 04:47:41.231796 | 187.1.128.119 | udp A zenitbET66.CoM | 200.248.248.0 2017-06-14 04:47:41.748585 | 187.1.128.119 | tcp A ZenItbET66.cOm | 200.248.248.0 2017-06-14 04:47:42.274296 | 187.1.128.119 | udp A zEnItbET66.coM | 200.248.248.0 2017-06-14 04:47:42.798544 | 187.1.128.119 | tcp A zeNitBET66.com | 200.248.248.0
ビット0x20のハックは比較的人気があります-リゾルバの2.5％からのリクエストの約5％が来ます（ASNで一意のリゾルバを検討する場合）。
別の興味深いEDNSオプションはEDNS UDPペイロードサイズです 。これは、クライアントが受け入れる準備ができているDNSパケットの最大サイズを通知します。 EDNSサポートをアナウンスしないリクエストの4分の1と、このオプションを4096バイトに設定するリクエストの55％に加えて、他にも興味深い値がいくつかあります。
リクエストの2％は、より大きなUDPパケットを必要とせず、512の最小許容値を使用すると答えています。そのようなリゾルバの例は、 ミヌシンスクの irc.kristel.ruです。 TCP しばらくしてサイズを512バイトにリセットするなど、他のリゾルバーでも同様の動作が見られます。
ts | proto | qtype | qname | udpsz ---------------------------+-------+-------+--------------------+------ 2017-06-14 12:41:59.678401 | udp | A | zenitbet66.com | 512 2017-06-14 12:41:59.898596 | tcp | A | zenitbet66.com | 512 2017-06-14 12:42:32.14485 | udp | A | m.zenitbet66.com | 4096 2017-06-14 12:44:40.532815 | udp | A | www.kisa54.com | 4096 2017-06-14 12:56:54.083849 | udp | A | diplom-lipetsk.com | 4096 2017-06-14 12:56:54.311013 | tcp | A | diplom-lipetsk.com | 4096 2017-06-14 13:06:38.524876 | udp | A | www.cool-sino.com | 4096
また、DNS増幅を検索できるスキャナーがログに記録されました。 クライアントサイズを65527バイトに設定します。これは最大値です。 興味深いことに、powerdnsは応答リソースレコードなしで「大きな」応答を送信し、ヘッダーに切り捨てられたフラグを設定して、リゾルバーを強制的にTCPに切り替えます。 したがって、powerdnsは、大きなUDP応答を処理するときにDNS増幅を回避します。
TCP Fast Openを使用して単一の TCP DNSクエリが入ってこなかったことに少し驚きました。 もちろん、この機能がないことは、速度が心配な場合は、まず、リゾルバーをTCPに強制的に切り替えるような大規模なDNS回答を行うべきではないという事実によって説明できます。
DNSとルーティング
10時間で、上記のガラスはDNSに追加されたIPv4アドレスへの32ルートを表示しませんでしたが、少なくともLG TTKと大学ネットワークで 20時間後にこれらのルートが表示されました。 RIPE Atlasを使用して測定を行う場合、解決を実行し、フィルターへのルートを記録し、2049 A
レコードを応答として受信する可能性のある多くの輸送プロバイダーを見つけることができます。
- データライン-filter01.dtln.ruがtracerouteで点灯し始め、
- Rostelecom -AS8997の終了時のtracerouteで、Rostelecomホップ188.254.78.25および95.167.93.150が「クローズ」IPへのルートに追加されます。これは、同じ/ 24ネットワークから近隣ホストへの多数のルートでは観察されません。 ほとんどバランスの取れたアーティファクト、
- ReTNは、「専用」ホストへの3ホップのルートの拡張と同様の話です。 @ amaraoは、 ハブの ReTNネットワークでの通過時のフィルターについて既に書いています
リストは不完全です、なぜなら 精査の方法によってコンパイルされました。 リストに大きなプロバイダーが存在することは、この攻撃に対する重要なインフラストラクチャの潜在的な脆弱性の問題が解決されていないことを示唆しています。 質問も開いたままです：
- 応答内のDNSリソースレコードの順序は、特殊効果にどのように影響しますか？ たとえば、
sortlist
を使用sortlist
か、LUAコードで直接手動で応答を生成することで指定できます。 - 「解決」されたIPv4アドレスはどれくらい速く捕捉されますか？
- IPv6アドレス解決は解決されていますか？
- そのようなデータから、他にどんな興味深い結論を引き出すことができますか？
誰かが自分でデータを見たい場合、RIPE Atlasではこれらは測定値8844224、8844225、8844226、8844227、8844228、8844229、8844230、8844231、8844232、8844233、8844234、8844235 です 。 実験の最初の16時間のリクエストは、 postgresダンプとして利用できます：9.6 。 別のリクエストでギガバイトのpcapを発送できます。