ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.24
  6. 3.技術トレンド

Internet Infrastructure Review(IIR)Vol.24
2014年8月22日発行
RSS

目次

3.4 DNSと攻撃

DNSは多くの機器に実装されており、多くのアプリケーションが実質的に依存しているため、攻撃に悪用されたり攻撃の対象となったりすることがあります。主にオープンリゾルバと呼ばれる、誰からの問い合わせにも応答するDNSキャッシュサーバを踏台にしたDNS増幅攻撃は、その増幅効率と攻撃分散の良さから広く悪用されてきました。多くのDNSキャッシュサーバが、何ら対策されないままに誰からの問い合わせにも応答する状態だったために踏台として悪用されました。国内のISPのDNSキャッシュサーバは近年徐々に設定を変更し、そのユーザからのみDNS問い合わせを受け付けるようになってきています。ただし、ブロードバンドルータに実装されいてる一部のDNS中継機能は標準でインターネットからのDNS問い合わせにも制限なく応答してしまうため、踏台として悪用されてしまいます。これらは個別のユーザによる対応が必要となるため、継続的な注意喚起が必要です。

DNSの権威サーバに対する攻撃やその悪用も発生しています。通常のDDoSと同じく、大量のトラフィックを権威サーバ宛に送信して輻輳によるサービス妨害を狙った攻撃や、DNSのプロトコルとしては正常な問い合わせを権威サーバに大量に投げつけてDNS増幅攻撃の踏台に悪用される事例が発生しています。単純な妨害トラフィックであれば適当なパケットフィルタなどで防御できますが、増幅攻撃の踏台として悪用された場合は攻撃を意図した問い合わせを単純に見分けることができないため、対応に検討が必要です。JP DNSを含むいくつかの権威DNSでは、Response Rate Limiting(RRL)と呼ばれる、連続した同一応答を抑制する機能を実装し、影響の軽減に努めています(※6)。ただし、この対策も万能ではないため、引き続き攻撃手法に注視し、適切な対応を模索していく必要があります。

ISPのDNSキャッシュサーバでは、2014年初旬から断続的にいくつかのドメイン名に関する大量のDNS問い合わせを観測しています。意図は不明ですが、恐らく該当ドメイン名の権威サーバに対する分散攻撃であろうと推測しています。ただし、この攻撃に付随した該当権威サーバとの通信が大量に発生するため、DNSキャッシュサーバでも過負荷になり、DNSキャッシュサーバ利用者の名前解決に遅延が生じるなどの障害が発生する場合があります。攻撃者がこれを意図しているかは別にして、利用者に影響が出てしまうようなら何らかの対策が必要ですが、オープンリゾルバになっているブロードバンドルータが踏台に利用されたり、ユーザの端末に感染したbotからのDNS問い合わせであったりと、ユーザからの通常のDNS問い合わせと同様に見えてしまうため、汎用的な対策が難しい攻撃です。異常な頻度の問い合わせ形式を注視して、都度状況に応じた対策が必要となります。

DNSでは問い合わせプロトコルとして主にUDPが利用されています。UDPはTCPと比べて通信の成りすましが容易で、攻撃者が偽の応答を注入できる可能性があります。偽の応答の注入に成功するには、問い合わせとIPアドレス、ポート番号、DNS ID、QNAMEの情報が一致する必要があります。防御側では問い合わせの該当情報が偽の応答と一致しないように努力する必要があります。DNS IDが既に十分乱数から生成されているとすると、残るは送信元ポート番号に良い乱数を利用することが必須です。送信元ポート番号を固定している古いDNS実装を利用している場合には最新のDNS実装に更新するなどして、推測しにくい問い合わせを送出できるように対策が必要です。また、一部ファイアウォールやNAPT機器では、せっかく問い合わせ元でDNS IDや送信元ポート番号に乱数を利用しても、これらの情報を上書きしてしまうものもあるため、併せて注意が必要です。

多くのDNS関連の攻撃には、送信元IPアドレスの偽装が利用されています。各ネットワークでBCP38(※7)を実装して、送信元IPアドレスの偽装ができない環境が整えば、現在のDNSを悪用した攻撃はほとんどが根絶可能です。BCP38を容易に実装できるようにとuRPF check機能も各社ルータに実装されているため、特に端末が接続しているようなネットワークでは送信元IPアドレスを偽装した攻撃の送出を未然に防げるように、積極的に送信元IPアドレスの検証導入をご検討ください。

3.技術トレンド

ページの終わりです

ページの先頭へ戻る