ネットワーク セキュリティに関する問題のトラブルシューティング
Web Application Firewall (WAF) が必要なトラフィックをブロックしている理由を特定する
Web Application Firewall (WAF) を通過する必要がある要求がブロックされている場合があります。
アプリケーションまたは組織のニーズに合わせて厳密な Open Web Application Security Project (OWASP) 規制を調整する場合、ルールをカスタマイズまたは無効にしたり、問題や誤検知を引き起こしている可能性のある除外を作成したりするのに WAF が役立ちます。 これはサイトごとおよび URI ごとに行われます。 つまり、ポリシーの変更は特定のサイトや URI にのみ影響し、同じ問題がない可能性がある他のサイトには関係ありません。
以下の記事は、WAF の機能およびそのルールとログのしくみを理解するのに役立ちます。
WAF ログの理解
WAF ログは、一致する、またはブロックされたすべての評価済みの要求のステートメントとして機能します。 誤検知に気付き、WAF がブロックすべきではない要求をブロックしている場合は、次の手順を行うことができます。
特定の要求を見つけます。
ログを調べて、要求の特定の URI、タイムスタンプ、またはトランザクション ID を見つけます。
誤検知を修正します。
WAF ログの表示
WAF ログを表示するには、次の手順を行います。
Azure portal で、[すべてのリソース] を選択し、[Application Gateway WAF ポリシー] を選びます。
[アクティビティ ログ] を選択します。
個々の操作を選択して詳細を確認します。
アクティビティ ログは、[CSV としてダウンロードする] を選択してダウンロードすることができます。
アクティビティ ログ イベントを別のサービスにストリーミングするには、[アクティビティ ログのエクスポート] を選択します。
[アクティビティ ログのエクスポート] で、次のようにします。
[診断設定の追加] を選択します。
[診断設定の名前] を入力します。
[カテゴリ] でストリーミングする関連するログ カテゴリを選択します。 たとえば、[セキュリティ]、[ポリシー]、および [アラート] を選択します。
[宛先の詳細] でストリーミング先を選択します。 たとえば、[Log Analytics ワークスペースに送信する] を選択します。
追加の宛先の詳細を入力します。 たとえば、関連する [サブスクリプション] と [Log Analytics ワークスペース] です。
[保存] を選択します。
異常スコアリング モード
異常スコアリング モードは、トラフィックをブロックするかどうかを決定するために OWASP によって使用されます。 異常スコアリング モードでは、ファイアウォールが防止モードの場合、いずれかのルールに一致するトラフィックがすぐにブロックされることはありません。 ルールには特定の条件 (重大、エラー、警告、通知) があります。 これらのそれぞれに、異常スコアという数値が関連付けられています。 数値は要求の重大度を示します。
詳細については、異常スコアリング モードに関するページをご覧ください。
誤検出の修正
誤検知を修正し、ブロックされたトラフィックの問題を回避するために、除外リストを使用できます。 除外リストの使用は、要求の特定の部分、または無効になっているルール セットにのみ適用されます。 要求全体を除外するのではなく、特定の条件に対して本文、ヘッダー、または Cookie を除外することを決定できます。 グローバル設定環境では、WAF を通過するすべてのトラフィックに特定の除外が適用されます。
除外リストの詳細については、WAF 構成に関するページを参照してください。
Azure portal を使用して除外リストを構成するには
WAF ポータルに移動します。
[マネージド ルール] で [除外の管理] を選択します。
除外リストの例:
- ルールを無効にする: ルールを無効にすると、特定の条件を非脅威として扱うことができます。それ以外の場合は悪意のあるものとしてフラグが設定され、ブロックされます。 グローバル設定環境では、WAF 全体のルールを無効にすることは危険であり、セキュリティが低下する可能性があります。
ルール グループまたは特定のルールを無効にするには
アプリケーション ゲートウェイに移動し、[Web アプリケーション ファイアウォール] を選択します。
お使いの WAF ポリシーを選択します。
[管理されているルール] を選択します。
無効にするルールまたはルール グループを検索します。
無効にするルールのチェック ボックスをオンにします。
ページの上部で、選択したルールについてのアクション ([有効/無効]) を選択します。
[保存] を選択します。
Fiddler というサードパーティ製のツールで追加情報を提供できます。 Fiddler は次の場合に役立ちます。
要求属性名を見つける: 個々の要求を確認し、Web ページの特定のフィールドの呼び名を確かめます。 これは、除外リストを使用して検査から特定のフィールドを除外するのにも役立ちます。
要求ヘッダー名を見つける: Chrome の開発者ツール内で要求および応答ヘッダーを表示するか、GET 要求のヘッダーを確認します。
要求 Cookie 名を見つける: Fiddler の [Cookie] タブを選択して、Cookie を表示します。
グローバル パラメーターを制限して誤検出を排除する
要求本文の検査を無効にする: アプリケーションに対する脅威ではない特定の本文は、[要求本文の検査] をオフに設定することで、WAF によって評価されないようにすることができます。 このようにすると、要求本文のみが検査されません。 ヘッダーと Cookie は、除外リストに含まれている場合を除き、引き続き検査されます。
ファイル サイズの制限: WAF のファイル サイズを制限することで、Web サーバーとアプリケーションへの攻撃の可能性を減らすことができます。 大きなファイルを許可すると、バックエンドが枯渇するリスクが高くなります。 攻撃を防ぐために、ファイル サイズをアプリケーションの一般的なケースに制限することをお勧めします。
Note
ファイアウォール メトリック (WAF_v1 のみ) v1 Web Application Firewall の場合、ポータルで次のメトリックを使用できるようになりました。
- Web Application Firewall のブロックされた要求数 - ブロックされた要求の数。
- Web Application Firewall のブロックされたルール数 - 一致しており、要求がブロックされたすべてのルール。
- Web Application Firewall のルール配布の合計 - 評価中に一致したすべてのルール
メトリックを有効にするには、ポータルの [メトリック] タブを選択し、3 つのメトリックのいずれかを選択します。
顧客が実行している TLS のバージョンを確認する
クライアントが必要な最小バージョンより前のバージョンのトランスポート層セキュリティ (TLS) を使用している場合、Azure Storage への呼び出しはすべて失敗します。 そのため、セキュリティの観点から、Azure Storage アカウントでは、クライアントが要求を送信するために最小バージョンの TLS を使用することが求められる場合があります。 たとえば、ストレージ アカウントに TLS 1.2 が必要な場合、TLS 1.1 を使用しているクライアントから送信された要求は失敗します。
ストレージ アカウントに必要な最小バージョンのトランスポート層セキュリティ (TLS) の構成に関する記事では、クライアント アプリケーションに影響する可能性がある Azure Storage アカウントの最小 TLS バージョンを構成する方法について説明しています。
クライアント TLS バージョンを構成する
クライアントの場合、特定のバージョンの TLS で要求を送信できるのは、オペレーティング システムとクライアントによって使用される .NET Framework でそのバージョンがサポートされている場合のみです。
PowerShell クライアントで TLS 1.2 を有効にするには:
# Set the TLS version used by the PowerShell client to TLS 1.2.
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
# Create a new container.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
New-AzStorageContainer -Name "sample-container" -Context $ctx
Azure Storage クライアント ライブラリのバージョン 12 を使用して、.NET クライアントで TLS 1.2 を有効にするには:
public static async Task ConfigureTls12()
{
// Enable TLS 1.2 before connecting to Azure Storage
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
// Add your connection string here.
string connectionString = "";
// Create a new container with Shared Key authorization.
BlobContainerClient containerClient = new BlobContainerClient(connectionString, "sample-container");
await containerClient.CreateIfNotExistsAsync();
}
Azure Storage クライアント ライブラリのバージョン 11 を使用して、.NET クライアントで TLS 1.2 を有効にするには:
static void EnableTls12()
{
// Enable TLS 1.2 before connecting to Azure Storage
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
// Add your connection string here.
string connectionString = "";
// Connect to Azure Storage and create a new container.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("sample-container");
container.CreateIfNotExists();
}
詳細については、「TLS 1.2 のサポート」を参照してください。
Note
指定されたバージョンの TLS がクライアントによって要求の送信に使用されたことを確認する際に、Fiddler または同様のツールが役立つ場合があります。
ポイント対サイト シナリオの暗号化または証明書関連の問題をトラブルシューティングする
ポイント対サイト (P2S) VPN 接続は単一のエンドポイントによって開始され、リモートの場所から VNet に接続する場合に便利です。 ポイント対サイトは、VNet に接続する必要があるクライアントがごく少数である場合により適切な選択肢です。 P2S 接続に VPN デバイス、パブリック ネットワーク、公開 IP アドレスは必要ありません。
P2S VPN では、Secure Socket Tunneling Protocol (SSTP)、および IKEv2 がサポートされています。 ポイント対サイト接続を使用して、Windows、Linux、または macOS を実行しているさまざまなクライアントを Azure VNet に安全に接続できます。
証明書の生成
ルート証明書を生成する
まず、ルート証明書の公開キー (.cer ファイル) を取得します。 ルート証明書を作成した後、(秘密キーではなく) 公開証明書をエクスポートします。 その後、このファイルが Azure にアップロードされます。 ルート証明書は、P2S 経由で仮想ネットワークに接続するための Azure によって信頼されたソースとして機能します。 ルート証明書、エンタープライズ証明書、または自己署名証明書を生成するには、2 つの方法があります。 自己署名ルート証明書を作成するには、次の手順を検討します。
Windows PowerShell コンソールを開きます。
次の例では、"P2SRootCert" という名前の自己署名ルート証明書が作成され、"Certificates-Current User\Personal\Certificates" に自動的にインストールされます。 certmgr.msc、またはユーザー証明書の管理を開くと、証明書を表示できます。
次のコマンドを変更して実行することができます。
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature ` -Subject "CN=P2SRootCert" -KeyExportPolicy Exportable ` -HashAlgorithm sha256 -KeyLength 2048 ` -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSignPowerShell コンソールを開いたままにして、次の手順に進み、クライアント証明書を生成します。
クライアント証明書を生成する
クライアント証明書は、それが自己署名ルート証明書から生成されるコンピューターに自動的にインストールされます。 クライアント証明書を別のクライアント コンピューターにインストールする場合は、それを .pfx ファイルとして、証明書チェーン全体と共にエクスポートする必要があります。 .pfx ファイルには、クライアント認証に必要なルート証明書情報が含まれます。 クライアント証明書、エンタープライズ証明書、または自己署名ルート証明書を作成するには、2 つの方法があります。
同じ証明書を使用するのではなく、クライアントごとに一意の証明書を生成することをお勧めします。 これは、特定のクライアント証明書を失効させる場合、同じ証明書を使用するすべてのクライアントに対して新しい証明書を生成してインストールする必要がないためです。 クライアント証明書を生成するには、次の手順を検討します。
PowerShell コンソール セッションがまだ開いている場合は、次の例を使用します。
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature ` -Subject "CN=P2SChildCert" -KeyExportPolicy Exportable ` -HashAlgorithm sha256 -KeyLength 2048 ` -CertStoreLocation "Cert:\CurrentUser\My" ` -Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")新しい PowerShell コンソール セッションの場合は、次の手順を検討します。
- コンピューターにインストールされている自己署名ルート証明書を特定します。 次のコマンドレットは、コンピューターにインストールされている証明書の一覧を返します。
Get-ChildItem -Path "Cert:\CurrentUser\My"返された一覧でサブジェクト名を探し、その横にある拇印をテキスト ファイルにコピーします。 この場合は "P2SRootCert" です。
Thumbprint Subject ---------- ------- 7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655 CN=P2SRootCert前の手順の拇印を使用して、ルート証明書の変数を宣言します。
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\<THUMBPRINT>"THUMBPRINT を、子証明書の生成元となるルート証明書の拇印に置き換えます。
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655"この例では、"P2SChildCert" という名前のクライアント証明書が生成されます。 生成したクライアント証明書は、コンピューターの "Certificates - Current User\Personal\Certificates" に自動的にインストールされます。
次のコマンドを変更して実行し、クライアント証明書を生成することができます。
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `
-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
ルート証明書とクライアント証明書のエクスポートについては、「ユーザー VPN 接続の証明書を生成してエクスポートする」を参照してください。
Azure 証明書を使用してポイント対サイト接続を構成するには、次のようにする必要があります。
VPN クライアント アドレス プールを追加します。
トンネルの種類と認証の種類を指定します。
ルート証明書の公開キー情報をアップロードします。
エクスポートされたクライアント証明書をインストールします。
VPN クライアントの設定を構成します。
Azure に接続します。
Azure 証明書を使用してポイント対サイト接続を構成する詳細な手順については、「P2S VPN と証明書による認証を使用した VNet への接続: ポータル - Azure VPN Gateway」を参照してください。
VPN 接続がアクティブであることを確認するには (Windows クライアント)、管理者特権でのコマンド プロンプトを開いて、ipconfig/all を実行します。
仮想マシンに接続するには (Windows クライアント):
プライベート IP アドレスを特定します。
VNet に接続されていることを確認します。
タスク バーの検索ボックスに「RDP」または「リモート デスクトップ接続」と入力してリモート デスクトップ接続を開き、[リモート デスクトップ接続] を選択します。 PowerShell で "mstsc" コマンドを使用して、リモート デスクトップ接続を開くこともできます。
リモート デスクトップ接続で、VM のプライベート IP アドレスを入力します。 [オプションの表示] を選択し、追加の設定を調整してから接続します。
接続のトラブルシューティングを行う
VPN 接続を使って仮想マシンに接続する際に問題が発生した場合は、以下をお読みください。
VPN 接続が成功したことを確認します。
VM のプライベート IP アドレスに接続していることを確かめます。
プライベート IP アドレスを使って VM に接続できるものの、コンピューター名では接続できない場合には、DNS 構成を確認します。
詳細については、VM に対するリモート デスクトップ接続のトラブルシューティングに関するページを参照してください。
VNet に対して DNS サーバーの IP アドレスが指定された後に VPN クライアント構成パッケージが生成されたことを確認します。 DNS サーバーの IP アドレスを更新した場合は、新しい VPN クライアント構成パッケージを生成してインストールしてください。
重複するアドレス空間がないことを確かめます。 たとえば、IP アドレスが、接続先の VNet のアドレス範囲内、または VPNClientAddressPool のアドレス範囲内にある場合は、 "ipconfig" を使用して、接続元のコンピューターのイーサネット アダプターに割り当てられている IPv4 アドレスを確認します。
信頼されたルート証明書を追加する場合は、信頼されたルート証明書のアップロードに関するページを参照してください。
信頼されたルート証明書を削除するには
仮想ネットワーク ゲートウェイの [ポイント対サイトの構成] ページに移動します。
そのページの [ルート証明書] セクションで、削除する証明書を見つけます。
証明書の横にある省略記号を選んでから、 [削除] を選択します。
クライアント証明書の失効
クライアント証明書の失効は、信頼されたルート証明書の削除とは異なります。 信頼されたルート証明書 .cer ファイルを Azure から削除すると、ルート証明書によって生成または認証されたすべてのクライアント証明書が失効します。 クライアント証明書を失効させる場合、同じルート証明書に関連付けられている他の証明書は引き続き動作します。
クライアント証明書を失効させるには、失効リストにサムプリントを追加します。
クライアント証明書の拇印を取得します。 「方法: 証明書のサムプリントを取得する」を参照してください。
情報をテキスト エディターにコピーし、文字列が 1 つにつながるようにスペースをすべて削除します。
仮想ネットワーク ゲートウェイの [ポイント対サイトの構成] ページに移動します。 このページは、信頼されたルート証明書のアップロードに使用したものです。
[失効した証明書] セクションで、証明書のフレンドリ名を入力します。
拇印の文字列をコピーして [拇印] フィールドに貼り付けます。
拇印が検証され、自動的に失効リストに追加されます。 リストが更新されていることを示すメッセージが画面に表示されます。
更新が完了した後は、証明書を接続に使用することができなくなります。 この証明書を使用して接続を試みたクライアントには、証明書が無効になっていることを示すメッセージが表示されます。
セキュリティで保護されたエンドポイントへの接続のトラブルシューティングを行う
Azure プライベート エンドポイントは、仮想ネットワークのプライベート IP アドレスを使用し、プライベートで安全にプライベート リンク サービスに接続するネットワーク インターフェイスです。
プライベート エンドポイントで使用できる接続シナリオを以下に示します。
同じリージョンの仮想ネットワーク。
リージョンでピアリングされた仮想ネットワーク。
グローバルにピアリングされた仮想ネットワーク。
VPN または Azure ExpressRoute 回線を介したオンプレミスのお客様。
接続に関する問題を診断する
次の手順に従って、プライベート エンドポイントのセットアップに関する接続の問題を解決するために必要なすべての構成が整っていることを確かめます。 詳細な手順については、「接続に関する問題を診断する」を参照してください。
リソースを参照して、プライベート エンドポイントの構成を確認します。
Azure Monitor を使用して、データが流れているかどうか確認します。
Azure Network Watcher の VM の接続のトラブルシューティングを使用します。
テスト結果の DNS 解決には、プライベート エンドポイントに割り当てられているものと同じプライベート IP アドレスが含まれている必要があります。
ソース仮想マシンでは、NIC の [有効なルート] でプライベート エンドポイント IP のネクスト ホップへのルートが InterfaceEndpoints として設定されている必要があります。
接続の結果が正しいと確認された場合、接続の問題は、アプリケーション層でのシークレット、トークン、パスワードなどの他の側面に関連している可能性があります。
サポート チケットを提出する前に絞り込みます。
プライベート エンドポイントが、ロード バランサーにリンクされている Private Link サービスにリンクされている場合は、バックエンド プールが正常と報告されるかどうかを確認します。 ロード バランサーの正常性を修正すると、プライベート エンドポイントへの接続に関する問題が解決します。
問題が解決せず、接続の問題がまだ存在する場合は、Azure サポート チームにお問い合わせください。
サイト間シナリオの暗号化または証明書関連の問題をトラブルシューティングする
VPN ゲートウェイ用の IPsec/IKE ポリシーのパラメーター
IPsec/IKE 標準プロトコルでは、幅広い暗号アルゴリズムがさまざまな組み合わせでサポートされています。 コンプライアンスまたはセキュリティ要件を満たすために Azure Stack Hub でサポートされているパラメーターについては、「IPsec/IKE パラメーター」の記事で説明されています。
ポリシーを使用する際は、次の重要な考慮事項に注意してください。
IPsec/IKE ポリシーは、Standard および HighPerformance (ルートベース) ゲートウェイ SKU でのみ機能します。
ある特定の接続に対して指定できるポリシーの組み合わせは 1 つだけです。
IKE (メイン モード) と IPsec (クイック モード) の両方について、すべてのアルゴリズムとパラメーターを指定する必要があります。 ポリシーを部分的に指定することはできません。
オンプレミスの VPN デバイスでポリシーがサポートされるかどうかを、VPN デバイス ベンダーの仕様で確認します。
以下の手順は、IPsec/IKE ポリシーを作成して構成し、それを新規または既存の接続に適用する方法を示しています。 詳細な手順については、Azure Stack Hub でサイト間 (S2S) 接続用の IPsec/IKE ポリシーを構成する手順に関するページを参照してください。
IPsec/IKE ポリシーを作成して設定します。
IPsec/IKE ポリシーを使用する新しいサイト間 VPN 接続を作成します。
手順 1 - 仮想ネットワーク、VPN ゲートウェイ、およびローカル ネットワーク ゲートウェイを作成する。
手順 2 - IPsec/IKE ポリシーを使用するサイト間 VPN 接続を作成する。
接続用の IPsec/IKE ポリシーを更新します。