アプリケーション異常で検知可能です｡
Webの システム管理 > ネットワーク > 異常状態 > [tab]アプリケーション異常 にて新規設定を追加します｡
攻撃タイプを”ワーム”にしてください｡
ベースラインが閾値になります｡この例だとDNSクエリの応答パケット(送信元ポート udp/53)が 500pps を超えると検知します｡値は調整してください｡
検知スコープが”ホーム”の場合､発信元がホームネットワークに該当する場合に検知対象となります｡
(ホームネットワークは システム管理 > ネットワーク > ホームネットワーク で設定します)
設定後、ディスパッチを行います｡
(システム管理 > 構成 にて実施)
閾値をこえるDNSクエリへの応答パケットが発生した場合､このように検知します｡
(画面例はテストのため閾値を低くしています)
GenieATMはA10 Thunder TPSやRadware DefensePro等のミチゲーションデバイスと連携してDDoS攻撃を防御する機能を持っています。
ブラックホールポリシーと同様のミチゲーションポリシーをあらかじめ定義しておき，特定のホストへの攻撃を検知したときに当該ホストへのトラフィックへの経路をミチゲーションデバイスに向けることで防御を行います。
デバイス連携の自動ミチゲーションを有効にしていたにもかかわらず，防御対象のIPアドレスに対する攻撃が検出されたときに，ポリシーが発動しない場合があります。その場合，すでに発動中のミチゲーションアクションによりポリシーに設定したデバイスの帯域が埋まっている可能性があります。
ミチゲーションデバイス連携ポリシーの設定画面には，下のような帯域設定項目があります。これは，デバイスのキャパシティを超えて異常トラフィックが流れ込まないようにするための機能です。
例えば，帯域を1Gbpsに設定しているデバイスに現在発動中のミチゲーションにより合計1Gbps超のトラフィックがすでに流入している場合，当該デバイスについて新たなミチゲーションは発動されません。ただし，ブラックホールポリシーなどほかのタイプのポリシーが定義されている場合は，そちらが発動します。
DoS攻撃防御のためのブラックホールルーティングにおいてNullルートのIPアドレスに0.0.0.0を設定すると，DoS防御が発動されてもルート変更が有効にならないケースがあります。
これは，ルータが0.0.0.0のアドレスをNext Hopとして採用しないことが原因の場合があります。このときの動作はルータの実装に依りますが，たとえば，vyattaでは以下のようなログが出力されて，失敗します。
Apr 8 05:31:18 vyatta254 bgpd[2322]: 172.16.2.8 rcvd UPDATE w/ attr: nexthop 0.0.0.0, origin i, localpref 255, metric 0, community 1:1,path Apr 8 05:31:18 vyatta254 bgpd[2322]: 172.16.2.8 rcvd UPDATE about 20.1.0.0/24 -- DENIED due to: martian next-hop;
そのため，Nullルートとしては0.0.0.0以外のIPアドレスを設定するようにしてください。