検索あなたには「このページの編集」を行う権限がありません。このページのソースの閲覧やコピーができます。DNSampはオープンリゾルバを狙ったDOS攻撃のひとつです。DNSサーバに対して別名ドメインのクエリを行い、その時に得られる応答が「なるべく長いもの」を要求するDOSです。いうのが普通のDNSサーバの動作なのですが、オープンリゾルバは'''自分のサイトに関係ない情報にも応答してしまう'''DNSサーバです。VoIP-info.jpの場合には、www.voip-info.jpとかvoip-info.jpのMXレコードには応答するべきですが、www.google.comのような「よその」ドメインに対するクエリがなされた場合には応答する必要はありません。応答してしまうものをオープンリゾルバと呼びます。DNSサーバは何も外から引かれるだけでなく内側からも引かれるわけで、その場合には内側からは外のドメインが引けるけれども、外からは他のドメインが引けてはいけないという条件が必要になります。これはDNSサーバの設定のリカーシブ機能のことで、通常は上記のような挙動をするようにリカーシブは自ドメイン/ネットワーク内だけに許可を与えます。普通はこの対策をしておけばリカーシブされないので、DNSamp攻撃は防ぐことが'''出来るように思えます'''。ここ(voip-info.jp)を含む、高橋のネットワークではいくつかのDNSサーバが動いていますが、いずれもオープンリゾルバにはなっていません。このためDNSamp攻撃に対する対策は'''できてたはず'''でした。ところが2013年8月に入ってから攻撃が激化し耐えられなくなりました。単純にいうとネットワークはこういう構造になっており、トップ・ルータの下にグローバルなネットワークがあります。ここにはグローバルIPに出ているサーバ類がいます。迂闊だったのはこのトップルータの性能でした。DNSのクエリはご承知の通り、UDPのショートパケットです。このため、一度に大量のクエリが投げつけられるとDNSampによる被害そのものは出ないものの、リクエストが大量すぎてルータのCPUが一杯一杯になってしまい、他のトラフィックが通れないという状況になってしまいました。悪いことに、特定のサーバ宛てのクエリを遮断しようとフィルタをかけたり、またそのログを取得しようとするとフィルタの「弾き返し性能」によりルータの負荷は上がり、ログのためのUDPでトラフィックはますます上がるという悪循環に陥ります。そんなわけで、トップルータをより高性能なものに交換するという措置を取りました。みなさんご承知の通り、UDPのショートパケットのスイッチング性能は高いルータでもそれほど高くなかったりというやっかいなものです。VoIPでも頭を悩ませるところのひとつですからね。オープンリゾルバに対する問題は、サーバとルータに気をつけてれば良いはずだったのですが、実はちょっとした問題があり、サーバを運用していない人にも影響する可能性があります。Resolver)に対する注意喚起について])のですが、ルータそのものがDNSサーバ機能を持っているものに関しては、この攻撃を受けうる可能性がとても高いことになります。次のような例でも対象になり得るかもしれません。当たり前のPPPoEなどによる接続かつ、NATを使用している場合、ローカル側ではDHCPを使ってIPアドレス、ゲートウェイ、DNSサーバを取得してきますが、この場合にはルータそれ自体がDNSサーバの役目をしています。ルータのIPアドレスめがけてDNSクエリが行われた場合、このルータはどのような挙動をするのでしょうか?それは'''わかりません'''。ルータの実装よりけりだからです。これに応答するルータがあって、なおかつリカーシブに応答してしまうと、ルータそのものがDNSamp用の踏み台とされかねません。一般的なルータで入力側にフィルタ機能がある場合には「外」からのDNSクエリに対してはブロックするという作戦を取ることができます。内からは問いあわせなければいけないので、内から外へのクエリは通します。'''追記:『普通の』アクセスルータでも入力(WAN)側のフィルタが適切でないと外からのDNSクエリに応答するものがありました。いうことは単なるアクセス回線しか持っていなくてもDNSampに荷担する可能性があります。サーバを運用している場合にはオープンリゾルバになっていなければ、外から問いあわせされてもRefusedで返るので特に問題ない「気」はします。当然ながら猛烈なトラフィックを食らうと他のサービスに影響する可能性があります。以下の例ではヤマハを使った対策を示します。設定例はFWX120のものですが、RTX系でも使えると思います。DNSクエリが多大なトラフィックになってしまうのであれば、QoSをかけて低減すれば他のサービスに影響を与えにくくなります。しておけばDNSクエリが多大になっても他のサービスには影響しません。ヤマハだとこんな感じでやります。これでDNSのクエリに使う帯域を100kbspに絞ることができます。そもそもDNSクエリは小さいのでそんなに帯域は要らないはずです。上記の例ではDNS以外のその他のトラフィックには60Mbpsを割り当てています。この方法には欠点があります。DoSを食らった場合、それに帯域を占有され正常なリクエストもドロップしてしまいます。「普通に」自サイトに対しクエリしようとしているものまで落としてしまうことになります。上の例ではLAN1側でQoSをかけていますが、実はこれには理由があります。単純な帯域制御であればLAN2側でかけてもいいのですが、ひと工夫してサービスをデグレードしないように設定を行います。ヤマハの資料によれば、RTX5000,RTX3500,FWX120,RTX810,RTX1200,SRT100がこのDCCをサポートするようです。実はQoSをかける例のところでLAN2側を使わなかった理由がこのDCCです。本来ならばppに対してこのDCCが効けば良いのですが、現状のファームウェアではこれはサポートされてないようで、残念ながら「入り口」におけるDCCが作動しません。そこでLAN1側で行うようにしています。Control(DCC)では制限された帯域を越えたホストをブロックする機能があります。これは単純なQoSとは異なり、帯域を食い過ぎてるホスト(IP)を一定時間蹴る機能です。DoSの場合、一般的には攻撃してくる元のIPアドレスは不明です。不明どころか複数箇所からDDoSを食らうかもしれませんし、毎回、IPアドレスが異なるかもしれません。このため、単純なフィルターでは対応できません。LUAで書けば対応できるかもな気もしますが。そこで、ヤマハのこのDCC機能を使って、多大なDNSクエリを投げてきたホストをブロックしてしまおうというわけです。設定例は次のような感じです。DCCでは「その条件」を越えたら次のクラスにリダイレクトするという機能がありますが、ここではブロック(forwarding=reject)します。上記の例ではDNSの帯域を100kbpsとし、その50%を15秒以上使う(threshold=50%,15)とブロックし、15分(time=900)経ったら解除するという設定です。この時の判断基準はデフォルトのソースIPとなり、帯域を食っているソースIPはブロックされるという挙動になります。コマンドで見ることができます。特別ページページ情報プライバシー・ポリシーVoIP-Info.jpについて免責事項モバイルビュ。