ドメインネームシステム（DNS）プロバイダーに対する分散型サービス拒否（DDoS）攻撃は、安全でないIoTデバイスの増加に伴い、その数と規模が増加している。これらの攻撃は、そのような名前解決のためのプロバイダに依存するWebサイトに連鎖的に影響する。DNSプロバイダは、このような攻撃からWebサイトを守るさまざまな方法を提供しているが、Webサイトを保護する方法の1つは、複数のDNSプロバイダを使用することである。
2016年にはDNSプロバイダDynに対して過去最大のDDoS攻撃が行われた。3つの波に広がり、Miraiマルウェアに感染したIoTデバイスのボットネットを使用して結集された。Amazon、Paypal、Reddit、Githubのような多くのサービスが影響を受けた。この攻撃により、Dynはネームサーバによって解決されたドメインの正当なDNSクエリに応答できず、そのドメインのエンドユーザは、そのドメインに到達できなくなった。
Dynの技術責任者であるPhil Stanhope氏によると、Dynで起きた問題には、Linuxカーネルの欠陥を利用したTCP SYNクッキーによる攻撃がある。SYNクッキーは、SYNフラッド攻撃を軽減する方法である。SYNフラッド攻撃は、TCP SYN要求を連続して送信することでターゲットシステムのリソースを使い切ろうとするものである。しかし、SYNクッキーには独自の問題がある。それは、Linux 3.xではSYNクッキーを生成するためにマシン全体のロックが使用されることである。ロックにより、システムはコアの数に関係なく単一のコアシステムとして動作し、実際の処理能力を低下させる。Linux 4.xでは、各CPUコアに閉じたロックを導入することで、この問題を修正した。
DNSプロバイダは、攻撃に対してスクラビングなどのさまざまな方法を活用している。スクラビングでは、保護をサービスとして提供するサードパーティを通して、全てのトラフィックがフィルタリングされる。そのサービスでは、悪意のあるトラフィックは除去され、正当なトラフィックが最終的な宛先へ向けて通される。Akamai、AT&T、Verizon、Arbor Networksなどのさまざまなベンダがこのようなサービスを提供している。
Webサイトまたはドメインに対するHTTP（あるいは他のプロトコルの）リクエストが発生すると、名前からIPアドレス（またはアドレス）を解決するためのDNSクエリが生成される。リクエストは、複数のリゾルバを経由して、各レベルで名前に対するオーソリティを持つサーバに送信される。例えば、まず、www.infoq.comのリクエストがルートサーバ、次に.comのトップレベルドメイン（TLD）サーバ、次にinfoq.comのオーソリティを持つサーバにヒットする。経路上のリゾルバは結果をキャッシュして後続の応答を速める。キャッシュは、DNS応答の生存時間（TTL）値によって制御される。infoq.comのオーソリティを持つサーバに対するDDoS攻撃は、正当なクエリに応答できなくなり、Webサイト全体が利用できなくなる可能性がある。
一般に、DNSサーバの冗長性により、そのように利用できなくなることを防ぐことができる。どの商用DNSプロバイダも、設定されたドメインに対して複数のDNSサーバを持つ。digコマンドまたはdrillコマンドを使用すると、ネームサーバレコードを見ることができる（以下の例はinfoq.com）。
# dig infoq.com ns
; <<>> DiG 9.10.3-P4-Ubuntu <<>> infoq.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47143
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infoq.com. IN NS;; ANSWER SECTION:
infoq.com. 259200 IN NS ns1.contegix.com.
infoq.com. 259200 IN NS ns2.contegix.com.;; Query time: 367 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 03 23:47:46 IST 2017
;; MSG SIZE rcvd: 83
ただし、プロバイダがDDoS攻撃を受けた場合、すべてのネームサーバが影響を受ける可能性がある。このようなケースを回避するには、複数のDNSプロバイダを持つことが有効である。
複数のDNSプロバイダを使用するには、すべてのレコードをレスポンスの一部として送信できるように、各DNSプロバイダのネームサーバレコードを編集できるようにする必要がある。また、各プロバイダには複数のネームサーバがあり、それらに順序はないため、あるプロバイダへのリクエストが失敗した場合、そのプロバイダの別のネームサーバ全てで試す代わりに、他のプロバイダへリクエストを送信する。
DNSの堅牢性のための他の方法として、同じIPアドレスを持つ複数のネームサーバを必要とするAnycastがある。DNSクエリが行われると、パケットは最も近いネームサーバにルーティングされる。失敗した場合、パケットは自動的に、ベースにあるルーティングプロトコルによって正常に機能している最も近いネームサーバにルーティングされる。
正しいTTLの設定は重要である。それによって、レスポンスを処理する中間サーバでレコードがキャッシュされる場合でも、セカンダリサーバへのフェイルオーバは起こりうる。Stanhope氏がVelocityの講演で述べているが、今後、そのような攻撃に対抗し、軽減していくために、NetOps、DevOps、SecOps、SREチーム間のコラボレーションが必要である。
Rate this Article
- Editor Review
- Chief Editor Action