一般的なトラブルシューティングとベスト プラクティス
以下のカスタム フィールドを含むようにアクセス ログを設定します。
%u、%g、%m、%k、%L(これらの値は大文字と小文字が区別されます)。
これらのフィールドの説明については、アクセス ログのフォーマット指定子と W3C ログ ファイルのフィールド を参照してください。
設定の手順については、アクセス ログのカスタマイズ および ログ サブスクリプションの追加および編集 を参照してください。
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この付録の構成は、次のとおりです。
以下のカスタム フィールドを含むようにアクセス ログを設定します。
%u、%g、%m、%k、%L(これらの値は大文字と小文字が区別されます)。
これらのフィールドの説明については、アクセス ログのフォーマット指定子と W3C ログ ファイルのフィールド を参照してください。
設定の手順については、アクセス ログのカスタマイズ および ログ サブスクリプションの追加および編集 を参照してください。
WSA を AsyncOS 10.5 にアップグレードして、FIPS モードおよび CSP 暗号化をイネーブルにした後に、暗号化と証明書に関する問題が発生した場合は、次の項目を確認してください。
FIPS モードの CSP 暗号化がイネーブルになる前に動作していた機能が、暗号化がイネーブルになった後に動作しなくなった場合は、CSP 暗号化に問題があるかどうかを判別します。CSP 暗号化および FIPS モードをディセーブルにして、機能をテストします。動作する場合は、FIPS モードをイネーブルにして再びテストします。動作する場合は、CSP 暗号化をイネーブルにして再びテストします。FIPS モードの有効化または無効化 を参照してください。
AsyncOS 10.5 にアップグレードする前に WSA で受け入れられた証明書は、再アップロードしたときに、アップロード方法に関係なく(つまり、[HTTPS プロキシ(HTTPS Proxy)]、[証明書管理(Certificate Management)]、[SaaS
のアイデンティティプロバイダー(Identity Provider for SaaS)]、ISE 設定、認証設定などの UI ページを使用した場合も、certconfig
CLI コマンドを使用した場合も)拒否されることがあります。
証明書の署名者 CA が「カスタムの信頼できる証明機関」として [証明書の管理(Certificate Management)] ページ([ネットワーク(Network)] > [証明書管理(Certificate Management)])ページで追加されていることを確認してください。証明書パス全体を信頼することができない場合は、証明書を WSA にアップロードできません。
また、古い設定をリロードすると、含まれている証明書が信頼されなくなって、リロードに失敗することがあります。保存された設定をロードする間に、これらの証明書を置き換えてください。
(注) |
すべての証明書検証エラーは、監査ログ( |
Kerberos チケットのキャッシュを表示および消去するための KerbTray または klist(どちらも Windows Server Resource Kit に付属)。Active Directory を表示および編集するための Active Directory Explorer。Wireshark は、ネットワークのトラブルシューティングに使用できるパケット アナライザです。
一部のユーザ エージェントまたはアプリケーションは、認証に失敗してアクセスを拒否されると、Web セキュリティ アプライアンスへの要求の送信を繰り返します。その結果、マシン クレデンシャルを使用して、Active Directory サーバへの要求の送信が繰り返されるので、運用に悪影響を及ぼすことがあります。
最適な結果を得るには、これらのユーザ エージェントの認証をバイパスします。問題のあるユーザ エージェントの認証のバイパス を参照してください。
LDAP サーバは NTLMSSP をサポートしていません。一部のクライアント アプリケーション(Internet Explorer など)は、NTLMSSP と Basic の選択肢が与えられたときに、常に NTLMSSP を選択します。以下の条件がすべて該当する場合は、ユーザの認証に失敗します。
ユーザが LDAP レルムにのみ存在する。
識別プロファイルで LDAP レルムと NTLM レルムの両方を含むシーケンスを使用している。
識別プロファイルで「基本または NTLMSSP」認証方式を使用している。
ユーザが Basic を介して NTLMSSP を選択するアプリケーションから要求を送信する。
上記の条件の少なくとも 1 つが該当する場合は、認証プロファイル、認証レルム、またはアプリケーションを再設定してください。
以下の条件がすべて該当する場合は、LDAP 認証に失敗します。
LDAP 認証レルムで Active Directory サーバを使用している。
Active Directory サーバが別の認証サーバへの LDAP 参照を使用している。
参照された認証サーバが Web セキュリティ アプライアンスで使用できない。
回避策:
アプライアンスで LDAP 認証レルムを設定するときに、Active Directory フォレストにグローバル カタログ サーバ(デフォルト ポートは 3268)を指定します。
advancedproxyconfig
> authentication
CLI コマンドを使用して、LDAP 参照をディセーブルにします。デフォルトでは、LDAP 参照はディセーブルになります。
関連する問題
基本認証方式を使用する場合、AsyncOS for Web では 7 ビット ASCII 文字のパスフレーズのみがサポートされます。パスフレーズに 7 ビット ASCII 以外の文字が含まれていると、基本認証は失敗します。
Web セキュリティ アプライアンスが WCCP v2 対応デバイスに接続されている場合、NTLM 認証が機能しないことがあります。透過 NTLM 認証を適切に実行しない、厳格にロックダウンされた Internet Explorer バージョンを使ってユーザが要求を行っており、アプライアンスが WCCP v2 対応デバイスに接続されている場合、ブラウザはデフォルトで基本認証を使用します。その結果、認証クレデンシャルが不要な場合でも、ユーザはクレデンシャルの入力を要求されます。
回避策
Internet Explorer で、[ローカル イントラネット(Local Intranet )] ゾーンの [信頼できるサイト(trusted sites)] リストに Web セキュリティ アプライアンスのリダイレクト ホスト名を追加します([ツール(Tools)] > [インターネット オプション(Internet Options)] > [セキュリティ(Security)] タブ)。
[ブロックするオブジェクト タイプ(Block Object Type)] セクションで Microsoft Office ファイルをブロックすると、一部の Microsoft Office ファイルがブロックされない可能性があります。
すべての Microsoft Office ファイルをブロックする必要がある場合は、[ブロックするMIMEタイプ(Block Custom MIME Types)] フィールドに application/x-ole を追加します。ただし、このカスタム MIME タイプをブロックすると、Visio ファイルや一部のサード パーティ アプリケーションなど、すべての Microsoft 複合オブジェクト フォーマット タイプがブロックされます。
DOS の実行可能オブジェクト タイプをブロックするように Web セキュリティ アプライアンスを設定すると、Windows OneCare のアップデートもブロックされます。
Firefox ブラウザが WPAD による DHCP ルックアップをサポートしていない可能性があります。最新の情報については、https://bugzilla.mozilla.org/show_bug.cgi?id=356831
を参照してください。
PAC ファイルが Web セキュリティ アプライアンスにホストされている場合に、Firefox(または、DHCP をサポートしていない他のブラウザ)で WPAD を使用するには、ポート 80 を介して PAC ファイルを使用するようにアプライアンスを設定します。
ステップ 1 |
[セキュリティサービス(Security Services)] > [Webプロキシ(Web Proxy)] を選択し、[プロキシを設定する HTTP ポート(HTTP Ports to Proxy)] フィールドからポート 80 を削除します。 |
ステップ 2 |
アプライアンスにファイルをアップロードする場合、PAC サーバ ポートとしてポート 80 を使用します。 |
ステップ 3 |
ポート 80 の Web プロキシを指し示すようにブラウザが手動設定されている場合は、[プロキシを設定するHTTP ポート(HTTP Ports to Proxy)] フィールドで、別のポートを指し示すようにブラウザを再設定します。 |
ステップ 4 |
PAC ファイルのポート 80 への参照を変更します。 |
アプライアンスのリブート時に、「DNS キャッシュのブートに失敗(Failed to bootstrap the DNS cache)」というメッセージを含むアラートが生成された場合は、システムがプライマリ DNS サーバに接続できなかったことを示しています。この事象は、ネットワーク接続が確立される前に DNS サブシステムがオンラインになった場合、ブートのタイミングで発生します。このメッセージが別のタイミングで表示された場合、ネットワーク問題が発生しているか、または DNS 設定で有効なサーバが指定されていないことを示しています。
フェールオーバーグループを誤って設定すると、複数のプライマリアプライアンスをもたらしたり、その他のフェールオーバーの問題が発生したりする可能性があります。failoverconfig
CLI コマンドの testfailovergroup
サブコマンドを使用して、フェールオーバーの問題を診断します。
次に例を示します。
wsa.wga> failoverconfig
Currently configured failover profiles:
1. Failover Group ID: 61
Hostname: failoverV4P1.wga, Virtual IP: 10.4.28.93/28
Priority: 100, Interval: 3 seconds
Status: PRIMARY
Choose the operation you want to perform:
- NEW - Create new failover group.
- EDIT - Modify a failover group.
- DELETE - Remove a failover group.
- PREEMPTIVE - Configure whether failover is preemptive.
- TESTFAILOVERGROUP - Test configured failover profile(s)
[]> testfailovergroup
Failover group ID to test (-1 for all groups):
[]> 61
仮想アプライアンス上に展開している場合は、ハイパーバイザのインターフェイス/仮想スイッチが無差別モードを使用するように設定されていることを確認してください。
(Web インターフェイスから)アクセスしようとしている機能の機能キーの有効期限が切れている場合は、シスコの担当者またはサポート組織までご連絡ください。
ネイティブ FTP 要求が FTP プロキシに透過的にリダイレクトされる場合、FTP サーバに対するホスト名情報は含まれず、IP アドレス情報だけが含まれます。そのため、要求の宛先がそれらのサーバである場合でも、ホスト名情報しか持っていない一部の定義済み URL カテゴリと Web レピュテーション フィルタが、ネイティブ FTP 要求と一致しなくなります。それらのサイトへのアクセスをブロックする場合は、サイトの IP アドレスを使用してサイト用のカスタム URL カテゴリを作成する必要があります。
FTP プロキシと FTP サーバとの接続が遅い場合、特に、Cisco データ セキュリティ フィルタがイネーブルのときに、大きなファイルのアップロードに時間がかかることがあります。そのため、FTP プロキシがファイル全体をアップロードする前に FTP クライアントがタイムアウトしてしまい、トランザクション失敗の通知を受け取る場合があります。しかし、トランザクションは失敗しておらず、バックグラウンドで続行され、FTP プロキシによって完了されます。
FTP クライアントのアイドル タイムアウト値を適切に増加することにより、この問題を回避できます。
発信マルウェア対策スキャンによって FTP プロキシがアップロードをブロックすると、FTP クライアントは FTP サーバ上にゼロ バイト ファイルを作成します。
FTP-over-HTTP 要求では、Chrome ブラウザはユーザ エージェント文字列を含まないためユーザ エージェントとして検出されません。
WSA は、数千ものクライアントとサーバの接続を並行して処理するように設計されており、送信/受信バッファのサイズは安定性を犠牲にすることなく、最適なパフォーマンスを実現するように設定されています。通常、実際の用途は、多数の一時的な接続で構成されたブラウザ トラフィックです。これには受信パケットステアリング(RPS)データと受信フローステアリング(RFS)データが含まれ、WSA が最適化されています。
ただし、プロキシ経由で大容量ファイルを転送する場合などは、アップロードまたはダウンロード速度が著しく低下することがあります。たとえば、10 Mbps の回線で WSA を通じて 100 MB のファイルをダウンロードすると、サーバからファイルを直接ダウンロードするよりも約 7 ~ 8 倍の時間がかかる可能性があります。
大容量ファイル転送が多数行われる特異な環境では、この問題を改善するために networktuning
コマンドを使用して送信/受信バッファのサイズを増やすことができますが、そうするとネットワーク メモリが枯渇してシステムの安定性に影響が生じる可能性もあります。networktuning
コマンドの詳細については、Web セキュリティ アプライアンスの CLI コマンドを参照してください。
注意 |
TCP 受信/送信バッファ制御ポイントとその他の TCP バッファ パラメータを変更する場合は、注意が必要です。副次的な影響を理解している場合にのみ、 |
ここでは、2 つの異なるアプライアンスでの networktuning
コマンドの使用について説明します。
networktuning
sendspace = 131072
recvspace = 131072
send-auto = 1 [Remember to disable miscellaneous > advancedproxy > send buf auto tuning]
recv-auto = 1 [Remember to disable miscellaneous > advancedproxy > recv buf auto tuning]
mbuf clusters = 98304 * (X/Y) where is X is RAM in GBs on the system and Y is 4GB.
sendbuf-max = 1048576
recvbuf-max = 1048576
質問
これらのパラメータは何ですか。
WSA には、固有のニーズに合わせて変更できる複数のバッファと最適化アルゴリズムがあります。バッファ サイズは、「最も一般的な」導入シナリオに合わせて初めから最適化されています。ただし、より高速の接続ごとのパフォーマンスが必要な場合に大きいバッファ サイズを使用できますが、全体的なメモリ使用量が増加します。そのため、バッファ サイズの増加は、システムで使用可能なメモリの範囲内にする必要があります。送信/受信スペース変数は、ソケット経由の通信用にデータを保存するために使用できるバッファ サイズを制御します。自動送信/受信オプションを使用して、送信/受信 TCP ウィンドウ サイズの動的スケーリングを有効および無効にします(これらのパラメータは、FreeBSD カーネルに適用されます)。
これらの例の値はどのように決定されましたか。
この「問題」が発生したお客様のネットワークでさまざまな値のセットをテストして、これらの値に絞りました。その後、シスコのラボで安定性の変化とパフォーマンスの向上についてさらにテストしました。自己責任で、これら以外の値を自由に使用できます。
なぜ、これらの値はデフォルトではないのですか。
前述のとおり、デフォルトで WSA は最も一般的な導入向けに最適化されており、また、非常に多くの場所で動作する際に接続ごとのパフォーマンスに不満がないように最適化されています。ここで説明した変更を行うと、RPS 数は増加せず、実際には低下する可能性があります。
重要x80 または x90 アプライアンスの電源を再投入する場合は、アプライアンスが起動するまで(すべての LED が緑色になるまで)少なくとも 20 分間待ってから、電源ボタンを押してください。
ハードウェア アプライアンスの前面/背面パネルのライトは、アプライアンスの状態およびステータスを示します。これらのインジケータの説明については、『Cisco x90 Series Content Security Appliances Installation and Maintenance Guide』など、http://www.cisco.com/c/en/us/support/security/web-security-appliance/products-installation-guides-list.html [英語] から入手可能なハードウェア ガイドを参照してください。
温度範囲など、アプライアンスの仕様についてもこれらのマニュアルで確認できます。
このアラートは、問題を示している場合と示していない場合があります。バッテリ再学習タイムアウト自体は、RAID コントローラに問題があることを示すものではありません。コントローラは、後続の再学習で回復します。以降 48 時間他の RAID アラートに関する電子メールを監視して、この問題が他の問題の副作用ではないことを確認してください。システムから他の RAID タイプのアラートが示されない場合は、この警告を無視してかまいません。
透過的にリダイレクトされた HTTPS 要求の場合、Web プロキシは宛先サーバとやり取りして、サーバ名とサーバが属する URL カテゴリを判別する必要があります。したがって、Web プロキシがルーティング ポリシー グループのメンバーシップを評価する時点では、まだ宛先サーバとやり取りしていないので、HTTPS 要求の URL カテゴリが不明です。Web プロキシが URL カテゴリを認識していない場合、情報が不足しているために透過的 HTTPS 要求をユーザ定義のルーティングポリシーと一致させることはできません。
その結果、どのルーティングポロシーグループにも、どの識別プロファイルにも URL カテゴリ単位のメンバーシップ基準がない場合は、透過的にリダイレクトされる HTTPS トランザクションのみがルーティングポリシーと一致します。ユーザ定義のルーティングポリシーまたは識別プロファイルが URL カテゴリ単位でメンバーシップを定義している場合は、透過的 HTTPS トランザクションはデフォルトのルーティングポリシーグループと一致します。
HTTPS 要求が、以前の HTTP 要求の認証情報を利用できないクライアントから発信された場合、AsyncOS は HTTPS プロキシの設定に応じて、HTTPS 要求に失敗するか、またはユーザを認証するために HTTPS 要求を復号化します。この動作を定義するには、[セキュリティサービス(Security Services)] > [HTTPS プロキシ(HTTPS Proxy)] ページで [HTTPS 透過的要求(HTTPS Transparent Request)] 設定を使用します。「復号化ポリシー」の章の「HTTPS プロキシの有効化」に関する項を参照してください。
パケット キャプチャをスキャンすると、カスタム カテゴリおよびデフォルト(Web)カテゴリの HTTPS 復号化パススルー ポリシーに対して別々の時間で「Client Hello」ハンドシェイクが送信されます。
デフォルト カテゴリを介した HTTPS ページのパススルーでは、要求元から Client Hello を受信する前に Client Hello が送信され、接続が失敗します。カスタム URL カテゴリを介した HTTPS ページのパススルーでは、要求元から Client Hello を受信した後に Client Hello が送信され、接続が成功します。
対応策として、SSL 3.0 のみと互換性がある Web ページのパススルー アクションを使用して、カスタム URL カテゴリを作成することができます。
HTTPS サーバへのトラフィックが、Web プロキシなどのプロキシ サーバによって復号化されると、一部の HTTPS サーバは期待どおりに機能しなくなります。たとえば、セキュリティの高い銀行のサイトなど、一部の Web サイトとそれらに関連する Web アプリケーションおよびアプレットは、オペレーティング システムの証明書ストアを使用するのではなく、信頼できる証明書のハードコードされたリストを維持します。
すべてのユーザがこれらのタイプのサイトにアクセスできるようにするには、これらのサーバへの HTTPS トラフィックの復号化をバイパスします。
ステップ 1 |
拡張プロパティを設定して、影響を受ける HTTPS サーバを含むカスタム URL カテゴリを作成します。 |
ステップ 2 |
メンバーシップの一環としてステップ 1 で作成されたカスタム URL カテゴリを使用する復号化ポリシーを作成し、カスタム URL カテゴリに対するアクションを [通過(Pass Through)] に設定します。 |
Referer ベースの例外は、アクセス ポリシーでのみサポートされます。HTTPS トラフィックでこの機能を使用するには、アクセス ポリシーで例外を定義する前に、例外用に選択する URL カテゴリの HTTPS 復号化を設定する必要があります。ただし、この機能は特定の条件下では機能しません。
通常、アプライアンスで生成またはアップロードされるルート証明書情報は、信頼できるルート認証局としてクライアント アプリケーションで認識されません。ユーザが HTTPS 要求を送信すると、大部分の Web ブラウザでは、デフォルトで、Web サイトのセキュリティ証明書に問題があることを知らせる警告メッセージがクライアント アプリケーションによって表示されます。通常、エラー メッセージには、Web サイトのセキュリティ証明書が信頼できる認証局によって発行されていないこと、または Web サイトが未知の認証局によって認証されていることが表示されます。クライアント アプリケーションによっては、この警告メッセージがユーザに示されず、ユーザは承認されない証明書を受け入れることができません。
(注) |
Mozilla Firefox ブラウザ:Mozilla Firefox ブラウザで使用するには、アップロードする証明書に「basicConstraints=CA:True」を含める必要があります。この制約により、Firefox は、信頼されたルート認証局としてルート証明書を認識できるようになります。 |
以下のツールは、ISE 関連の問題をトラブルシューティングする際に役立ちます。
ISE テスト ユーティリティ。ISE サーバへの接続のテストに使用され、貴重な接続関連情報を提供します。これは、[Identity Services Engine] ページの [テスト開始(Start Test)] オプションです(ISE/ISE-PIC サービスへの接続を参照)。
ISE およびプロキシ ログ(以下を参照)。 ログによるシステム アクティビティのモニタ
ISE 関連の CLI コマンド iseconfig
および isedata
。特に isedata
は、セキュリティ グループ タグ(SGT)のダウンロードを確認するために使用します。詳細については、Web セキュリティ アプライアンスの CLI コマンドを参照してください。
Web トラッキング機能およびポリシー トレース機能。これらを使用してポリシーの一致に関する問題をデバッグできます。たとえば、許可されるべきユーザがブロックされた場合(または、その逆の場合)などに使用できます。詳細については、ポリシーのトラブルシューティング ツール:ポリシー トレースを参照してください。
パケット キャプチャ(サポートの使用 する場合)
認証ステータスを確認する場合は、openssl Online Certificate Status Protocol(ocsp)ユーティリティを使用できます。これは https://www.openssl.org/ から入手できます。
WSA と ISE サーバは 証明書を使用して正常な接続を相互認証します。したがって、一方のエンティティによって指定された各証明書を、もう一方が認識できなければなりません。たとえば、WSA のクライアント証明書が自己署名の場合、該当する ISE サーバの信頼できる証明書リストに同じ証明書が含まれている必要があります。同様に、WSA クライアント証明書が CA 署名付きの場合も、該当する ISE サーバにその CA ルート証明書が存在している必要があります。同様の要件は、ISE サーバ関連の管理証明書および pxGrid 証明書にも該当します。
証明書の要件およびインストールについては、Cisco Identity Services Engine(ISE)/ ISE パッシブ ID コントローラ(ISE-PIC)の統合 で説明されています。証明書関連の問題が発生した場合は、以下を確認してください。
CA 署名付き証明書を使用する場合:
管理証明書および pxGrid 証明書のルート CA 署名証明書が WSA に存在していることを確認します。
WSA クライアント証明書のルート CA 署名証明書が ISE サーバの信頼できる証明書リストに含まれていることを確認します。
自己署名証明書を使用する場合:
(WSAで生成され、ダウンロードされた)WSA クライアント証明書が、ISE サーバにアップロードされており、ISE サーバの信頼できる証明書リストに含まれていることを確認します。
(ISE サーバで生成され、ダウンロードされた)ISE 管理者証明書および pxGrid 証明書が、WSA にアップロードされており、WSA の証明書リストに含まれていることを確認します。
期限切れの証明書:
アップロード時に有効だった証明書が、期限切れでないことを確認します。
以下の ISE サービス ログの抜粋は、証明書の欠落または無効な証明書による接続タイムアウトを示しています。
WSA のこれらのトレース レベル ログ エントリは、30 秒後に ISE サーバへの接続の試行が終了されることを示しています。
Identity Services Engine(ISE/ISE-PIC サービスへの接続)で [テスト開始(Start Test)] を実行中に ISE サーバへの接続が失敗した場合、ポート 443 と 5222 に設定されている ISE サーバへの接続を確認します。
ポート 5222 は公式のクライアント/サーバ Extensible Messaging and Presence Protocol(XMPP)ポートであり、ISE サーバへの接続に使用されます。また、Jabber や Google Talk などのアプリケーションでも使用されます。ただし、一部のファイアウォールはポート 5222 をブロックするように設定されています。
接続の確認に使用できるツールには、tcpdump
などがあります。
WSA が ISE サーバへの接続を試みたときに、以下の問題によって失敗することがあります。
ISE サーバのライセンスの期限が切れている。
ISE サーバの [管理(Administration)] > [pxGrid サービス(pxGrid Services)] ページで、pxGrid ノードのステータスが [未接続(not connected)] になっている。このページで [自動登録の有効化(Enable Auto-Registration)] がオンになっていることを確認してください。
失効した WSA クライアント(特に「test_client」または「pxgrid_client」)が、ISE サーバ上に存在する。これらは削除する必要があります。ISE サーバの [管理(Administration)] > [pxGrid サービス(pxGrid Services)] > [クライアント(Clients)] を参照してください。
すべてのサービスが起動して実行される前に、WSA が ISE サーバへの接続を試みている。
ISE サーバに対する一部の変更(証明書のアップデートなど)では、ISE サーバまたはそこで実行されているサービスの再起動が必要です。この間に ISE サーバへの接続を試みると失敗しますが、最終的に接続に成功します。
ここでは、WSA における ISE 関連の重要なログ メッセージについて説明します。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: Waiting for client connection timed out
WSA の ISE プロセスが 30 秒以内に ISE サーバに接続できませんた。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: WSA Client cert/key missing. Please check ISE config
WSA クライアント証明書とキーが WSA の [Identity Service Engine] 設定ページでアップロードされなかったか、生成されませんでした。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: ISE service exceeded maximum allowable disconnect duration with ISE server
WSA の ISE プロセスが 120 秒以内に ISE サーバに接続できず、終了しました。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: Subscription to updates failed ...
WSA の ISE プロセスが、アップデートのために ISE サーバに登録できませんでした。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: Could not create ISE client: ...
ISE サーバ接続用の WSA の ISE クライアントを作成するときに、内部エラーが発生しました。
Tue Mar 24 03:56:47 2015 Critical: ISEEngineManager: Bulk Download thread failed: ...
この内部エラーは、接続または再接続時に SGT の一括ダウンロードに失敗したことを示しています。
Tue Mar 24 03:56:47 2015 Critical: ISEService: Unable to start service. Error: ...
WSA の ISE サービスの起動に失敗しました。
Tue Mar 24 03:56:47 2015 Critical: ISEService: Unable to send ready signal ...
WSA の ISE サービスが heimdall に Ready 信号を送信できませんでした。
Tue Mar 24 03:56:47 2015 Critical: ISEService: Unable to send restart signal ...
WSA の ISE サービスが heimdall に再起動信号を送信できませんでした。
カスタムおよび外部 URL カテゴリを作成および編集し、[外部ライブ フィード(External Live Feed)] ファイル([シスコ フィード形式(Cisco Feed Format)] または [Office 365 フィード形式(Office 365 Feed Format)] のいずれか)を提供する場合、[ファイルの取得(Get File)] ボタンをクリックして、指定したサーバとの接続を開始し、ファイルをダウンロードして解析する必要があります。このプロセスの進行状況と結果が表示されます。 エラーが発生した場合は、進行状況と結果が説明されます。問題を修正し、もう一度ファイルのダウンロードを試します。
次の 4 種類のエラーが発生する可能性があります。
接続の例外
Failed to resolve server hostname
:フィード ファイルの場所として指定した URL は無効です。この問題を解決するには、正しい URL を指定します。
プロトコル エラー
Authentication failed due to invalid credentials
:サーバ認証が失敗しました。サーバ接続に適切なユーザ名とパスフレーズを指定します。
The requested file is not found on the server
:フィード ファイルに指定した URL が無効なリソースを示しています。指定したサーバで正しいファイルが使用できることを確認します。
コンテンツ検証エラー
Failed to validate the content of the field
:フィード ファイルのコンテンツが無効です。
解析エラー
シスコ フィード形式 .csv ファイルは、1 つ以上のエントリを含む必要があります。各エントリはサイトのアドレスまたは有効な正規表現文字列で、カンマ、アドレスタイプ(site
または regex
のいずれか)が続きます。フィード ファイルのエントリに対してこの表記規則に従わない場合、解析エラーがスローされます。
また、http://
または https://
を site
エントリの一部としてファイルに含めないでください。エラーが発生します。つまり、www.example.com
は正しく解析されますが、http://www.example.com
ではエラーが発生します。
Microsoft サーバから取得した XML ファイルは、標準の XML パーサーによって解析されます。XML タギングの矛盾にも、解析エラーとしてフラグが付きます。
解析エラーの行番号はログに含まれます。次に例を示します。
Line 8: 'www.anyurl.com' - Line is missing address or address-type field.
フィード ファイルの 8 行目には、有効なアドレスまたは正規表現のパターン、またはアドレスタイプは含まれていません。
Line 12: 'www.test.com' - Unknown address type.
12 行目に無効なアドレスタイプがあります。アドレスタイプは site
または regex
のいずれかになります。
カスタムおよび外部 URL カテゴリの作成および編集中に [External Live Feed Category(外部ライブ フィード ファイル カテゴリ)] > [Cisco Feed Format(シスコ フィード形式)] オプションの
.csv ファイルを提供すると、シスコ フィード形式サーバがインターネット インフォメーション サービス(IIS)のバージョン 7 または 8 ソフトウェアを実行している場合にファイルを取得する際、[406 not acceptable(406
受け入れられません)] エラーが発生する場合があります。同様に、feedsd
ログでは次のような内容が報告されます。31 May 2016 16:47:22 (GMT +0200) Warning: Protocol Error: 'HTTP error while fetching file from the server'
。
これは、IIS 上の .csv ファイルのデフォルトの MIME タイプが text/csv
ではなく application/csv
であるためです。この問題は、IIS サーバにログインし、.csv ファイルの MIME タイプのエントリを text/csv
に編集することで解決できます。
UNIX または OS X システムから Windows システムに .csv(テキスト)フィード ファイルのコンテンツをコピーアンドペーストする場合、余分な改行(\r
)が自動的に追加され、フィード ファイルの形式が不正になる場合があります。
.csv ファイルを手動で作成する場合や、SCP、FTP、または POST を使用して UNIX または OS X から Windows システムにファイルを転送する場合は、問題はありません。
Web アクセス ポリシー グループに、[モニタ(Monito)] に設定されたカスタム URL カテゴリ セットとその他のコンポーネント(Web レピュテーション フィルタ、DVS エンジンなど)がある場合に、カスタム URL カテゴリ内の URL に対する要求を許可するかブロックするかについて最終決定が行われると、要求のアクセス ログ エントリには、カスタム URL カテゴリの代わりに、定義済みの URL カテゴリが表示されます。
アクセス ログでの HTTPS トランザクションの表示は、HTTP トランザクションと似ていますが、特性は少し異なります。記録される内容は、トランザクションが HTTPS プロキシに明示的に送信されるか、または透過的にリダイレクトされるかどうかによって異なります。
CONNECT。これは、HTTPS 要求が HTTPS プロキシに明示的に送信されたときにアクセス ログに記録されます。
HTTPS トラフィックが復号化されたときは、アクセス ログにトランザクションに対して、以下の 2 つのエントリが含まれます。
HTTP 方式および復号化された URL。例:「GET https://ftp.example.com」。
完全な URL は、HTTPS プロキシがトラフィックを復号化するときだけ表示されます。
内部ロギング プロセスがフル バッファにより Web トランザクション イベントをドロップする場合、AsyncOS for Web が設定されたアラート受信者にクリティカルな電子メール メッセージを送信します。
デフォルトでは、Web プロキシが非常に高い負荷を受けたときに、内部ロギング プロセスは Web プロキシの負荷を減らす際にそれらを記録するイベントをバッファします。ロギング バッファ ファイルが完全に満杯になったときに、Web プロキシはトラフィックの処理を続行しますが、ロギング プロセスはイベントの一部をアクセス ログまたは Web トラッキング レポートに記録しません。これは、Web トラフィックのスパイク時に発生する可能性があります。
ただし、アプライアンスが持続的に過剰容量になっている場合にも、ロギング バッファが満杯になることがあります。AsyncOS for Web は、ロギング プロセスがデータをドロップしなくなるまで、数分ごとにクリティカルな電子メール メッセージを送信し続けます。
クリティカルなメッセージは以下のようなテキストが含まれます。
Reporting Client: The reporting system is unable to maintain the rate of data being generated. Any new data generated will
be lost.
AsyncOS for Web が、このクリティカルなメッセージを継続的または頻繁に送信する場合、アプライアンスは過剰容量になっている可能性があります。Web セキュリティ アプライアンスの容量を追加する必要があるかどうかを確認するには、シスコ カスタマー サポートにお問い合わせください。
サードパーティ製のログ アナライザ ツールを使用して、W3C アクセス ログを閲覧したり解析する場合は、状況に応じて [タイムスタンプ(timestamp)] フィールドを含める必要があります。W3C の [タイムスタンプ(timestamp)] フィールドには、UNIX エポック以降の時間が表示され、ほとんどのログ アナライザはこの形式の時間のみ認識します。
HTTPS プロキシをイネーブルにすると、すべての HTTPS ポリシー決定が復号化ポリシーによって処理されます。また、アクセスおよびルーティング ポリシー グループ メンバーシップを HTTPS で定義することも、HTTPS トランザクションをブロックするようにアクセス ポリシーを設定することもできなくなります。
アクセスおよびルーティング ポリシー グループの一部のメンバーシップが HTTPS によって定義されており、一部のアクセス ポリシーが HTTPS をブロックする場合は、HTTPS プロキシをイネーブルにすると、それらのアクセスおよびルーティング ポリシー グループがディセーブルになります。ポリシーは、いつでもイネーブルにすることができますが、そうすると、HTTPS 関連の設定がすべて削除されます。
[ブロックするオブジェクト タイプ(Block Object Type)] セクションで Microsoft Office ファイルをブロックすると、一部の Microsoft Office ファイルがブロックされない可能性があります。
すべての Microsoft Office ファイルをブロックする必要がある場合は、[ブロックするMIMEタイプ(Block Custom MIME Types)] フィールドに application/x-ole を追加します。ただし、このカスタム MIME タイプをブロックすると、Visio ファイルや一部のサード パーティ アプリケーションなど、すべての Microsoft 複合オブジェクト フォーマット タイプがブロックされます。
DOS の実行可能オブジェクト タイプをブロックするように Web セキュリティ アプライアンスを設定すると、Windows OneCare のアップデートもブロックされます。
識別プロファイルをディセーブルにすると、その識別プロファイルは関連するポリシーから削除されます。識別プロファイルがイネーブルになっていることを確認し、再びポリシーに追加します。
複数の識別プロファイルの基準が同じである場合、AsyncOS は一致する最初の識別プロファイルにトランザクションを割り当てます。したがって、トランザクションはその他の同じ基準の識別プロファイルとは照合されず、以降の同じ基準の識別プロファイルに適用されるポリシーは照合も適用もされません。
クレデンシャルの暗号化がイネーブルの場合は、サロゲートとして IP アドレスを使用するようにアプライアンスを設定する必要があります。
クレデンシャルの暗号化がイネーブルになっており、サロゲート タイプとして Cookie を使用するように設定されている場合、認証は HTTPS 要求や FTP over HTTP 要求で機能しません。クレデンシャルの暗号化がイネーブルの場合、Web プロキシは HTTPS 接続を使用して、クライアントを認証のために Web プロキシ自体にリダイレクトするからです。認証が成功した後、Web プロキシは元の Web サイトにクライアントをリダイレクトします。ユーザの識別を続行するために、Web プロキシはサロゲート(IP またはクッキー)を使用する必要があります。ただし、要求が HTTP または FTP over HTTP を使用している場合、Cookie を使用してユーザを追跡すると、以下の動作が引き起こされます。
したがって、HTTP 要求と FTP over HTTP 要求は、認証を必要としないアクセス ポリシーとのみ一致します。通常、これらの要求は、認証を必要としないグローバル アクセス ポリシーに一致します。
アプライアンスがクッキー ベースの認証を使用する場合、Web プロキシは、HTTP 要求を介した HTTPS および FTP のクライアントからクッキー情報を取得しません。このため、クッキーからユーザ名を取得できません。
HTTPS 要求や FTP over HTTP 要求は、他のメンバーシップ基準に従って識別プロファイルと照合されますが、識別プロファイルで認証が必要な場合でも、Web プロキシはクライアントに認証を要求しません。代わりに、Web プロキシはユーザ名を NULL に設定し、ユーザを未認証と見なします。
その後、ポリシーと照合して評価される際に、未認証の要求は [すべてのID(All Identities)] を指定しているポリシーとのみ一致し、[すべてのユーザ(All Users)] が適用されます。通常、これはグローバル アクセス ポリシーなどのグローバル ポリシーです。
ユーザは自分のクレデンシャルではなく、マシン クレデンシャルを使用して識別され、その結果、誤ったアクセス ポリシーが割り当てられる場合があります。
回避策:
マシン クレデンシャルのサロゲート タイムアウト値を小さくします。
ステップ 1 |
|
ステップ 2 |
マシン クレデンシャルのサロゲート タイムアウトを入力します。 |
[アクセス ポリシー(Access Policy)]、[識別プロファイルとユーザ(Identification Profiles and Users)]、[1 つ以上の識別プロファイルを選択(Select One or More Identification Profiles)]、[選択されたグループとユーザ(Selected Groups and Users)] など、ポリシーのパラメータを変更した場合、変更が有効になるまで数分かかります。
ポリシー トレース ツールはクライアント要求をエミュレートし、Web プロキシによる要求の処理方法を詳しく示します。Web プロキシの問題をトラブルシューティングするときに、このツールを使用し、クライアント要求を追跡してポリシー処理をデバッグできます。基本トレースを実行したり、詳細なトレース設定を行ってオプションをオーバーライドしたりできます。
(注) |
ポリシー トレース ツールを使用する場合、Web プロキシはアクセス ログまたはレポート データベース内の要求を記録しません。 |
ポリシー トレース ツールは、要求を Web プロキシだけで使用されるポリシーと照合して評価します。これらのポリシーには、アクセス、暗号化 HTTPS 管理、ルーティング、セキュリティ、発信マルウェア スキャンがあげられます。
(注) |
SOCKS および外部 DLP ポリシーは、ポリシー トレース ツールによって評価されません。 |
(注) |
CLI コマンド maxhttpheadersize を使用して、プロキシ要求の最大 HTTP ヘッダー サイズを変更できます。この値を大きくすると、指定したユーザが多数の認証グループに属しているか、または応答ヘッダーが現在の最大ヘッダー サイズよりも大きい場合に発生する可能性のあるポリシー トレースの失敗を軽減できます。このコマンドの詳細については、Web セキュリティ アプライアンスの CLI コマンド を参照してください。
|
ステップ 1 |
[システム管理(System Administration)] > [ポリシー トレース(Policy Trace)] を選択します。 |
||||||||||
ステップ 2 |
[送信先 URL(Destination URL)] フィールドに、トレースする URL を入力します。 |
||||||||||
ステップ 3 |
(任意)追加のエミュレーション パラメータを入力します。
|
||||||||||
ステップ 4 |
[一致するポリシーの検索(Find Policy Match)] をクリックします。 ポリシー トレースの出力が [結果(Results)] ペインに表示されます。
|
関連項目
[ポリシー トレース(Policy Trace)] ページの [詳細設定(Advanced)] セクションで、[要求の詳細(Request Details)] ペインの設定項目を使用し、このポリシー トレース用に発信マルウェア スキャン要求を調整できます。
ステップ 1 |
[ポリシー トレース(Policy Trace)] ページの [詳細設定(Advanced)] セクションを展開します。 |
||||||||||||||||
ステップ 2 |
[要求の詳細(Request Details)] ペインのフィールドを必要に応じて設定します。
|
||||||||||||||||
ステップ 3 |
[一致するポリシーの検索(Find Policy Match)] をクリックします。 ポリシー トレースの出力が [結果(Results)] ペインに表示されます。 |
[ポリシー トレース(Policy Trace)] ページの [詳細設定(Advanced)] セクションで、[レスポンスの詳細の上書き(Response Detail Overrides)] ペインの設定項目を使用し、このポリシー トレース用に Web アクセス ポリシー レスポンスのアスペクトを「調整」できます。
ステップ 1 |
[ポリシー トレース(Policy Trace)] ページの [詳細設定(Advanced)] セクションを展開します。 |
||||||||||||||
ステップ 2 |
[レスポンスの詳細の上書き(Response Detail Overrides)] ペインのフィールドを必要に応じて設定します。
|
||||||||||||||
ステップ 3 |
[一致するポリシーの検索(Find Policy Match)] をクリックします。 ポリシー トレースの出力が [結果(Results)] ペインに表示されます。 |
ファイル レピュテーションと分析のトラブルシューティングを参照してください
(注) |
これは KVM の問題であり、状況によって異なる場合があります。 |
詳細については、https://www.mail-archive.com/kvm@vger.kernel.org/msg103854.html および https://bugs.launchpad.net/qemu/+bug/1329956 を参照してください。
ステップ 1 |
次の点をチェックします。 cat /sys/module/kvm_intel/parameters/enable_apicv
|
ステップ 2 |
上記の値が Y に設定されている場合: |
アプライアンスのハード リセットが必要な場合は、サードパーティの Platform Management(IPMI)ツールを使用してアプライアンス シャーシをリモートからリブートできます。
制約事項
ステップ 1 |
IPMI を使用して、必要なクレデンシャルと共に、先に設定したリモート電源管理ポートに割り当てられた IP アドレスに、サポートされている電源の再投入コマンドを発行します。 たとえば、IPMI をサポートする UNIX タイプのマシンからは、次のようなコマンドを発行します。
S195、S395、および S695 モデルの場合は、次を使用します。
ここで |
ステップ 2 |
アプライアンスが再起動されるまで、少なくとも 11 分間待ちます。 |
以下は、認証をサポートしていないため、Web セキュリティ アプライアンスが透過モードで展開されている場合に使用できないアプリケーションのリストの一部です。
回避策:認証を必要としない URL のユーザ クラスを作成します。
ユーザの最初のクライアント要求が POST 要求で、ユーザの認証が必要な場合、POST 本文のコンテンツは失われます。この問題は、アクセス コントロールのシングル サインオン機能を使用しているアプリケーションに対して POST 要求を行った場合に発生することがあります。
回避策:
(注) |
アクセス コントロールを使用すると、アプリケーション認証ポリシーで設定された Assertion Consumer Service(ACS)URL の認証をバイパスできます。 |
アプライアンスとアップストリーム プロキシの両方が NTLMSPP による認証を使用している場合、設定によっては、アプライアンスとアップストリーム プロキシで、認証クレデンシャルを要求する無限ループが発生する可能性があります。たとえば、アップストリーム プロキシでは基本認証が必要だが、アプライアンスでは NTLMSPP 認証が必要な場合、アプライアンスはアップストリーム プロキシに正常に基本認証クレデンシャルを渡すことができません。これは、認証プロトコルの制限によるものです。
設定:
Web プロキシはクライアントから「Authorization」HTTP ヘッダーを受信しますが、アップストリーム プロキシ サーバでは「Proxy-Authorization」HTTP ヘッダーが必要であるため、クライアント要求はアップストリーム プロキシで失敗します。
ネットワークに FTP 接続をサポートしていないアップストリーム プロキシが含まれる場合は、すべての ID に適用され、かつ FTP 要求にのみ適用されるルーティング ポリシーを作成する必要があります。ルーティング ポリシーを設定して、FTP サーバに直接接続するか、プロキシのすべてが FTP 接続をサポートしているプロキシ グループに接続します。
仮想ホストにおける以下の操作は、ハードウェア アプライアンスのプラグを抜くことと同等であり、特に AsyncOS の起動中ではサポートされていません。
問題
前回の作業後にネットワーク接続が失われる。
解決方法
これは KVM の問題です。OpenStack ドキュメントの「KVM: Network connectivity works initially, then fails」の項を参照してください。このドキュメントは、http://docs.openstack.org/admin-guide-cloud/content/section_network-troubleshoot.html にあります。
問題
Ubuntu 仮想マシン上で実行しているときに、アプライアンスのパフォーマンスが低下して、ウォッチドッグの問題が発生し、アプライアンスが異常に高い CPU 使用率を示す。
解決方法
Ubuntu から最新の Host OS アップデートをインストールしてください。
問題
KVM 展開で実行されている仮想アプライアンスに関する問題は、ホスト OS の設定の問題と関連している可能性があります。
解決方法
『Virtualization Deployment and Administration Guide』のトラブルシューティングに関するセクションおよびその他の情報を参照してください。このドキュメントは、
WCCP を使用している展開では、HTTP、HTTPS、および FTP の各ポートの合計 30 が最大ポート エントリ数になります。
アプライアンスでは、アプライアンスが接続されているネットワークで送受信される TCP/IP と他のパケットをキャプチャして表示できます。
(注) |
パケット キャプチャ機能は UNIX の tcpdump コマンドに似ています。 |
ステップ 1 |
[ヘルプとサポート(Help and Support)] > [パケットキャプチャ(Packet Capture)] を選択します。 |
||||||||||||||
ステップ 2 |
(任意)[設定の編集(Edit Settings)] をクリックし、パケット キャプチャの設定を変更します。
(任意)パケット キャプチャの変更を送信して確定します。
|
||||||||||||||
ステップ 3 |
[キャプチャを開始(Start Capture)] をクリックします。実行中のキャプチャを手動で停止するには、[キャプチャを停止(Stop Capture)] をクリックします。 |
アプライアンスは、取り込んだパケット アクティビティをファイルに保存し、そのファイルをローカルに格納します。デバッグやトラブルシューティングのために、FTP を使用してパケット キャプチャ ファイルをシスコ カスタマー サポートに送信できます。
(注) |
また、FTP を使用してアプライアンスに接続し、captures ディレクトリからパケット キャプチャ ファイルを取り出すこともできます。 |
ステップ 1 |
[ヘルプとサポート(Help and Support)] > [パケットキャプチャ(Packet Capture)] を選択します。 |
ステップ 2 |
[パケットキャプチャファイルの管理(Manage Packet Capture Files)] ペインから、使用するパケット キャプチャ ファイルを選択します。このペインが表示されない場合は、アプライアンスにパケット キャプチャ ファイルが保存されていません。 |
ステップ 3 |
必要に応じて、[ファイルのダウンロード(Download File)] または [選択ファイルの削除(Delete Selected File)] をクリックします。 |
サポートに問い合わせる前に以下の手順を実行してください。
緊急ではない場合は、アプライアンスを使用してサポート要請をシスコ カスタマー サポートに送信できます。アプライアンスは要請を送信する際に、アプライアンスの設定も送信します。サポート要求を送信するには、アプライアンスがインターネットに電子メールを送信できる必要があります。
(注) |
緊急の問題がある場合は、Cisco Worldwide Support Center に連絡してください。 |
ステップ 1 |
[ヘルプとサポート(Help and Support)] > [テクニカルサポートに問い合わせる(Contact Technical Support)] を選択します。 |
ステップ 2 |
(任意)要請のその他の受信者を選択します。デフォルトでは、サポート要請とコンフィギュレーション ファイルがシスコ カスタマー サポートに送信されます。 |
ステップ 3 |
自身の連絡先情報を入力します。 |
ステップ 4 |
問題の詳細を入力します。
|
ステップ 5 |
[送信(Send)] をクリックします。トラブル チケットがシスコで作成されます。 |
Cisco Content Security 仮想アプライアンスのサポート ケースを報告する場合は、仮想ライセンス番号(VLN)、契約番号、および製品 ID コード(PID)を提供する必要があります。
発注書を参照するか以下の表を使用すると、仮想アプライアンスで動作中のソフトウェア ライセンスに基づく PID を特定できます。
機能 |
PID |
説明 |
---|---|---|
Web Security Essentials |
WSA-WSE-LIC= |
内容:
|
Web Security Premium |
WSA-WSP-LIC= |
内容:
|
Web Security Anti-Malware |
WSA-WSM-LIC= |
Sophos および Webroot Anti-Malware シグネチャが含まれます。 |
McAfee Anti-Malware |
WSA-AMM-LIC= |
— |
高度なマルウェア防御 |
WSA-AMP-LIC= |
— |
[リモートアクセス(Remote Access)] オプションを使用すると、シスコ カスタマー サポートがサポートのためにリモート アプライアンスにアクセスできるようになります。
ステップ 1 |
[ヘルプとサポート(Help and Support)] > [リモートアクセス(Remote Access)] を選択します。 |
||||||
ステップ 2 |
[有効(Enable)] をクリックします。 |
||||||
ステップ 3 |
[カスタマーサポートのリモートアクセス(Customer Support Remote Access)] オプションを設定します。
|
||||||
ステップ 4 |
変更を送信し、保存します。 |
||||||
ステップ 5 |
ページ上部近くに表示される成功メッセージでシード文字列を検索し、書き留めます。 セキュリティ上の理由から、この文字列はアプライアンスに保存されず、後から文字列を確認する方法はありません。 安全な場所にこのシード文字列を保存します。 |
||||||
ステップ 6 |
シード文字列をサポート担当者に提出します。 |