このトピックでは、プロビジョニング中に発生する可能性のある一般的な Web Application Firewall (WAF) 3.0 の問題について説明します。
概要
プロビジョニング前の機能と構成
プロビジョニング中の問題
プロビジョニング後の問題
WAF におけるオリジン IP アドレスと back-to-origin IP アドレスの違いは何ですか？
WAF back-to-origin IP アドレス WAF back-to-origin IP アドレスは、トラフィックが処理された後、WAF が通常のトラフィックをオリジンサーバーに転送するために使用する IP アドレス範囲です。これらの IP アドレスは Alibaba Cloud によって割り当てられ、オリジンサーバーに送信されるリクエストのソースとして WAF を識別します。
back-to-origin IP アドレスは通常、固定された IP アドレスの範囲です。
オリジンサーバーの観点から見ると、クライアントからのすべてのリクエストは WAF によって傍受され、転送されます。実際のクライアント IP アドレスは、
X-Forwarded-Forやカスタムヘッダーなどの HTTP ヘッダーフィールドに記録されます。
オリジン IP アドレス オリジン IP アドレスは、サービスをホストするバックエンドサーバーのパブリック IP アドレス、またはそのドメイン名が解決される IP アドレスです。ユーザーが Web サイトにアクセスしたときにリクエストを受信し、レスポンスを返す宛先アドレスです。
オリジン IP アドレスは、単一の IP アドレスまたは負荷分散のための複数の IP アドレスにすることができます。
オリジン IP アドレスは、Web サイトの実際のエンドポイントです。ECS、SLB、OSS などの Alibaba Cloud サービス、または他のクラウドプロバイダーのサービスにデプロイできます。
同じドメイン名でクラウドネイティブモードと CNAME 接続タイプを同時に使用できますか？
いいえ。各ドメイン名は、クラウドネイティブまたは CNAME のいずれか 1 つのプロビジョニングモードしか使用できません。同じドメイン名に両方のモードを使用すると、転送の競合が発生し、保護が無効になります。CNAME モードで WAF によって保護されているドメイン名があり、クラウドネイティブモードに切り替えたい場合は、まずそのドメイン名の CNAME プロビジョニング構成を削除する必要があります。その後、クラウドネイティブモードでドメイン名をプロビジョニングできます。
WAF は 1 つのドメイン名で複数のオリジン IP アドレスを保護できますか？
はい。WAF では、1 つのドメイン名に対して最大 20 個のオリジン IP アドレスを構成できます。
WAF はヘルスチェックをサポートしていますか？
はい、WAF はデフォルトでヘルスチェックを有効にします。WAF は、すべてのオリジン IP アドレスのヘルスステータスをチェックします。オリジン IP アドレスが応答しない場合、WAF はアクセスリクエストを他の正常なオリジン IP アドレスに転送します。
オリジン IP アドレスが応答しない場合、WAF は自動的にその IP アドレスのサイレント期間を設定します。サイレント期間が終了すると、WAF はそのオリジン IP アドレスに新しいアクセスリクエストを転送しようとすることがあります。
WAF の専用 IP アドレスは DDoS 攻撃から防御できますか？
専用 IP アドレスは、1 つのドメイン名に対する大規模な DDoS 攻撃によって、他のプロビジョニングされたドメイン名がアクセス不能になるのを防ぎます。詳細については、「専用 IP アドレスの価値」をご参照ください。
WAF は CDN または Anti-DDoS Pro および Anti-DDoS Premium と共にプロビジョニングできますか？
はい、WAF は CDN、Anti-DDoS Pro、および Anti-DDoS Premium と完全に互換性があります。WAF を Anti-DDoS または CDN と併用する場合、WAF が提供する CNAME アドレスを Anti-DDoS または CDN のオリジンアドレスとして設定する必要があります。このアーキテクチャでは、トラフィックが Anti-DDoS または CDN を通過し、WAF に転送されてから、オリジンサーバーに到達します。このデプロイメントにより、オリジンサーバーに包括的なセキュリティ保護が提供されます。詳細については、「Anti-DDoS Pro または Anti-DDoS Premium と WAF をデプロイしてウェブサイトのセキュリティを向上させる」および「WAF と CDN をデプロイして、CDN が有効になっているドメイン名を保護する」をご参照ください。
WAF は CDN、Anti-DDoS、WAF を使用するクロスアカウントアーキテクチャをサポートしていますか？
はい。CDN、Anti-DDoS、WAF のクロスアカウント製品ポートフォリオを使用して、DDoS 攻撃や Web アプリケーション攻撃から防御するセキュリティアーキテクチャを構築できます。
WAF はアップ 証明書とキーのセキュリティをどのように確保しますか？ HTTPS トラフィックを復号化し、アクセスリクエストの内容を記録しますか？
HTTPS サービスを保護する場合、Alibaba Cloud WAF では、対応する SSL 証明書とキーをアップロードして HTTPS トラフィックを復号化し、攻撃シグネチャを検査する必要があります。キーの保存と管理には、専用のキーサーバーを使用します。キーサーバーは、Alibaba Cloud Key Management Service (KMS) を利用して、証明書とキーのデータセキュリティ、整合性、可用性を保護し、規制および等級保護のコンプライアンス要件を満たします。KMS の詳細については、「KMS とは」をご参照ください。
WAF は、アップロードされた SSL 証明書とキーを使用して、リアルタイム検査のためにのみ HTTPS トラフィックを復号化します。攻撃レポートやデータ統計の表示などの目的で、攻撃シグネチャ (ペイロード) を含むリクエストコンテンツの一部のみを記録します。お客様の許可なく、リクエストまたはレスポンスの完全なコンテンツを記録することはありません。
Alibaba Cloud WAF は、ISO 9001、ISO 20000、ISO 22301、ISO 27001、ISO 27017、ISO 27018、ISO 27701、ISO 29151、BS 10012、CSA STAR、等級保護コンプライアンスレベル 3、SOC 1/2/3、C5、HK Finance、OSPAR、PCI DSS など、複数の国際的な権威ある認証を取得しています。標準の Alibaba Cloud 製品として、Alibaba Cloud プラットフォームと同じレベルのセキュリティおよびコンプライアンス資格を有しています。詳細については、「Alibaba Cloud トラストセンター」をご参照ください。
Web サイトは WAF によって保護されていますが、ドメイン名リストに見つからないのはなぜですか？
Web サイトの ICP 登録の有効期限が切れている可能性があり、その結果、ドメイン名がプロビジョニング要件を満たさなくなります。WAF は、そのようなドメイン名を保護対象リストから自動的にパージします。ドメイン名の ICP 登録を完了してから、Web サイトを WAF に再度追加する必要があります。Alibaba Cloud ICP 登録の詳細については、「ICP 登録プロセス」をご参照ください。
中国本土 の WAF インスタンスで Web サイトを保護する前に、ドメイン名に有効な ICP 登録があることを確認する必要があります。関連する法律および規制を遵守するため、中国本土の WAF インスタンスは、ICP 登録の有効期限が切れたドメイン名を定期的にパージします。
WAF はカスタムヘッダーを使用してクライアントのソース IP アドレスを取得し、記録する方法は？
カスタムヘッダーからクライアントのソース IP アドレスを取得する: Anti-DDoS Pro や Anti-DDoS Premium、CDN などの他のレイヤー 7 プロキシサービスが WAF の前にデプロイされている場合、カスタムヘッダーを使用してクライアント IP アdress を保存できます。この方法では、攻撃者が X-Forwarded-For (XFF) ヘッダーを偽造して WAF 検出ルールをバイパスするのを防ぐことで、セキュリティを向上させます。これを行うには、クライアントのソース IP アドレスを X-Client-IP や X-Real-IP などのカスタムヘッダーフィールドに配置し、WAF がそのヘッダーフィールドから読み取るように構成します。WAF は、指定されたヘッダーフィールドの値をクライアントのソース IP アドレスとして取得します。複数のヘッダーフィールドを指定した場合、WAF は指定された順序でヘッダーからクライアント IP アドレスを読み取ろうとします。
クライアント IP アドレスをカスタムヘッダーに記録する: WAF 保護のために Web サイトを追加するときに、トラフィックマーキングを有効にできます。この機能により、WAF はクライアント IP アドレスをクライアントリクエストのカスタムヘッダーフィールドに書き込みます。バックエンドサーバーは、WAF によって転送された back-to-origin リクエストの指定されたヘッダーフィールドからクライアント IP アドレスを取得できます。これは、バックエンドサーバーがビジネス分析のために特定のカスタムヘッダーからクライアント IP アドレスを取得する必要があるシナリオで役立ちます。
同じドメイン名が複数のクラウドプロダクトインスタンスに解決されます。どのようにプロビジョニングすればよいですか？
クラウドネイティブモードを使用する場合、SLB インスタンスのサービスポートなど、これらすべてのクラウドプロダクトインスタンスを同時にプロビジョニングする必要があります。これにより、WAF はそれらすべてのトラフィックをリダイレクトできます。
CNAME モードを使用する場合、ドメイン名を追加すると、すべてのクラウドプロダクトインスタンスが WAF のデフォルトの緩和ポリシーによって保護されます。
複数のドメイン名が同じクラウドプロダクトインスタンスに解決されます。どのようにプロビジョニングすればよいですか？
クラウドネイティブモードを使用する場合、プロビジョニングされたクラウドプロダクトインスタンス上のすべてのドメイン名は、WAF のデフォルトの緩和ポリシーによって保護されます。ただし、個々のドメイン名に異なる保護ルールを構成する場合は、それらを保護対象オブジェクトとして追加する必要があります。詳細については、「保護対象オブジェクトを手動で追加する」をご参照ください。
CNAME モードを使用する場合は、ドメイン名を 1 つずつ追加する必要があります。
CNAME プロビジョニングでサポートされているドメイン名サフィックスは何ですか？
WAF 3.0 は、中国のドメイン名サフィックスを含むほとんどのドメイン名サフィックスをサポートしています。サポートされている中国のサフィックスのリストについては、「iana.org」をご参照ください。
WAF 3.0 は WAF 2.0 よりも多くのドメイン名サフィックスをサポートしています。WAF 2.0 でプロビジョニングがサポートされていないドメイン名が見つかった場合は、WAF 3.0 にアップグレードすることをお勧めします。
WAF は HTTPS 相互認証をサポートしていますか？
いいえ、CNAME および透過プロキシモードは HTTPS 相互認証をサポートしていません。ただし、WAF 3.0 のサービスベースのプロビジョニングソリューションはサポートしています。現在、サービスベースのプロビジョニングをサポートしているクラウド製品には、ALB、MSE、FC、SAE があります。このタイプのプロビジョニングは、WAF コンソールのクラウドネイティブモードセクションで構成できます。
WAF は WebSocket、HTTP 2.0、または SPDY プロトコルをサポートしていますか？
WAF は WebSocket プロトコルをサポートしています。Enterprise Edition 以上のサブスクリプションプラン、および従量課金プランは、HTTP 2.0 プロトコルのリスニングをサポートしています。SPDY プロトコルはサポートされていません。
攻撃者が HTTP 2.0 クリアテキストスマグリングを使用して WAF をバイパスするのを防ぐには、ヘッダー名が Upgrade で値が h2c のリクエストをブロックするカスタムルールを作成できます。詳細については、「特定のリクエストから防御するためのカスタムルールを作成する」をご参照ください。
WAF で HTTP 2.0 サービスを保護すると、オリジンサーバーに影響しますか？
はい。WAF で HTTP 2.0 サービスを保護するということは、WAF がクライアントからの HTTP 2.0 リクエストを処理できることを意味します。ただし、WAF は現在、HTTP 1.0/1.1 を介した back-to-origin リクエストの転送のみをサポートしています。WAF とオリジンサーバー間では HTTP 2.0 はまだサポートされていません。したがって、WAF で HTTP 2.0 サービスを保護すると、オリジンサーバーの HTTP 2.0 機能に影響します。たとえば、オリジンサーバーの HTTP 2.0 多重化機能が無効になり、オリジンサーバーのサービス帯域幅が増加する可能性があります。
WAF は NTLM プロトコル認証を使用する Web サイトのプロビジョニングをサポートしていますか？
いいえ。Web サイトが NTLM プロトコル認証を使用している場合、WAF によって転送されたアクセスリクエストは、オリジンサーバーの NTLM 認証に失敗する可能性があります。クライアントには認証プロンプトが繰り返し表示されます。Web サイト認証には他の方法を使用することをお勧めします。
WAF QPS 制限は WAF インスタンス全体に対するものですか、それとも構成された単一のドメイン名の上限ですか？
WAF のクエリ/秒 (QPS) 制限は、WAF インスタンス全体に適用されます。
たとえば、WAF インスタンスで保護対象として 3 つのドメイン名を設定した場合、これら 3 つのドメイン名の合計 QPS は指定された制限を超えることはできません。QPS が購入した WAF インスタンスの制限を超えると、インスタンスがサンドボックスに入る可能性があります。実際の QPS が仕様を超えたり、インスタンスがサンドボックスに入ったりした場合、製品はサービスレベル契約 (SLA) に従うことが保証されなくなります。
WAF back-to-origin IP 範囲と WAF が提供する CNAME を表示する方法は？
プロビジョニングリストページの次の図に示す場所で、各プロビジョニング済みドメイン名に対して WAF が提供する WAF back-to-origin IP 範囲と CNAME アドレスを見つけることができます。
プロビジョニングする SLB、NLB、または ECS インスタンスが構成ページで見つからない場合のトラブルシューティング
考えられる原因 | 関連操作 |
プロビジョニングする SLB、NLB、または ECS インスタンスが条件を満たしていません。 | プロビジョニング条件と照らし合わせてインスタンスを確認します。条件の詳細については、「SLB インスタンスのプロビジョニング条件」、「NLB インスタンスのプロビジョニング条件」、および「ECS インスタンスのプロビジョニング条件」をご参照ください。 |
プロビジョニングする SLB インスタンスに対応するリスナーが追加されていません。 |
|
WAF が SLB、NLB、または ECS インスタンスと同期できませんでした | アセットを同期する具体的な手順については、「アセットを手動で同期する」をご参照ください。 |
HTTPS トラフィックリダイレクトポートを追加すると、SLB 証明書が不完全ですというメッセージが表示されます。どうすればよいですか？
問題の説明
HTTPS トラフィックリダイレクトポートを追加すると、WAF はそのポートに構成されている証明書のソースを検証します。ポートを追加すると、次のメッセージが表示されます: ポート XXX の SLB 証明書が不完全です。SLB コンソールに移動し、Certificate Service から証明書を再選択してください。
考えられる原因
構成された証明書が Alibaba Cloud Certificate Management Service (Original SSL Certificate) から購入されておらず、Alibaba Cloud Certificate Management Service (Original SSL Certificate) にアップロードされていません。
SLB インスタンスの HTTPS ポートリスナーの証明書は SLB コンソールからアップロードされました。ただし、このアップロード方法では、証明書情報が Certificate Management Service (旧 SSL 証明書) に自動的に同期されません。WAF は Certificate Management Service からのみ証明書情報を取得するため、WAF は完全な証明書コンテンツを取得できず、「証明書が不完全です」というメッセージが表示されます。
以前にアップロードした証明書が手動で削除され、証明書が Certificate Management Service (Original SSL Certificate) に存在しなくなりました。
解決策
証明書を Certificate Management Service (Original SSL Certificate) にアップロードします。詳細については、「SSL 証明書のアップロード」をご参照ください。
SLB コンソールで証明書を作成し、証明書ソースとして Alibaba Cloud 発行の証明書を選択します。詳細については、「Alibaba Cloud 発行の証明書を選択する」をご参照ください。
SLB コンソールで、アップロードされたサーバー証明書を選択します。詳細については、「ステップ 2: SSL 証明書を構成する」をご参照ください。
WAF のオリジン IP アドレスには、ECS インスタンスのパブリック IP アドレスとプライベート IP アドレスのどちらを入力すればよいですか？
パブリック IP アドレスを入力する必要があります。WAF はオリジンフェッチにインターネットを使用し、プライベート IP アドレスはサポートしていません。
オリジンサーバーのパブリック IP アドレスが公開されています。攻撃者が WAF をバイパスしてオリジンのパブリック IP アドレスを直接攻撃した場合はどうなりますか？
次のいずれかの方法を使用できます: 方法 1: CNAME モードで、WAF back-to-origin IP 範囲からのトラフィックのみを許可するようにオリジンサーバーを構成します。これにより、WAF のみがオリジンサーバーと通信できるようになります。詳細については、「WAF back-to-origin IP アドレスを許可する」をご参照ください。
方法 2: クラウドネイティブモードを使用します。
WAF プロビジョニング後に 502 ステータスコードを受信する複数のシナリオ
問題の説明
WAF をプロビジョニングした後、バックエンドサービスにアクセスすると 502 ステータスコードが返されます。ログには 502 ステータスコードを持つリクエストが表示されます。
原因と解決策
シナリオ 1: CNAME モードでの 502 エラー
シナリオ 2: クラウドネイティブモードのレイヤー 7 SLB で断続的な 5xx エラーが発生する
詳細な原因分析
WAF back-to-origin 接続アイドルタイムアウト: 3,600 秒 (1 時間)
説明: SLB と WAF の間で 1 時間データ転送がない場合、WAF は自動的に接続を閉じます。
SLB クライアント向け接続アイドルタイムアウト: 15 秒
説明: クライアント (この場合は WAF インスタンス) と SLB の間で 15 秒間データ転送がない場合、SLB は自動的に接続を閉じます。
極端なケースでは、SLB 側で持続的接続が期限切れになります (15 秒以上データ転送なし)。その時点で、WAF back-to-origin リクエストがその持続的接続を再利用して SLB にデータを送信します。SLB には持続的接続に関する情報がなくなったため、 RST メッセージを送信してリクエストを終了します。これにより、WAF 側で 502 ステータスコードを持つログエントリが生成されます。
解決策
クラウドネイティブモードのレイヤー 7 SLB の [アイドルタイムアウト] を調整します。SLB のクライアント向け接続アイドルタイムアウトより小さい値、たとえば 14 秒に設定します。
シナリオ 3: 長い URI による断続的な 502 エラー
シナリオ 4: WAF が複数のレイヤー 4 SLB に back-to-origin リクエストを送信するときの断続的な 502 エラー
現在のネットワークアーキテクチャ
現在のアーキテクチャでは、WAF はリバースプロキシモードでプロビジョニングされ、複数のレイヤー 4 SLB に back-to-origin リクエストを送信します。バックエンドの RealServer (RS) は同じポートでリッスンし、複数のレイヤー 4 SLB にアタッチされています。
詳細な原因分析
ECS インスタンスが複数のレイヤー 4 (TCP) SLB インスタンスのバックエンドサーバーとして機能し、これらの SLB インスタンスが同じバックエンドサービスポートで構成されている場合、次のことが発生する可能性があります: クライアントリクエストが WAF クラスター内の同じ WAF インスタンスノードから SLB に送信され、同じ WAF ノード IP アドレスがこれらの SLB インスタンスのフロントエンドサービスに同時にアクセスするために使用される場合、一部の接続が失敗したりタイムアウトしたりする可能性があります。
ケース 1: 5 次元ルール競合、TCP ストリーム衝突
WAF クラスターが複数の SLB ノードにセキュリティ保護を提供する場合、これらの SLB ノードへのリクエストは同じ WAF back-to-origin IP アドレスから発信される可能性があります。
WAF インスタンスノードが back-to-origin リクエストを送信して CLB1 にアクセスすると、接続 (WIP:CPORT->VIP1:VPORT1) はバックエンド ECS に到達すると (WIP:CPORT->DIP:DPORT) に変換されます。
同じ WAF インスタンスノードが back-to-origin リクエストを送信して CLB2 にアクセスすると、接続 (WIP:CPORT->VIP2:VPORT2) もバックエンド ECS に到達すると (WIP:CPORT->DIP:DPORT) に変換されます。
2 つの TCP 接続のシーケンス番号と状態がバックエンドサーバーで競合するため、接続の確立に失敗します。具体的には、2 つの開始された TCP 接続は、バックエンドサーバーによって同じ 5 次元ルール (TCP:WIP:CPORT:DIP:DPORT) を持つものと見なされます。この 5 次元ルールの競合により、SYN メッセージがドロップされる可能性があります。
ケース 2: 不正なメッセージリターンパス
完全なリクエストパスでは、リクエストを開始する SLB ノードとレスポンスメッセージを受信する SLB ノードが異なります。
WAF は CLB2 を介して back-to-origin SYN メッセージを送信します。5 次元ルールは WIP:CPORT->VIP1:VPORT1 です。バックエンド ECS2 に到達すると、WIP:CPORT->DIP:DPORT に変換されます。
この時点で ECS2 に 5 次元ルール TCP:WIP:CPORT:DIP:DPORT の TIME-WAIT 接続がある場合、最初のステップからの SYN メッセージを受信し、正当であると判断して SYN-ACK メッセージで応答します。
ECS2 は複数の SLB にアタッチされているため、SYN-ACK メッセージを CLB1 に送り返す可能性があります。CLB1 にこの 5 次元ルールのセッションがない場合、CLB1 はパケットに対して双方向リセットを送信します。これにより、WAF は 502 エラーを返します。
解決策
解決策 1 (推奨)
ネットワークアーキテクチャを変更します。たとえば、複数のレイヤー 7 SLB をオリジンサーバーとして使用して、複数の異なるレイヤー 4 SLB ノードが同じバックエンドサービスの同じポートにリクエストを転送しないようにします。
解決策 2
SLB から NLB に移行します。構成で、クライアント IP アドレスアフィニティを無効にして、5 次元ルールの競合問題を解決します。バックエンドサービスに Proxy Protocol をデプロイして、実際のクライアント IP アドレスを取得します。詳細については、「Proxy Protocol 機能を使用してクライアント IP アドレスを取得する」をご参照ください。
手順
NLB コンソールにログインします。上部のメニューバーで、NLB インスタンスがデプロイされているリージョンを選択します。
左側のナビゲーションウィンドウで、 を選択します。
サーバーグループを選択し、[アクション] 列の [基本情報の編集] をクリックします。[基本情報の編集] ダイアログボックスで、[クライアント IP アフィニティ] を無効にして変更を保存します。
解決策 3 (非推奨)
チケットを起票して FULLNAT モードを有効にすることができます。複数の SLB インスタンスが同じバックエンドサーバーの同じポートにリクエストを転送する場合、FullNAT はソースアドレスを変更して各接続の 5 次元ルールを一意にすることで競合を回避します。SLB リスナーで FULLNAT モードを有効にして、5 次元ルールの競合を回避します。
WAF プロビジョニング後にファイルのアップロードが失敗する
この問題は、ファイルのアップロードがサイズ制限を超えたために発生する可能性があります。WAF は最大 2 GB のファイルアップロードサイズをサポートしています。リクエストボディが 2 GB を超えると、WAF は 413 ステータスコードを返します。返されたステータスコードを確認して、ファイル転送サイズ制限に達したかどうかを判断できます。
有効期限が近づいている証明書を更新する方法は？
更新方法はプロビジョニングモードによって異なります:
CNAME モードについては、「ドメイン名にバインドされた証明書を更新する」をご参照ください。
ECS インスタンスを使用したクラウドネイティブモードについては、「ECS トラフィックリダイレクトポートにバインドされた証明書を更新する」をご参照ください。
SLB インスタンスを使用したクラウドネイティブモードについては、「SLB トラフィックリダイレクトポートにバインドされた証明書を更新する」をご参照ください。
NLB インスタンスを使用したクラウドネイティブモードについては、「NLB トラフィックリダイレクトポートにバインドされた証明書を更新する」をご参照ください。
ALB インスタンスを使用したクラウドネイティブモードの場合、WAF コンソールで更新する必要はありません。Certificate Management Service (旧 SSL 証明書) コンソールで ALB インスタンスに証明書をデプロイするだけです。詳細については、「SSL 証明書を Alibaba Cloud サービスにデプロイする」をご参照ください。
クラウドネイティブプロビジョニング後、オリジンサーバーは実際のクライアント IP アドレスを取得できますか？
はい、できます。WAF は実際のクライアント IP アドレスをクラウドプロダクトインスタンスに直接提供します。