概要
この記事は、Firepowerシステムのデータパスを体系的にトラブルシューティングし、Firepowerのコンポーネントがトラフィックに影響を与えているかどうかを判断する方法を説明する一連の記事の一部です。Firepowerプラットフォームのアーキテクチャに関する情報や、その他のデータパスのトラブルシューティングに関する記事へのリンクについては、概要記事を参照してください。
この記事では、Firepowerのデータパスのトラブルシューティングの6番目の段階であるアクティブ認証機能について説明します。
前提条件
- この記事は、現在サポートされているすべてのFirepowerプラットフォームに関連しています
- Firepowerデバイスがルーテッドモードで動作している必要があります
アクティブ認証フェーズのトラブルシューティング
問題がIDによって引き起こされているかどうかを判断する場合は、この機能が影響を与えるトラフィックを理解することが重要です。トラフィックの中断を引き起こす可能性があるアイデンティティ自体の唯一の機能は、アクティブ認証に関連するものです。パッシブ認証では、トラフィックが予期せずドロップされることはありません。アクティブ認証の影響を受けるのはHTTP(S)トラフィックだけであることを理解することが重要です。IDが動作していないために他のトラフィックが影響を受ける場合、これはポリシーがユーザ/グループを使用してトラフィックを許可/ブロックするため、ID機能がユーザを特定できない場合は予期せぬ事態が発生する可能性が高くなります。このセクションのトラブルシューティングでは、アクティブ認証のみに関連する問題を順に説明します。
リダイレクト方式の確認
アクティブな認証機能には、HTTPサーバを実行するFirepowerデバイスが含まれます。トラフィックがアクティブ認証アクションを含むアイデンティティポリシールールに一致すると、Firepowerは307(一時的なリダイレクト)パケットをセッションに送信し、クライアントをキャプティブポータルサーバにリダイレクトします。
現在、アクティブ認証には5種類あります。2つのリダイレクトは、センサーのホスト名と、レルムに関連付けられたActive Directoryプライマリドメインで構成されるホスト名に送信され、3つのリダイレクトは、キャプティブポータルリダイレクトを実行するFirepowerデバイスのインターフェイスのIPアドレスに送信されます。
リダイレクトプロセスで何らかの問題が発生した場合、サイトが使用できないため、セッションが中断する可能性があります。そのため、リダイレクションが実行コンフィギュレーションでどのように動作しているかを理解することが重要です。次の図は、この設定の側面を理解するのに役立ちます。
アクティブ認証がホスト名にリダイレクトしている場合、クライアントはciscoasa.my-ad.domain:<port_used_for_captive_portal>にリダイレクトされます
パケットキャプチャの生成
パケットキャプチャの収集は、アクティブな認証の問題のトラブルシューティングで最も重要な部分です。パケットキャプチャは、次の2つのインターフェイスで行われます。
- アイデンティティ/認証の実行時にトラフィックが入力されるFirepowerデバイスのインターフェイス
- 次の例では、内部インターフェイスが使用されます
- FirepowerがHTTPSサーバへのリダイレクションに使用する内部トンネルインターフェイス – tun1
- このインターフェイスは、トラフィックをキャプティブポータルにリダイレクトするために使用されます
- トラフィックのIPアドレスは、出力時に元のアドレスに戻されます
2つのキャプチャが開始され、対象トラフィックがFirepowerデバイスを介して実行され、キャプチャが停止されます。
内部インターフェイスのパケットキャプチャファイル「ins_ntlm」が/mnt/disk0ディレクトリにコピーされることに注目します。次に、デバイスからダウンロードできるように/var/commonディレクトリにコピーできます(すべてのFTDプラットフォームで/ngfw/var/common)。
> expert
# copy /mnt/disk0/<pcap_file> /var/common/
パケットキャプチャファイルは、この記事の指示に従って、>プロンプトからFirepowerデバイスからコピーできます。
または、Firepowerバージョン6.2.0以降のFirepower Management Center(FMC)にはオプションはありません。FMCでこのユーティリティにアクセスするには、[Devices] > [Device Management]に移動します。次に、 アイコンをクリックし、その後に[Advanced Troubleshooting] > [File Download]をクリックします。その後、該当するファイルの名前を入力し、[Download]をクリックします。
パケットキャプチャ(PCAP)ファイル分析
WiresharkのPCAP分析を実行すると、アクティブな認証操作で問題を特定できます。非標準ポートはキャプティブポータル設定(デフォルトでは885)で使用されるため、SSLなどのトラフィックをデコードするようにWiresharkを設定する必要があります。
内部インターフェイスキャプチャとトンネルインターフェイスキャプチャを比較する必要があります。両方のPCAPファイルで問題のセッションを識別する最善の方法は、IPアドレスが異なるため、一意の送信元ポートを見つけることです。
上記の例では、サーバのhelloパケットが内部インターフェイスキャプチャから欠落していることに注意してください。これは、クライアントに戻されなかったことを意味します。パケットがSnortによってドロップされた可能性があります。また、パケットまたは設定の誤りが原因である可能性もあります(不具合または設定の誤り)。
注:Snortは、HTTPの不正利用を防ぐために、自身のキャプティブポータルトラフィックを検査します。
暗号化されたストリームの復号化
SSLスタックに問題がない場合は、PCAPファイルのデータを復号化してHTTPストリームを表示することが有益な場合があります。これを実現する方法は2つあります。
- Windowsで環境変数を設定する(より安全 – 推奨)
- この方法では、プリマスターシークレットファイルを作成します。これは、次のコマンドを使用して実行できます(Windowsのコマンド端末から実行)。setx SSLKEYlOGFILE "%HOMEPATH%\Desktop\premaster.txt"
- その後、Firefoxでプライベートセッションを開き、SSLを使用して対象のサイトを参照できます。
- 対称キーは、上記のステップ1でコマンドで指定したファイルに記録されます。
- Wiresharkは、ファイルを使用して対称キーを使用して復号化できます(次の図を参照)。
- RSA秘密キーを使用する(テスト証明書とユーザを使用しない限り、セキュリティが低い)
- 使用する秘密キーは、キャプティブポータル証明書に使用される秘密キーです
- これは、非RSA(楕円曲線など)やephemeral(Diffie-Hellmanなど)では動作しません
注意:方法2を使用する場合は、Cisco Technical Assistance Center(TAC)に秘密キーを提供しないでください。ただし、一時的なテスト証明書とキーを使用できます。テストユーザは、テストにも使用する必要があります。
復号化されたPCAPファイルの表示
次の例では、PCAPファイルが復号化されています。NTLMがアクティブ認証方式として使用されていることを示します。
NTLM認証が行われた後、クライアントは元のセッションにリダイレクトされ、意図した宛先(http://www.cisco.com)に到達できるようになります。
緩和手順
パッシブ認証のみに切り替え
アイデンティティポリシーでアクティブ認証を使用すると、リダイレクトプロセスで何らかの問題が発生した場合に、許可(HTTP(s)トラフィックのみ)をドロップできます。迅速な緩和策は、アクティブ認証のアクションを使用してアイデンティティポリシー内のルールを無効にすることです。
また、[Passive Authentication]がアクションとして設定されているルールで、[Use active authentication if passive authentication cannot identify user]オプションがオンになっていないことを確認します。
TACに提供するデータ
次のステップ
アクティブ認証コンポーネントが問題の原因ではないと判断された場合、次のステップは、侵入ポリシー機能のトラブルシューティングです。
ここをクリックして、次の記事に進んでください。