ネットワーク セキュリティに関する問題のトラブルシューティング
Web アプリケーション ファイアウォール (WAF) が必要なトラフィックをブロックしている理由を特定する
Web アプリケーション ファイアウォール (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 ポリシーを選びます。
[マネージド ルール] を選びます。
無効にするルールまたはルール グループを検索します。
無効にするルールのチェック ボックスをオンにします。
選択したルールのページの上部にあるアクション (有効/Disable) を選択します。
保存 を選択します。
Fiddler と呼ばれるサード パーティ製ツールは、追加情報を提供できます。 Fiddler は次の支援を行います。
要求属性名の検索: 個々の要求を確認し、Web ページの特定のフィールドが呼び出されるかどうかを判断します。 また、除外リストを使用して検査から特定のフィールドを除外するのにも役立ちます。
要求ヘッダー名の検索: Chrome の開発者ツール内で要求ヘッダーと応答ヘッダーを表示するか、GET 要求のヘッダーを表示します。
要求 Cookie 名の検索: Fiddler の [Cookie] タブを選択して Cookie を表示します。
グローバル パラメーターを制限して誤検知をなくす
要求本文の検査を無効にする: アプリケーションに対する脅威ではない特定の本体は、[ Inspect request body ]\(要求本文の検査\) をオフに設定することで、WAF によって評価されないようにすることができます。 この方法では、要求本文のみが検査されません。 ヘッダーと Cookie は、除外リストに含まれている場合を除き、引き続き検査されます。
ファイル サイズの制限: WAF のファイル サイズを制限することで、Web サーバーとアプリケーションへの攻撃の可能性を減らすことができます。 大きなファイルを許可すると、バックエンドが使い果たされるリスクが高くなります。 攻撃を防ぐには、アプリケーションの一般的なケースにファイル サイズを制限することをお勧めします。
注
ファイアウォール メトリック (WAF_v1のみ) v1 Web アプリケーション ファイアウォールの場合、ポータルで次のメトリックを使用できるようになりました。
- Web アプリケーション ファイアウォールのブロックされた要求数 - ブロックされた要求の数。
- Web アプリケーション ファイアウォールのブロックされた規則の数 - 一致し、要求がブロックされたすべてのルール。
- Web アプリケーション ファイアウォールの規則の分布の合計 - 評価中に一致したすべてのルール
メトリックを有効にするには、ポータルで [メトリック] タブを選んで、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 のサポートを参照してください。
注
Fiddler または同様のツールは、指定したバージョンの TLS がクライアントによって要求の送信に使用されたことを確認するのに役立ちます。
ポイント対サイト シナリオの暗号化/証明書関連の問題のトラブルシューティング
ポイント対サイト (P2S) VPN 接続は 1 つのエンドポイントによって開始され、リモートの場所から 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 コンソールを開きます。
次の例では、"Certificates-Current User\Personal\Certificates" に自動的にインストールされる "P2SRootCert" という名前の自己署名ルート証明書を作成します。 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" という名前のクライアント証明書が生成されます。 生成したクライアント証明書は、コンピューターの "証明書 - 現在のユーザー\個人用\証明書" に自動的にインストールされます。
次のコマンドを変更して実行して、クライアント証明書を生成できます。
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 構成を確認します。
RDP 接続について詳しくは、VM へのリモート デスクトップ接続のトラブルシューティングに関する記事をご覧ください。
VNet に対して DNS サーバーの IP アドレスが指定された後で、VPN クライアント構成パッケージが生成されたことを確認します。 DNS サーバーの IP アドレスを更新した場合は、新しい VPN クライアント構成パッケージを生成してインストールしてください。
重複するアドレス空間がないことを確認します。 たとえば、IP アドレスが接続先の VNet のアドレス範囲内にある場合や、VPNClientAddressPool のアドレス範囲内にある場合です。 "ipconfig" を使用して、接続先のコンピューター上のイーサネット アダプターに割り当てられている IPv4 アドレスを確認します。
信頼されたルート証明書を追加するには、「 信頼されたルート証明書をアップロードする」を参照してください。
信頼されたルート証明書を削除するには:
仮想ネットワーク ゲートウェイのポイント対サイト構成ページに移動します。
ページのルート証明書セクションで、削除する証明書を見つけます。
証明書の横にある省略記号を選んで、[削除] を選びます。
クライアント証明書を取り消す
クライアント証明書の取り消しは、信頼されたルート証明書の削除とは異なります。 信頼されたルート証明書.cerファイルを Azure から削除すると、ルート証明書によって生成/認証されたすべてのクライアント証明書が取り消されます。 クライアント証明書を失効すると、同じルート証明書に関連付けられている他の証明書が引き続き動作できるようになります。
クライアント証明書を取り消すには、失効リストに拇印を追加します。
クライアント証明書の拇印を取得します。 証明書の拇印を取得する方法を参照してください。
情報をテキスト エディターにコピーし、連続する文字列になるようにすべてのスペースを削除します。
仮想ネットワーク ゲートウェイのポイント対サイト構成ページに移動します。 これは、信頼されたルート証明書のアップロードに使用したのと同じページです。
[ 失効した証明書 ] セクションで、証明書のフレンドリ名を入力します。
拇印の文字列をコピーして [拇印] フィールドに貼り付けます。
拇印が検証されて、失効リストに自動的に追加されます。 リストが更新されていることを示すメッセージが画面に表示されます。
更新が完了した後、その証明書は接続に使用できなくなります。 この証明書を使って接続を試みたクライアントには、証明書が有効ではなくなったことを示すメッセージが表示されます。
セキュリティで保護されたエンドポイントへの接続のトラブルシューティングを行う
Azure プライベート エンドポイントは、仮想ネットワークのプライベート IP アドレスを使用し、プライベートかつ安全にプライベート リンク サービスに接続するネットワーク インターフェイスです。
プライベート エンドポイントで使用できる接続シナリオを次に示します。
同じリージョンの仮想ネットワーク。
リージョン別にピアリングされた仮想ネットワーク。
グローバルにピアリングされた仮想ネットワーク。
VPN または Azure ExpressRoute 回線経由のオンプレミスのお客様。
接続に関する問題を診断する
次の手順では、プライベート エンドポイントのセットアップに関する接続の問題を解決するために、必要なすべての構成が確実に適用されるようにします。 詳細な手順については、 接続の問題の診断に関する記事を参照してください。
リソースを参照して、プライベート エンドポイントの構成を確認します。
Azure Monitor を使用して、データが流れているかどうかを確認します。
Azure Network Watcher からの VM 接続のトラブルシューティングを使用します。
テスト結果の DNS 解決のプライベート IP アドレスは、プライベート エンドポイントに割り当てられているものと同じになる必要があります。
ソース仮想マシンは、NIC の有効ルートでプライベート エンドポイント IP の次のホップを「InterfaceEndpoints」として指定する必要があります。
接続の結果が正しいことが確認された場合、接続の問題は、アプリケーション層でのシークレット、トークン、パスワードなどの他の側面に関連している可能性があります。
サポート チケットを提出する前に絞り込みます。
プライベート エンドポイントがロード バランサーにリンクされている Private Link サービスにリンクされている場合は、バックエンド プールが正常と報告されているかどうかを確認します。 ロード バランサーの正常性を修正すると、プライベート エンドポイントへの接続に関する問題が解決されます。
問題が解決されず、接続の問題がまだ存在する場合は、Azure サポート チームにお問い合わせください。
サイト間シナリオでの暗号化/証明書関連の問題のトラブルシューティング
VPN ゲートウェイの IPsec および IKE ポリシー パラメーター
IPsec および IKE プロトコル標準では、さまざまな組み合わせで幅広い暗号アルゴリズムがサポートされています。 記事 IPsec/IKE パラメーターでは、コンプライアンスまたはセキュリティの要件を満たすために Azure Stack Hub でサポートされるパラメーターについて説明します。
これらのポリシーを使用する場合は、次の重要な考慮事項に注意してください。
IPsec/IKE ポリシーは、Standard および HighPerformance (ルートベース) ゲートウェイ SKU でのみ機能します。
指定できるポリシーの組み合わせは、特定の接続に対して 1 つだけです。
IKE (メイン モード) と IPsec (クイック モード) の両方について、すべてのアルゴリズムとパラメーターを指定する必要があります。 部分的なポリシー指定は許可されていません。
オンプレミスの VPN デバイスでポリシーがサポートされているかどうかを、VPN デバイス ベンダーの仕様に確認してください。
次の手順では、IPsec/IKE ポリシーを作成して構成し、新規または既存の接続に適用する方法を示します。 詳細な手順については、Azure Stack Hub でサイト間 (S2S) VPN 接続の IPsec/IKE ポリシーを構成する手順に従います。
IPsec/IKE ポリシーを作成して設定します。
IPsec/IKE ポリシーを使用して新しいサイト間 VPN 接続を作成します。
手順 1 - 仮想ネットワーク、VPN ゲートウェイ、ローカル ネットワーク ゲートウェイを作成します。
手順 2 - IPsec/IKE ポリシーを使用してサイト間 VPN 接続を作成します。
接続の IPsec/IKE ポリシーを更新します。