ホワイト ペーパー

F5 DDoS対策:推奨プラクティス(第1巻)

Updated December 29, 2013
  • Share via AddThis

1 コンセプト

今日、分散型サービス拒否(DDoS)攻撃は、名高い金融機関からサービス プロバイダまで、多くの組織にとって最大の関心事となっています。経験豊富な管理者は、F5装置がDDoS攻撃の緩和に適しているだけでなく、あるタイプのDDoS攻撃を緩和できる唯一の製品となりうることを理解しています。しかし、F5製品で補完することで完全なオンプレミスDDoSソリューションを実現できることは、まだ多くの管理者が知りません。

DDoS攻撃を受けると、ネットワークの一部が応答不能になり、機器が全面的に停止する可能性があるなど、大きな負担が生じかねません。そのような状況で防御策を練ることは得策ではありません。ネットワーク アプリケーションの備えを「平時」に整えておくことで、将来の攻撃を緩和することができます。

このガイドでは、F5ネットワーキング ソリューションとオプションのF5セキュリティ ソリューションが導入されていることを前提としています。

また、特に記載のない限り、すべての構成、コマンド、プラットフォームがTMOS 11.3.0を使用しているものとします。

技術情報の多くはF5装置に固有のものですが、一部の戦略(ポートの枯渇を回避するためのSNATプールの使用など)は他のベンダの機器にも適用される場合があります。

2 DDoS耐性の高いアーキテクチャ

DDoS耐性の高いアプリケーション デリバリ ネットワークを構築することが可能です。このセクションでは、ネットワークとアプリケーションを回復力の高いものにするために、攻撃を受ける前にできる備えについて説明します。

2.1 F5の推奨アーキテクチャ

図1:F5が推奨する2層のDDoS対策

多くの組織は、DDoS耐性を高めるためにアーキテクチャの設計を見直しています。F5は、2層構造のDDoSソリューションを多くのお客様にお勧めしています。第1層(境界)は、レイヤ3と4を保護するネットワーク ファイアウォールと単純なロード バランシングを組み込みます。第2層には、SSL終端やWebアプリケーションファイア ウォールなどのより高度でCPU負荷の高いサービスを配置します。

2層構造の防御アプローチには次のようなメリットがあります。

  • 緩和を分離することで、レイヤ3と4の攻撃を第1層で緩和し、アプリケーション防御を第2層で行うことができます。
  • 各層を個別に拡張できます。例えば、WAFの使用量が増加している場合は、第1層に影響を与えることなく、別のアプライアンス(またはブレード)を第2層に追加できます。
  • プラットフォームのタイプやさらにはソフトウェア バージョンが層ごとに異なっていても構いません。
  • 第2層に新しいポリシーを適用した場合、新しいポリシーが完全に検証されるまで、第1層はトラフィックの一部だけを新しいポリシーに差し向けることができます。
  第1層 第2層 DMZ
F5のコンポーネント AFM + LTM LTM + ASM GTM DNS Express
OSIモデル レイヤ3 + 4 レイヤ7以上 DNS
機能 ネットワーク ファイアウォール SSL終端  
第1層ロード バランシング Webアプリケーション ファイアウォール DNS解決
IPレピュテーション ブラックリスト バランシング  
緩和される攻撃 SYNフラッド Slowloris  
ICMPフラッド Slow POST UDPフラッド
不正な形式のパケット Apache Killer DNSフラッド
TCPフラッド RUDY/Keep Dead NXDOMAINフラッド
既知の不正ユーザー SSL再ネゴシエーション DNSSEC

2.2 第1層:ネットワーク防御

第1層は、ネットワーク ファイアウォールを中心として構築されています。ほとんどの場合、ネットワーク ファイアウォール(F5製もそれ以外もある)が既に導入され、ネットワーク ファイアウォール チーム(または少なくとも管理者)がいます。この層では、レイヤ3とレイヤ4(IPとTCP)の防御を準備し、DDoS攻撃時のSYNフラッドとTCPフラッドを緩和し、送信元アドレスをブロックします。

以降のセクションの内容は第1層の装置に当てはまります。それがF5® BIG-IP® Advanced Firewall Manager™(AFM)ファイアウォール モジュールであるか、他社製ネットワーク ファイアウォールの前に置かれたF5® BIG-IP® Local Traffic Manager™(LTM)ロード バランサであるかは関係ありません。

2.2.1 仮想サーバー タイプの選択

第1層でF5製ファイアウォール(BIG-IP AFM)またはF5製ロード バランサ(BIG-IP LTM)のいずれかを使用している組織は、この構成をどのように構築するかを選択できます。「リスナー」オブジェクトを定義する方法は4通りあります。いずれの方法も構成をアレンジするための有効な方法ですが、DDoSへの対処方法の強みはそれぞれ異なります。

  • フルプロキシ仮想サーバーは、F5構成の標準的な仮想サーバーです。これらのリスナーは、サーバーへのセカンダリ接続を開始する前に、各着信クライアントとの実際の接続を確立します。クライアント接続を終了して検証するという動作そのものが、第2層を呼び出す前の幅広い防御策となります。
  • 転送仮想サーバーは、高速処理とSYNフラッドに対する防御を同時に実現しますが、フルプロキシ仮想サーバーのような幅広い防御は提供しません。
  • ワイルドカード仮想サーバーは、ファイアウォール ルールをアプリケーション仮想サーバーから分離できます。これにより、「FTPサービスを提供する任意のアドレスに対して、このルールセット、このミラーリング ポリシー、このソースNATポリシーを適用する」といったルールを作成できるようになります。
  • ルート ドメインは、重複したIPサブネットを論理的な別のルーティング テーブルに分離するもので、サービス プロバイダの環境で一般的に使用されています。ルート ドメインは、それ自体にはDDoSに関するメリットがほぼありませんが、レイヤ4のセキュリティ ポリシーを適用するための基盤として使用することが可能です。
図2:ワイルドカード サーバーは第1層のオプションの1つ

ltm virtual ws_ftp { destination 0.0.0.0:ftp ip-protocol tcp profiles { ftp { } tcp { } } translate-address disabled }

一般的にF5では、DDoSが最大の懸念である場合は、フルプロキシまたは転送仮想サーバーを第1層で使用することを推奨しています。

2.2.2 第1層でのSYNフラッドの緩和

F5では常にTCP SYNフラッドを緩和します。バージョン11.5では、Direct Server Return(DSR)仮想サーバーに対するSYNフラッドも緩和されます。お使いのBIG-IPでSYNフラッド対策が講じられていることを確認するには、シンプルなshowコマンドを使用して、個々の仮想サーバーのSYNフラッド統計を表示します。

% tmsh show ltm virtual vip1
…

SYN Cookies

 Status full-software

 Hardware SYN Cookie Instances 0

 Software SYN Cookie Instances 2

 Current SYN Cache 0

 SYN Cache Overflow 0

 Total Software 432.2K

 Total Software Accepted 0

 Total Software Rejected 0

 Total Hardware 0

 Total Hardware Accepted 0

多くのF5プラットフォームは、SYNフラッドをハードウェアで緩和でき、メインのトラフィック ステアリングCPUが他のタスクを実行できるようになっています。

 

プラットフォーム 1秒あたりのハードウェアSYN数 バージョン
B4300ブレード 8,000万 11.3
B2100ブレード 4,000万 11.3
10200V 8,000万 11.3
10000S 4,000万 11.4
7200V 4,000万 11.4
7000S 2,000万 11.4
5200V 4,000万 11.4
5000S 2,000万 11.4
*8800、8400、6800、6400を含む旧式のプラットフォームは、ハードウェアSYN Cookieもサポートしていますが、これらのモデルは、このドキュメントの基準であるバージョン11.3ではサポートされていません。

表1:SYNフラッドに対するハードウェア サポート プラットフォームの一覧

SYNフラッドを緩和するためハードウェア オフロードを特定の仮想サーバーで有効にするには、より厳格なセキュリティ ポスチャを持つtcpプロファイルを作成します。この例では、DDoS関連の2つの変数を設定します。具体的には、ハードウェアSYN Cookieを有効にし、さらに「ゼロウィンドウ」TCP攻撃が仮想サーバーに与える影響を軽減するdeferred-accept変数も設定します。

% tmsh create ltm profile tcp tcp_ddos { hardware-syn-cookie deferred-accept 
enabled zero-window-timeout 10000 }

次に、既存の「tcp」プロファイルを置き換えることで、新しいtcpプロファイルを仮想サーバーに関連付けます。

% tmsh list ltm virtual vip1 profiles

% tmsh modify ltm virtual vip1 profiles replace-all-with { tcp_ddos my_ddos1 
http }

2.2.3 第1層でのUDPとUDPフラッドの拒否

UDPフラッドは容易に生成でき、防御が困難なため、よく使われるDDoS攻撃ベクトルです。一般的に、仮想サーバーの背後にあるアプリケーションがUDPトラフィックを積極的に受け入れていない限り、仮想サーバーに向かうUDPトラフィックを許可しないでください。

アプリケーションがUDPを受け入れる場合でも、UDPフラッドによってシステムが制圧される可能性があり、アプリケーションの仮想サーバーへのUDPトラフィックを一時的に拒否する必要が生じる場合があります。

% tmsh create security firewall rule-list drop_udp { rules add { drop_udp_rule 
{ action drop ip-protocol udp place-after first } } }

% tmsh modify ltm virtual vip1 fw-rules { drop_udp_vip1 { rule-list drop_udp } 
} }

攻撃が停止したら、仮想サーバーからルールを削除して構いません。

バージョン11.5では、例外を細かく設定してUDPフラッドを監視し、緩和することができます。これにより、第1層の仮想サーバーを通過するUDPトラフィックのベースラインを設定できます。このしきい値を超えたUDPトラフィックは、ユーザーが定義した8つのポート例外(RTSPやDNSなど)のいずれかに一致しない限り、排除されます。

2.2.4 ICMPフラッドの拒否

ICMPもまた、一般的なDDoS攻撃ベクトルです。ICMPフラグメントは、生成となりすましが容易であり、さまざまなタイプのネットワーキング デバイスのリソースを枯渇させる可能性があります。

BIG-IP AFMは、トラフィック パターン分析に基づいて、正常な量のICMPとICMPフラッドを区別することができます。BIG-IP AFMのネットワーク ファイアウォールを仮想サーバー上で有効にすると、数種類のトラフィックの増加を監視できます。正常な量は許可され、フラッドの残りの部分は拒否されます。

2.2.5 AFMのDDoSデバイス プロファイルの使用

攻撃者がファイアウォールのリソースを消費する方法の1つは、特別に細工された無効なパケットを大量に送りつけることです。ファイアウォールは、各パケットを調べてログに記録する必要があります。例えば、不審なフラグのある組み合わせ(PSH+ACKと空のペイロードなど)がよく使われていても、翌月には別の組み合わせが使われるようになることがわかっています。

このように状況が変化するため、どのようなL3/L4攻撃が起こる可能性が高いかを予測することは困難です。(他社製ファイアウォールの)セキュリティ管理者は、これらの攻撃に注意し、必要以上にCPUが使用されないように配慮しながら、攻撃をブロックするためのルールを組み込むことができるように備えておく必要があります。

この問題に対するF5のアプローチは、L3/L4プロトコル検証の多くを、それをサポートしているTMOSプラットフォーム上のカスタム ハードウェア ロジックに移行することでした。BIG-IP AFMモジュールは、クリスマス ツリー パケットやLAND攻撃パケットのフラッドなど、レイヤ3とレイヤ4の多数のDDoS攻撃ベクトルをデフォルトで監視しています。これらのパケットはほぼすべて、BIG-IPの設定に関係なく廃棄されます。これらのパケットのフラッドが検出されると、BIG-IP AFMは特別なログ メッセージを送信できます。

表1は、ハードウェア支援型L3/L4プロトコル検証をサポートしているTMOSプラットフォームを示しています。これらは、SYNフラッド ハードウェアをサポートしているプラットフォームと同じです。

どのプラットフォーム(仮想エディションを含む)でも、L3/L4で不審なパケットのフラッドを追跡するパラメータの管理が可能です。管理画面には、ユーザー インターフェイスの[Security]タブからアクセスできます。[DoS Protection][Device Configuration]の順に選択します。

図3:ネットワークDDoS構成の設定

これらの設定には、コマンドラインでsecurity dos device-configコマンドを使用してアクセスできます。値は、プラットフォームごとではなく、トラフィック管理マイクロカーネル(tmm)ごとに設定されます。この表では、列がこれらの値に対応しています。

  • Detection Threshold PPS。攻撃が発生しているかどうかを判断するためにBIG-IPシステムで使用される、(この攻撃タイプの)1秒あたりのパケット数です。1秒あたりのパケット数がこのしきい値を超えると、BIG-IPシステムは攻撃をログに記録して報告し、1秒ごとにチェックを続けて、しきい値を超えている間はしきい値に攻撃を示すマークを付けます。
  • Detection Threshold Percent。攻撃が発生していることを示す増加率の値です。BIG-IPシステムは、現在のレートと直近1時間の平均レートを比較します。例えば、直近1時間の平均レートが1000パケット/秒で、増加率のしきい値を100に設定した場合、攻撃は平均を100%上回る2000パケット/秒で検出されます。しきい値を超えると、攻撃がログに記録されて報告されます。BIG-IPシステムは、レート制限を直近1時間の平均値に自動的に設定し、その制限を超えたパケットはすべて排除されます。BIG-IPシステムは、着信パケットのレートが増加率のしきい値を下回るまで毎秒チェックを継続します。レート制限は、指定された制限値をレートが再び下回るまで継続されます。
  • Default Internal Rate Limit。このタイプのパケット数の上限を示す1秒あたりパケット数の値です。このタイプのパケットのうちしきい値を超えた分はすべて排除されます。レート制限は、指定された制限値をレートが再び下回るまで継続されます。

2.2.6 TCP接続フラッドの緩和

TCP接続フラッドは、レイヤ4の異常であり、ネットワーク上のあらゆるステートフル デバイス、特にファイアウォールに影響を与えます。これらのフラッドの多くは空で、実際の中身がありません。第1層のBIG-IP LTMまたはBIG-IP AFMは、大容量の接続テーブルに接続を吸収することで、これらのフラッドを緩和できます。

 

プラットフォーム TCP接続テーブルのサイズ SSL接続テーブルのサイズ
VIPRION 4480(4 x B4300) 1億4,400万 3,200万
VIPRION 4480(1 x B4300) 3,600万 800万
VIPRION 4400(4 x B4200) 4,800万 500万
VIPRION 4400(1 x B4200) 1,200万 100万
VIPRION 2400(4 x B2100) 4,800万 1,000万
VIPRION 2400(1 x B2100) 1,200万 250万
11000シリーズ 2,400万~3,000万 264万~390万
10200シリーズ 3,600万 700万
8900シリーズ 1,200万 264万

 

プラットフォーム TCP接続テーブルのサイズ SSL接続テーブルのサイズ
7000シリーズ 2,400万 400万
6900シリーズ 600万 660,000
5000シリーズ 2,400万 400万
4200Vシリーズ 1,000万 240万
3900シリーズ 600万 660,000
仮想エディション 300万 660,000

2.2.7 アダプティブ リーピングの構成

大容量の接続テーブルを使用している場合でも、フラッド攻撃に対する対策プロファイルを強化するために調整できる設定があります。

BIG-IP接続テーブルがいっぱいになると、アダプティブ リーピングの下限値と上限値に従って接続が「リーピング」されます。これらの値をデフォルト値の85と95より下げることで、「接続数を急増」させるDDoSの緩和を早い段階で開始し、最初の攻撃がサーバーに負荷をかける時間を短縮することができます。

% tmsh modify ltm global-settings connection adaptive-reaper-lowater 75

2.2.8 アイドル タイムアウトを変更して空の接続フラッドに対抗

レイヤ4の接続フラッドがF5デバイスにもたらすリスクは一般に高くありませんが、他のファイアウォールなどのステートフル デバイスには確実に影響を及ぼします。これらのデバイスは、F5の状態テーブルがいっぱいになるかなり前に、ほぼ機能不全になります(セクション2.2.6の表2を参照)。接続フラッドの中身が主に空の接続である場合は、これらの空の接続をより積極的に閉じるようにBIG-IPに指示することができます。

BIG-IPにはレイヤ4に関連する主要なプロファイルが3つあります。

  • fastL4:ハードウェア支援型の高性能TCPプロファイル
  • tcp:大多数の仮想サーバーで使用される標準的なTCPプロファイル
  • udp:標準的なUDPプロファイル

注:WAN最適化に関連するものなど、tcpまたはudpプロファイルに基づいた上記以外のプロファイルもある場合があります。

BIG-IPによって接続が閉じられるまでのアイドル時間を制御するには、これらのプロファイルの以下の属性を使用します。負荷の大きい攻撃に対しては、値を徐々に小さくしてください。

fastL4プロファイルについては、reset-on-timeoutidle-timeoutの値をオーバーライドします。デフォルトのタイムアウト値は300秒ですが、攻撃を受けているときは大幅に短くする必要があります。

 % tmsh create ltm profile fastl4 fastl4_ddos { reset-on-timeout disabled idle- timeout 15 }

攻撃を受けている各fastL4仮想サーバーについては、fastL4プロファイルを新しいものに置き換えます。

tcpプロファイルについても、同じ理由で同じ2つの値をオーバーライドします。それと同時に、hardware-syn-cookiezero-window-timeoutの値も調整できます。セクション2.2.2を参照してください。

udpプロファイルについては、idle-timeoutの値だけを小さくします(デフォルトは60秒)。

2.2.9 レートシェーピングの制御

迅速に導入できるもう1つの防御策は、レートシェーピングです。レートシェーピングを使用すると、BIG-IPでのイングレス トラフィックのレートを制限できるため、ボリューム型攻撃に対抗する最も簡単な方法かもしれません。しかし、レートシェーピングは強力ですが、DDoSに対する防御策としては理想的とは言えません。レートシェーピングでは正当な要求と不正な要求が区別されないため、正当なトラフィックも排除され、望ましくない結果を招きかねません。

レートシェーピング プロファイルは手動で構成してから、仮想サーバーに割り当てます。

この例では、少なくとも1 mbsのトラフィックはターゲットに到達するが、10 mbsを超えるトラフィックは許可されないことが、「protect_apache」というrate-shapingクラスによって保証されています。

net rate-shaping class protect_apache { rate 1mbps ceiling 10mbps }


次に、ターゲットである各仮想サーバーにこのrate-shapingクラスを適用します。

2.2.10 最大ICMP拒否率の設定

システム変数TM.MaxRejectRateを使用すると、仮想サーバー接続数と着信接続数が一致しない場合にBIG-IPシステムが送信するTCP RSTまたはICMP到達不能パケットの数を制限することで、サービス拒否攻撃の影響を軽減することができます。システム変数TM.MaxRejectRateのデフォルト値は、1秒あたりのTCP RSTまたはICMP到達不能パケット数が250個です。

この値を100に下げることで、ネットワークのパフォーマンスに影響を与えることなく、アウトバウンドの輻輳を軽減できます。

% tmsh modify sys db tm.maxrejectrate value 100

2.3 第2層:アプリケーション防御

第2層には、ログインウォール、Webアプリケーション ファイアウォール ポリシー、BIG-IP LTM iRuleなど、アプリケーションを識別するCPU負荷の高い防御メカニズムを展開します。第2層では、通常、SSL終端も処理します。第1層でSSLを終端している場合もありますが、SSLのキーとポリシーの機密情報をセキュリティ境界で維持することになるため、この方法は一般的ではありません。

2.3.1 GETフラッドについて

再帰的なGETとPOSTは、今日最も有害な攻撃に挙げられています。これらの攻撃は、正当なトラフィックと区別することが極めて難しいためです。

GETフラッドはデータベースやサーバーを枯渇させます。また、「オーバーフローによるデータ漏洩」も引き起こします。F5の記録では、1人の攻撃者が100 MbsのGETクエリをターゲットに送信して20 Gbsのデータを引き出した事例があります。

シグネチャベースのDDoS対策ソリューション(F5製または他のベンダ製)を導入している場合は、それを活用してアプリケーションを保護してください。F5では、BIG-IP LTMとF5® BIG-IP® Application Security Manager™(ASM)を使用した、アプリケーション層に対する深刻な攻撃を緩和するためのさまざまな方法を提供しています。

GETフラッドの緩和戦略には以下があります。

  • ログインウォールによる防御
  • DDoS対策プロファイル
  • リアル ブラウザ エンフォースメント
  • CAPTCHA
  • リクエスト スロットリングiRule
  • カスタムiRule

2.3.2 ログインウォールを構成して脅威の対象領域を縮小

アプリケーションレベルの攻撃を回避する最も強力な手法は、認証されたユーザーのみがアプリケーションのデータベース部分にアクセスできるようにすることです。ログインウォールの構築には、細心の注意を要するため、DDoS攻撃下の大変なときではなく、平時に行うことをお勧めします。すべてのアプリケーションが登録ユーザーを信頼できるわけではなく、匿名トラフィックの処理が必要となるわけではありませんが、登録ユーザーを信頼できる場合は、ログインウォールが防御策となります。

2.3.2.1 ASMでログインウォールを指定

BIG-IP ASMでは、ログイン ページとログイン エンフォースメントを使用して、BIG-IP ASMポリシー内でこれを行うことができます。この機能により、ユーザーはログイン ページのいずれかで正常に認証されない限り、一連のURLを操作できなくなります。

まず、[Security]→[Application Security]→[Sessions and Logins]画面からログイン ページを定義します。

次に、[Login Enforcement]タブを使用して、保護する必要があるページを指定します。理想的には、.MP4や.PDFのようなサイズの大きなオブジェクトや、非対称攻撃で使用される可能性のあるデータベース クエリなどを含めます。

ログイン エンフォースメント機能の詳細については、BIG-IP ASM構成ガイドのセクション「ログイン ページの作成」を参照してください。

注:どのリソースを保護すべきかわからない場合は、[Reconnoiter Your Own Applications]を使用するとアプリケーションを調べることができます。セクション3.2.2を参照してください。

2.3.2.2 ログインウォールのスクリプト化

BIG-IP LTM iRuleだけでログインウォールを構築するには、ログイン ページで特定のCookieを設定し、それ以外のすべてのページでそのCookieを確認します。このiRuleを作成し、アタッチしてテストします。その後、デタッチして、必要に応じて有効にできるようライブラリに保存します。

DevCentralのログインウォールiRuleにはこちらからアクセスできます。

2.3.2.3 DoS対策プロファイルを使用したアプリケーションの保護

F5のWebアプリケーション ファイアウォールであるBIG-IP ASMには、アプリケーションに固有の「DoSプロファイル」が含まれています。これらの強力なプロファイルは、サーバーのレイテンシまたはhttp要求レートを監視することでDoS状態を検出します。BIG-IP ASMは、攻撃が緩和されると、オプションのiRuleイベントをトリガすることができます。

緩和オプションは以下のとおりです。

以下のコマンドを使用して、DoSプロファイルを作成し、アプリケーションにアタッチします。

% tmsh create security dos profile my_dos_prof { application add { Lrule1 { 
latency-based { url-rate-limiting enabled mode blocking } } } }

% tmsh modify ltm virtual my_vip1 profiles add { my_dos_prof }

このDoSプロファイルには、[Security]タブからアクセスできます。次に、[DoS Protection]を選択します。その画面から[Application Security]を選択し、L7DOS対策パラメータを設定します。

図4:ASMモジュールの包括的なL7DOS対策のための構成

2.3.2.4 リアル ブラウザ エンフォースメント

F5デバイスでは、認証とtpsベースの検出(セクション2.3.2.3)以外の方法でも、ボットの可能性が高いものから本物のWebブラウザを分離することができます。

BIG-IP ASMを使用した最も簡単な方法は、DoS対策プロファイルを作成し、[Source IP-Based Client Side Integrity Defense]オプションをオンにすることです。これにより、JavaScriptのリダイレクトがクライアント ストリームに埋め込まれ、送信元IPアドレスが最初に判明したときに各接続が検証されます。

図5:本物のブラウザであることを確認するためにJavaScriptリダイレクトを埋め込む

コマンドラインでは次のように入力します。

% modify security dos profile my_ddos1 application modify { Lrule1 { tps-based { ip-client-side-defense enabled } } } 

2.3.2.5 スクリプトによるGET要求フラッドのスロットリング

F5 DevCentralコミュニティでは、GET要求を自動的にスロットリングする強力なiRuleがいくつか開発されており、最新の攻撃手法に対応するため、これらのiRuleはお客様によってさらに改良されています。

以下は、このドキュメントで十分に説明できるほどシンプルなiRuleの1つです。ライブ版はDevCentralのHTTP-Request-Throttle
のページにあります。

when RULE_INIT {

 # Life timer of the subtable object. Defines how long this object exist in the 
subtable

 set static::maxRate 10

 # This defines how long is the sliding window to count the requests.

 # This example allows 10 requests in 3 seconds

 set static::windowSecs 3

 set static::timeout 30

}

when HTTP_REQUEST {

 if { [HTTP::method] eq "GET" } {

 set getCount [table key -count -subtable [IP::client_addr]]

 if { $getCount < $static::maxRate } {

 incr getCount 1

 table set -subtable [IP::client_addr] $getCount "ignore" 
$static::timeout $static::windowSecs

 } else {

 HTTP::respond 501 content "Request blockedExceeded requests/sec 
limit."

 return

 }

 }

}

もう1つのiRuleは、上記のiRuleから派生したもので、禁止されているIPアドレスをそのiRule自体で管理することもできる上級版です。

  • 不審な接続を排除します。
  • ブラウザが使用されていることを確認するために、クライアントにJavaScriptリダイレクトを返します。
  • クライアント アドレスまたはURIによってレートを制限します。
  • URI-Request Limiter iRule:特定のURIへ、またはIPからの過剰なHTTP要求を排除します

2.3.2.6 CAPTCHAを使用したボットの排除

GETフラッドを緩和するもう1つの方法は、CAPTCHAメカニズムを使用して「人間性」を検証することです。CAPTCHAメカニズムでは、歪んだ単語の画像をユーザーに見せて、ユーザーがその単語をWebフォームに入力することで人間性を証明します。ハッカーや研究者が10年以上前からこのメカニズムを「突破」しようとしているにもかかわらず、CAPTCHAは今なお、人間とコンピュータを見分ける最良の方法の1つです。パターン認識アルゴリズムの進歩により、攻撃者はCAPTCHAシステムの自動化に近づきつつありますが、F5の経験から、CAPTCHAを「突破」するための計算に要する労力は、少ない労力で大きな利益を得るという最先端のDDoS攻撃者の利点を大幅に減らすものであるため、これらの攻撃は今のところ理論上のものでしかありません。つまり、CAPTCHAがボットネットを撃退するための有効な手段であることに変わりはありません。

Googleは、この機能を実行しながら古い文字の解読にも利用するreCAPTCHAサービスを提供しています。接続の相手側に人間がいることの検証に使用されるGoogle ReCAPTCHA iRuleは、DevCentralにあります。このiRule(約150行)をダウンロードして、基本的な情報(Google reCAPTCHAキーやDNSサーバーなど)を提供するように編集し、BIG-IPで使用できるようにします。これを仮想サーバーにアタッチしてテストした後、展開可能な状態にしておきます。

2.3.3 カスタムの緩和策のスクリプト化

他の手法をすべて使用できない場合は、アプリケーション層の攻撃からアプリケーションを守るためにカスタムのiRuleを作成する必要が生じることがあります。カスタムのiRuleは、通常、フィルタリングと無差別ブロッキングの2つのカテゴリのいずれかに分類されます。

この緩和策は、このドキュメントで取り上げるすべての手法の中で「手作業」による部分がおそらく最も多いものの、俊敏に対応するF5のお客様の間で最もよく使用され、かつ最も強力な手法でもあります。F5® iRules®のプログラミング性は極めて高く、スクリプトを適切に作成できれば、ほぼあらゆる種類の攻撃をブロックすることができます。セキュリティ関連のiRuleは今日、多くの組織を保護し、アプリケーション層のDDoS攻撃に対するF5の真の差別化要因の1つとなっています。

攻撃の痕跡としてアウトバウンドのインターネット アクセスが残っている場合は、その攻撃に該当するキーワードをdevcentral.f5.comで検索してみてください。お客様に必要なiRuleが既に作成されているかもしれません。

独自のiRuleを作成するには、まず攻撃トラフィックを分析して、不正なトラフィックと正当なトラフィックを区別するために使用できる着信攻撃トラフィックの特徴を見つけます。次に、そのトラフィックを検出して排除するiRuleを作成します。iRuleの作成に精通していない場合は、このドキュメント(およびDevCentral)の随所に掲載されているiRuleを例として使用することができます。そして、新しいiRuleをアプリケーションの仮想サーバーにアタッチします。

シンプルなセキュリティiRuleの例として、次に示す初期のDirt Jumper iRuleがあります。このiRuleでは、マルウェアのreferrerフィールドに//が含まれていないことが鍵となります。

when HTTP_REQUEST {

 if { [HTTP::header exists "Referer"] } {

 if { not ([HTTP::header "Referer"] contains "\x2F\x2F") } {

 drop

 }

 }

}

正当なトラフィックと不正なトラフィックを簡単に区別できない場合は、要求されたオブジェクトに基づいてトラフィックを排除するiRuleを作成します。例えば、攻撃者がサイズの大きな特定のPDFファイルやMP4ファイルを要求してきた場合は、iRuleを使用して、そのオブジェクトへのすべての要求を排除することができます。

 ltm data-group internal block_uris { records { /faqs/faq.mp4 { } /locator/locations.pdf { } /cgi-bin { } } type string } 

BIG-IPの外部でホストされている外部データ グループを使用することもできます。

次に、シンプルなスクラバiRuleを使用して、データ クラスに一致するURIを求めている要求を排除します。

ltm data-group internal block_uris {

 records {

 /faqs/faq.mp4 { }

 /locator/locations.pdf { }

 /cgi-bin { }

 }

 type string

}

これが最善の解決策でないことは明らかです。なぜなら、不正なトラフィックとともに正当なトラフィックも拒否されてしまうためです。この手法でサーバーを存続させることはできますが、上記のようなルールを作成する時間と能力があれば、正当なトラフィックと不正なトラフィックを区別する何らかの特徴がおそらく見つかるでしょう。

2.3.4 第2層でのSSL DDoSの緩和

いずれの層でもSSLを終端させることは可能であり、それが望ましい場合もありますが、F5では、物理的(非仮想的)なアプライアンスを使用してSSLを第2層で終端させることを推奨しています。実際、F5の物理デバイスでSSLアクセラレーション ハードウェアを使用することで、以下を含むさまざまなSSL DDoS攻撃を緩和できます。

  • SSLプロトコル攻撃
  • SSLリプレイ攻撃
  • SSL接続フラッド

F5は、ハードウェアを使用するかどうかにかかわらず、アダプティブ リーピング(セクション2.2.7を参照)と大容量の接続テーブル(セクション2.2.6を参照)を使用してSSL接続フラッドを緩和することもできます。

SSL再ネゴシエーション攻撃は、2つの方法のいずれかで緩和することができます。大抵は、仮想サーバーのSSL clientsslプロファイルでSSL再ネゴシエーション機能を一時的に無効にするだけで済みます。ただし、持続時間が非常に長い接続(現金自動預払機やデータベース接続など)では、再ネゴシエーション機能がやはり必要です。

2.3.5 接続の多重化とポートの枯渇について

一般的に、接続の多重化やSNATのような機能は第1層で実行しないでください。これらの機能とそれに関連する追加機能(X-Forwarded-Forヘッダーの埋め込みなど)は、第2層で処理すべきです。

2.3.5.1 接続の多重化

レイヤ7のDDoSは、接続テーブルなどのバックエンド リソースを枯渇させる可能性があります。この影響に対抗する1つの方法は、ロード バランサを介して接続を多重化することです。BIG-IP LTMでOneConnectと呼ばれるこの機能により、1秒あたりの全体的な要求数を維持(または改善)しながら、使用されるTCP接続の数を桁違いに減らすことができます。

OneConnect機能は、DDoS防御策として使用する前に、各アプリケーションでテストしておく必要があります。アプリケーションによっては、依存する接続数がユーザーごとに異なる場合があります。

2.3.5.2 ポートの枯渇

SNATは、宛先IPごとに約64,000の同時接続をサポートしています。大量の要求を受け取ると、64,000という接続数の上限を超えて、TCPポートが枯渇してしまう可能性があります。SNATプールを使用することで、この制限を回避することが可能です。SNATプール内で適切なIPアドレスを設定して、ポートの枯渇を緩和します。

例えば、仮想サーバーvip1が単純なオートマップによる送信元アドレス変換を使用している場合、次のコマンドを使用して、IPアドレスのプールを使用するように変更できます。この例では、わずか3つのアドレスを使用して、使用可能なポート数を64,000個から192,000個に増やしています。

% tmsh create ltm snatpool ddos_snatpool members add { 10.1.20.161 10.1.20.162 10.1.20.163 } % tmsh modify ltm virtual vip1 source-address-translation { pool ddos_snatpool }

SNATプールに追加された各アドレスに別々のタイムアウト値を割り当てることをお勧めします(デフォルト値は無期限)。アイドル タイムアウトを設定すると、BIG-IPはアイドル接続を閉じて、アップストリームのステートフル ファイアウォールを保護することができます。

% tmsh modify ltm snat-translation 10.128.20.161 { ip-idle-timeout 60 }

3 その他のDDoS推奨プラクティス

3.1 DNS DDoSの緩和

DNSは、HTTPに次いで2番目に標的とされているサービスです。DNSが中断されると、単一のアプリケーションだけでなくすべての外部データ センタ サービスが影響を受けます。この単一障害点に加え、DNSインフラストラクチャは従来からプロビジョニングが不十分なことが、DNSが攻撃を受けやすい原因となっています。攻撃者がDNSを特に標的としていない場合でも、DNSが意図せず標的となることも多くあります。攻撃クライアントがフラッド攻撃を開始する前に標的ホストのIPをすべて照会している場合、それがDNSに対する間接的な攻撃となります。

DNS攻撃には、UDPベースのDNSプロトコルが比較的単純であることに由来する次の2つの特徴があります。

  • DNS攻撃は簡単に生成できる。
  • DNS攻撃は防御するのが難しい。
図6:DNS DDoSの緩和

DNS DDoS攻撃を緩和するためのオンプレミスの戦略は4つあります。

  • プロトコル検証を使用する。
  • DNSフラッドを検出して防止する。
  • NXDOMAINクエリ フラッドに対してDNSサービスをオーバープロビジョニングする。
  • 最後の手段としてブラックリストを使用する。

3.1.1 DNSサービスの配置を考える

図1で示したとおり、DNSサービスは、独自のデバイス セットとしてセキュリティ境界の背後に配置されています。DNSの多くは、セキュリティ層の間にある、いわゆるDMZから提供されています。その目的は、提供するアプリケーションからDNSを独立させておくことにあります。例えば、データ センタのその部分が停止した場合、DNSは要求をセカンダリ データ センタ(またはクラウド)にリダイレクトすることができます。F5では、柔軟性と可用性を最大限に高めるために、DNSをセキュリティ層やアプリケーション層から切り離しておくこの戦略を推奨しています。

複数のデータ センタを持つ大規模企業では、さらに一歩踏み込んで、F5のGTM DNS ExpressとBIG-IP AFMファイアウォール モジュールを組み合わせて、メインのセキュリティ境界の外部にDNSを配置する場合があります。このアプローチの主な利点は、DDoSによって第1層のファイアウォールがオフラインになっても、DNSサービスを利用可能な状態に維持できることです。

図7:代替の外部DNSアーキテクチャ

3.1.2 プロトコル検証を使用したDNSサービスの保護

DNSがDMZの内側と外側のどちらにあっても、GTMまたはBIG-IP AFMを使用して、DNSサーバーに到達する前にDNS要求を検証できます。

GTMがグローバル サーバーのロード バランシングを実行している場合は、既に多くのDNS DDoS攻撃をブロックしている可能性が十分にあります。DNSクエリ/応答のパフォーマンスは、GTM GUIのメイン ダッシュボードから確認できます。GTMはDNSのフルプロキシであるため、すべての要求を自動的に検証し、無効なものは排除します。

それにもかかわらず、有効に見える要求でサーバーが制圧されてしまう場合があります。F5のBIG-IP AFMファイアウォール モジュールを使用している場合は、プロトコル セキュリティ プロファイルを使用して、特定のタイプのDNS要求のみをさらにフィルタリングすることができます。

[Security]タブで[Protocol Security]を選択し、[Security Profiles]を選択します。[DNS]を選択し、[Create]ボタンを押します。この画面では、さまざまなタイプの要求をフィルタリングまたはブロックするためのプロトコル セキュリティ プロファイルを作成できます。

図8:DNSプロトコルの検証

3.1.3 DNSフラッドの検出

F5のBIG-IP AFMファイアウォール モジュールは、強力なDNS DDoS対策機能を備えており、レコード タイプ別にDNSフラッドを検出することができます。[Security]タブで[DoS Protection]を選択し、[DoS Profiles]を選択して、最後に[Create]を選択します。作成画面で、DNSのチェックボックスをクリックし、しきい値パラメータを設定して承諾します。

図9:DNSフラッドの検出

[Protocol Errors]チェックボックスを選択すると、悪意のあるDNSクエリや不正なDNSクエリが検出されるようになります。また、DNSクエリのトラフィックがどの程度増加しても問題ないかがパーセンテージで表示され、この値を超えると、不正なDNSクエリや悪意のあるDNSクエリの追跡が開始されます。

注:現時点で、このファイアウォール機能はフラッドを検出しますが、それを緩和するパケットを排除することはありません。

3.1.4 クエリ フラッドに対するDNSサービスのオーバープロビジョニング

DNSサービスは、従来からプロビジョニングが不十分であり、その理由の一端として、多くの組織におけるDNSのオーナーシップが、特定のチームにとって望ましい展開になっていないことが挙げられます。実際の理由が何であれ、かなりの割合のDNS導入環境が、小規模から中規模のDDoS攻撃にさえ耐えられないほどプロビジョニングが不十分です。

DNSキャッシュが一般的となったのは、DNSキャッシュのパフォーマンスを飛躍的に向上させ、標準的なDNSクエリ攻撃に対して一定の回復力をもたらすためでしたが、攻撃者は「no such domain」(NXDOMAIN)と呼ばれる攻撃に切り替え、キャッシュのパフォーマンス上の利点はすぐになくなりました。

これを改善するためにF5が推奨する方法は、特殊で高性能なDNSプロキシ モジュールであるF5® DNS Express®をDNSサービスとともにフロントエンドで使用することです。DNS Expressは、既存のDNSサーバーの前面で高機能リゾルバとして機能して、ゾーン情報をサーバーから読み込み、各要求を解決するか、NXDOMAINを返します。DNS Expressは、キャッシュではないため、NXDOMAINクエリ フラッドによって空にすることはできません。

GTMまたはDNSサービスで、DNS ExpressはCPUあたり1秒間に250,000件の要求を処理できるため、最も悪質なDNS攻撃を除くすべての攻撃に対して耐性があります。DNSサーバーは、ゾーン データを管理するためにそのまま使用されます。

3.1.5 最後の手段としてブラックリストを使用

DNSトラフィックは古くからあるUDPであり、生成となりすましが容易です。送信元IPのブラックリストなど、レイヤ3とレイヤ4の従来の防御策は、DNSフラッドに対しては一般的に効果がありません。それどころか、送信元IPに基づいてDNS要求をブロックすることは非常に危険です。例えば、大手ISPからの要求を意図せずブロックした結果、多くの正当なユーザーへのサービスを知らずに拒否してしまう可能性があります。

「BIG-IPシステム:DOS対策とプロトコル ファイアウォールの実装」(第3章:DNS DDoS攻撃の検出と防止)を参照してください。

3.1.6 DDoS攻撃への参加に注意

3.1.6.1 未使用のクエリ タイプ

攻撃者は、未使用のサービスに対するクエリを送信することで、DNSサービスが第三者のターゲットを攻撃するように仕向けることができます。BIG-IP AFM画面(上の図9を参照)を使用して、使用していないクエリ タイプを無効にしてください。そうすることで、これらのタイプのクエリが送られてきても排除されます。クエリに応答しないことで、DDoS攻撃に参加してしまう事態を防ぐことができます。

このことは、MX(メール サービス)やゾーン転送に特に当てはまります。既知の特定の時間に転送している組織は、それ以外のすべての時間でIXFR、AXFR、ZXFRタイプを無効にしておいてください。

3.1.6.2 DNSSEC

DNSSECは、グローバル ドメイン名サービスの重要な進化版と言えます。最終的にはこのサービスにより、フィッシングなどの不正行為を削減できます。ただし、DNS DDoSの場合、状況はより複雑です。DNSSECの応答は、従来のDNS UDP応答の10~20倍のサイズになることがあるため、DNSSECサーバーが無効な応答を他のコンピュータに意図せず連続して送りつけて、それらのコンピュータを実際には攻撃することになってしまいます。

GTMにより、F5は市場で最高レベルの性能を誇るDNSSECソリューションを提供しています。GTMの能力は、攻撃ベクトルとして利用された場合、強力な武器になり得ます。そのため、GTMではGTM自体が攻撃に参加することにならないよう応答数を制限できるようになっています。

 % tmsh modify sys db dnssec.maxnsec3persec value 10 

dnssec.maxnsec3persec変数は、GTMが1秒間に送信するNSEC3認可のNXDOMAINメッセージ数の上限を制御します。デフォルトの0は無制限を意味します。1秒間に10~100件など、より厳格な値を設定すると、攻撃時にGTM自体が利用されるのを防ぐことができます。

% tmsh modify sys db dnssec. signaturecachensec3 value true 

dnssec.signaturecachensec3変数をfalseに設定すると、NXDOMAINメッセージがGTMキャッシュを使用することがなくなり、GTMのキャッシュが攻撃者によって「no such domain」応答で埋め尽くされるのを防ぐことができます。

3.2 その他のDDoSベスト プラクティスのための準備

DDoS攻撃への備えに時間をかけることは、防御効果を高めることにつながります。ここでは、DDoS攻撃に備えて組織の体制を整える方法をいくつか紹介します。

3.2.1 ロギングの構成と検証

攻撃を受けているときは、診断を送信したり、異常やトラフィックの急増をログに記録したりする可能性が高くなります。大規模なDDoS攻撃に対処するには、高性能な機能に加え、計測も重要です。つまり、BIG-IPの高速ロギング機能を使用して、Splunkなどのサードパーティ製ロギング デバイスやArcSightなどのSIEMに情報を送信する必要があります。

注:DDoS攻撃を緩和するには、第1層でBIG-IPの高速ロギング機能を使用する必要があります。集中的なDDoS攻撃はローカルのディスクベース ロギングを制圧する可能性があるため、ローカル ロギングは使用しないでください。

3.2.1.1 高速ロギングの設定

  1. 外部ログ サーバー(この場合はsyslog)に割り当てるプールを作成します。ArcSightやTrustWaveなど、お使いの環境でサポートされるSIEMソリューションに合わせて、必要に応じて変更を加えます。次に、文字列を適切にフォーマットして転送するためのlog configオブジェクトを作成します。

% tmsh create ltm pool hsl_pool members add { 10.128.10.250:514 }

% tmsh create sys log-config destination remote-high-speed-log log_dest_HSL { pool-name hsl_pool }

% tmsh create sys log-config destination remote-syslog log_dest_format { format rfc5424 remote-high-speed-log log_dest_HSL }

% tmsh create sys log-config publisher log_pub_ddos { destinations { log_dest_HSL log_dest_format } }

2.    GUIを使用してログ プロファイル オブジェクトを作成します。

[Security]>[Event Logs]>[Logging Profiles]ページにアクセスします。以下を使用してログ プロファイルを作成します。

 

プロファイル名

 

ddos_log_profile

ネットワーク ファイアウォール

有効

ネットワーク ファイアウォール:パブリッシャ

log_pub_ddos

ルール一致のロギング

承諾、排除、拒否

IPエラーのロギング

有効

TCPエラーのロギング

有効

TCPイベントのロギング

有効

ストレージ形式

field-list。すべての使用可能なアイテムを選択し、選択済みアイテムのリストに移動します

3.    そのログ プロファイル オブジェクトを、アプリケーションを保護する仮想サーバーに関連付けます。

 % tmsh modify /ltm virtual vip1 { security-log-profiles add { ddos_ log_profile } } 

3.2.2 自社のアプリケーションを調べる

最先端のDDoSを利用する攻撃者は、DDoS攻撃を開始する数日から数週間前にアプリケーションを偵察します。まず、Webサイトを徘徊し、有効なURIの読み込み時間とデータ サイズを手に入れます。結果として得られたデータセットをソートすることで、CPUとデータベースに対する負荷が最も高いクエリや最大サイズのオブジェクト(PDFやMP4など)をすばやく探し出します。DDoS攻撃の間は、これらのオブジェクトに対して繰り返しクエリを実行して、インフラストラクチャを枯渇させます。

セクション3.8の説明に従って、攻撃が起きたときにその攻撃を緩和することもできますが、自社のアプリケーションを調べることで事前に備えることができます。これにより、どのURIとサブシステムが標的になる可能性が高いかを詳しく把握できるため、後でより多くの情報に基づいてトリアージの決定を下せるようになります。

理想は、LoadRunnerのようなツールや、必要なメトリクスを提供してくれるパフォーマンス モニタリング ツールを導入することです。これらの機能がない場合にURL、読み込み時間、データ サイズの基本的なテーブルを取得する最も簡単な方法は、ほとんどのLinuxディストリビューションで利用可能なwgetユーティリティを実行することです。このユーティリティは次の構文で実行します。

% wget -r --spider http://10.128.10.150 2>&1 | grep saved 2013-08-25 15:44:29 (2.48 MB/s) - `10.128.1.150/index.html' saved [22304] 2013-08-25 15:44:29 (5.53 MB/s) - `10.128.1.150/index.php' saved [22304] 2013-08-25 15:44:29 (7.06 MB/s) - `10.128.1.150/sell.php' saved [41695]

大かっこ内の末尾の数字は要求のデータ サイズです。読み込み時間を取得するには、時間の値(2番目のフィールド)の差を求めます。

3.2.3 iHealthによる既存のBIG-IP デバイスの稼働状況の検証

F5は、F5® iHealth®と呼ばれるクラウドベースの診断およびヒューリスティック サービスを提供しています。iHealthは、F5デバイスの構成を検査し、BIG-IPを高速、安全、かつ使用可能な状態に保つための推奨事項を提案します。これらの設定の大部分は、最初の2つの高速処理と安全性に関連するものですが、一部は可用性、ひいてはDDoSに対する回復力に関連しています。

この例では、iHealthはSNATプールがタイムアウト値なしで設定されていることを示しています。これを参考にして、リソースの有効活用を重視するのであれば、強化された仮想サーバーで使用するSNATプールにアイドル タイムアウトを設定することで、接続数を抑え、アップストリームのファイアウォールが過負荷になるのを防ぐべきです。

iHealthの詳細については、iHealthのWebサイトを参照してください。

3.2.4 DDoSプレイブックの準備

DDoSプレイブックまたはランブックは、IT担当者がDDoS攻撃に対処するための手順書です。優れたプレイブックがあれば、新しく管理者になったとき(そして以前から管理者であった場合も)DDoS攻撃に対処するのに役立ちます。プレイブックは、ホワイトリストと連絡先情報の更新を反映させて、最新の状態に保つ必要があります。

DDoS訓練(またはテスト)を定期的に実施して最新の状況を把握し、プレイブックの妥当性を確認している組織はごく一部です。主要なメンバーが不在のときに、スタッフがプレイブックの手順を練習する機会を設けてください。攻撃が都合の良いタイミングで発生するとは限りませんから。

プレイブックをお持ちでない場合は、F5がご用意しています。

3.2.5 2層構造での防御策の見直し

これまでのセクションで説明した防御策の中で、F5以外のネットワーク ファイアウォールを使用している管理者にとっては特に見直す価値があるものがあります。

以下の点を覚えておいてください。

  • SNATプールは、第1層でのポートの枯渇を緩和する。
  • トラフィック シェーピングは第1層で行う。
  • TCP接続を積極的にリーピングする。
  • DNSのブラックリストは最後の手段である。
  • ログインウォールとCAPTCHAは第2層に実装する。
  • 第2層でCPUに負荷のかかる省略可能な機能は無効にする。
  • 高速リモート ロギングを常に使用する。

このベスト プラクティス ガイドで提案した推奨事項を実践することで、アプリケーションのDDoS攻撃への備えの多くを整えることができます。

4 まとめ

サービス拒否攻撃による今日の脅威の状況を把握しておくことは重要です。既に導入している防御装置をどのように活用すべきかを理解していることは、さらに重要です。

どのようなリソースとどのようなニーズがあるかに応じて、DDoSに対する回復力の強化を目的としてネットワークの設計の見直しを既に進めている場合もあるでしょう。見直しを検討しているのであれば、セクション2.1でお勧めした多層アーキテクチャに注目してください。DDoS目的でレイヤ4とレイヤ7に個別に取り組むことは、ネットワーク セキュリティがF5製品だけで構築されていない場合にも合理的なアプローチです。

推奨プラクティスに従うことで、ネットワーク、アプリケーション、そしてスタッフが攻撃に耐えられるようになるための準備を整えることができます。

DDoS緩和のためにF5が提案する推奨プラクティスの最後のステップは、DDoSプレイブックを準備することです。プレイブックは、攻撃を緩和するためのリアルタイムの手順を示したガイドであり、ワークシートとログを含んでいます。F5では、プレイブック作成の土台となるテンプレートをご用意しています。

専門家は、DDoSが今後長期間にわたり、インターネット上の問題であり続けると予測しています。DDoSに備えることが単なる選択肢ではなく、必要条件となる日も遠くありません。

付録

アプリケーション攻撃の分類と対策

次のセクションでは、特定のレイヤ7攻撃ベクトルに対して推奨される緩和策を示します。これらの多くは、特に悪質な「slow-and-low」タイプの攻撃です。

目次

  • Slowloris
  • Keep Dead
  • Low Orbit Ion Cannon(LOIC)
  • Slow-POST
  • ゼロ ウィンドウ攻撃
  • Slow-Read攻撃
  • RUDY
  • Apache Killer
  • SSL再ネゴシエーション
  • Dirt Jumper iRule

Slowloris

Slowlorisは一般的なHTTP攻撃ベクトルです。攻撃者は、HTTPセッションを維持するために、(非常に低速で)小容量のHTTPヘッダーを送信します(例えば、「X-a: b」を299秒ごとに送信するなど)。仮想サーバーが現在レイヤ4でロードバランシングを行っている場合は、レイヤ7に変更することを検討してください。これにより、HTTPプロファイルを追加した場合に本質的に対策が強化されます。

% tmsh list ltm virtual vip1
ltm virtual vip1 { 
destination 10.128.10.141:http 
profiles { 
fastL4 { } 
}
}

% tmsh modify ltm virtual vip1 profiles replace-all-with { tcp http }

これにより、BIG-IPによってSlowloris接続が吸収されるようになります。接続が増えて他のデバイス(ファイアウォールなど)に影響を及ぼすことが懸念される場合は、次のSlowloris iRuleを使用して、10秒経過しても完了していない接続をすべて排除します(この秒数は自由に調整できます)。

# Slowloris iRule

when CLIENT_ACCEPTED {

 set hsl [HSL::open -proto UDP -pool hsl_pool]

 set rtimer 0

 after 10000 {

 if { not $rtimer } {

 drop

 HSL::send $hsl "Dropped [IP::client_addr] – connection too 
slow"

 }

 }

}

when HTTP_REQUEST {

 set rtimer 1

}

Keep Dead

この攻撃は、CPUとRAMを消費することを目的としています。キープアライブとHTTP HEADメソッドを使用することで、サーバーに対して開かれた接続の数に基づくファイアウォール防御を発動させずに、要求のフラッドを生成することができます。

BIG-IP ASMモジュールは、(ブラウザでは通常使用されない)HEAD要求を拒否できます。該当するアプリケーション セキュリティ ポリシーで「Allowed Methods」を設定することで、HEAD要求を拒否することが可能です。

詳細については、解決策12312を参照してください。

Low Orbit Ion Cannon(LOIC)

Low Orbit Ion Cannonは、ハクティビスト グループの「アノニマス」と密接に関連した自発的なボットネット ツールです。このツールは、SYNフラッドとUDPフラッドを使用しますが、レイヤ7のHTTPフラッドで最もよく知られています。SYNフラッドとUDPフラッドを緩和したとすれば(セクション2.2.2と2.2.3を参照)、最後のステップは、LOIC GETフラッドを緩和することです。

多くの場合、これを緩和する最速の方法は、各LOIC HTTP要求に含まれる攻撃の「抗議メッセージ」をフィルタリングすることです。Wiresharkやtcpdumpなどのツールを使用してメッセージを探し出し、そのメッセージをデータグループに追加します。スペースは「%20」で表します。時間が経つとメッセージが変化する可能性があるため、攻撃が続いている間は監視する必要があるでしょう。

 ltm data-group anonmsgs { records { Somos%20legi { } U%20dun%20goofed { } } type string } 

BIG-IPの外部でホストされている外部のデータ クラスを使用できます。tmshコマンド シェルの「help search data-group」を参照してください。

次に、シンプルなスクラバiRuleを使用して、そのデータ クラスにペイロードを含んでいる要求を排除します。

ltm rule loic_defense_rule {

 when CLIENT_ACCEPTED {

 set hsl [HSL::open -proto UDP -pool hsl_pool]

 }

 when HTTP_REQUEST {

 if { [class match [HTTP::uri] contains anonmsgs] } {

 drop 

 HSL::send $hsl "Dropped [IP::client_addr] – suspected Low Orbit Ion Cannon"

 } 

 }

}

Slow-POST

Slow-POST攻撃の核心は、特定の「content-length」(通常は大きな値)を持つPOST要求を送信し、アイドル時間を長く保ちながら、非常にゆっくりとメッセージ本文をサーバーに送信することにあります。サーバーはデータを受信し続ける間、接続を開いたままにします。これらの要求がサーバーに対して大量に実行されると、接続テーブルが枯渇する可能性があり、サーバーはそれ以上の要求に応答できなくなります。

BIG-IP ASMモジュールを使用している場合は、BIG-IP ASMシステム変数画面に表示される変数のうちの2つを使用してSlow-POST攻撃を緩和できます。具体的には、[Security]、[Options]、[Application Security]、[Advanced Configuration]、[System Variables]の順に移動して次の変数を変更します。

slow_transaction_timeout(デフォルトは10秒)。必要に応じてこの値を小さくします。

max_slow_transactions(デフォルトは25トランザクション)。必要に応じてこの値を5以下にします。

BIG-IP ASMを使用していない場合は、Slow-POSTの緩和策としてこのBIG-IP LTM iRuleを参照してください。このiRuleは、次のセクションで説明するSlow-Read iRuleとともに使用できます。Slow-Read iRuleはサーバーベース、Slow-POST iRuleはクライアントベースなので、2つのiRuleとして個別にアタッチしてください。

ゼロ ウィンドウ攻撃

ゼロ ウィンドウ攻撃は、検出するのが困難なレイヤ4攻撃です。その仕組みは、ターゲットとの間にTCP接続を確立してデータを要求し、TCPウィンドウ サイズをゼロに設定します。この攻撃により、サーバー、キャッシュ、またはミドルウェアで接続が停止します。

攻撃者がBIG-IPに対してTCPウィンドウ サイズをゼロに設定している場合は、セクション2.2.2で説明したzero-window- timeout tcpプロファイル値を使用して緩和することができます。

Slow-Read攻撃

Slow-Read攻撃の仕組みは、正当なHTTP要求を送信して、バッファからHTTP応答を非常にゆっくりと読み取ります。ターゲット上でできるだけ多くの接続をアクティブな状態に保つことを目的としています。

バージョン11.3.0では、BIG-IP ASMモジュールのlow-and-slow防御策が、Slow POSTなどのインバウンド要求に対して有効に機能します。Slow-Readに対しては、次のBIG-IP LTM iRule緩和策を使用してください。

when SERVER_CONNECTED {

 TCP::collect

}

when SERVER_DATA {

 set rtimer 0

# Time in milliseconds before HTTP response read is considered slow:

 after 5000 {

 if { not $rtimer} {

 set hsl [HSL::open -proto UDP -pool hsl_pool]

# Slow read detected for this server response. Increment the count by adding a 
table entry:

# Add the client source IP::port to the subtable with a timeout

 table set -subtable "MyApp" "[IP::client_addr]:[TCP::client_port]" 
"ignored" 180

# If we are over the concurrency limit then reject

 if { [table keys -subtable "MyApp" -count] > 5} {

 clientside {reject}

 table delete -subtable "MyApp" "[IP::client_addr]:[TCP::client_
port]"

 HSL::send $hsl "Dropped [IP::client_addr] – reading too slow"

 } 

 }

 }

 TCP::notify response 

 TCP::release

 TCP::collect

}

when USER_RESPONSE {

 set rtimer 1

}

when CLIENT_CLOSED {

 table delete -subtable "MyApp" "[IP::client_addr]:[TCP::client_port]" 

}

RUDY

R-U-Dead-Yet(略してRUDY)では、Slow-POSTに加え、ロングフォームのフィールドを送信する一般的なHTTP DoS攻撃が使用されます。

Apache Killer

Apache Killerは、Range攻撃とも呼ばれます。クライアント ブラウザ(携帯電話のブラウザなど)は、ドキュメントの一部だけが必要なときに、HTTPのRangeヘッダーを使用してデータの「範囲」を要求することができます。例えば、クライアントが最初の100バイトだけを必要としている場合は、次のように要求します。

 Range:bytes=0-100 

Apache Killer攻撃は、複数の重複する範囲を要求することで、ApacheなどのWebサーバーを混乱させます。

 Range:bytes=0-,5-1,5-2,5-3,… 

Apache Killerを緩和する方法は3つあります。1つは、HTTPプロファイルを変更して、単純にRangeヘッダーを削除することです。例えば、httpプロファイルの名前が「http_ddos2」である場合は、次のコマンドを実行します。

 % tmsh modify ltm profile http http_ddos2 { header-erase range } 

より高い精度でApache Killerを緩和するには、次のiRuleを使用して、要求された範囲が5つを超えた場合にのみ範囲要求を削除します。

when CLIENT_ACCEPTED {

 set hsl [HSL::open -proto UDP -pool hsl_pool]

}

when HTTP_REQUEST {

 # remove Range requests for CVE-2011-3192 if more than five ranges are 
requested

 if { [HTTP::header "Range"] matches_regex {bytes=(([0-9\- ])+,){5,}} } {

 HTTP::header remove Range

 HSL::send $hsl "Client [IP::client_addr] sent more than 5 ranges. Erasing 
range header."

 }

}

BIG-IPソリューションを使用した3つ目の緩和方法は、次のBIG-IP ASM攻撃シグネチャを使用して攻撃を検出し、対処することです。

 pcre:"/Range:[\t ]*bytes=(([0-9\- ])+,){5,}/Hi"; 

SSL再ネゴシエーション

特定のSSLクライアントから多数の再ネゴシエーションが発生している場合は、SSL再ネゴシエーション攻撃を受けている可能性があります。これを緩和する最も簡単な方法は、仮想サーバーに関連付けられたclientsslプロファイルでSSL再ネゴシエーションを無効にすることです。しかし、攻撃を緩和しながら正当なクライアント(従来の「Step-Up」とも呼ばれるServer-Gated Cryptographyブラウザなど)の再ネゴシエーションをサポートする必要がある場合は、このiRuleなどを使用できます。このルールは、再ネゴシエーションの試行が1分間に5回を超えた場合、その接続を閉じます。

when RULE_INIT { 

 set static::maxquery 5 

 set static::mseconds 60000 

} 

when CLIENT_ACCEPTED { 

 set ssl_hs_reqs 0 

 set hsl [HSL::open –proto UDP –pool hsl_pool]

} 

when CLIENTSSL_HANDSHAKE { 

 incr ssl_hs_reqs 

 after $static::mseconds { if {$ssl_hs_reqs > 0} {incr ssl_hs_reqs -1} } 

 if { $ssl_hs_reqs > $static::maxquery } { 

 after 5000 

 drop

 HSL::send $hsl "Dropped [IP::client_addr] – too many SSL renegotiations"

 } 

}

Dirt Jumper iRule

Dirt Jumperツールの一部のバージョンでは、referrerフィールドに//が含まれていません。Dirt Jumperの接続を検出して排除するシンプルなiRuleを以下に示します。

when CLIENT_ACCEPTED {

 set hsl [HSL::open –proto UDP –pool hsl_pool]

} 

when HTTP_REQUEST {

 if { [HTTP::header exists "Referer"] } {

 if { not ([HTTP::header "Referer"] contains "\x2F\x2F") } {

 HSL::send $hsl "DDoS Dirt-Jumper HTTP Header Structure missing x2f x2f 
Referer protocol identifier from [IP::client_addr]"

 drop

 }

 }

}