本記事では、ウェブサイトを Web Application Firewall (WAF) 3.0 に追加する際によくある問題をリストアップしています。
概要
オンボーディング前の機能と設定に関するお問い合わせ
オンボーディング中に発生する可能性のある問題
オンボーディング設定ページでオンボーディングしたい CLB インスタンス、NLB インスタンス、または ECS インスタンスが見つからない場合のトラブルシューティング
WAF のオリジン IP アドレスには、ECS インスタンスのパブリック IP とプライベート IP のどちらを使用すべきか
HTTPS トラフィックリダイレクションポートを追加する際に、「CLB 証明書が不完全です」というメッセージが表示される
CNAME オンボーディング中に、HTTP バックツーオリジンを設定した後に ERR_TOO_MANY_REDIRECTS が表示される理由
クラウド製品のオンボーディングで CLB インスタンスをオンボーディングする際に InvalidTLS エラーが発生する理由
オリジンサーバーのパブリック IP が公開されている場合に、攻撃者が WAF をバイパスしてオリジンのパブリック IP を直接攻撃するのを防ぐ方法
オンボーディング後に発生する可能性のある問題
WAF におけるオリジン IP アドレスとバックツーオリジン IP アドレスの違い
WAF のバックツーオリジン IP：WAF が保護対象のトラフィックをオリジンサーバーに転送するために使用する IP 範囲です。これらの IP は Alibaba Cloud によって割り当てられ、オリジンへのリクエストを行う際に WAF をソースとして識別します。
バックツーオリジン IP 範囲は通常、固定された IP アドレスのセットです。
オリジンサーバーから見ると、すべてのクライアントリクエストは WAF によって傍受され、転送されます。実際のクライアント IP は、
X-Forwarded-Forなどの HTTP ヘッダーフィールドまたはカスタムヘッダーに記録されます。
オリジン IP：ビジネスを実際にホストしているバックエンドサーバーのパブリック IP アドレス、またはドメインから解決される IP アドレスです。ユーザーが Web サイトにアクセスした際に、最終的にリクエストを受信して応答を返す宛先です。
オリジン IP は、単一の IP アドレスまたは複数の IP アドレス (負荷分散をサポート) にすることができます。
オリジン IP は、Web サイトの実際のサービスアドレスであり、Alibaba Cloud Elastic Compute Service (ECS)、Server Load Balancer (SLB)、Object Storage Service (OSS)、または他のクラウドプロバイダーにデプロイされている場合があります。
同一ドメインでクラウド製品のオンボーディングと CNAME オンボーディングを同時に使用できるか
推奨されません。各ドメインは、クラウド製品のオンボーディングまたは CNAME オンボーディングのいずれか 1 つのオンボーディングモードしか使用できません。同じドメインを 2 回オンボーディングすると、転送の競合が発生し、保護が無効になります。CNAME オンボーディングによって既に WAF で保護されているドメインをクラウド製品のオンボーディングに切り替える必要がある場合は、まずそのドメインの CNAME オンボーディング設定を削除してから、クラウド製品モードで再度オンボーディングする必要があります。
WAF は単一ドメイン配下の複数のオリジンサーバー IP を保護できるか
はい。単一の WAF ドメインに対して最大 20 個のオリジン IP アドレスを設定できます。
WAF はオリジンサーバーのヘルスチェックを実行するか
WAF はデフォルトでヘルスチェックを有効にします。WAF はすべてのオリジン IP のアクセシビリティをチェックします。オリジン IP が応答しなくなった場合、WAF はリクエストを他の正常なオリジン IP に転送します。
オリジン IP が応答しなくなると、WAF はその IP に対して自動的にサイレンス期間を設定します。サイレンス期間が終了した後、新しいリクエストがテストのために再度その IP に転送されることがあります。
WAF の専用 IP は DDoS 攻撃を軽減できるか
専用 IP は、1 つのドメインへの大規模な DDoS 攻撃によって、オンボーディングされている他のすべてのドメインがアクセス不能になる状況を防ぎます。詳細については、「専用 IP アドレスの価値」をご参照ください。
WAF は CDN や Anti-DDoS Proxy と統合できるか
WAF は CDN および Anti-DDoS Proxy サービスと完全に互換性があります。併用する場合は、WAF の CNAME アドレスを Anti-DDoS Proxy または CDN のオリジンとして設定するだけです。これにより、トラフィックは Anti-DDoS Proxy または CDN を経由して WAF に転送され、その後 WAF を経由してオリジンサーバーに転送されるため、オリジンに包括的なセキュリティを提供します。詳細については、「Anti-DDoS Proxy と WAF を使用して Web サイトサービスを保護する」および「WAF で CDN アクセラレーションされたドメインを保護する」をご参照ください。
WAF は CDN + Anti-DDoS Proxy + WAF アーキテクチャのアカウント間利用をサポートしているか
はい。異なる Alibaba Cloud アカウント間で CDN、Anti-DDoS Proxy、WAF を使用して、DDoS 攻撃や Web アプリケーション攻撃に対するセキュリティアーキテクチャを構築できます。
WAF はアップロードされた証明書と秘密鍵のセキュリティをどのように確保しているか。WAF は HTTPS トラフィックを復号し、リクエスト内容をログに記録するか
HTTPS トラフィックを保護する場合、Alibaba Cloud WAF では、HTTPS トラフィックを復号して攻撃シグネチャを検出するために、対応する SSL 証明書と秘密鍵をアップロードする必要があります。当社は専用のキーサーバーを使用して証明書とキーを保存および管理します。キーサーバーは Alibaba Cloud Key Management Service (KMS) 上に構築されており、規制および等級保護の要件に準拠して、証明書とキーのデータセキュリティ、整合性、可用性を確保します。KMS の詳細については、「Key Management Service とは」をご参照ください。
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 製品として、WAF はクラウドプラットフォームレベルで Alibaba Cloud プラットフォームと同じセキュリティコンプライアンス認定を有しています。詳細については、「Alibaba Cloud トラストセンター」をご参照ください。
Web サイトが WAF で保護されているにもかかわらず、ドメインリストに表示されない
ドメインの ICP 登録が期限切れになり、オンボーディング要件に準拠しなくなったため、WAF によって自動的に削除された可能性があります。ドメインの ICP 登録を完了し、WAF に再度オンボーディングする必要があります。Alibaba Cloud の ICP 登録については、「ICP 登録プロセス」をご参照ください。
Web サイトを中国本土の WAF インスタンスにオンボーディングする前に、ドメインが有効な ICP 登録を持っていることを確認する必要があります。適用される法律および規制を遵守するため、中国本土の WAF インスタンスは、ICP 登録が期限切れのドメインを定期的に消去します。
WAF がクライアントのソース IP を取得し、カスタムヘッダーを介してクライアント IP を記録する方法
カスタムヘッダーからクライアントのソース IP を取得する：Web サイトビジネスに WAF の前に他のレイヤー 7 プロキシサービス (Anti-DDoS Proxy や CDN など) がある場合、攻撃者が XFF フィールドを偽造して WAF の検出ルールを回避し、ビジネスのセキュリティを向上させるのを防ぐために、カスタムヘッダーを使用してクライアント IP を伝達できます。クライアントのソース IP をカスタムヘッダーフィールド (例：X-Client-IP または X-Real-IP) に配置し、WAF がそのヘッダーフィールドから読み取るように設定します。WAF は、指定されたヘッダーフィールドの値をクライアントのソース IP として使用します。複数のヘッダーフィールドを設定した場合、WAF はそれらから順番にクライアント IP を読み取ろうとします。
カスタムヘッダーにクライアント IP を記録する：Web サイトを WAF に追加する際に、トラフィックマーキングを有効にすると、WAF はクライアント IP をクライアントリクエストのカスタムヘッダーに書き込みます。バックエンドサーバーは、バックツーオリジンリクエストの指定されたヘッダーフィールドからクライアント IP を読み取ることができます。これは、バックエンドサーバーがビジネス分析のために指定されたカスタムヘッダーからクライアント IP を取得する必要があるシナリオに適用されます。
ALB インスタンスの Anti-DDoS と WAF 保護 の違いは何か。両方を有効にすべきか。
Web Application Firewall (WAF) と Anti-DDoS 対策は、2 つの独立した補完的なセキュリティ機能です。それらの主な違いは次のとおりです：
WAF：主に SQL インジェクション、クロスサイトスクリプティング (XSS) 攻撃、CC 攻撃などのアプリケーション層 (L7) の脅威から保護します。この保護を有効にするには、Application Load Balancer (ALB) インスタンスを「ALB WAF Enhanced Edition」にアップグレードできます。この操作には追加料金が発生します。詳細については、「ALB インスタンスの WAF 保護を有効にする」をご参照ください。
Anti-DDoS 対策：主にネットワーク層およびトランスポート層 (L3/L4) でのボリューム攻撃から保護します。ALB インスタンスは、デフォルトで無料の基本的な Anti-DDoS 対策を提供します。攻撃トラフィックがブラックホールしきい値を超えた場合は、Anti-DDoS (Enhanced) EIP を購入してアタッチできます。詳細については、「Anti-DDoS (Enhanced) EIP を ALB インスタンスに関連付ける」をご参照ください。
これらの機能は、アプリケーションが直面するセキュリティリスクに基づいて設定できます。ネットワーク層とアプリケーション層での包括的な多層防御のために、両方の保護機能を有効にすることができます。
WAF はレイヤー 4 TCP プロトコルのオンボーディングをサポートしているか
WAF は、レイヤー 4 CLB (TCP) および ECS インスタンスのポートでリッスンされる HTTP および HTTPS プロトコルトラフィックの WAF 保護を有効にすることをサポートしています。他の非 HTTP/HTTPS プロトコルを使用するポート上のトラフィックの転送と保護はサポートしていません。
Web アプリケーションファイアウォールとして、WAF は主に Web トラフィック、つまり HTTP および HTTPS トラフィックを保護します。したがって、レイヤー 4 CLB (TCP) または ECS インスタンスのポートによって監視されるトラフィックが Web トラフィックである場合、WAF は転送保護を提供できます。ただし、レイヤー 4 クラウド製品インスタンスが他のアプリケーション層プロトコルトラフィック (FTP、SMTP など) を伝送する場合、WAF はそのようなトラフィックを転送できません。
CNAME でオンボーディングされたドメイン情報リストを一括エクスポートする方法
DescribeInstance API を呼び出して WAF インスタンス ID を取得し、次に DescribeDomains API を呼び出して、CNAME でオンボーディングされたすべてのドメインのリストをクエリできます。
CNAME オンボーディング中に、WAF はドメインタイプのオリジン (CNAME など) をどのように負荷分散するか
CNAME オンボーディングモードでは、オリジンに複数のサーバーアドレスがある場合、さまざまな ロードバランシングアルゴリズム オプションを選択して、WAF がバックツーオリジンリクエストを対応するサーバーに転送し、負荷分散を実現できます。
[サーバーアドレス] が ドメイン名(CHAMEなど) に設定されている場合、このドメインを解決すると複数の IP アドレスが返されると、WAF は解決された IP アドレス間でクライアントリクエストを負荷分散します。複数のドメインを入力した場合、WAF はすべての解決結果を展開し、それら全体で負荷分散します。
ただし、ドメインを 1 つだけ入力し、各ドメイン解決で 1 つの IP アドレスしか返されない場合、WAF は負荷分散を実行せず、解決された単一の結果にのみバックツーオリジンを転送します。
同一ドメイン名が複数のクラウド製品インスタンスに解決される場合のオンボーディング方法
クラウド製品のオンボーディングを使用する：これらのクラウド製品インスタンス (例えば、CLB インスタンスのサービスポート) をすべて同時にオンボーディングする必要があります。これにより、WAF はトラフィックをそれらすべてにリダイレクトします。
CNAME オンボーディングを使用する：ドメインを CNAME でオンボーディングした後、すべてのクラウド製品インスタンスは WAF のデフォルト保護ポリシーによって保護されます。
複数のドメイン名が同一のクラウド製品インスタンスに解決される場合のオンボーディング方法
クラウド製品のオンボーディングを使用する：クラウド製品インスタンスをオンボーディングした後、そのインスタンス上のすべてのドメインは自動的に WAF のデフォルト保護ポリシーによって保護されます。ただし、個々のドメインに個別の保護ルールを設定したい場合は、各ドメインを保護対象として手動で追加する必要があります。詳細については、「保護対象を手動で追加する」をご参照ください。
CNAME オンボーディングを使用する：各ドメインを個別にオンボーディングします。
CNAME オンボーディングでサポートされているドメイン名サフィックス
WAF 3.0 は、中国のドメイン名サフィックスを含む、ほとんどのドメイン名サフィックスをサポートしています。サポートされている中国のサフィックスの完全なリストについては、「iana.org」をご参照ください。
WAF 3.0 は WAF 2.0 よりも多くのドメインサフィックスをサポートしています。ドメインサフィックスが WAF 2.0 でサポートされていない場合は、WAF 3.0 へのアップグレードを推奨します。
WAF は HTTPS 相互認証 (mTLS) をサポートしているか
CNAME オンボーディングと透過的オンボーディングは HTTPS 相互認証をサポートしていません。WAF 3.0 のサービスベースのオンボーディングソリューションはサポートしています。現在、サービスベースのオンボーディングをサポートしているクラウド製品には、ALB、MSE、FC、SAE が含まれます。これは WAF コンソールのクラウド製品オンボーディングセクションで設定できます。
WAF は WebSocket、HTTP/2、または SPDY プロトコルをサポートしているか
WebSocket プロトコル：トラフィック転送はサポートされています。セキュリティ保護は提供されません。
HTTP/2 プロトコル：リスニングとバックツーオリジンがサポートされています。
SPDY プロトコル：サポートされていません。
攻撃者が HTTP/2 クリアテキストスマグリング (h2c) を使用して WAF をバイパスするのを防ぐために、ヘッダー名が Upgrade で値が h2c のリクエストを傍受するカスタムルールを作成できます。詳細については、「特定のリクエストから防御するためのカスタムルールを作成する」をご参照ください。
WAF は NTLM プロトコル認証を使用する Web サイトをサポートしているか
いいえ。Web サイトが NTLM プロトコル認証を使用している場合、WAF によって転送されたアクセスリクエストはオリジンサーバーでの NTLM 認証に失敗し、クライアントで繰り返し認証プロンプトが表示される可能性があります。Web サイトには別の認証方式を使用することを推奨します。
WAF の QPS 制限は WAF インスタンス全体に適用されるか、それとも各ドメインに個別に適用されるか
WAF の QPS 制限は、WAF インスタンス全体に適用されます。
たとえば、WAF インスタンスに 3 つのドメインを設定した場合、それらの合計 QPS は指定された制限を超えてはなりません。QPS が購入した WAF インスタンスの制限を超えると、インスタンスはサンドボックスに入る可能性があります。実際の QPS が仕様を超えるか、インスタンスがサンドボックスに入ると、WAF はサービスレベル契約 (SLA) への準拠を保証しなくなります。
購入した WAF インスタンスは別の Alibaba Cloud アカウントへのスムーズな移行をサポートしているか
WAF インスタンスは、他の Alibaba Cloud アカウントへの直接のスムーズな移行をサポートしていません。アカウント間で WAF を使用する必要がある場合は、次の代替ソリューションのいずれかを使用してください：
解約と再購入：現在のアカウントで WAF インスタンスを解約してリリースし、ターゲットアカウントで再購入します。
統一されたマルチアカウント管理：マルチアカウント管理機能を使用して、現在のアカウントの WAF システムの下でターゲットアカウントを管理します。
WAF のバックツーオリジン IP 範囲と WAF が提供する CNAME を表示する方法
オンボーディングリストページの次の図に示す場所で、WAF のバックツーオリジン IP 範囲と、オンボーディングされた各ドメインに対して WAF が提供する CNAME アドレスを確認できます。
オンボーディング設定ページでオンボーディングしたい CLB インスタンス、NLB インスタンス、または ECS インスタンスが見つからない場合のトラブルシューティング
考えられる原因 | 関連するアクション |
オンボーディングしたい CLB インスタンス、NLB インスタンス、または ECS インスタンスがオンボーディング条件を満たしていない。 | インスタンスがオンボーディング条件を満たしているか確認してください。詳細については、「CLB インスタンスのオンボーディング条件」、「NLB インスタンスのオンボーディング条件」、および「ECS インスタンスのオンボーディング条件」をご参照ください。 |
オンボーディングしたい CLB インスタンスに対応するリスナーが設定されていない。 |
|
WAF が CLB、NLB、または ECS インスタンスを同期していない。 | アセットを手動で同期する手順については、「アセットの手動同期」をご参照ください。 |
HTTPS トラフィックリダイレクションポートを追加する際に、「CLB 証明書が不完全です」というメッセージが表示される場合の対処法
症状
HTTPS トラフィックリダイレクションポートを追加すると、WAF はそのポートの証明書ソースを検証します。ポートを追加した後、次のメッセージが表示されることがあります：ポート XXX の CLB 証明書は不完全です。CLB コンソールで SSL 証明書サービスから証明書を再選択してください。
考えられる原因
証明書は Alibaba Cloud Certificate Management Service (Original SSL Certificate) 経由で購入されておらず、Alibaba Cloud Certificate Management Service (Original SSL Certificate) にアップロードされていません。
CLB インスタンスの HTTPS ポートリスナーの証明書が CLB コンソールを通じてアップロードされた。しかし、このアップロード方法では証明書情報がデジタル証明書管理サービス (旧 SSL 証明書管理) に自動的に同期されない。WAF はデジタル証明書管理サービスからのみ証明書情報を取得するため、「証明書が不完全です」というメッセージが表示される。
以前 Digital Certificate Management Service にアップロードされた証明書が手動で削除され、Certificate Management Service (Original SSL Certificate) にお客様の証明書が含まれなくなりました。
ソリューション
証明書を Certificate Management Service (Original SSL Certificate) にアップロードします。詳細については、「SSL 証明書をアップロードする」をご参照ください。
CLB コンソールで証明書を作成し、証明書ソースとして Alibaba Cloud 発行の証明書を選択します。手順については、「Alibaba Cloud SSL 証明書サービスの証明書を使用する」をご参照ください。
CLB コンソールで、アップロードされたサーバー証明書を選択します。手順については、「ステップ 2：SSL 証明書の設定」をご参照ください。
WAF のオリジン IP アドレスには、ECS インスタンスのパブリック IP とプライベート IP のどちらを使用すべきか
パブリック IP を使用してください。WAF はパブリックネットワーク経由でバックツーオリジンを実行し、プライベート IP アドレスはサポートしていません。
クラウド製品のオンボーディング中に複数の拡張証明書の追加が失敗する理由
考えられる原因の 1 つは、証明書の 1 つが無効であることです。複数の拡張証明書を追加する際は、選択した各証明書が有効であることを確認してください。期限切れの証明書は追加の失敗を引き起こします。
クラウド製品を WAF にオンボーディングした後も、保護対象を設定する必要があるか
デフォルトでは、クラウド製品が WAF にオンボーディングされると、WAF は自動的に保護対象を生成し、追加の設定は不要です。ただし、複数のドメインが同じクラウド製品インスタンスに解決され、各ドメインに個別の保護ルールを設定したい場合は、各ドメインを保護対象として手動で追加する必要があります。詳細については、「保護対象の追加」をご参照ください。
保護対象を追加した後、保護ルールを設定する際に対応するドメインを有効なオブジェクトとして選択することで、複数のドメインに対する詳細な保護を実現できます。
CNAME オンボーディング中に、HTTP バックツーオリジンを設定した後に ERR_TOO_MANY_REDIRECTS が表示される理由
HTTP バックツーオリジンとは、WAF が HTTP プロトコルを使用してバックツーオリジンリクエストをオリジンサーバーに転送することを意味し、デフォルトのバックツーオリジンポートは 80 です。この機能を有効にすると、クライアントが WAF にポート 80 または 443 のどちらでアクセスしても、WAF はデフォルトで HTTP プロトコルとポート 80 を使用してバックツーオリジンを行います。オリジンサーバーのポート 80 に実際のビジネスがない場合、この機能を有効にすると Web サイトへのアクセスに問題が発生します。
オリジンサーバーのポート 80 に実際のビジネスがなく、ポート 80 にリダイレクトが設定されている場合 (たとえば、301 ステータスコードを返してポート 443 にリダイレクトする場合)、クライアントのアクセスは継続的にリダイレクトされ、ERR_TOO_MANY_REDIRECTS が表示されます。
クラウド製品のオンボーディングで CLB インスタンスをオンボーディングする際に InvalidTLS エラーが発生する理由
クラウド製品のオンボーディングで CLB インスタンスをオンボーディングする際に、エラー Waf.Pullin.InvalidTLS (無効な TLS) が表示されることがあります。これは、CLB インスタンスがパフォーマンス共有型インスタンスである可能性が高いです。WAF はパフォーマンス共有型インスタンスの TLS 設定情報の取得をサポートしていません。クラウド製品のオンボーディングをサポートするには、インスタンスをパフォーマンス専有型インスタンスに変更する必要があります。詳細については、CLB インスタンスタイプ をご参照ください。
オリジンサーバーのパブリック IP が公開されている場合に、攻撃者が WAF をバイパスしてオリジンのパブリック IP を直接攻撃するのを防ぐ方法
方法 1：CNAME オンボーディングモードで、オリジンサーバーが WAF のバックツーオリジン IP 範囲からのトラフィックのみを受け入れるように設定し、WAF のみがオリジンサーバーと通信できるようにします。詳細については、「WAF のバックツーオリジン IP 範囲を許可する」をご参照ください。
方法 2：クラウド製品のオンボーディングを使用します。
WAF へのオンボーディング後の 502 エラーに関する複数のシナリオ
症状
WAF へのオンボーディング後、バックエンドサービスにアクセスすると 502 ステータスコードが返される、またはログに 502 ステータスコードを持つリクエストが表示される。
原因と解決策
シナリオ 1：CNAME オンボーディングモードでの 502 エラー
シナリオ 2：クラウド製品オンボーディングモードでのレイヤー 7 CLB での断続的な 5XX エラー
詳細な原因分析
WAF のバックツーオリジン接続アイドルタイムアウト：3,600 秒 (1 時間)
説明：CLB と WAF 間の接続で 1 時間データ転送がない場合、WAF は自動的に接続を閉じます。
CLB のクライアント向け接続アイドルタイムアウト：15 秒
説明：クライアント (この場合は WAF インスタンス) と CLB 間の接続で 15 秒間データ転送がない場合、CLB は自動的に接続を閉じます。
極端なケースでは、CLB 側で持続的接続が期限切れになる瞬間 (15 秒以上のデータ転送がない)、WAF はその接続を再利用して新しいバックツーオリジンリクエストを CLB に送信します。CLB はもはや接続状態を持っていないため、 RST パケットを送信してリクエストを終了します。これにより、WAF 側で 502 ステータスコードのログが記録されます。
ソリューション
レイヤー 7 CLB のクラウド製品オンボーディング設定でアイドル持続的接続タイムアウトを、CLB のクライアント向け接続アイドルタイムアウトよりも小さい値 (たとえば 14 秒) に調整します。
シナリオ 3：URI が長すぎることによる断続的な 502 エラー
シナリオ 4：WAF が複数のレイヤー 4 CLB にバックツーオリジンリクエストを送信する際の断続的な 502 エラー
現在のネットワークアーキテクチャ
現在のアーキテクチャでは、WAF はリバースプロキシモードでオンボーディングされ、複数のレイヤー 4 CLB インスタンスにバックツーオリジンします。バックエンドの RealServer (RS) は同じポートでリッスンし、複数のレイヤー 4 CLB インスタンスの背後にマウントされています。
詳細な原因分析
ECS インスタンスが、同じバックエンドサービスポートで設定された複数のレイヤー 4 (TCP プロトコル) CLB インスタンスのバックエンドサーバーとして機能する場合、次の問題が発生する可能性があります：同じ WAF ノードからのリクエストが、同じ WAF インスタンスノードの IP アドレスを使用して同時に CLB インスタンスにバックツーオリジンされると、一部の接続が失敗またはタイムアウトする可能性があります。
ケース 1：5 タプル競合、TCP ストリーム衝突
WAF が複数の CLB ノードを保護する場合、それらのノードからのリクエストは同じ WAF バックツーオリジン IP アドレスから発信されることがあります。
WAF ノードが CLB1 にバックツーオリジンリクエストを送信すると、接続 (WIP:CPORT->VIP1:VPORT1) はバックエンド ECS に到達すると (WIP:CPORT->DIP:DPORT) に変換されます。
WAF ノードが CLB2 にバックツーオリジンリクエストを送信すると、接続 (WIP:CPORT->VIP2:VPORT2) もバックエンド ECS に到達すると (WIP:CPORT->DIP:DPORT) に変換されます。
2 つの TCP 接続のシーケンス番号と状態がバックエンドサーバーで競合するため、接続の確立に失敗します。具体的には、開始された両方の TCP 接続は、バックエンドサーバー上で同じ 5 タプル (TCP:WIP:CPORT:DIP:DPORT) を持つと見なされます。この 5 タプル競合により、SYN パケットがドロップされる可能性があります。
ケース 2：応答パケットのルーティングエラー
完全なリクエストパスにおいて、リクエストを開始した CLB ノードと応答パケットを受信する CLB ノードが異なります。
WAF は CLB2 を介して SYN パケットをバックツーオリジンし、5 タプルは WIP:CPORT->VIP1:VPORT1 です。バックエンドの ECS2 に到達すると、WIP:CPORT->DIP:DPORT に変換されます。
この時点で ECS2 に TIME-WAIT 接続がある場合、5 タプルは TCP:WIP:CPORT:DIP:DPORT です。ステップ 1 の SYN パケットを受信すると、ECS2 は SYN が有効であると判断し、SYN-ACK パケットで応答します。
ECS2 は複数の SLB インスタンスの背後にマウントされているため、SYN-ACK パケットを CLB1 に送り返す可能性があります。CLB1 がこの 5 タプルのセッションを持っていない場合、CLB1 は双方向のリセットパケットを送信し、WAF は 502 を返します。
ソリューション
ソリューション 1 (推奨)
ネットワークアーキテクチャを変更し、たとえば、複数のレイヤー 7 CLB インスタンスをオリジンサーバーとして使用して、複数の異なるレイヤー 4 CLB ロードバランサーノードが同じバックエンドサービスの同じポートにリクエストを転送するのを避けます。
ソリューション 2
CLB から NLB に移行し、NLB 設定で クライアント IP アフィニティを無効にして 5 タプル競合を解決します。バックエンドサービスに Proxy Protocol をデプロイして、実際のクライアント IP を取得します。詳細については、「Proxy Protocol の使用」をご参照ください。
手順
Network Load Balancer (NLB) コンソールにログインします。トップナビゲーションバーで、NLB インスタンスがデプロイされているリージョンを選択します。
左側のナビゲーションウィンドウで、を選択します。
サーバーグループを選択し、[操作] 列で [基本情報の変更] をクリックします。[基本情報の変更] ダイアログボックスで、[クライアント IP の保持] を無効にし、変更を保存します。
ソリューション 3 (非推奨)
チケットを起票して、FULLNAT モードを有効にすることができます。複数の CLB インスタンスが同じバックエンドサーバーの同じポートにリクエストを転送する場合、FullNAT はソースアドレスを変更し、各接続の 5 タプルを一意にして競合を回避します。CLB リスナーで FULLNAT モードを有効にして、5 タプル競合を回避します。
シナリオ 5：Linux カーネルパラメータの問題によりリクエストが 502 を返す
WAF へのオンボーディング後にファイルアップロードが失敗する
これは、ファイルアップロードが 2 GB の最大制限を超えたために発生する可能性があります。WAF は現在、最大 2 GB のファイルアップロードをサポートしています。リクエストボディが 2 GB を超えると、WAF は 413 ステータスコードを返します。返されたステータスコードを使用して、ファイル転送サイズ制限に達したかどうかを判断できます。
有効期限が近づいている証明書を更新する方法
更新方法は、オンボーディングモードによって異なります：
CNAME オンボーディングの場合、「ドメイン証明書の更新」をご参照ください。
ECS インスタンスを使用したクラウド製品のオンボーディングの場合、「ECS トラフィックリダイレクションポートにバインドされた証明書の更新」をご参照ください。
CLB インスタンスを使用したクラウド製品のオンボーディングの場合、「CLB トラフィックリダイレクションポートにバインドされた証明書の更新」をご参照ください。
NLB インスタンスを使用したクラウド製品のオンボーディングの場合、「NLB トラフィックリダイレクションポートにバインドされた証明書の更新」をご参照ください。
ALB インスタンスを使用したクラウド製品のオンボーディングの場合、WAF コンソールでの更新は不要です。デジタル証明書管理サービス (旧 SSL 証明書) コンソールから ALB インスタンスに証明書をデプロイするだけです。手順については、「証明書のデプロイ方法の選択」をご参照ください。
クラウド製品のオンボーディング後、オリジンサーバーはクライアントの実際の IP を取得できるか
はい。WAF はクライアントの実際の IP をクラウド製品インスタンスに直接提供します。
WAF にオンボーディングされたドメインをスキャンすると脆弱な暗号スイートが報告される場合に、セキュリティ要件を満たすために TLS プロトコルバージョンと暗号スイートを設定する方法
WAF にオンボーディングされた HTTPS Web サイトがセキュリティおよびコンプライアンス要件を満たすようにするため、高バージョンの TLS プロトコルと強力な暗号スイートを設定することを推奨します。
高セキュリティの TLS プロトコルと暗号スイートは、クライアントの互換性を低下させる可能性があります。設定後、古いクライアント (Internet Explorer など) を使用しているユーザーは Web サイトにアクセスできなくなる場合があります。有効にする前に、クライアントの互換性を十分に評価してください。
ステップ 1：設定場所の特定
TLS プロトコルバージョンと暗号スイートの設定エントリは、WAF のオンボーディングモードによって異なります。
CNAME オンボーディング
CNAME オンボーディングモードでは、設定場所はスキャン対象によって異なります。特定のスキャン対象に基づいて、対応する場所で設定してください。
オンボーディングされたドメインのスキャン：CNAME アクセス タブで、ターゲットドメインを見つけ、[操作] 列の 編集 をクリックします。Edit Domain Name ページで、プロトコルタイプ > [HTTPS] セクションで、詳細設定 を展開し、TLS バージョン と [HTTPS] 暗号スイート を見つけます。
WAF VIP のスキャン：CNAME アクセス タブで、右側の デフォルトの SSL/TLS 設定 をクリックし、デフォルトの証明書をアップロードして、TLS バージョン と [HTTPS] 暗号スイート を設定します。
クラウド製品のオンボーディング
クラウド製品のオンボーディングモードでは、ECS インスタンス、レイヤー 4 CLB インスタンス (リスニングプロトコルは TCP)、および NLB インスタンスの場合、WAF 側で設定します。他のクラウド製品のオンボーディングシナリオでは、設定はそれぞれの製品コンソールで完了する必要があります。
レイヤー 7 CLB インスタンスをクラウド製品のオンボーディングでオンボーディングする場合、カスタム暗号スイートはサポートされていません。システムが提供する TLS セキュリティポリシーのみを選択できます。
ALB インスタンスをクラウド製品のオンボーディングでオンボーディングする場合、暗号スイートをカスタマイズする必要がある場合は、手動で TLS セキュリティポリシーを作成する必要があります。詳細については、「TLS セキュリティポリシー」をご参照ください。
ECS、レイヤー 4 CLB (リスニングプロトコルは TCP)、NLB：クラウドプロダクトアクセス タブで、ターゲットインスタンスを見つけ、
アイコンをクリックし、ターゲットポートを選択し、[操作] 列の 操作 をクリックし、証明書の編集 を選択します。TLS バージョン と 暗号スイート の場所で設定します。ALB：ALB コンソールで、ターゲットインスタンスを見つけた後、リスナー タブに移動し、ターゲットリスナーを見つけて、TLS セキュリティポリシー を設定します。
レイヤー 7 CLB (リスニングプロトコルは HTTPS)：CLB コンソールで、ターゲットインスタンスを見つけた後、リスナー タブに移動し、ターゲットリスナーを見つけ、証明書の管理 をクリックし、表示されるダイアログボックスで TLS セキュリティポリシー を設定します。
FC、MSE、APIG、SAE：対応する製品コンソールで設定します。
ステップ 2：TLS プロトコルバージョンの選択
古い TLS プロトコルバージョンによるセキュリティリスクを避けるため、TLS 1.2 以降を選択することを推奨します。Web サイトが TLS 1.3 をサポートしている場合は、TLS 1.3 以上対応 を選択します。
TLS 1.3 のサポートを有効化します。 を選択すると、WAF は次の 3 つのデフォルト TLS 1.3 暗号スイートを提供します：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、および TLS_CHACHA20_POLY1305_SHA256。これらの暗号スイートはカスタマイズできません。
ステップ 3：暗号スイートの選択
脆弱な暗号スイートによるセキュリティリスクを避けるため、次のリストから強力な暗号スイートを選択することを推奨します。
強力な暗号スイート | 脆弱な暗号スイート |
|
|
暗号スイートのセキュリティに関する推奨事項：ECDHE-RSA-AES128-SHA256 および ECDHE-RSA-AES256-SHA384 暗号スイートは、キー交換に ECDHE、認証に RSA、暗号化モードに AES-CBC を使用します。AES-GCM などの認証暗号化モードを使用する暗号スイートと比較して、これらのスイートはセキュリティとパフォーマンスが低くなります。一部のセキュリティスキャンツールは、これらを脆弱な暗号スイートとして識別する場合があります。この場合、カスタム暗号スイートを選択し、これら 2 つのスイートを手動で除外してください。
暗号スイートの命名規則：暗号スイートの命名規則は異なるため、WAF は OpenSSL 形式で暗号スイートを表示しますが、一部のスキャンツールは IANA 標準を使用する場合があります。たとえば、OpenSSL の ECDHE-ECDSA-AES256-SHA384 は、IANA の TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 に対応します。マッピングをすばやく調べるには、ciphersuite.info にアクセスするか、他の TLS 検索ツールを使用してください。
オンボーディング後のログで upstream_addr フィールドが「-」と表示される理由
ログの upstream_addr フィールドが - と表示される場合、WAF がオリジンサーバーにバックツーオリジンリクエストを送信しなかったことを意味します。たとえば、リクエストが WAF によってブロックされた場合などです。詳細な分析のために、upstream_status や upstream_response_time などの他のフィールドを確認することを推奨します。
クラウドネイティブモードで WAF によってブロックされたリクエストが ALB ログに記録される理由
クラウドネイティブモードでは、WAF 3.0 は組み込み SDK を使用して、セキュリティ検出機能を Application Load Balancer (ALB) のデータプレーンに直接統合します。リクエストが ALB インスタンスに到達し、データ処理フローに入ると、ALB はアクセスログを生成します。その後 WAF がリクエストをブロックすると、クライアントにブロックページを返し、リクエストはバックエンドサーバーに転送されません。アクセスログの記録は、WAF がリクエストをブロックする前に生成されるため、取り消されません。
クラウドネイティブモードでは、SSL 証明書を WAF とソース ECS インスタンスの両方に設定する必要があるか
はい。クラウドネイティブモードでは、WAF とソース ECS インスタンスの両方に有効な SSL 証明書が必要です。このモードは、WAF のみに証明書がある設定をサポートしていません。SSL を WAF にオフロードし、WAF が HTTP 経由でソースサーバーと通信できるようにするには、CNAME モードを使用する必要があります。