反射型/増幅型DDoS攻撃への適切な対処とは？

さて、前回の増幅型DDoSについて、今回は実効性のある対処方法など考えてみたいと思います。なお、レイアウトについては色々試行錯誤しながら書いているこのブログ、前回と変わっている点はご了承ください。いや使えないタグが多いんですよ。

前回のおさらい

---

反射型・増幅型攻撃とは、以下のような攻撃を指します。

1. 対象のIPアドレスを発信元とする、UDPの「問い合わせ」パケットを偽造し、
2. 世界中にある「誰からの問い合わせも受け付ける」サーバに偽造したパケットを投げ、
3. サーバが「偽造された」パケットを元に、被害者のアドレスに「答え」を返し、
4. 世界中から、大量の「答え」パケットが、対象のサーバに届くことで、
5. 対象のサーバがアクセスできなくなる攻撃。

帯域やサーバのスペックを上回るアクセスを簡単に生成できる攻撃方法として、よく利用されています。

増幅攻撃の必要条件

---

そして、増幅型攻撃が可能になるためには、いくつか条件があります。

UDPであること
これはコネクションレスであるUDPでしか、送信元の偽造ができないからです。

「誰からの問い合わせも受け付ける」サーバが世界中に大量にあること
「答え」のデータが「問い合わせ」に対して大きいこと
この二つは、利用できるサーバの数と、増幅率が最終的な攻撃の大きさにつながります。

よく利用されていて、フィルタしにくいこと
よく利用されていれば、該当PORTを塞ぐなどの対処ができず、攻撃の成功率が上がります。

この4つを満たす攻撃方法として、現在はDNS、NTP、SSDP、などが使われているようです。稀なものとしてRIP、MS SQL Serverのバグを利用するもの、などがありました。(UDPの ウェルノウンPORT を順に辿って、どうしたらこのプロトコルで増幅型攻撃が可能か、その場合どう防ぐか、を調べてみるのも面白いかもしれません)

DNSやNTP増幅攻撃への対処方法

---

対処として、RIPやSSDPは正直さっさと塞げば良いと思っています。が、NTPやDNSについてはそうもいきません。特に自社ネットワーク内にドメインの権威サーバなどを用意していたり、リゾルバを各クライアントが設定できると、DNSをフィルタしにくくなります。

そこで、以下の対策をとることで実効性のある対策がカスタマイズACLでも可能になります。

[構成 — DNSの場合]

1. 自社ネットワーク内にDNSリゾルバサーバを設置し、自社ネットワーク内のリゾルバとしては全てそのリゾルバを利用する。
   リゾルバのIPアドレスは少数の複数個で固定する。インターネット上のDNS権威サーバへのアクセスなど、相手先のPORTが53(DNS)となるパケット行うサーバを限定します。つまりそれ以外のアクセスはフィルタできるようにします。
2. 特定の外部リゾルバサーバのみ、自社ネットワークから直接アクセスを許可する。
   社内ネットワーク内部に設置したリゾルバへの増幅攻撃は可能性として存在します。その場合DNSが利用できなくなる可能性があります。対処として、事前に特定の外部リゾルバサーバのみを許可しておくと良いでしょう。Googleでもよいですし、ISPの指定リゾルバなども考えられます。
3. 権威サーバを持っている場合、権威サーバのマスタは自社に置くとしても、キャッシュサーバ(スレーブ)は自社ネットワークの外に置き、NSはキャッシュサーバを登録する。
   どういう対策を取っていたとしても、最悪の場合には攻撃を受けることがあるかもしれません。その場合に攻撃を受けて全ての機能が停止しないように、攻撃を受ける可能性のあるDNS権威サーバについては、自社ネットワークの外に出しておく方が賢明です。DNSキャッシュサーバを利用するのがよいでしょう。

以上の構成で、自社ネットワークとインターネットの間でやりとりされるDNSがわかりやすく、少数のサーバに限定されるようになります。(自社内リゾルバ、外部利用リゾルバ、自社内権威サーバ、外部キャッシュサーバ)

[ACLの設定]

DNSの正常なやり取りが、自社内リゾルバ、外部利用リゾルバ、自社内権威サーバ、外部キャッシュサーバに限られるので、「その他のDNSクエリや返答」については「増幅を含む悪意ある攻撃」の可能性があると判断し、フィルタをかけます。

[ACL例](Pseudo-code)

許可: inbound, udp, src any:53, dest <自社内リゾルバ>
許可: outbound, udp, src <自社内リゾルバ>, dest any:53

許可: inbound, udp, src <外部利用リゾルバ>:53, dest any
許可: outbound, udp, src any, dest <外部利用リゾルバ>:53

許可: inbound, udp, src <外部キャッシュサーバ>:53, dest <自社内権威サーバ>
許可: outbound,udp, src <自社内権威サーバ>:53, dest <外部キャッシュサーバ>

拒否: both, udp, src any:53 dest any

[設置場所]

自社ネットワークのFWなどにこれらのACLを導入しても、結局ISPから自社ネットワークまでの帯域を利用されてしまえば意味がありません。当社のカスタマイズドACLのような「送信元PORTを指定してフィルタリングできるサービス」を提供しているISPを利用し、ISP側でこのフィルタをかける方が効果があります。

対処方法の効果

---

実際どれほどの効果があるかについて詳細は述べられませんが、当社の場合、DDoSを日常的に受けているお客様に対して、実際にDNSの増幅型攻撃によるサービス停止や影響を出さないよう設定し、攻撃の影響を最小化しております。

対処方法の限界やデメリット

---

この対処方法についても限界や制限、デメリットも当然存在します。

外部リゾルバの品質
外部利用リゾルバの品質や、外部キャッシュサーバに対する攻撃でサービスに影響が出る可能性があります。十分な品質を保てる外部リゾルバを利用する必要があります。

ISPの帯域
ISPのもつ帯域を超える攻撃に対しては、接続しているISPにおいて輻輳(「トラフィックの渋滞」)が発生し攻撃が成功してしまいます。

当社の場合、当社帯域を超える可能性のある攻撃について、上記で設定したACLに基づき、上流プロバイダ側でのフィルタリング依頼を行うことでこの問題の解決を試みています。

輻輳が既に発生している場合
例えば攻撃者に隣接する、遠方のネットワーク内で既にDDoSによる影響が出ていた場合、そのドロップしたパケットを救出することはできません。

以上の制限はあるものの、実効性のある対処としてACLは有効な手段であると、当社では考えています。

最後に

---

ボットネットによる直接のSYNフラッドなど、サーバを標的とする帯域に影響が見受けられにくい攻撃に対してはACLではなく、ロードバランサやDDoS対策機器の導入、またサービス型のDDoS対策や、もしくはカーネル側での防衛対策やネットワーク周りのパッチ対策が有効となります。実際にネットワークのパケット処理効率を上げるパッチやツールなども存在します。

しかし、真の脅威である大型攻撃、特に増幅型攻撃については増幅型攻撃の特徴を捉えることで、簡単なACLによる実効性のある対処が可能な場合もあります。当社では、「カスタマイズドACL」 などを基に、実効性のあるDDoS対策をお客様にご提案いたしております。

---

インターナップのDDoS攻撃対策サービス

▶DDoS攻撃対策サービスのご案内