CONTENTS
Lastmodified 2013-04-02 (火) 15:49:27
Topix
過去最大規模のDDoS攻撃が発生、ピーク時には300Gbps以上のトラフィック
参考URL
http://www.e-ontap.com/internet/osc2009/img18.html
オープンリゾルバとか滅べばいいのにと思いつつオープンリゾルバについて書く
http://forums.freebsd.org/showthread.php?t=21692
pf Code:
table <ddos> persist # stop ddos block in log quick on $ext_if proto tcp from <ddos> to $web_ip port { 80, 443 } label ddos-block # http ddos prevention # I would lower these limits as they are high pass in quick on $ext_if proto tcp to $web_ip port { 80, 443 } flags S/SA label http keep state \ (max-src-conn 120, max-src-conn-rate 180/60, overload <ddos> flush global)
http://www.konata.net/freebsd/204_pf.php
tcpdump 取り敢えず・・・あれ?
root@ns1:/root # tcpdump tcpdump: WARNING: usbus0: That device doesn't support promiscuous mode (BIOCPROMISC: Operation not supported) tcpdump: WARNING: usbus0: no IPv4 address assigned tcpdump: packet printing is not supported for link type USB: use -w
netstat -i
root@ns1:/root # netstat -i Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll usbus 0 <Link#1> 0 0 0 0 0 0 fxp0 1500 <Link#2> 00:e0:18:90:33:a0 1416902 0 0 1514015 0 0 fxp0 1500 218.44.228.14 218.44.228.146 1408797 - - 1514343 - - fxp0 1500 fe80::2e0:18f fe80::2e0:18ff:fe 0 - - 1 - - plip0 1500 <Link#3> 0 0 0 0 0 0 lo0 16384 <Link#4> 729 0 0 729 0 0 lo0 16384 localhost ::1 0 - - 0 - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - lo0 16384 your-net localhost 77 - - 729 - -
tcpdump -i fxp0 port 53 で、どうじゃ?
root@ns1:/root # tcpdump -i fxp0 port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:53:25.015800 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.016516 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.017911 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.019799 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.024139 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.052324 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.075201 IP 174.128.233.250.33830 > 218.44.228.146.domain: 7490+ [1au] ANY? isc.org. (36) 06:53:25.117580 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.182056 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.242778 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.268370 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.271770 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.285396 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.350268 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.351398 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.370023 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.434142 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.553123 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.556276 IP 174.128.233.250.17172 > 218.44.228.146.domain: 7490+ [1au] ANY? isc.org. (36) 06:53:25.561019 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.597657 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.599639 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.614615 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.624453 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.662672 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.685140 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.727451 IP 174.128.233.250.24281 > 218.44.228.146.domain: 7490+ [1au] ANY? isc.org. (36) 06:53:25.747649 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 06:53:25.810225 IP zz20920572084.clear-ddos.com.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:13.354876 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:13.792561 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:13.828066 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:14.112792 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:14.850590 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:15.025459 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:15.062656 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:15.464877 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 07:11:16.205400 IP 64.40.9.7.25345 > 218.44.228.146.domain: 10809+ [1au] ANY? isc.org. (36) 445 packets captured 1026 packets received by filter 0 packets dropped by kernel
Protection against isc.org any attack – dns attack isc.org any query
http://www.minihowto.eu/protectio-against-isc-org-any-attack-dns-attack-isc-org-any-query
207 6:23 tcpdump port 53 208 6:23 tcpdum 209 6:23 tcpdump 210 6:27 netstat -i 211 6:29 usbdump -i lo0 212 6:31 ifconfig -a 213 6:32 tcpdump -D 214 6:38 tcpdump -i 215 6:38 tcpdump -i fxp0 216 6:44 history 217 6:44 tcpdump -i fxp0 port 53
http://d.hatena.ne.jp/chipa34/20080210/1202650183
flora{101} % tcpdump port 53
http://h2np.net/mynotebook/post/425
http://www.gossamer-threads.com/lists/nanog/users/111680
http://www.atmarkit.co.jp/flinux/rensai/iptables207/iptables207a.html
http://www.npa.go.jp/cyberpolice/server/rd_env/pdf/20060711_DNS-DDoS.pdf
2013-03-27 10:46:37
DNS キャッシュサーバを運用する場合、再帰的クエリを受け付ける範囲を適切 に制限しておかないと、外部の悪意ある第三者から DDoS 攻撃に悪用される可 能性があります。このようなサーバを「オープンリゾルバ」と呼びます。2006 年ころにオープンリゾルバを使った DDoS 攻撃が話題になりましたが、最近も DDoS 攻撃でオープンリゾルバが使われていること、また、国内にオープンリゾ ルバが多数存在することが指摘されています。 下記の情報などを参考に、管理するサーバがオープンリゾルバになっていない か、いま一度確認してみてください。
参考文献 (日本語) JPRS トピックス&コラム DDoSにあなたのDNSが使われる - DNS Ampの脅威と対策 -
http://jprs.jp/related-info/guide/003.pdf
JPRS DNS の再帰的な問合せを使った DDoS 攻撃の対策について
http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html
参考文献 (英語) CloudFlare The DDoS That Knocked Spamhaus Offline (And How We Mitigated It)
http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho
DNS関連技術情報のトップへ戻る -------------------------------------------------------------------------------- --------------------------------------------------------------------- ■ DNS の再帰的な問合せを使った DDoS 攻撃の対策について 2006/03/29 (Wed) --------------------------------------------------------------------- ▼概要 DNS の再帰的な問合せ (recursive queries) を使った DDoS 攻撃が数多く発 生しています。適切なアクセス制限を行っていない DNS サーバは、DDoS 攻撃 の踏み台として使用される可能性があります。 DNS サーバはその機能から、キャッシュサーバ (Recursive Server) とコンテ ンツサーバ (Authoritative Server) の 2 つに分類することができます。ま た、両機能を兼ね備えたキャッシュ・コンテンツ兼用サーバもあります。 このうち、再帰的な問合せを処理するのがキャッシュサーバであり、本ドキュ メントは、キャッシュサーバ (兼用サーバを含む) の運用管理者を対象として います。 コンテンツサーバの設定についても、本ドキュメントを参考に設定を見直して いただければ幸いです。 * キャッシュサーバ クライアントからの問い合わせ要求を受けると、コンテンツサーバに対し て再帰的に問い合わせを行い、結果をクライアントに返す DNS サーバで す。PC などがインターネットに接続する際に設定する DNS サーバであり、 DHCP や PPP などで自動的に設定される場合もあります。 * コンテンツサーバ 管理するドメインの情報 (ゾーン情報) を持ち、キャッシュサーバからの 問合せに回答する DNS サーバです。 * キャッシュ・コンテンツ兼用サーバ 名前の通り、1 台の DNS サーバでキャッシュサーバとコンテンツサーバ の両方を兼用するものです。インターネットで利用されている DNS サー バの多くが、この兼用型であるという統計があります。 ▼攻撃の踏み台とならないために BIND 編 DNS サーバの実装として最も多く利用されている BIND は、設定ファイルに指 定しない限り、アクセス制限は行われません。アクセス制限を明示的に指定し ていない BIND のキャッシュサーバは、DDoS 攻撃の踏み台となる可能性があ ります。 以下に、アクセス制限を行ったキャッシュ・コンテンツ兼用型の BIND の設定 ファイルの例を示します。これは次のような機能を持つ DNS サーバでの設定 例です。 - 自組織向けにキャッシュサーバの機能を提供している。 - 自組織のネットワークで利用している IP アドレスは、202.11.16.0/23、 192.168.100.0/24、172.20.0.0/16 である。 - "example.jp" と "example2.jp" のコンテンツサーバの機能を提供してい る。 - "example.jp" は自組織のドメインであり、マスタサーバとして動作し ている。 - "example2.jp" は別組織のドメインであり、セカンダリサーバとして動 作している。 なお、後に説明する一部の設定を除いて、本設定は BIND 8 と BIND 9 で共通 に利用できるものです。但し、実際に利用する場合は、controls (以下の例で は省略) を正しく設定してください。controls が無くても動作しますが、設 定ファイルの再読み込みなどができなくなることがあります。 キャッシュ・コンテンツ兼用サーバ ------------------------------------------------------------------- 1 // [パート 1] 自組織のネットワークの設定 2 // 3 acl my-network { 4 202.11.16.0/23 ; 5 192.168.100.0/24 ; 6 172.20.0.0/16 ; 7 } ; 8 9 // [パート 2] グローバルオプションの設定 10 // 11 options { 12 fetch-glue no ; // BIND 9では不要 13 recursion yes ; // キャッシュサーバの場合 yes 14 directory "/etc/ns" ; 15 16 allow-query { 17 localhost ; 18 my-network ; 19 } ; 20 allow-transfer { none ; } ; 21 }; 22 23 // [パート 3] ルートサーバへの hint 情報 24 // 25 zone "." { 26 type hint ; 27 file "named.root" ; 28 } ; 29 30 // [パート 4] example.jpのマスターサーバとしての設定 31 // 32 zone "example.jp" { 33 type master ; 34 file "example.jp.zone" ; 35 allow-query { any ; } ; 36 allow-transfer { 172.20.10.1 ; } ; 37 } ; 38 39 // [パート 5] example2.jpのセカンダリーサーバとしての設定 40 // 41 zone "example2.jp" { 42 type slave ; 43 file "bak/example2.jp.zone" ; 44 masters { 192.168.100.200 ; } ; 45 allow-query { any ; } ; 46 } ; ------------------------------------------------------------------- [パート 1] 自組織のネットワークの設定 3 ~ 7 行目は、アクセス制限を行うために、自組織のネットワークを定義 しています。ここでは、"my-network" という名前で、自組織のネットワー クである 202.11.16.0/23、192.168.100.0/24、172.20.0.0/16 の 3 つの IP アドレスの範囲を指定しています。 [パート 2] オプションの設定 11 ~ 21 行目がグローバルなオプションの設定です。12 行目の fetch-glue は必ず no を設定します。尚 BIND 9 ではいかなる場合も fetch-glue の機能は no ですので、この行は不要です。13 行目の recursion yes が、BIND をキャッシュサーバとして動作させるために必要 なオプションです。BIND のデフォルト値は yes ですが、ここでは明示的に 記述しています。 16 ~ 19 行目がアクセス制限の肝となる、allow-query の設定です。 allow-query には、アクセスを許可するネットワークを記述するため、[パー ト 1]で記述した自組織のネットワークと、localhost (127.0.0.1 や ::1) からのアクセスを指定します。グローバルオプションで allow-query を記 述することで、このサーバ全体が指定ネットワークからのアクセスのみを許 可するようになります。 BIND ではデフォルトで任意のサーバからのゾーン転送を許すため、20 行目 の allow-transfer で none を指定し、一旦全てのサーバからのゾーン転送 を禁止します。 [パート 3] ルートサーバへの hint 情報 25 ~ 28 行目がルートサーバへの hint 情報です。これはキャッシュサー バとして動作させる場合に必要なものですので、必ず記述してください。尚 "named.root" は、本ドキュメント執筆時点では、2004 年 1 月 29 日のも のが最新です (ファイル内に日付が記述してあります)。もしこれより古い ものしか手元に無い場合には、最新版を以下より入手して下さい。 ftp://ftp.internic.net/domain/named.root [パート 4] example.jp のマスタサーバとしての設定 32 ~ 37 行目までが "example.jp" のマスタサーバとしての設定です。ゾー ン情報は、example.jp.zone というファイルに保存してあります。 ここでもっとも重要なのが 35 行目の allow-query の行です。このサーバ では [パート 2] の options で、自組織のネットワークのみアクセスを許 可する設定を行っています。したがって、このままではコンテンツサーバと して組織外からの問い合わせに回答しなくなるため、35 行目の allow-query に any を指定して、インターネット全体からの問い合わせに 回答するように設定します。 36 行目の allow-transfer は、example.jp のセカンダリサーバである 172.20.10.1 へのゾーン転送を許可する設定です。 [パート 5] example2.jp のセカンダリーサーバとしての設定 41 ~ 46 行目までが "example2.jp" のセカンダリサーバとしての設定です。 example.jp のマスタサーバの設定と同様に、45 行目の allow-query を設 定しています。 ▼ BIND でのキャッシュサーバとコンテンツサーバの分離 BIND はキャッシュ・コンテンツ兼用型として設定されることがあります。し かし、コンテンツサーバとキャッシュサーバを分離することで、ルータやファ イアウォールによる適切なパケットフィルタリングなどを行うことが可能にな ります。上記の設定を元にキャッシュサーバとコンテンツサーバを分離した設 定例を以下に示します。 現在 BIND 8 でキャッシュ・コンテンツ兼用サーバを運用している場合は、こ の設定のように分離した運用を行うことを強く推奨します。 コンテンツサーバ用の設定 ------------------------------------------------------------------- 1 // [パート 2] グローバルオプションの設定 2 // 3 options { 4 fetch-glue no ; // BIND 9 では不要 5 recursion no ; // コンテンツサーバの場合は no 6 directory "/etc/ns" ; 7 allow-transfer { none ; } ; 8 }; 9 10 // [パート 3] ルートサーバへの hint 情報 11 // 12 zone "." { 13 type hint ; 14 file "/dev/null" ; // ファイル名に /dev/null を指定する 15 } ; 16 17 // [パート 4] example.jp のマスターサーバとしての設定 18 // 19 zone "example.jp" { 20 type master ; 21 file "example.jp.zone" ; 22 allow-transfer { 172.20.10.1 ; } ; 23 } ; 24 25 // [パート 5] example2.jp のセカンダリーサーバとしての設定 26 // 27 zone "example2.jp" { 28 type slave ; 29 file "bak/example2.jp.zone" ; 30 masters { 192.168.100.200 ; } ; 31 } ; ------------------------------------------------------------------- 特に重要なところは、5 行目の recursion no と 13 行目の hint 情報のファ イル名として "/dev/null" を指定している点です。この設定では、特に allow-query でアクセス制限を行う必要は無いため、[パート 1]にあたる acl の設定はありません。 キャッシュサーバ用の設定 ------------------------------------------------------------------- 1 // [パート 1] 自組織のネットワークの設定 2 // 3 acl my-network { 4 202.11.16.0/23 ; 5 192.168.100.0/24 ; 6 172.20.0.0/16 ; 7 } ; 8 9 // [パート 2] グローバルオプションの設定 10 // 11 options { 12 fetch-glue no ; // BIND 9 では不要 13 recursion yes ; // キャッシュサーバの場合 yes 14 directory "/etc/ns" ; 15 16 allow-query { 17 localhost ; 18 my-network ; 19 } ; 20 }; 21 22 // [パート 3] ルートサーバへの hint 情報 23 // 24 zone "." { 25 type hint ; 26 file "named.root" ; 27 } ; ------------------------------------------------------------------- キャッシュサーバとしては、ゾーンの設定が不要ですので [パート 4] と [パー ト 5] にあたる部分を除いただけとなります。 ▼攻撃の踏み台とならないために djbdns 編 djbdns は、キャッシュサーバとコンテンツサーバがそれぞれ別々の実装になっ ており、キャッシュサーバとコンテンツサーバの兼用はできません。コンテン ツサーバが tinydns、キャッシュサーバは dnscache です。 dnscache は、BIND と違い、指定した IP アドレスからのみアクセスを受け付 けます。このため、すでに設定されている dnscache が DDoS の踏み台として 利用される可能性は低いのですが、この機会に改めて設定の見直しを行うこと をお勧めします。 dnscache のアクセス制限は、設定ディレクトリ内の ip ディレクトリにある ファイルで指定します。ここでは、/var/service/dnscache/root/ip であると します。 $ cd /var/service/dnscache/root/ip $ ls 127.0.0.1 202.11.16 この場合は、ローカルホストである、127.0.0.1 と 202.11.16.0/24 からのア クセスを許すようになっています。アクセス制限の範囲を広げて 202.11.16.0/23 からのアクセス (つまり 202.11.16.0/24 と 202.11.17.0/24) を許可するのであれば、上記の環境で以下を実行します。 $ touch /var/service/dnscache/root/ip/202.11.17 ▼攻撃の踏み台とならないために Windows DNS サービス編 Windows の DNS サーバである、Windows DNS サービスは、単体ではアクセス を制限する機能はありません。またコンテンツサーバとキャッシュサーバの機 能が兼用となっています。このため、キャッシュサーバにアクセス制限を行う には、2 台のサーバを使い、キャッシュサーバとコンテンツサーバを物理的に 分離し、キャッシュサーバ側にのみルータ等の外部の機器によるアクセス制限 を施す必要があります。 Windows DNS サービスで、コンテンツ専用サーバとするには、DNS コンソール のプロパティを選びます。詳細タブに「再帰を無効にする」というチェックボッ クスがあるので、ここを選択すると、コンテンツ専用サーバになります。 --------------------------------------------------------------------- -------------------------------------------------------------------------------- 株式会社日本レジストリサービス Copyrightc2001-2013 Japan Registry Services Co., Ltd.
Total access 4074:本日 1:昨日 0