SlideShare a Scribd company logo

iptables BPF module 効果測定

•
•
@ otsuka752
@ otsuka752

iptables BPF module 効果測定 DROP! the ${RANDOM} queries

1 of 28
iptables BPF module 効果測定 DROP! the ${RANDOM} queries 2015/02/15 @otsuka752 (@twovs)
復習 ${RANDOM}.www.example.jp の query を iptables で DROP するには… $ sudo iptables -A 'INPUT|FORWARD' -j DROP -p udp --dport 53 ¥ -m bpf --bytecode "18,177 0 0 0,0 0 0 20,12 0 0 0,7 0 0 0,80 0 0 0,12 0 0 0,4 0 0 1,7 0 0 0,64 0 0 0,21 0 7 58161015,64 0 0 4,21 0 5 124090465,64 0 0 8,21 0 3 1836084325,64 0 0 12,21 0 1 40529920,6 0 0 1,6 0 0 0,"
測定したこと A) iptables 無しの qps [query/sec] bind-9.10.1-P1/NSD-4.1.1 B) ${RANDOM}.www.example.jp の query をB) ${RANDOM}.www.example.jp の query を iptables で DROP した時の qps と応答率 C) iptables のルールを増やした時の qps -m bpf --bytecode=… の行を追加
やらなかったこと • DNS cache (キャッシュ)サーバの性能測定 • パフォーマンスチューニング (OS/bind/NSD/dnsperf などなど)(OS/bind/NSD/dnsperf などなど) • ipset の利用 http://ipset.netfilter.org/ • …
構成概要/全体
構成概要/server • Intel(R) Xeon(R) CPU 5148 @ 2.33GHz (x2) • Ubuntu 14.0.4.1 • iptables v1.4.21 • DNS authoritative server • bind-9.10.1-P1 • NSD-4.1.1 (without libevent) • zone-data • 100万レコード • bind/NSD で同じ zone-data ファイルを使用
構成概要/client • Intel(R) Xeon(R) CPU 5148 @ 2.33GHz (x2) • Ubuntu 14.0.4.1 • dnsperf-src-2.0.0.0-1 • query-data • NOERROR になる(zone-file に登録済) QNAME 10万件 • NXDOMAIN になる(zone-file に無い) QNAME 10万件 • NOERROR と NXDOMAIN 半分ずつ交互の QNAME 10万件 • tcpreplay-4.1.0 • pcap-data • NXDOMAIN になる QNAME を問い合わせる • 送信元の IP:port が query 間で重複しないパケット
dnsperf dnsperf -s (server) -p 53 -a (client) -x 0 ¥ -d (data-file) -c 1 -l 60 -b 212992 -t 5 -q 100 -S 5 • -d the input data file (default: stdin) ${EXIST}.example.jp A や ${RANDOM}.example.jp A など • -b socket send/receive buffer size in kilobytes server/client のデフォルト値を明示的に指定(212992) • -q the maximum number of queries outstanding (default: 100) 色々変更したけど大差無いのでデフォルト値(100) • -Q limit the number of queries per second 試験B) では正常 query の最大 qps を指定して測定 • 詳細は man や参考資料を
A) iptables 無しの qps • NOERROR ${EXIST}.example.jp • NXDOMAIN(1) ${RANDOM}.example.jp • NXDOMAIN(2) ${RANDOM}.www.example.jp • MIXED NOERROR と NXDOMAIN(1) を交互に
A) まとめ/iptables 無し • bind-9.10.1-P1 69000[qps] NSD-4.1.1 160000[qps] (本構成での bind/NSD の qps を出しただけ) • NOERROR を応答するより NXDOMAIN の応答の方が若干速い
B) iptables で DROP した時 • DNS queries • bind には 1000, 10000, 20000, 30000, 40000, 60000[qps] を • NSD には 60000, 100000, 130000,• NSD には 60000, 100000, 130000, 150000[qps] を最大 qps に指定し性能測定 • ATTACK queries • NXDOMAIN となる ${RANDOM} query を 700000[qps] まで徐々に付与
B) iptables で DROP した時 bind/NSD の 応答を測定する DNS query 送信元 IP:port が query 間で重複しない DNS ${RANDOM} query
B-1a) bind(<70K ATTACK) *1 [qps] ATTACK [qps]
B-1b) bind(<70K ATTACK) [%] *1 ATTACK [qps]
B-1) まとめ/bind(<70K) • (*1) 高負荷(>40000[qps])で稼動している bind は 5000[qps] 4[Mbps]以下の ATTACK で影響を受け 応答率が悪化する応答率が悪化する
B-2a) bind(<700K ATTACK) [qps] *2 *3 ATTACK [qps]
B-2b) bind(<700K ATTACK) *4 *5 [%] *5 ATTACK [qps]
B-2) まとめ/bind(<700K) • (*2) <40000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP すれば 少なくとも 50-70万[qps] 400-560[Mbps]の少なくとも 50-70万[qps] 400-560[Mbps]の ATTACK でも影響を受けない • (*3) 50-70万[qps] の ATTACK を生成できなかった client マシンの性能限界だと思われる
B-2) まとめ/bind(<700K) • (*4) 60000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP すれば 20万[qps] 160[Mbps]程度までの ATTACK でも20万[qps] 160[Mbps]程度までの ATTACK でも 影響を受けない • (*5) 60000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP しても 50万[qps] 400[Mbps]の ATTACK を受けると 応答率は 80[%]程度になる
B-3a) NSD(<700K ATTACK) [qps] *6 *8 *7 ATTACK [qps]
B-3b) NSD(<700K ATTACK) *8[%] ATTACK [qps]
B-3) まとめ/NSD(<700K) • (*6)は iptables 無し (*7)は iptables あり 何の傾き??? (何かの限界???) • (*8) 60000[qps]で稼動している NSD は iptables で ${RANDOM} query を DROP すれば 40万[qps] 320[Mbps]程度までの ATTACK でも 影響を受けない(同条件の bind の結果は (*4))
C) iptables のルールを増やした時 • NOERROR となる ${EXIST}.example.jp で qps 測定 • iptables -m bpf --bytecode … の行数を増やした • time(右軸)は iptables を設定した時の所要時間[sec]
C) まとめ • 性能的にも運用上もルールは 2桁(<100)にしたい • 大文字小文字混在の ATTACK の DROP が困難 www.example.jp www.example.jPwww.example.jP www.example.Jp www.example.JP … WWW.EXAMPLE.Jp WWW.EXAMPLE.JPで 1000行以上に
感想 • 一定の効果は確認できたけど… 本気の攻撃には効果なし ＜知ってた 通常の query が少ないサーバには有効か??? • もっと現実的な値でも測定すれば良かった• もっと現実的な値でも測定すれば良かった query < 1000[qps] && iptables < 100[lines] (ただし ATTACK は最大まで) • サーバ(client)がもっと欲しい 途中のルータ/FireWall で DROP させたり DNS/ATTACK queries を別サーバから…などなど
募集 • 感想 • 突っ込み • アイディア• アイディア • …
参考 • DNSの評価と計測の話 Internet Week 2013 https://www.nic.ad.jp/ja/materials/iw/2013/ proceedings/d2/d2-hattori.pdf • DNS 水責め攻撃から DNS 権威サーバを守る たった 1つのステキな方法 http://www.slideshare.net/twovs/ how-to-defend-dns-authoritative-server-against-dns-watertorture • Tcpreplay http://tcpreplay.jp/ http://tcpreplay.appneta.com/
ENDEND

More Related Content

iptables BPF module 効果測定

  • 1. iptables BPF module 効果測定 DROP! the ${RANDOM} queries 2015/02/15 @otsuka752 (@twovs)
  • 2. 復習 ${RANDOM}.www.example.jp の query を iptables で DROP するには… $ sudo iptables -A 'INPUT|FORWARD' -j DROP -p udp --dport 53 ¥ -m bpf --bytecode "18,177 0 0 0,0 0 0 20,12 0 0 0,7 0 0 0,80 0 0 0,12 0 0 0,4 0 0 1,7 0 0 0,64 0 0 0,21 0 7 58161015,64 0 0 4,21 0 5 124090465,64 0 0 8,21 0 3 1836084325,64 0 0 12,21 0 1 40529920,6 0 0 1,6 0 0 0,"
  • 3. 測定したこと A) iptables 無しの qps [query/sec] bind-9.10.1-P1/NSD-4.1.1 B) ${RANDOM}.www.example.jp の query をB) ${RANDOM}.www.example.jp の query を iptables で DROP した時の qps と応答率 C) iptables のルールを増やした時の qps -m bpf --bytecode=… の行を追加
  • 4. やらなかったこと • DNS cache (キャッシュ)サーバの性能測定 • パフォーマンスチューニング (OS/bind/NSD/dnsperf などなど)(OS/bind/NSD/dnsperf などなど) • ipset の利用 http://ipset.netfilter.org/ • …
  • 6. 構成概要/server • Intel(R) Xeon(R) CPU 5148 @ 2.33GHz (x2) • Ubuntu 14.0.4.1 • iptables v1.4.21 • DNS authoritative server • bind-9.10.1-P1 • NSD-4.1.1 (without libevent) • zone-data • 100万レコード • bind/NSD で同じ zone-data ファイルを使用
  • 7. 構成概要/client • Intel(R) Xeon(R) CPU 5148 @ 2.33GHz (x2) • Ubuntu 14.0.4.1 • dnsperf-src-2.0.0.0-1 • query-data • NOERROR になる(zone-file に登録済) QNAME 10万件 • NXDOMAIN になる(zone-file に無い) QNAME 10万件 • NOERROR と NXDOMAIN 半分ずつ交互の QNAME 10万件 • tcpreplay-4.1.0 • pcap-data • NXDOMAIN になる QNAME を問い合わせる • 送信元の IP:port が query 間で重複しないパケット
  • 8. dnsperf dnsperf -s (server) -p 53 -a (client) -x 0 ¥ -d (data-file) -c 1 -l 60 -b 212992 -t 5 -q 100 -S 5 • -d the input data file (default: stdin) ${EXIST}.example.jp A や ${RANDOM}.example.jp A など • -b socket send/receive buffer size in kilobytes server/client のデフォルト値を明示的に指定(212992) • -q the maximum number of queries outstanding (default: 100) 色々変更したけど大差無いのでデフォルト値(100) • -Q limit the number of queries per second 試験B) では正常 query の最大 qps を指定して測定 • 詳細は man や参考資料を
  • 9. A) iptables 無しの qps • NOERROR ${EXIST}.example.jp • NXDOMAIN(1) ${RANDOM}.example.jp • NXDOMAIN(2) ${RANDOM}.www.example.jp • MIXED NOERROR と NXDOMAIN(1) を交互に
  • 10. A) まとめ/iptables 無し • bind-9.10.1-P1 69000[qps] NSD-4.1.1 160000[qps] (本構成での bind/NSD の qps を出しただけ) • NOERROR を応答するより NXDOMAIN の応答の方が若干速い
  • 11. B) iptables で DROP した時 • DNS queries • bind には 1000, 10000, 20000, 30000, 40000, 60000[qps] を • NSD には 60000, 100000, 130000,• NSD には 60000, 100000, 130000, 150000[qps] を最大 qps に指定し性能測定 • ATTACK queries • NXDOMAIN となる ${RANDOM} query を 700000[qps] まで徐々に付与
  • 12. B) iptables で DROP した時 bind/NSD の 応答を測定する DNS query 送信元 IP:port が query 間で重複しない DNS ${RANDOM} query
  • 15. B-1) まとめ/bind(<70K) • (*1) 高負荷(>40000[qps])で稼動している bind は 5000[qps] 4[Mbps]以下の ATTACK で影響を受け 応答率が悪化する応答率が悪化する
  • 18. B-2) まとめ/bind(<700K) • (*2) <40000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP すれば 少なくとも 50-70万[qps] 400-560[Mbps]の少なくとも 50-70万[qps] 400-560[Mbps]の ATTACK でも影響を受けない • (*3) 50-70万[qps] の ATTACK を生成できなかった client マシンの性能限界だと思われる
  • 19. B-2) まとめ/bind(<700K) • (*4) 60000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP すれば 20万[qps] 160[Mbps]程度までの ATTACK でも20万[qps] 160[Mbps]程度までの ATTACK でも 影響を受けない • (*5) 60000[qps]で稼動している bind は iptables で ${RANDOM} query を DROP しても 50万[qps] 400[Mbps]の ATTACK を受けると 応答率は 80[%]程度になる
  • 22. B-3) まとめ/NSD(<700K) • (*6)は iptables 無し (*7)は iptables あり 何の傾き??? (何かの限界???) • (*8) 60000[qps]で稼動している NSD は iptables で ${RANDOM} query を DROP すれば 40万[qps] 320[Mbps]程度までの ATTACK でも 影響を受けない(同条件の bind の結果は (*4))
  • 23. C) iptables のルールを増やした時 • NOERROR となる ${EXIST}.example.jp で qps 測定 • iptables -m bpf --bytecode … の行数を増やした • time(右軸)は iptables を設定した時の所要時間[sec]
  • 24. C) まとめ • 性能的にも運用上もルールは 2桁(<100)にしたい • 大文字小文字混在の ATTACK の DROP が困難 www.example.jp www.example.jPwww.example.jP www.example.Jp www.example.JP … WWW.EXAMPLE.Jp WWW.EXAMPLE.JPで 1000行以上に
  • 25. 感想 • 一定の効果は確認できたけど… 本気の攻撃には効果なし ＜知ってた 通常の query が少ないサーバには有効か??? • もっと現実的な値でも測定すれば良かった• もっと現実的な値でも測定すれば良かった query < 1000[qps] && iptables < 100[lines] (ただし ATTACK は最大まで) • サーバ(client)がもっと欲しい 途中のルータ/FireWall で DROP させたり DNS/ATTACK queries を別サーバから…などなど
  • 26. 募集 • 感想 • 突っ込み • アイディア• アイディア • …
  • 27. 参考 • DNSの評価と計測の話 Internet Week 2013 https://www.nic.ad.jp/ja/materials/iw/2013/ proceedings/d2/d2-hattori.pdf • DNS 水責め攻撃から DNS 権威サーバを守る たった 1つのステキな方法 http://www.slideshare.net/twovs/ how-to-defend-dns-authoritative-server-against-dns-watertorture • Tcpreplay http://tcpreplay.jp/ http://tcpreplay.appneta.com/