現在のサイバーセキュリティ環境では、オリジンサーバーを悪意のある攻撃から保護することが不可欠です。ほとんどの場合、異常なユーザーエージェント(UA)ヘッダーは、Webクローリング、脆弱性スキャン、分散型サービス拒否(DDoS)攻撃など、さまざまな攻撃を実行するために使用されます。理解を容易にするために、このタイプの攻撃は UA 攻撃と呼ばれます。このトピックでは、Web Application Firewall(WAF)3.0 のカスタムルールモジュールを使用して UA 攻撃を防御する方法について説明します。
ネットワークアーキテクチャ
次のネットワークアーキテクチャでは、WAF は異常トラフィックをブロックして、通常のトラフィックのみが Elastic Compute Service(ECS)インスタンスに到達するようにします。
クイックデプロイメント
WAF が悪意のある UA 攻撃をどのように防御するかを体験できるように、Alibaba Cloud はネットワークアーキテクチャのクイックデプロイメントを提供しています。
クイックアップグレード中、システムは自動的に次のリソースを作成します。仮想プライベートクラウド(VPC)、vSwitch、ポート 22、80、および 443 でのアクセスを許可するセキュリティグループ、パブリックアクセスをサポートする従量課金 ECS インスタンス、およびポート 80 をリスニングに使用する CLB インスタンス。[クイックデプロイメント] をクリックしてデバッグページに移動できます。表示されるページで、[デバッグの開始] をクリックします。次に、[計画と適用] をクリックします。デプロイメントが完了したら、Web サービスを ECS インスタンスにデプロイし、「レイヤー 7 CLB インスタンスの WAF 保護を有効にする」をご参照ください。 |
|
UA 攻撃
攻撃者は、HTTP リクエストの UA ヘッダーを偽造または改ざんして、実際の身元を隠し、セキュリティ保護対策を回避できます。異常な UA ヘッダーは、次の攻撃で使用できます。
悪意のあるクローリング:Web サイトのコンテンツが大量にスクレイピングされ、大量の帯域幅とリソースが消費されます。
脆弱性スキャン:Web サイトが自動的にスキャンされ、悪用される可能性のある脆弱性が見つかります。
HTTP フラッド攻撃:サーバーに大量のリクエストが送信され、サーバーが期待どおりに応答できなくなります。
スプーフィングとバイパス:UA ヘッダーが偽造され、特定のセキュリティとアクセスコントロールポリシーがバイパスされます。
前提条件
WAF 3.0 インスタンスが購入されています。詳細については、「サブスクリプション WAF 3.0 インスタンスを購入する」および「従量課金 WAF 3.0 インスタンスを購入する」をご参照ください。
Web サービスが保護対象として WAF 3.0 に追加されています。詳細については、「保護対象と保護対象グループを設定する」をご参照ください。
手順
ステップ 1: UA データを収集して分析する
保護ルールを設定する前に、通常のアクセスに使用される UA ヘッダーについて理解しておく必要があります。これは、通常のトラフィックと異常なトラフィックを区別するのに役立ちます。この例では、レイヤー 7 CLB インスタンスのログ収集が有効になっており、収集されたログを Simple Log Service で表示および分析できます。詳細については、「データ収集機能を有効にする」をご参照ください。
[Simple Log Service コンソール] にログオンします。 プロジェクトと Logstore を選択して、ログクエリと分析ページに移動します。

ログフィールドを表示します。CLB インスタンスのログ収集が有効になると、Simple Log Service はインスタンスのリクエストパケットに関する情報を収集します。収集されたログのフィールドの詳細については、「ログフィールド」をご参照ください。 http_user_agent フィールドは、リクエストの UA ヘッダーを指定します。[http_user_agent] フィールドをクリックして、数が最も多い UA 値を選択できます。次に、コンソールは、指定された時間範囲内に UA 値を含むすべてのログを表示します。

前の図は、UA 値が Apache-HttpClient/4.5.13 (Java/1.8.0_381) であるリクエストが、過去 15 分間のすべてのリクエストの 99% を占めていることを示しています。 UA 値が Apache-HttpClient/4.5.13 (Java/1.8.0_381) であるリクエストの総数は 4,368 です。
ステップ 2:カスタムルールモジュールの保護ルールを作成する
ドメイン名または API が攻撃者によって悪意を持ってアクセスされ、ログに null 値またはランダムな文字列を使用する UA ヘッダーなど、多くの偽造された UA ヘッダーが含まれている場合は、ビジネスシナリオに基づいて異常なリクエストを識別する必要があります。
この例では、ステップ 1 で収集されたデータは、同じ UA 値を持つリクエストの数が急増していることを示しています。これは、異常トラフィックの可能性を示しています。この場合、カスタムルールモジュールの保護ルールを作成して、WAF が異常トラフィックをブロックできるようにすることができます。
[WAF 3.0 コンソール] にログオンします。上のナビゲーションバーで、WAF インスタンスのリソースグループとリージョンを選択します。中国本土 または 中国本土以外 を選択できます。
左側のナビゲーションウィンドウで、 を選択します。
Web コア保護 ページの カスタムルール セクションで、テンプレートの作成 をクリックします。
[テンプレートの作成 - カスタムルール] パネルで、[ルールの作成] をクリックして、現在の保護テンプレートの保護ルールを作成します。
ルール名:この例では、ルール名を [Abnormal_UA_Interception] に設定します。
一致条件:この例では、[一致フィールド] パラメーターに [ユーザーエージェント] を選択し、[論理演算子] パラメーターに [含む] を選択し、[一致コンテンツ] パラメーターに [Apache-HttpClient/4.5.13 (Java/1.8.0_381)] と入力します。
実際のシナリオでは、必要に応じてパラメーターを設定できます。
アクション: ブロック

[OK] をクリックします。異常な UA 遮断 という名前の保護ルールが [ルール設定] セクションに表示されます。ルール ID を記録することをお勧めします。ルール ID を使用して、ルールの保護パフォーマンスを表示できます。この例では、ルール ID は 20766535 です。

[テンプレートの作成 - カスタムルール] パネルの [選択対象オブジェクト] セクションで、必要な [保護されたオブジェクト] または [保護されたオブジェクトグループ] を選択し、[選択されたオブジェクト] セクションに追加します。

[OK] をクリックします。[追加済み。] メッセージが表示されます。これは、保護テンプレートが作成されたことを示します。
検証
保護ルールが有効になったら、次の方法を使用してルールの保護パフォーマンスを検証できます。ログのリクエスト情報を表示し、セキュリティレポートのルールの詳細を表示します。
WAF ログを表示する
WAF ログで、異常な UA ヘッダーを使用するブロックされたリクエストを表示できます。ログで、final_action フィールドの値が block の場合、リクエストはブロックされます。詳細については、「ログフィールド」をご参照ください。
保護対象に対して WAF の Simple Log Service 機能 が有効になっている場合にのみ、WAF ログを表示できます。
[WAF 3.0 コンソール] にログオンします。上のナビゲーションバーで、WAF インスタンスのリソースグループとリージョンを選択します。リージョンには [中国本土] または [中国本土以外] を選択できます。
左側のナビゲーションウィンドウで、 を選択します。
[ログサービス] ページの上部で、CLB インスタンス用に生成された保護対象を選択します。 次の図は、異常な UA トラフィックが WAF によってブロックされ、WAF ログに記録されていることを示しています。

WAF セキュリティレポートを表示する
WAF セキュリティレポートで、保護ルールの保護パフォーマンスを表示できます。
[WAF 3.0 コンソール] にログオンします。
左側のナビゲーションウィンドウで、 を選択します。 [セキュリティレポート] ページで、上部の検索バーを使用して、カスタムルール保護モジュールと CLB インスタンス用に生成された保護対象をフィルタリングします。
Top 5 Hits セクションで、ステップ 2 で作成した異常な UA ヘッダーをブロックするための保護ルールが一致した回数を表示できます。
サービスログを表示する
保護ルールが有効になると、CLB インスタンスのサーバーログに異常な UA ヘッダーを使用するリクエストが含まれなくなります。次の図は、過去 15 分間の CLB インスタンスのログを示しています。異常な UA ヘッダーを使用するリクエストは WAF によってブロックされます。リクエストは CLB インスタンスに転送されません。

