想定する攻撃がリゾルバ経由のDNS水責めだけなら、攻撃してくるリゾルバに対しては、権威サーバが応答するauth sectionのNS RRSetか、NSのAレコードを変える防御(攻撃を局所化する)手法が考えられるかな。やってるとこはすでにありそうだ
2015-02-14 19:21:47おお、移転通知を利用すると。。。 QT @hdais: 想定する攻撃がリゾルバ経由のDNS水責めだけなら、攻撃してくるリゾルバに対しては、権威サーバが応答するauth sectionのNS RRSetか、NSのAレコードを変える防御(攻撃を局所化する)手法が考えられるかな。
2015-02-14 23:50:10@OrangeMorishita 私が想定してたのはもう少し穏当な方法で、攻撃してくるリゾルバにだけ、移転通知インジェクションで隔離された全く別の権威サーバ(一応正しい応答はするが攻撃で死亡することはやむなし) へリダイレクトする事でした
2015-02-15 02:44:25@OrangeMorishita 移転通知インジェクションが効かないリゾルバもあるようなので、zone apexのNS名のAレコードは通常時は正規の権威サーバのIPを返し、攻撃してくるリゾルバには"攻撃隔離用権威サーバ" のIPを返すことでも、攻撃は隔離できるかなぁと
2015-02-15 02:59:11DNS 水責め攻撃対策?/iptables BPF module 効果測定 by @otsuka752 #dnswatertortureauthoritativeservertcpdumpbpf slideshare.net/twovs/iptables… @SlideShareさんから
2015-02-15 15:47:34@otsuka752 実験乙です。 iptablsの行数の問題であれば権威DNSはexample\.co.\jpは無視してもかまわないと思いますので www\.example\.co\.jp → wwwの部分のみ評価で現実的な行数になると思います。(それでも綺麗ではないですが)
2015-02-15 18:05:42@t0r0_twit どもです。BPF で、前半だけ見れば十分ってのは気付きませんでした。なるほど。
2015-02-15 18:12:31@otsuka752 逆に共有権威DNSとキャッシュDNSはiptablesでの対応は十分に行えない可能性があるんです。いまのところはunbound方式の問い合わせでの攻撃は見受けられないので対応できると思いますが。。。
2015-02-15 18:16:15@t0r0_twit うちの cache サーバは特定少数にしか提供してないので、真面目に考えられてないです...。 unbound 方式とは、大文字小文字混在の 0x20 な query と言うことでしょうか?
2015-02-15 18:30:57@otsuka752 です。(大文字小文字混在) キャッシュであればそれなりなISPやオープンリゾルバになっていなければ高々しれたqpsだと思いますのでrpzやゾーン投入で十分耐えられると思います(量コントロールにiptablesもいれるとなお良しです)
2015-02-15 18:35:46@t0r0_twit 了解です。ありがとうございます。 ゾーン投入の手順くらいはまとめておこうかと思います。
2015-02-15 18:38:46@otsuka752 あと、iptablesだと性能限界がip_conntrack_maxに左右されると思いますがそこは弄りました?ip_conntrack_maxを十分に大きくしてあげてip_conntrack_udp_timeoutの値も見てあげないと頭たたいちゃいます。
2015-02-15 18:46:25@t0r0_twit 今回は触らずでした...。次回は、自分のところの実環境に合わせた(正規の)負荷に合わせてやってみます。
2015-02-15 20:06:14