DNSキャッシュポイズニング攻撃 確認 対策 まとめ

JPRSから緊急の注意喚起がされて、少し焦ったのでメモ。

  （緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）

→最近、カミンスキー型攻撃手法のDNSキャッシュポイズニング攻撃が日本で増えているため、注意されたし。とのこと。

カミンスキー型攻撃とはなんぞ？？

→2008年7月にカミンスキーさんが明らかにしたポイズニングの手法。

　それまでのキャッシュポイズニングと異なり、

　①攻撃目標となる名前に対し連続・繰り返し攻撃が可能で、

　②一部実装では既存のキャッシュが上書きされるため、

   目標に対し、効率的に攻撃できてしまうらしい。

　参照：http://jprs.jp/related-info/guide/009.pdf

対策は？

ソースポートランダマイゼーション

→DNSで使用するUDPポート番号をランダム化すること。

確認方法は？

①確認サイトを使う。

　・Web-based DNS Randomness Test | DNS-OARC

　　「Test My DNS」ボタンを押し、すべて「GREAT」ならOKとのこと。

　　　※ただし、記事作成時点で、実行したが、応答なし。。

②BINDのnamed.confの設定値を見る。

 具体的には、named.confにおいて下記の設定例のように、

    1）query-source/query-source-v6が設定されている行が存在する
    2）かつ、portによりポート番号が明示的に指定されている

  場合、該当する行を削除し、namedを再起動する必要があります。

  （不適切な設定例）
    query-source address * port 53;
    query-source-v6 address * port 53;

その他、NW機器についても掲載されていたが、

詳細はベンダーまでとのことだった。。

2. ネットワーク機器における不適切なポートの再変換

  ファイアーウォールやルーターなど、ネットワーク機器におけるネットワー  クアドレス変換（NAT）機能の不適切な実装により、キャッシュDNSサーバー で実施したソースポートランダマイゼーションが無効にされてしまう場合が あることが判明しています。

  この場合、該当するネットワーク機器の設定変更やファームウェアの更新、 リプレースなどの対応が必要になります。

各機器における具体的な対応方法 については、各ネットワーク機器のベンダーにお問い合わせください。

体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践