$30 off During Our Annual Pro Sale. View Details »

DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Ra...

kazeburo
January 26, 2023

DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Random Subdomain Attack and mitigations

JANOG51発表資料
https://www.janog.gr.jp/meeting/janog51/dns/

2017年のJANOG39にて弊社から「DNS権威サーバ向けのDDoS攻撃対策をした話~さくらインターネット編~」というプログラムを行い、実際に発生した障害やその後の取り組みを共有し、DNS権威サーバ向けのDDoS対策について議論いたしました。

それから5年経ちクラウドファースト、クラウドバイデフォルトなどと言われるようにクラウドサービス前提にシステムの構築運用がなされるようになり、DNSにおいても例外なくクラウドサービスが使われ、その重要度がますます高まっております。

その中で2022年にさくらのクラウドのDNS権威サーバサービスにDNS水責め攻撃が発生し、L7ファイアウォールの導入、dnsdistなどサーバ上のミドルウェアで攻撃を緩和する対策、またメトリクス取得の強化を行いました。

本セッションでは、それらの取り組みを共有し、DNS権威サーバサービスへ向けた攻撃の検知および有効な対策について議論させて頂ければと思います。

kazeburo

January 26, 2023
Tweet

More Decks by kazeburo

Other Decks in Technology

Transcript

  1. Me • ⻑野雅広(ながのまさひろ) • @kazeburo Twitter/GitHub • さくらインターネット株式会社 
 クラウド事業本部

    SRE室 室⻑ • さくらインターネットの展⽰ブース@ふじさんホール2Fにいます
  2. クラウド事業本部 SRE室 • 2022年7⽉に発⾜した新しい部署 • ミッション • クラウドサービスの信頼性を⾼めることにより、お客様や社会のDXをしっかり⽀える • ビジョン

    • 社内でのSREの実践を広め、お客様への価値提供を⾏う • さくらのサービスそのものの信頼性向上、それにより価値向上を⽬指す • さくら社員がEnabling SREとして、お客様・社外のサービスの信頼性向上に携わる
  3. クラウド事業本部SRE室の取り組み • Embedded SRE / Enabling SREとしての取り組み  • クラウドサービスのチーム開発/運⽤体制作り •

    CI/CDなどDX(Develoer Experience)向上の仕組みの構築 • ポストモーテム導⼊ • SRE as a Service • 社内における Kubernetes 基盤構築 • ログ/監視基盤の研究開発
  4. JANOG39の発表振り返り • 弊社DNSコンテンツサーバへのDDoS攻撃 • DDoSに耐えるためのバックボーンを含むインフラ構成の⾒直し • L7・DDoS Mitigation 装置の導⼊ •

    100Gトランジット導⼊ • 上流でのDDoS対策の検討 • 今回の発表は「さくらのクラウド」のDNSサービスに⾏われた攻撃を扱う
  5. DNSアプライアンスの構成 • 権威DNSサーバには PowerDNS Authoritative Server を採⽤ • Backendとして RDBMS

    (MariaDB) を使⽤ PowerDNS API MariaDB MariaDB レプリケーション 更新 参照 クエリ− dnsX サーバ API サーバ
  6. 「DNS⽔責め攻撃」とは • ランダムサブドメイン攻撃 (Pseudo-Random Subdomain Attack) と呼ばれ ることも • 2014年に初めて観測

    (https://cybersecurity-jp.com/column/34745) • 2014年〜2016年に攻撃や議論が多く⾏われている
  7. 実際の攻撃の記録(tcpdump) 07:25:11.719035 IP 209.216.160.2.50051 > 133.242.64.100.53: 43104 A? meetmodeling.example.com. (50)

    07:25:11.719057 IP 205.171.30.238.44916 > 133.242.64.100.53: 64321% [1au] A? _.modeling.example.com. (71) 07:25:11.719069 IP 172.70.109.31.63292 > 133.242.64.100.53: 40380 [1au] A? osaExpe1-pLatINUM.exAmpLe.cOm. (66) 07:25:11.719071 IP 3.139.136.204.44597 > 133.242.64.100.53: 32383% [1au] A? webdirect.foster.example.com. (65) 07:25:11.719113 IP 18.188.77.103.42513 > 133.242.64.100.53: 14853 [1au] A? note-modeling.example.com. (62) 07:25:11.719132 IP 172.70.33.19.27971 > 133.242.64.100.53: 35379 [1au] A? indian-awarded.example.com. (63) 07:25:11.719147 IP 12.121.89.48.43564 > 133.242.64.100.53: 23891 A? matchfiling.example.com. (49) 07:25:11.719156 IP 74.125.181.130.64517 > 133.242.64.100.53: 25285% [1au] A? xmL.mODeLING.eXaMple.CoM. (61) 07:25:11.719166 IP 165.225.41.202.17203 > 133.242.64.100.53: 53044% [1au] A? qatawarded.example.com. (59) 07:25:11.719176 IP 96.114.53.67.20082 > 133.242.64.100.53: 41999 [1au] A? netherlands.filing.example.com. (67) 07:25:11.719190 IP 172.253.195.196.35276 > 133.242.64.100.53: 45639% [1au] A? tdd-modeling.example.com. (61) 07:25:11.719195 IP 172.253.217.12.40587 > 133.242.64.100.53: 62658% [1au] A? web.modeling.example.com. (61) 07:25:11.719197 IP 172.253.9.4.50295 > 133.242.64.100.53: 37961% [1au] A? co.awarded.example.com. (59) 07:25:11.719224 IP 172.71.29.39.30489 > 133.242.64.100.53: 2496 [1au] A? SfaaSobvioUs.ExamplE.Com. (61) 07:25:11.719235 IP 209.66.107.33.57264 > 133.242.64.100.53: 50511 [1au] A? hap.modeling.example.com. (61) 07:25:11.719275 IP 96.114.53.69.53157 > 133.242.64.100.53: 5679 [1au] A? gitcn-awarded.example.com. (62) 07:25:11.719312 IP 172.70.229.30.59530 > 133.242.64.100.53: 45890 [1au] A? ipafoster.example.com. (58) 07:25:11.719336 IP 172.217.46.78.59507 > 133.242.64.100.53: 60186% [1au] A? testcloud-modeling.example.com. (67) 07:25:11.719351 IP 69.47.193.166.52891 > 133.242.64.100.53: 238 [1au] A? bfmpassing.example.com. (59) 07:25:11.719353 IP 34.218.119.91.26001 > 133.242.64.100.53: 31511% [1au] A? signal-modeling.example.com. (64) 07:25:11.719365 IP 34.218.119.91.13381 > 133.242.64.100.53: 4210% [1au] A? pairfiling.example.com. (59) • ランダムな⽂字列、単語の組み合わせ • ⼤⽂字・⼩⽂字まざり(Google Public DNS仕様) • ラベル数が増えることも
  8. 実際の攻撃の記録(攻撃元) # zgrep -i example.com tcpdump_20221216-0725.txt.gz | awk '{print $3}’

    | awk -F. '{print $1”.”$2”.x.x”}’ | sort | uniq -c | sort -hr | head -20 159123 172.253.x.x # public DNSఏڙऀA 96013 74.125.x.x # public DNSఏڙऀA 63560 172.70.x.x # public DNSఏڙऀB 48554 172.71.x.x # public DNSఏڙऀB 44872 18.217.x.x # Ϋϥ΢υେखC 42478 3.139.x.x # Ϋϥ΢υେखC 42057 3.18.x.x # Ϋϥ΢υେखC 39979 3.142.x.x # Ϋϥ΢υେखC 29020 3.228.x.x # Ϋϥ΢υେखC 28547 8.0.x.x 27688 172.217.x.x 27478 44.192.x.x 23852 172.68.x.x 22859 173.194.x.x 19080 165.225.x.x 17485 192.221.x.x 17328 172.69.x.x • Public DNS提供者A, Bが多い • オープンリゾルバを踏み台にしている • ⽇によって傾向が異なることもある • ⽶国以外、ロシアなどのIPが混じることもある
  9. iptablesでの対策 # *.example.com ͷ໰͍߹ΘͤΛམͱ͢ iptables -I INPUT 14 -i eth0

    -p udp --dport 53 -m string --hex-string "| 076578616d706c6503636f6d000001|" --algo bm --from 41 --to 512 -j DROP -m comment -- comment "*.example.com:a:udp" iptables -I INPUT 14 -i eth0 -p tcp --dport 53 -m string --hex-string "| 076578616d706c6503636f6d000001|" --algo bm --from 67 --to 512 -j DROP -m comment -- comment “*.example.com:a:tcp" # www.example.com ͷ໰͍߹Θͤ͸ڐՄ͢Δ iptables -I INPUT 14 -i eth0 -p udp --dport 53 -m string --hex-string "| 777777076578616d706c6503636f6d000001|" --algo bm --from 41 --to 512 -j ACCEPT -m comment -- comment "www.example.com:a:udp" iptables -I INPUT 14 -i eth0 -p tcp --dport 53 -m string --hex-string "| 777777076578616d706c6503636f6d000001|" --algo bm --from 67 --to 512 -j ACCEPT -m comment -- comment "www.example.com:a:tcp"
  10. 対策の改善へ • iptables / DDoS Mitigation装置での対策の問題点 • iptablesでは⼤⽂字⼩⽂字混じりのクエリは扱えない • ⼤規模な攻撃では影響を受ける可能性

    • DDoS Mitigation装置では攻撃検知するとゾーン丸ごとレートリミットがかか る仕様 • お客様影響が避けられない • 攻撃者の狙いを回避できているか
  11. dnsdist (https://dnsdist.org/) • PowerDNSの開発元がOSSとしてリリ ースしているDNSのプロキシーサーバ • dnsdist is a highly

    DNS-, DoS- and abuse-aware loadbalancer. Its goal in life is to route traf fi c to the best server, delivering top performance to legitimate users while shunting or blocking abusive traf fi c.
  12. dnsdist設定 addLocal("0.0.0.0:53", {reusePort=true}) addLocal("0.0.0.0:53", {reusePort=true}) newServer({address="127.0.0.1:1053",name="backend1"}) newServer({address="127.0.0.1:1053",name="backend2"}) setServerPolicy(roundrobin) domain1 =

    newSuffixMatchNode() domain1:add(newDNSName("example.com.")) addAction( AndRule({ SuffixMatchNodeRule(domain1), OrRule({QTypeRule(DNSQType.A),QTypeRule(DNSQType.AAAA)}), NotRule(QNameRule("example.com.")), NotRule(QNameRule("www.example.com.")), MaxQPSIPRule(3,16) }), DropAction() ) • 上流はローカルホストの1053ポート • ネイキッドドメイン(Zone Apex) 
 www以外にQPS制限 • /16 で 3QPS以上はDropする • 正しいサブドメインは影響受けない
  13. dnsdistベンチマーク • prsd-benchという負荷ツールをGo⾔語で作って導⼊前に検証 • 検証環境にてdnsdistを「2QPSを超えたらRefuseを返す」に設定 • 16万qps(960万クエリ/分)は捌けることを確認(CPU 4コア) # GOGC=500

    ./prsd-bench -P 53 -H 192.168.10.50 --max-workers 200 --max-length 8 -zone example.com 2023-01-06 11:17:34.853910735 +0900 JST m=+10.001231332 resolved: 2.100000 query/sec, refused 161820.500000 query/sec, failed 0.000000 query/sec 2023-01-06 11:17:44.856551706 +0900 JST m=+20.003872303 resolved: 2.000000 query/sec, refused 164345.000000 query/sec, failed 0.000000 query/sec 2023-01-06 11:17:54.853914469 +0900 JST m=+30.001235065 resolved: 2.000000 query/sec, refused 162952.400000 query/sec, failed 0.000000 query/sec
  14. 今後の対策案 • MySQL(MariaDB) backendをやめる • LMDB、BIND形式だと7-8倍以上の性能向上 • ゾーンまるごとキャッシュ • PowerDNS

    4.8系のマイルストーンに対策は上がっているが… • 負荷分散・オートスケール • 攻撃に対する対応・SLAの明記 • 反映遅延の許容範囲の緩和(マニュアルには1分と記載)
  15. PowerDNS Backend毎のベンチマーク Backend / label਺ϕϯνϚʔΫ qps 0 40000 80000 120000

    160000 label਺ 0 1 2 3 51,892 69,942 98,716 159,720 30,042 41,071 69,694 158,095 4,617 6,895 16,124 159,167 MySQL LMDB BIND