セキュアなWebアプライアンスのベストプラクティスの使用
内容
概要
このドキュメントでは、Cisco Secure Web Appliance(SWA)の設定方法に関するベストプラクティスについて説明します。
背景説明
このガイドは、ベストプラクティス構成のリファレンスとして提供されており、サポートされているネットワーク環境、ポリシー構成、モニタリング、およびトラブルシューティングなど、SWAの導入のさまざまな側面に対応しています。ここに記載されているベストプラクティスは、すべての管理者、アーキテクト、オペレータが理解する必要がありますが、ガイドラインに過ぎないため、ガイドラインとして扱う必要があります。各ネットワークには固有の要件と課題があります。
SWAはセキュリティデバイスとして、いくつかの固有の方法でネットワークと通信します。これはWebトラフィックの送信元と宛先の両方であり、WebサーバおよびWebクライアントとして同時に動作します。少なくとも、サーバ側のIPアドレスのスプーフィングとman-in-the-middle（中間者）技術を使用してHTTPSトランザクションを検査します。また、クライアントのIPアドレスをスプーフィングして、導入をさらに複雑にし、サポートするネットワーク設定に追加の要件を課すこともあります。このガイドでは、関連するネットワークデバイスの設定に関連する最も一般的な問題について説明します。
SWAポリシーの設定は、セキュリティの有効性と適用だけでなく、アプライアンスのパフォーマンスにも影響を与えます。このガイドでは、設定の複雑さがシステムリソースに与える影響について説明します。このコンテキストで複雑さを定義し、ポリシー設計でそれを最小限に抑える方法を説明します。また、特定の機能や、セキュリティ、スケーラビリティ、および有効性を向上させるためにこれらの機能をどのように設定すべきかに注目が集められています。
このドキュメントの「監視とアラート」セクションでは、アプライアンスを監視する最も効果的な方法について説明し、パフォーマンスと可用性の監視、およびシステムリソースの使用状況についても説明します。また、基本的なトラブルシューティングに役立つ情報も提供します。
ネットワーク環境
ICMP
RFC 1191で定義されているパスMTUディスカバリ。このメカニズムによって、任意のパスに沿ったパケットの最大サイズが決定されます。IPv4の場合、デバイスはパケットのIPヘッダーのDon't Fragment（DF；フラグメントなし）ビットを設定することにより、パス上の任意のパケットの最大伝送ユニット(MTU)を決定できます。パスに沿ったリンクで、デバイスがパケットをフラグメント化せずに転送できない場合、Internet Control Message Protocol(ICMP)Fragmentation Needed（タイプ3、コード4）メッセージが送信元に送り返されます。次に、クライアントはより小さいパケットを再送信します。これは、フルパスのMTUが検出されるまで続きます。IPv6はフラグメンテーションをサポートせず、Packet Too Big（タイプ2）ICMPv6メッセージを使用して、特定のリンクを介してパケットを収めることができないことを示します。
パケットのフラグメンテーションのプロセスはTCPフローのパフォーマンスに重大な影響を与える可能性があるため、SWAはPath MTU Discoveryを使用します。SWAがネットワークを通過するパスのMTUを判別できるようにするには、関連するネットワークデバイスで前述のICMPメッセージを有効にする必要があります。SWAでこの動作を無効にするには、pathmtudiscovery Command-Line Interface（CLI；コマンドラインインターフェイス）コマンドを使用します。これを行うと、デフォルトのMTUが576バイト（RFC 879による）に低下し、パフォーマンスに大きな影響を与えます。管理者は、SWAでMTUを手動で設定する追加の手順を実行する必要があります。 etherconfig CLI コマンド.
Web Cache Communication Protocol(WCCP)の場合、Webトラフィックは、インターネットへのクライアントパスに沿って、別のネットワークデバイスからSWAにリダイレクトされます。この場合、ICMPなどの他のプロトコルはSWAにリダイレクトされません。SWAがネットワーク上のルータからICMP Fragmentation Neededメッセージをトリガーする可能性がありますが、メッセージはSWAに配信されません。これがネットワークで発生する可能性がある場合は、Path MTU Discoveryを無効にする必要があります。前述したように、この設定では、SWAのMTUを手動で設定する追加の手順は、 etherconfig CLIコマンドが必要です。
ファイアウォール
デフォルト設定では、SWAは接続をプロキシするときにクライアントIPアドレスをスプーフィングしません。これは、すべての発信Webトラフィックの送信元がSWAのIPアドレスであることを意味します。ネットワークアドレス変換(NAT)デバイスに、これに対応できる十分な大きさの外部アドレスとポートのプールがあることを確認する必要があります。この目的のために特定のアドレスを割り当てることをお勧めします。
一部のファイアウォールでは、サービス拒否(DoS)保護や、単一のクライアントIPアドレスから大量の同時接続が発信されたときにトリガーされるその他のセキュリティ機能が採用されています。クライアントのIPスプーフィングが有効になっていない場合は、SWAのIPアドレスをこれらの保護から除外する必要があります。
Unicast Reverse Path Forwarding
SWAは、クライアントと通信するときにサーバのIPアドレスをスプーフィングします。オプションで、アップストリームサーバと通信するときにクライアントのIPアドレスをスプーフィングするように設定できます。Unicast Reverse Path Forwarding(uRPF)などの保護をスイッチで有効にして、着信パケットが予期される入力ポートに一致するようにできます。これらの保護により、パケットの送信元インターフェイスがルーティングテーブルと照合され、期待されるポートに到着したことが確認されます。必要に応じて、SWAをこれらの保護から除外する必要があります。
WCCPによるIPスプーフィング
SWAでIPスプーフィング機能が有効になっている場合、アウトバウンド要求は、アプライアンスが元のクライアント要求の送信元アドレスを使用しないようにします。これには、要求を発信したクライアントではなくSWAアウトバウンドインターフェイスに戻りパケットがルーティングされるように、関連するネットワークインフラストラクチャを追加設定する必要があります。
WCCPがネットワークデバイス（ルータ、スイッチ、またはファイアウォール）に実装されると、アクセスコントロールリスト(ACL)に基づいてトラフィックを照合するサービスIDが定義されます。その後、サービスIDがインターフェイスに適用され、リダイレクト用のトラフィックの照合に使用されます。IPスプーフィングが有効な場合は、リターントラフィックもSWAにリダイレクトされるように、2つ目のサービスIDを作成する必要があります。
SWAネットワークの設定
インターフェイス
SWAには、使用可能な5つのネットワークインターフェイス（M1、P1、P2、T1、およびT2）があります。これらはそれぞれ、可能な限り特定の目的に利用する必要があります。各ポートは、それぞれの理由で使用することをお勧めします。M1インターフェイスを専用の管理ネットワークに接続し、管理サービスの露出を制限するためにスプリットルーティングを有効にする必要があります。P1はクライアント要求トラフィックに制限できますが、P2は明示的なプロキシ要求を受け入れることができません。これにより、各インターフェイスのトラフィック量が減少し、ネットワーク設計のセグメント化が向上します。
T1およびT2ポートは、レイヤ4トラフィックモニタ(L4TM)機能で使用できます。この機能は、ミラー化されたレイヤ2ポートを監視し、既知の悪意のあるIPアドレスとドメイン名のブロックされたリストに基づいてトラフィックをブロックする機能を追加します。これは、トラフィックの送信元と宛先のIPアドレスを調べることによって行われ、ブロックされたリストが一致する場合はTCPリセットパケット、またはポート到達不能メッセージを送信します。任意のプロトコルで送信されたトラフィックは、この機能でブロックできます。
L4TM機能が有効になっていなくても、T1およびT2ポートがミラーポートに接続されている場合は、トランスペアレントバイパスを強化できます。WCCPの場合、SWAは着信パケットの送信元と宛先のIPアドレスだけを認識し、その情報に基づいてパケットをプロキシするか、またはバイパスするかを決定する必要があります。SWAは、レコードの存続可能時間(TTL)に関係なく、バイパス設定リストのすべてのエントリを30分ごとに解決します。ただし、L4TM機能が有効になっている場合、SWAはスヌーピングされたDNSクエリを使用して、これらのレコードをより頻繁に更新できます。これにより、クライアントがSWAとは異なるアドレスを解決した場合の誤検出のリスクが軽減されます。
管理ネットワークルーティング
専用管理ネットワークがインターネットにアクセスできない場合、各サービスはデータルーティングテーブルを使用するように設定できます。これはネットワークトポロジに合わせて調整できますが、一般に、すべてのシステムサービスに管理ネットワークを使用し、クライアントトラフィックにデータネットワークを使用することをお勧めします。AsyncOSバージョン11.0では、ルーティングを設定できるサービスは次のとおりです。
- 外部URLフィード
- 高度なマルウェア防御(AMP)ファイルレピュテーションと分析
- アップデートとアップグレード
- DNS
- Active Directory
管理トラフィックの追加の出力フィルタリングでは、次のサービスで使用するためにスタティックアドレスを設定できます。
- 外部URLフィード：
1.カスタムはホストされる場所によって異なる
2. AMPファイルのレピュテーションと分析
3. cloud-sa.amp.cisco.com（北米）
4. cloud-sa.eu.amp.cisco.com（欧州）
5. cloud-sa.apjc.amp.cisco.com（アジア太平洋）
- アップデートとアップグレード：
1. downloads-static.ironport.com
2. updates-static.ironport.com
ターロステレメトリ
Cisco Talosグループは、新たな脅威を特定することで知られています。Talosに送信されるすべてのデータは匿名化され、米国のデータセンターに保存されます。SensorBaseに参加することで、Web脅威の分類と特定が強化され、SWAやその他のシスコセキュリティソリューションからの保護が強化されます。
DNS
ドメインネームサーバー(DNS)セキュリティのベストプラクティスでは、すべてのネットワークで2つのDNSリゾルバーをホストする必要があることを提案しています。1つはローカルドメイン内からの権限のあるレコード用で、もう1つはインターネットドメインの再帰的な解決用です。これに対応するため、SWAではDNSサーバを特定のドメイン用に設定できます。ローカルクエリと再帰クエリの両方で1つのDNSサーバーしか使用できない場合は、すべてのSWAクエリに使用するときに追加される負荷を考慮してください。ローカルドメインには内部リゾルバを使用し、外部ドメインにはルートインターネットリゾルバを使用する方が良い方法です。これは、管理者のリスクプロファイルと許容範囲によって異なります。
デフォルトでは、SWAはレコードのTTLに関係なく、30分以上DNSレコードをキャッシュします。コンテンツ配信ネットワーク(CDN)を多用する最近のWebサイトは、IPアドレスが頻繁に変更されるため、TTLレコードが低くなっています。その結果、クライアントは特定のサーバに対して1つのIPアドレスをキャッシュし、SWAは同じサーバに対して異なるアドレスをキャッシュすることになります。これに対処するために、次のCLIコマンドを使用して、SWAのデフォルトTTLを5分に下げることができます。
SWA_CLI> dnsconfig
...
Choose the operation you want to perform:
- NEW - Add a new server.
- EDIT - Edit a server.
- DELETE - Remove a server.
- SETUP - Configure general settings.
- SEARCH - Configure DNS domain search list.
[]> SETUP
...
Enter the minimum TTL in seconds for DNS cache.
...
プライマリが使用できない場合は、セカンダリDNSサーバを設定する必要があります。すべてのサーバが同じ優先順位で設定されている場合、サーバIPはランダムに選択されます。設定されているサーバの数によって、特定のサーバのタイムアウトは異なります。テーブルは、最大6台のDNSサーバに対するクエリのタイムアウトです。
| DNSサーバの数 | クエリのタイムアウト（順番） |
| 1 | 60 |
| 2 | 5 45 |
| 3 | 5、10、45 |
| 4 | 1、3、11、45 |
| 5 | 1、3、11、45、1 |
| 6 | 1、3、11、45、1、1 |
また、CLIからのみ使用できる高度なDNSオプションもあります。CLIでは次のオプションを使用できます。
advancedproxyconfig > DNS コマンドを使用して、アップグレードを実行します。次のいずれかのオプションを選択します。
- 0：常に順番にDNS応答を使用する
- 1：クライアントが指定したアドレスを使用し、次にDNS
- 2:DNSの使用に制限がある
- 3:DNSの使用が非常に限られている
オプション1および2では、Webレピュテーションが有効な場合はDNSが使用されます。
オプション2および3では、アップストリームプロキシがない場合、または設定されたアップストリームプロキシが失敗した場合に、明示的なプロキシ要求にDNSが使用されます。
すべてのオプションで、ポリシーメンバーシップで宛先IPアドレスが使用される場合にDNSが使用されます。
これらのオプションは、クライアント要求を評価するときにSWAが接続先のIPアドレスをどのように決定するかを制御します。要求を受信すると、SWAは宛先IPアドレスとホスト名を確認します。SWAは、TCP接続の元の宛先IPアドレスを信頼するか、独自のDNS解決を行って解決済みのアドレスを使用するかを決定する必要があります。デフォルトは「0 = Always use DNS answers in order」です。これは、SWAがクライアントにIPアドレスを提供することを信頼しないことを意味します。
- オプション1:SWAは接続のためにクライアントが指定したIPアドレスを試行しますが、失敗した場合は解決済みのアドレスにフォールバックします。解決されたアドレスは、ポリシー評価(Webカテゴリ、Webレピュテーションなど)に使用されます。
- オプション2:SWAは接続にクライアント指定のアドレスのみを使用し、フォールバックしません。解決されたアドレスは、ポリシー評価（Webカテゴリ、Webレピュテーションなど）に使用されます。
- オプション3:SWAは接続にクライアント指定のアドレスのみを使用し、フォールバックしません。クライアントが指定したIPアドレスは、ポリシー評価（Webカテゴリ、Webレピュテーションなど）に使用されます。
選択するオプションは、特定のホスト名に対して解決されるアドレスを決定する際に、管理者がクライアントに設定する必要がある信頼度によって異なります。クライアントがダウンストリームプロキシである場合は、不要なDNSルックアップの追加の遅延を回避するためにオプション3を選択します。
ロード バランシング
WCCPでは、最大8台のアプライアンスを使用する場合に、透過的なトラフィックロードバランシングが可能です。これにより、ハッシュまたはマスクに基づいてトラフィックフローのバランスを取り、ネットワーク内にアプライアンスモデルが混在する場合に重み付けを行い、ダウンタイムなしでデバイスをサービスプールに追加したりサービスプールから削除したりできます。8つのSWAで処理できる量を超えるニーズがある場合は、専用のロードバランサを使用することをお勧めします。
WCCP設定の具体的なベストプラクティスは、使用するプラットフォームによって異なります。Cisco Catalyst®スイッチのベストプラクティスは、Cisco Catalyst Instant Accessソリューションのホワイトペーパーに記載されています。
WCCPをCisco適応型セキュリティアプライアンス(ASA)と併用する場合には制限があります。つまり、クライアントIPスプーフィングはサポートされておらず、クライアントとSWAは同じインターフェイスの背後にある必要があります。このため、レイヤ4スイッチまたはルータを使用してトラフィックをリダイレクトする方が柔軟です。ASAプラットフォームでのWCCPの設定については、『ASAでのWCCP：概念、制限事項、および設定』を参照してください。
明示的な導入では、プロキシ自動設定(PAC)ファイルが最も広く導入されている方法ですが、このドキュメントでは説明しない多くの欠点とセキュリティの影響があります。PACファイルを展開する場合、場所の構成にグループポリシーオブジェクト(GPO)を使用することをお勧めします。WPAD (Web Proxy Autodiscover Protocol)は攻撃者の一般的なターゲットであり、誤って構成すると悪用される可能性があります。SWAは複数のPACファイルをホストし、ブラウザのキャッシュ内でそれらの有効期限を制御できます。
PACファイルは、設定可能なTCPポート番号（デフォルトでは9001）からSWAに直接要求できます。ポートが指定されていない場合、要求はアウトバウンドWeb要求であるかのようにプロキシプロセス自体に送信できます。この場合、要求に存在するHTTPホストヘッダーに基づいて特定のPACファイルを提供できます。
ハイアベイラビリティ環境でKerberosを使用する場合は、別の方法で設定する必要があります。SWAはkeytabファイルをサポートします。これにより、複数のホスト名をサービスプリンシパル名(SPN)に関連付けることができます。詳細については、『高可用性展開でのKerberos認証用のWindows Active Directoryでのサービスアカウントの作成』を参照してください。
アクティブ認証
Kerberosは、NT LAN Manager Security Support Provider(NTLMSSP)よりも安全で、広くサポートされている認証プロトコルです。Apple OS XオペレーティングシステムはNTLMSSPをサポートしていませんが、ドメインが参加している場合はKerberosを使用して認証できます。基本認証はHTTPヘッダーで暗号化されずにクレデンシャルを送信し、ネットワーク上の攻撃者によって簡単にスニッフィングされる可能性があるため、使用しないでください。基本認証を使用する必要がある場合は、クレデンシャルが暗号化されたトンネル経由で送信されるように、クレデンシャルの暗号化を有効にする必要があります。
アベイラビリティを確保するために複数のドメインコントローラを設定に追加する必要がありますが、このトラフィックに固有のロードバランシングはありません。SWAは、設定されたすべてのドメインコントローラにTCP SYNパケットを送信し、最初に応答したドメインコントローラが認証に使用されます。
認証設定ページで設定された「リダイレクトホスト名」によって、認証を完了するための透過クライアントの送信先が決まります。Windowsクライアントが統合認証を完了してシングルサインオン(SSO)を実現するには、リダイレクトホスト名が[インターネットオプション]コントロールパネルの[信頼済みサイト]ゾーンにある必要があります。Kerberosプロトコルでは、リソースを指定するために完全修飾ドメイン名(FQDN)を使用する必要があります。つまり、Kerberosが目的の認証メカニズムである場合は、「ショートネーム」（または「NETBIOS」名）は使用できません。FQDNは、手動で「信頼済みサイト」に追加する必要があります（グループポリシーを使用するなど）。また、ユーザ名とパスワードを使用した自動ログインは、「インターネットオプション」コントロールパネルで設定する必要があります。
Firefoxでは、ブラウザがネットワークプロキシによる認証を完了するために、追加の設定も必要です。これらの設定は、about:configページで設定できます。Kerberosが正常に完了するためには、リダイレクトホスト名をnetwork.negotiate-auth.trusted-urisオプションに追加する必要があります。NTLMSSPの場合は、network.automatic-ntlm-auth.trusted-urisオプションに追加する必要があります。
認証サロゲートは、認証が完了した後の設定された期間、認証されたユーザを記憶するために使用されます。発生するアクティブな認証イベントの数を制限するために、可能な限りIPサロゲートを使用する必要があります。クライアントのアクティブな認証は、特にKerberosが使用されている場合、リソースを大量に消費するタスクです。サロゲートタイムアウトはデフォルトで3600秒（1時間）で、値を下げることができますが、推奨値の最小値は900秒（15分）です。
次の図は、「redirect.WSA.lab」がリダイレクトホスト名としてどのように使用されるかを示しています。
パッシブ認証
SWAは、他のシスコのセキュリティプラットフォームを利用して、プロキシユーザを受動的に特定できます。ユーザをパッシブに識別することで、SWAからの直接認証のチャレンジやActive Directory通信が不要になり、アプライアンスでの遅延やリソースの使用が減少します。現在、パッシブ認証に使用できるメカニズムは、Context Directory Agent(CDA)、Identity Services Engine(ISE)、およびIdentity Services Connector Passive Identity Connector(ISE-PIC)です。
ISEは、管理者が認証サービスを一元化し、広範なネットワークアクセス制御を活用できるようにする機能豊富な製品です。ISEが（Dot1x認証またはWeb認証リダイレクトを通じて）ユーザ認証イベントについて学習すると、認証に関係するユーザとデバイスに関する情報を含むセッションデータベースにデータを入力します。SWAはPlatform Exchange Grid(pxGrid)を介してISEに接続し、プロキシ接続に関連付けられたユーザ名、IPアドレス、およびセキュリティグループタグ(SGT)を取得します。AsyncOSバージョン11.7以降、SWAはISE上で外部Restfulサービス(ERS)に照会してグループ情報を取得することもできます。
推奨されるバージョンはISE 3.1およびSWA 14.0.2-X以降です。SWAのISE互換性マトリクスの詳細については、『セキュアWebアプライアンスのISE互換性マトリクス』を参照してください。
完全な統合手順の詳細については、『Webセキュリティアプライアンスエンドユーザガイド』を参照してください。
シスコは、Cisco Context Directory Agent(CDA)ソフトウェアのサポート終了を発表します。Cisco Context Directory Agent(CDA)を参照してください。
CDAパッチ6では、Microsoft Server 2016と互換性があります。ただし、管理者はCDAの導入をISE-PICに移行することを積極的に推奨します。どちらのソリューションも、WMIを使用してWindowsセキュリティイベントログを購読し、ユーザとIPのマッピング（「セッション」と呼ばれる）を生成します。CDAの場合、SWAはRADIUSを使用してこれらのマッピングを照会します。ISE-PICの場合、完全なISE導入と同じpxGrid接続とERS接続が使用されます。ISE-PIC機能は、完全なISEインストールと、スタンドアロンの仮想アプライアンスで使用できます。
サービスの設定
Webプロキシ
帯域幅を節約し、パフォーマンスを向上させるには、Webプロキシ設定でキャッシングを有効にする必要があります。SWAはデフォルトではHTTPSトランザクションをキャッシュしないため、HTTPSトラフィックの割合が増加するにつれ、これは重要性が低下しています。プロキシが明示的なクライアントだけにサービスを提供するように展開されている場合は、プロキシサービスを宛先としないトラフィックを拒否するために、転送モードを指定する必要があります。このようにして、アプライアンスの攻撃対象が減少し、優れたセキュリティ原則が実践されます。必要でない場合はオフにします。
範囲要求ヘッダーは、ダウンロードするファイルのバイト範囲を指定するためにHTTP要求で使用されます。オペレーティングシステムやアプリケーションの更新デーモンは、ファイルの小さな部分を一度に転送するためによく使用されます。デフォルトでは、SWAはこれらのヘッダーを除去するため、ウイルス対策(AV)スキャン、ファイルレピュテーションと分析、およびApplication Visibility Control(AVC)の目的でファイル全体を取得できます。プロキシ設定で範囲要求ヘッダーの転送をグローバルに有効にすると、管理者は、これらのヘッダーを転送または削除する個別のアクセスポリシーを作成できます。この設定についての詳細は、「アクセスポリシー」セクションを参照してください。
HTTPSプロキシ
セキュリティのベストプラクティスでは、秘密鍵が使用されるアプライアンスで秘密鍵を生成する必要があり、他の場所に転送されることはないことを推奨しています。HTTPSプロキシウィザードを使用すると、Transport Layer Security(TLS)接続の復号化に使用するキーペアと証明書を作成できます。その後、証明書署名要求(CSR)をダウンロードし、社内の認証局(CA)によって署名できます。Active Directory(AD)環境では、ADに統合されたCAはドメインのすべてのメンバーによって自動的に信頼され、証明書を展開するために追加の手順を必要としないため、これが最良の方法です。
HTTPSプロキシのセキュリティ機能の1つは、サーバ証明書を検証することです。ベストプラクティスは、無効な証明書では接続をドロップする必要があることを示しています。EUNの復号化を有効にすると、SWAはブロックの理由を説明するブロックページを表示できます。これを有効にしないと、ブロックされたHTTPSサイトでブラウザエラーが発生します。これにより、ヘルプデスクのチケットが増加し、SWAが接続をブロックしたという認識ではなく、何かが壊れているというユーザ側の想定が生じます。すべての無効な証明書オプションは、少なくともDecryptに設定する必要があります。証明書の問題によってサイトの読み込みが妨げられた場合、これらのオプションのいずれかをモニタのままにしても、有用なエラーメッセージは記録されません。
同様に、Online Certificate Services Protocol(OCSP)チェックは有効のままにしておき、どのオプションに対してもモニタを使用しないでください。関連するエラーメッセージのロギングを許可するには、失効した証明書を削除し、その他すべての証明書を少なくともDecryptに設定する必要があります。機関情報アクセス追跡（AIA追跡）は、クライアントが証明書の署名者と、追加の証明書をフェッチできるURLを収集できる手段です。たとえば、サーバから受信した証明書チェーンが不完全である（中間証明書またはルート証明書がない）場合、SWAはAIAフィールドをチェックし、それを使用して不足している証明書を取得し、信頼性を検証できます。この設定は、CLIで次のコマンドからのみ使用できます。
SWA_CLI> advancedproxyconfig
Choose a parameter group:
- AUTHENTICATION - Authentication related parameters
- CACHING - Proxy Caching related parameters
- DNS - DNS related parameters
- EUN - EUN related parameters
- NATIVEFTP - Native FTP related parameters
- FTPOVERHTTP - FTP Over HTTP related parameters
- HTTPS - HTTPS related parameters
- SCANNING - Scanning related parameters
- PROXYCONN - Proxy connection header related parameters
- CUSTOMHEADERS - Manage custom request headers for specific domains
- MISCELLANEOUS - Miscellaneous proxy related parameters
- SOCKS - SOCKS Proxy parameters
- CONTENT-ENCODING - Block content-encoding types
- SCANNERS - Scanner related parameters
[]> HTTPS
...
Do you want to enable automatic discovery and download of missing Intermediate Certificates?
[Y]>
...
レイヤ4トラフィックモニタ(L4TM)
L4TMは、SWAの範囲を拡張して、プロキシを通過しない悪意のあるトラフィック、およびすべてのTCPポートとUDPポートのトラフィックを含める非常に効果的な方法です。T1およびT2ポートは、ネットワークタップまたはスイッチモニタセッションに接続するように設計されています。スイッチモニタセッションを使用すると、SWAはクライアントからのすべてのトラフィックを受動的にモニタできます。悪意のあるIPアドレス宛てのトラフィックが見つかった場合、SWAはサーバのIPアドレスをスプーフィングしながらRSTを送信することでTCPセッションを終了できます。UDPトラフィックの場合は、Port Unreachableメッセージを送信できます。モニタセッションを設定する際には、SWAの管理インターフェイス宛てのトラフィックを除外して、この機能がデバイスへのアクセスを妨げる可能性を防ぐことをお勧めします。
L4TMは、悪意のあるトラフィックのモニタリングに加えて、バイパス設定リストを更新するためにDNSクエリもスヌーピングします。このリストは、Webサーバへの直接ルーティングのために特定の要求をWCCPルータに戻すためにWCCP展開で使用されます。バイパス設定リストに一致するパケットは、プロキシによって処理されません。リストには、IPアドレスまたはサーバ名を含めることができます。SWAは、レコードのTTLにかかわらず、バイパス設定リストのすべてのエントリを30分ごとに解決します。ただし、L4TM機能が有効になっている場合、SWAはスヌーピングされたDNSクエリを使用して、これらのレコードをより頻繁に更新できます。これにより、クライアントがSWAとは異なるアドレスを解決した場合の誤検出のリスクが軽減されます。
ポリシーの設定
SWAのパフォーマンスとスケーラビリティの中心となるのは、正しいポリシー設定です。これは、クライアントの保護と企業の要件の適用においてポリシー自体が効果的であるからというだけではありません。ポリシーの設定方法は、リソースの使用率やSWAの全体的な健全性とパフォーマンスに直接影響します。ポリシーが複雑すぎたり、不適切に設計されたりすると、アプライアンスが不安定になったり、応答が遅くなったりすることがあります。
複雑度
SWAポリシーの構築には、さまざまなポリシー要素が使用されます。設定から生成されたXMLファイルは、多数のバックエンド設定ファイルとアクセスルールを作成するために使用されます。設定が複雑になればなるほど、プロキシプロセスは各トランザクションのさまざまなルールセットの評価に多くの時間を費やす必要があります。SWAのベンチマークとサイジングでは、設定の複雑さの3階層を表すポリシー要素の基本セットが作成されます。10個のアイデンティティプロファイル、復号化ポリシー、アクセスポリシー、および10個の正規表現項目、50個のサーバIPアドレス、420個のサーバホスト名を含む10個のカスタムカテゴリは、低複雑度の設定と見なされます。これらの各数値に2と3を掛けると、それぞれ中複雑度と高複雑度の設定になります。
設定が複雑すぎると、通常、最初の症状としてWebインターフェイスやCLIでの応答が遅くなります。最初は、ユーザに大きな影響を与えることはできません。ただし、設定が複雑になるほど、プロキシプロセスがユーザモードで費やす必要がある時間が長くなります。このため、このモードで費やされた時間のパーセンテージを調べることは、SWAの速度低下の原因として非常に複雑な設定を診断する場合に便利な方法です。
CPU時間（秒単位）は、5分ごとにtrack_statsログに記録されます。つまり、ユーザ時間のパーセンテージは、（ユーザ時間+システム時間）/300として計算できます。ユーザ時間が270に近づくと、プロセスはユーザモードで非常に多くのCPUサイクルを消費します。これはほとんどの場合、設定が複雑すぎて効率的に解析できないためです。
注:SWAの同時接続の最大数は60,000で、同時サーバ接続の数は60,000です。
識別プロファイル
Identification(ID)プロファイルは、新しい要求が受信されたときに評価される最初のポリシー要素です。IDプロファイルの最初のセクションで設定されたすべての情報は、論理ANDで評価されます。つまり、要求がプロファイルに一致するには、すべての条件が一致する必要があります。ポリシーを作成する際には、必ず必要な範囲で具体的に指定する必要があります。個々のホストアドレスを含むプロファイルはほとんど必要なく、無秩序な構成につながる可能性があります。一般に、プロファイルの範囲を制限するには、HTTPヘッダー、カスタムカテゴリリスト、またはサブネットにあるユーザエージェント文字列を利用する方が適しています。
一般に、認証を必要とするポリシーは最下部に設定され、その上に例外が追加されます。認証を必要としないポリシーをオーダーする場合、最も使用されるポリシーはできるだけ上位に近いポリシーにする必要があります。失敗した認証に依存してアクセスを制限しないでください。ネットワーク上のクライアントがプロキシに対して認証できないことがわかっている場合は、認証を免除して、アクセスポリシーでブロックする必要があります。認証を繰り返すことができないクライアントは、認証されていない要求をSWAに送信します。SWAはリソースを使用し、CPUとメモリの過度の使用率を引き起こす可能性があります。
管理者は、一意のIDプロファイルと、それに対応する復号化ポリシーおよびアクセスポリシーが必要であると誤解することがよくあります。これは、ポリシー設定に対する非効率的な戦略です。可能な場合は、ポリシーを「折りたたむ」必要があります。これにより、1つのIDプロファイルを複数の復号化ポリシーおよびアクセスポリシーに関連付けることができます。これは、トラフィックがポリシーに一致するために、特定のポリシー内のすべての条件が一致する必要があるためです。認証ポリシーをより一般的にし、結果として生じるポリシーをより詳細に指定することで、全体としてポリシーの数を減らすことができます。
復号化ポリシー
IDプロファイルと同様に、復号化ポリシーで設定された基準も論理ANDとして評価されます。ただし、ISEからの情報が使用される場合は、1つの重要な例外があります。設定されている要素（ADグループ、ユーザ、またはSGT）に応じて、ポリシー照合がどのように機能するかを次に示します。
- ADグループおよびユーザ：以前の動作に変更はありません。ユーザがグループのメンバーである場合、またはユーザがポリシーで指定されている場合は、ポリシーが一致します。
- SGTおよびADグループおよびユーザ：ユーザがSGTに関連付けられておりADグループのメンバーである場合、またはポリシーでユーザが指定されている場合は、ポリシーが一致します。
- SGTおよびユーザ：ユーザがSGTに関連付けられているか、ポリシーでユーザが指定されている場合に、一致したポリシー。
SWAで実行されるすべてのサービスの中で、パフォーマンスの観点から見ると、HTTPSトラフィックの評価が最も重要です。復号化されたトラフィックの割合は、アプライアンスのサイジング方法に直接影響します。管理者は、Webトラフィックの少なくとも75 %をHTTPSと見なすことができます。
最初のインストール後、将来の成長に対する期待が正確に設定されるように、復号化されたトラフィックの割合を決定する必要があります。導入後は、この数値を四半期に1回確認する必要があります。SWAによって復号化されたHTTPSトラフィックの割合は、追加のログ管理ソフトウェアがなくても、access_logsのコピーを使用して簡単に確認できます。この番号は、単純なBashまたはPowerShellコマンドを使用して取得できます。各環境について説明する手順を次に示します。
1. HTTPS接続の総数（明示的および透過的の両方）を確認します。
Bash:
grep -cE 'tunnel://|TCP_CONNECT' aclog.current
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT').length2.復号化されたHTTPS接続の数を調べます。
Bash:
grep -E 'tunnel://|TCP_CONNECT' aclog.current | grep -c DECRYPT
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT’| Select-String -Pattern ‘DECRYPT’).length3. 2番目の値を1番目の値で割り、100を掛けます。
復号化ポリシーを設計する際には、ポリシーに記載されているさまざまなアクションによって、アプライアンスがどのようにHTTPS接続を評価するかを理解することが重要です。パススルーアクションは、SWAがすべてのパケットを復号化せずに、クライアントとサーバがTLSセッションの各終端を終端できるようにする必要がある場合に使用されます。サイトがパススルーに設定されている場合でも、SWAはサーバとの1つのTLSハンドシェイクを完了する必要があります。これは、SWAが証明書の有効性に基づいて接続をブロックし、証明書を取得するためにサーバとのTLS接続を開始する必要があるためです。証明書が有効な場合、SWAは接続を閉じ、クライアントがサーバと直接セッションのセットアップを続行できるようにします。
SWAがTLSハンドシェイクを実行しない唯一のケースは、サーバ名またはIPアドレスがカスタムカテゴリに存在し（パススルーに設定）、サーバ名がHTTP CONNECTまたはTLS Client Helloのいずれかで使用できる場合です。明示的なシナリオでは、クライアントはTLSセッションの開始前に（ホストヘッダー内で）プロキシにサーバのホスト名を提供するため、このフィールドはカスタムカテゴリに対してチェックされます。透過的な導入では、SWAはTLS Client HelloメッセージのServer Name Indication(SNI)フィールドを確認し、カスタムカテゴリと照合して評価します。ホストヘッダーまたはSNIが存在しない場合、SWAはサーバとのハンドシェイクを続行して、証明書のSubject Alternative Name(SAN)フィールドとCommon Name(CN)フィールドをその順序で確認する必要があります。
このポリシー設計における動作の意味は、既知の内部で信頼されるサーバを決定し、カスタムカテゴリリストからパススルーするように設定することで、TLSハンドシェイクの数を削減できることです。Webカテゴリとレピュテーションスコアに依存する必要はなく、SWAは引き続きサーバとのTLSハンドシェイクを完了する必要があります。ただし、これにより証明書の有効性チェックができなくなることに注意してください。
新しいサイトがWebに表示される速度は、SWAが使用するWebレピュテーションおよび分類データベースによって分類されていないサイトが多数ある可能性があります。これは、サイトが悪意のある可能性が必ずしも高いことを示しているわけではありません。さらに、これらすべてのサイトは、AVスキャン、AMPファイルのレピュテーションと分析、設定されているオブジェクトのブロックまたはスキャンの対象となります。このような理由から、ほとんどの場合、分類されていないサイトを削除することはお勧めしません。AVエンジンによって復号化およびスキャンされ、AVC、AMP、アクセスポリシーなどによって評価されるように設定するのが最善です。カテゴリ化されていないサイトの詳細については、「アクセスポリシー」セクションを参照してください。
アクセスポリシー
IDプロファイルと同様に、復号化ポリシーで設定された基準も、ISEからの情報を使用する際の1つの重要な例外を除いて、論理的なANDとして評価されます。次に、設定されている要素（ADグループ、ユーザ、またはSGT）に基づいて、ポリシー照合の動作について説明します。
- ADグループおよびユーザ：以前の動作に変更はありません。ユーザがグループのメンバーであるか、またはユーザがポリシーで指定されている場合は、ポリシーが一致しています。
- SGTおよびADのグループとユーザ：ユーザがSGTに関連付けられており、ADグループのメンバーであるか、またはポリシーでユーザが指定されている場合に一致するポリシー。
- SGTおよびユーザ：ユーザがSGTに関連付けられているか、ポリシーでユーザが指定されている場合に、一致したポリシー。
HTTPトラフィックは、認証後すぐにアクセスポリシーに対して評価されます。HTTPSトラフィックは、認証後、および一致する復号化ポリシーごとに復号化アクションが適用されるかどうかが評価されます。復号化された要求には、2つのaccess_logエントリがあります。最初のログエントリは最初のTLS接続（復号化）に適用されたアクションを示し、2番目のログエントリは復号化されたHTTP要求に対してアクセスポリシーによって適用されたアクションを示します。
「Webプロキシ」セクションで説明されているように、要求ヘッダーはファイルの特定のバイト範囲を要求するために使用され、一般的にOSとアプリケーション更新サービスによって使用されます。SWAでは、ファイル全体がなければマルウェアスキャンを実行したりAVC機能を利用したりできないため、デフォルトでこれらのヘッダーが発信要求から削除されます。ネットワーク上の多くのホストが更新を取得するために小さなバイト範囲を頻繁に要求している場合、これによりSWAがファイル全体を同時に数回ダウンロードする可能性があります。これにより、使用可能なインターネット帯域幅が急速に使い果たされ、サービスが停止する可能性があります。この障害の最も一般的な原因は、Microsoft WindowsのアップデートとAdobeソフトウェアのアップデートデーモンです。
これを軽減する最善のソリューションは、このトラフィックをSWAに完全に誘導することです。これはトランスペアレントに展開された環境では必ずしも実現可能ではありません。このような場合は、トラフィック専用のアクセスポリシーを作成し、それらのポリシーで範囲要求ヘッダー転送を有効にすることが次善のオプションです。これらの要求に対してAVスキャンとAVCは不可能であることを考慮する必要があります。そのため、ポリシーは目的のトラフィックのみを対象とするように慎重に設計する必要があります。多くの場合、これを実現する最善の方法は、要求ヘッダーにあるユーザエージェント文字列を照合することです。一般的な更新デーモンのユーザエージェント文字列は、オンラインで見つけることも、管理者が要求をキャプチャして調べることもできます。Microsoft WindowsのアップデートやAdobeソフトウェアのアップデートなど、ほとんどのアップデートサービスではHTTPSは使用されません。
「復号化ポリシー」セクションで説明したように、未分類のサイトを復号化ポリシーに含めないことはお勧めしません。同じ理由から、アクセスポリシーでこれらをブロックすることは推奨されません。動的コンテンツ分析(DCA)エンジンは、特定のサイトのコンテンツを、URLデータベース検索によって未分類とマークされるカテゴリ化されたサイトに対するその他のヒューリスティックデータと共に使用できます。この機能を有効にすると、SWAの未分類の判定の数が減少します。
アクセスポリシーのオブジェクトスキャン設定には、複数のタイプのアーカイブファイルを検査する機能があります。ネットワークが定期的にアプリケーションアップデートの一部としてアーカイブファイルをダウンロードする場合、これを有効にするとCPU使用率が大幅に増加する可能性があります。すべてのアーカイブファイルを検査する場合は、このトラフィックを事前に特定して除外する必要があります。このトラフィックを識別するために考えられる方法を調査する最初の場所は、ユーザエージェント文字列です。これは、IP許可リストの維持が困難になるのを防ぐのに役立ちます。
カスタムおよび外部URLカテゴリ
カスタムカテゴリリストは、IPアドレスまたはホスト名でサーバを識別するために使用されます。正規表現(regex)を使用して、サーバ名を照合するパターンを指定できます。サーバ名の照合に部分文字列の照合を使用するよりも、正規表現パターンを使用する方がはるかに多くのリソースを消費するため、これらを使用するのは絶対に必要な場合に限ります。正規表現を使用せずにサブドメインと一致させるには、ドメイン名の先頭に「。」を追加します。たとえば、「.cisco.com」も「www.cisco.com」に一致します。
「複雑度」の項で説明したように、低複雑度は10個のカスタムカテゴリリストとして定義され、中複雑度は20個、高複雑度は30個として定義されます。特にリストが正規表現パターンを使用する場合やエントリ数が多い場合は、この数値を20未満に抑えることをお勧めします。各タイプのエントリ数の詳細については、「アクセスポリシー」セクションを参照してください。
外部URLフィードは、静的なカスタムカテゴリリストよりもはるかに柔軟です。外部URLフィードを利用すると、管理者が手動で保持する必要がなくなるため、セキュリティに直接影響する可能性があります。この機能を使用すると、SWA管理者によって管理されていないリストを取得できるため、ダウンロードされたアドレスに個別の例外を追加する機能は、AsyncOSバージョン11.8で追加されました。
Office 365 APIは、この一般的に展開されるサービスに対してポリシーを決定する際に特に役立ち、個々のアプリケーション（PowerPoint、Skype、Wordなど）に利用できます。Microsoftでは、パフォーマンスを最適化するために、すべてのOffice365トラフィックのプロキシをバイパスすることをお勧めします。Microsoftのドキュメントには次のように記載されています。
「SSL Break and Inspectが最大の遅延を生み出す一方で、プロキシ認証やレピュテーションルックアップなどの他のサービスは、パフォーマンスの低下やユーザエクスペリエンスの低下を引き起こす可能性があります。さらに、これらの境界ネットワークデバイスには、すべてのネットワーク接続要求を処理するのに十分な容量が必要です。Office 365ネットワークの直接要求に対して、プロキシまたはインスペクションデバイスをバイパスすることをお勧めします。"https://learn.microsoft.com/en-us/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide .
透過的なプロキシ環境でこのガイダンスを使用することは困難な場合があります。AsyncOSバージョン11.8以降では、Office365 APIから取得した動的なカテゴリリストを使用して、バイパス設定リストを設定できます。このリストは、直接ルーティングのために、透過的にリダイレクトされたトラフィックをWCCPデバイスに送り返すために使用されます。
すべてのOffice 365トラフィックをバイパスすると、このトラフィックの基本的なセキュリティ制御とレポートを必要とする管理者にとって盲点となります。Office 365トラフィックがSWAによってバイパスされない場合は、発生する可能性のある特定の技術的課題を理解することが重要です。その1つが、アプリケーションに必要な接続数です。サイジングは、Office 365アプリケーションに必要な追加の永続的なTCP接続に対応するように適切に調整する必要があります。これにより、ユーザごとの永続的なTCPセッションの総数が10 ～ 15増加する可能性があります。
HTTPSプロキシによって実行される復号化と再暗号化のアクションによって、接続に少しの遅延が生じます。Office 365アプリケーションは遅延の影響を非常に受けやすく、WAN接続の遅さや地理的な場所の分散などの要因によって遅延が増加すると、ユーザエクスペリエンスが低下する可能性があります。
一部のOffice 365アプリケーションは独自のTLSパラメータを使用しているため、HTTPSプロキシはアプリケーションサーバーとのハンドシェイクを完了できません。これは、証明書の検証またはホスト名の取得に必要です。これを、TLS Client HelloメッセージでServer Name Indication(SNI)フィールドを送信しないSkype for Businessなどのアプリケーションと組み合わせると、このトラフィックを完全にバイパスする必要が生じます。AsyncOS 11.8では、宛先IPアドレスのみに基づいてトラフィックをバイパスする機能が導入されており、このシナリオに対処するための証明書チェックは行われていません。
モニタとアラート
CLIモニタ
SWA CLIには、重要なプロセスをリアルタイムで監視するためのコマンドが用意されています。最も有用なのは、proxプロセスに関連する統計情報を表示するコマンドです。status detailコマンドは、リソース使用率およびパフォーマンス・メトリックのサマリーの参照元として適しています。このサマリーには、稼働時間、使用帯域幅、レスポンス待機時間、接続数などが含まれます。このコマンドの出力例を次に示します。
SWA_CLI> status detail
Status as of: Fri Nov 11 14:06:52 2022 +03
Up since: Fri Apr 08 10:15:00 2022 +03 (217d 3h 51m 52s)
System Resource Utilization:
CPU 3.3%
RAM 6.2%
Reporting/Logging Disk 45.6%
Transactions per Second:
Average in last minute 55
Maximum in last hour 201
Average in last hour 65
Maximum since proxy restart 1031
Average since proxy restart 51
Bandwidth (Mbps):
Average in last minute 4.676
Maximum in last hour 327.258
Average in last hour 10.845
Maximum since proxy restart 1581.297
Average since proxy restart 11.167
Response Time (ms):
Average in last minute 635
Maximum in last hour 376209
Average in last hour 605
Maximum since proxy restart 2602943
Average since proxy restart 701
Cache Hit Rate:
Average in last minute 0
Maximum in last hour 2
Average in last hour 0
Maximum since proxy restart 15
Average since proxy restart 0
Connections:
Idle client connections 186
Idle server connections 184
Total client connections 3499
Total server connections 3632
SSLJobs:
In queue Avg in last minute 4
Average in last minute 45214
SSLInfo Average in last min 94
Network Events:
Average in last minute 0.0
Maximum in last minute 35
Network events in last min 124502rateコマンドを使用すると、proxプロセスで使用されるCPUのパーセンテージ、Requests Per Second（RPS；要求/秒）の数、およびキャッシュの統計情報に関するリアルタイム情報が表示されます。このコマンドは、中断されるまでポーリングを続行し、新しい出力を表示します。このコマンドの出力例を次に示します。
SWA_CLI> rate
Press Ctrl-C to stop.
%proxy reqs client server %bw disk disk
CPU /sec hits blocks misses kb/sec kb/sec saved wrs rds
5.00 51 1 147 370 2283 2268 0.6 48 37
4.00 36 0 128 237 21695 21687 0.0 47 38
4.00 48 2 179 307 8168 8154 0.2 65 33
5.00 53 0 161 372 2894 2880 0.5 48 32
6.00 52 0 198 328 15110 15100 0.1 63 33
6.00 77 0 415 363 4695 4684 0.2 48 34
7.00 85 1 417 433 5270 5251 0.4 49 35
7.00 67 1 443 228 2242 2232 0.5 85 44tcpservicesコマンドは、選択されたプロセスのリスニングポートに関する情報を表示します。各プロセスの説明と、アドレスとポートの組み合わせも表示されます。
SWA_CLI> tcpservices
System Processes (Note: All processes may not always be present)
ftpd.main - The FTP daemon
ginetd - The INET daemon
interface - The interface controller for inter-process communication
ipfw - The IP firewall
slapd - The Standalone LDAP daemon
sntpd - The SNTP daemon
sshd - The SSH daemon
syslogd - The system logging daemon
winbindd - The Samba Name Service Switch daemon
Feature Processes
coeuslogd - Main WSA controller
gui - GUI process
hermes - Mail server for sending alerts, etc.
java - Processes for storing and querying Web Tracking data
musd - AnyConnect Secure Mobility server
pacd - PAC file hosting daemon
prox - WSA proxy
trafmon - L4 Traffic Monitor
uds - User Discovery System (Transparent Auth)
wccpd - WCCP daemon
COMMAND USER TYPE NODE NAME
connector root IPv4 TCP 127.0.0.1:8823
java root IPv6 TCP [::127.0.0.1]:18081
hybridd root IPv4 TCP 127.0.0.1:8833
gui root IPv4 TCP 172.16.40.80:8443
ginetd root IPv4 TCP 172.16.40.80:ssh
nginx root IPv6 TCP *:4431
nginx root IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
api_serve root IPv4 TCP 172.16.40.80:6080
api_serve root IPv4 TCP 127.0.0.1:60001
api_serve root IPv4 TCP 172.16.40.80:6443
chimera root IPv4 TCP 127.0.0.1:6380
nectar root IPv4 TCP 127.0.0.1:6382
redis-ser root IPv4 TCP 127.0.0.1:6383
redis-ser root IPv4 TCP 127.0.0.1:6379
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25255
prox root IPv4 TCP 127.0.0.1:socks
prox root IPv6 TCP [::1]:socks
prox root IPv4 TCP 172.16.11.69:socks
prox root IPv4 TCP 172.16.11.68:socks
prox root IPv4 TCP 172.16.11.252:socks
prox root IPv4 TCP 127.0.0.1:ftp-proxy
prox root IPv6 TCP [::1]:ftp-proxy
prox root IPv4 TCP 172.16.11.69:ftp-proxy
prox root IPv4 TCP 172.16.11.68:ftp-proxy
prox root IPv4 TCP 172.16.11.252:ftp-proxy
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25256
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.21.11.69:https
prox root IPv4 TCP 172.21.11.68:https
prox root IPv4 TCP 172.21.11.252:https
prox root IPv4 TCP 127.0.0.1:25257
smart_age root IPv6 TCP [::127.0.0.1]:65501
smart_age root IPv6 TCP [::127.0.0.1]:28073
interface root IPv4 TCP 127.0.0.1:domain
stunnel root IPv4 TCP 127.0.0.1:32137Logging
Webトラフィックは非常に動的で、変化に富んでいます。プロキシの導入が完了したら、アプライアンスを通過するトラフィックの量と構成を定期的に再評価することが重要です。復号化されたトラフィックの割合を定期的に（四半期に1回）チェックして、サイズが初期インストールの期待と仕様に一致していることを確認する必要があります。これは、Advanced Web Security Reporting(AWSR)などのログ管理製品、またはアクセスログを使用する単純なBashまたはPowerShellコマンドで実行できます。また、RPSの数も定期的に再評価して、高可用性のロードバランシングされた構成で、トラフィックの急増とフェールオーバーを考慮するための十分なオーバーヘッドがアプライアンスにあることを確認する必要があります。
track_statsログは5分ごとに追加され、メモリ内のproxプロセスとそのオブジェクトに直接関連する出力の複数のセクションが含まれます。パフォーマンスモニタリングで最も役立つのは、さまざまな要求プロセスの平均遅延を示すセクションです。これには、DNSルックアップ時間、AVエンジンのスキャン時間、その他多くの有用なフィールドが含まれます。このログは、GUIやCLIからは設定できず、Secure Copy Protocol(SCP)またはFile Transfer Protocol(FTP)からのみアクセスできます。これは、パフォーマンスのトラブルシューティングを行う際に最も重要なログであるため、頻繁にポーリングする必要があります。
個々のSHDログ行は60秒ごとに書き込まれ、遅延、RPS、およびクライアント側とサーバ側の合計接続など、パフォーマンスの監視に重要なフィールドが多数含まれています。SHDログ行の例を次に示します。
Fri Nov 11 14:16:42 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 62 Band 11383 Latency 619 CacheHit 0 CliConn 3817 SrvConn 3804 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:17:42 2022 Info: Status: CPULd 2.6 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 10532 Latency 774 CacheHit 0 CliConn 3546 SrvConn 3539 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:18:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.6 Reqs 48 Band 7285 Latency 579 CacheHit 0 CliConn 3418 SrvConn 3410 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:19:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.6 Reqs 52 Band 34294 Latency 791 CacheHit 0 CliConn 3605 SrvConn 3586 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:20:43 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 8696 Latency 691 CacheHit 0 CliConn 3455 SrvConn 3432 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:21:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 49 Band 7064 Latency 1403 CacheHit 0 CliConn 3339 SrvConn 3330 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:22:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.8 Reqs 41 Band 5444 Latency 788 CacheHit 0 CliConn 3227 SrvConn 3212 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:23:43 2022 Info: Status: CPULd 2.2 DskUtil 45.7 RAMUtil 6.8 Reqs 48 Band 6793 Latency 820 CacheHit 0 CliConn 3280 SrvConn 3265 MemBuf 1 SwpPgOut 250467 ProxLd 3 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:24:44 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 44 Band 8735 Latency 673 CacheHit 0 CliConn 3405 SrvConn 3389 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:25:44 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 53 Band 8338 Latency 731 CacheHit 0 CliConn 3637 SrvConn 3622 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0access_logsには、個々のリクエストの遅延情報を示すカスタムフィールドを追加できます。これらのフィールドには、サーバ応答、DNS解決、およびAVスキャナ遅延が含まれます。トラブルシューティングに使用する貴重な情報を収集するには、これらのフィールドをログに追加する必要があります。使用する推奨されるカスタムフィールド文字列は次のとおりです。
[ Request Details: ID = %I, User Agent = %u, AD Group Memberships = ( %m ) %g ] [ Tx Wait Times (in ms): 1st byte to server = %:<1, Request Header = %:
, Response Header = %:h>, Client Body = %:b> ] [ Rx Wait Times (in ms): 1st request byte = %:1<, Request Header = %:h<, Client Body = %:b<, 1st response byte = %:>1, Response header = %:>h, Server response = %:>b, Disk Cache = %:>c; Auth response = %:
a; DNS response = %:
d, WBRS response = %:
r, AVC response = %:A>, AVC total = %:A<, DCA response = %:C>, DCA total = %:C<, McAfee response = %:m>, McAfee total = %:m<, Sophos response = %:p>, Sophos total = %:p<, Webroot response = %:w>, Webroot total = %:w<, Anti-Spyware response = %:
s, AMP response = %:e>, AMP total = %:e<; Latency = %x; %L ][Client Port = %F, Server IP = %k, Server Port = %p]
これらの値から導き出されるパフォーマンス情報は次のとおりです。
| カスタムフィールド | 説明 |
| %:<a | Webプロキシが要求を送信した後、Webプロキシ認証プロセスから応答を受信するまでの待機時間。 |
| %:<b | ヘッダーの後に要求本文をサーバーに書き込むまでの待機時間。 |
| %:<d | Webプロキシが要求を送信した後、WebプロキシDNSプロセスから応答を受信するまでの待機時間。 |
| %:<h | 最初のバイトの後に要求ヘッダーをサーバに書き込むまでの待機時間。 |
| %:<r | Webプロキシが要求を送信した後、Webレピュテーションフィルタから応答を受信するまでの待機時間。 |
| %:<s | Webプロキシが要求を送信した後、Webプロキシのスパイウェア対策プロセスから判定を受け取るまでの待ち時間。 |
| %:> | サーバからの最初の応答バイトの待機時間。 |
| %:>a | Webプロキシ認証プロセスから応答を受信するまでの待機時間。Webプロキシが要求を送信するために必要な時間を含みます。 |
| %:>b | ヘッダーの受信後に応答本文を完了するまでの待機時間。 |
| %:>c | Webプロキシがディスクキャッシュから応答を読み取るのに必要な時間。 |
| %:>d | WebプロキシDNSプロセスからの応答を受信するまでの待機時間。Webプロキシが要求を送信するために必要な時間が含まれます。 |
| %:>h | 最初の応答バイトの後のサーバヘッダーの待機時間。 |
| %:>r | Webレピュテーションフィルタから判定を受け取るまでの待機時間には、Webプロキシが要求を送信するために必要な時間が含まれます。 |
| %:>秒 | Webプロキシのスパイウェア対策プロセスから判定を受け取るまでの待機時間には、Webプロキシが要求を送信するために必要な時間が含まれます。 |
| %:1< | 新しいクライアント接続からの最初の要求バイトの待機時間です。 |
| %:1> | クライアントに書き込まれた最初のバイトの待機時間。 |
| %:b< | クライアント本体の完了までの待機時間です。 |
| %:b> | 完全な本文がクライアントに書き込まれるまでの待機時間。 |
| %:e> | Webプロキシが要求を送信した後、AMPスキャンエンジンから応答を受信するまでの待機時間。 |
| %:e< |
AMPスキャンエンジンから判定を受け取るまでの待機時間。Webプロキシが要求を送信するために必要な時間を含みます。 |
| %:h< | 最初のバイトの後に完全なクライアントヘッダーを待機する時間。 |
| %:h> | 完全なヘッダーがクライアントに書き込まれるまでの待機時間。 |
| %:m< | McAfeeスキャンエンジンから判定を受け取るまでの待機時間。Webプロキシが要求を送信するために必要な時間を含みます。 |
| %:m> | Webプロキシが要求を送信した後、McAfeeスキャンエンジンから応答を受信するまでの待機時間。 |
| %F | クライアント送信元ポート。 |
| %p | Webサーバポート。 |
| %k | データソースIPアドレス（WebサーバIPアドレス）。 |
| %:w< | Webrootスキャンエンジンから判定を受信するまでの待機時間。Webプロキシが要求を送信するために必要な時間を含みます。 |
| %:w> | Webプロキシが要求を送信した後、Webrootスキャンエンジンから応答を受信するまでの待機時間。 |
SWAライセンスモデルでは、物理アプライアンスのライセンスを仮想アプライアンスに再利用できます。この機能を利用して、ラボ環境で使用するテスト用SWAvアプライアンスを導入できます。新しい機能と構成をこの方法で試験的に導入することで、ライセンス条項に違反することなく、また同時に安定性と信頼性を確保できます。
Advanced Web Security Reporting(AWSR)
SWAからのレポートデータを最大限に活用するには、AWSRを活用する必要があります。特に、多くのSWAが展開されている環境では、このソリューションはセキュリティ管理アプライアンス(SMA)で中央集中型レポートを使用する場合に比べて何倍もスケーラブルであり、データに深みとカスタマイズを大幅に追加するカスタムレポート属性を提供します。レポートは、組織のニーズに合わせてグループ化およびカスタマイズできます。AWSRのサイジングには、シスコアドバンスドサービスグループを活用する必要があります。
電子メールアラート
SWAに組み込まれているEメールアラートシステムは、ベースラインアラートシステムとして最も活用されています。すべての情報イベントが有効になっているとノイズが多くなる可能性があるため、管理者のニーズに合わせて適切に調整する必要があります。アラートを制限し、すべてのアラートをアクティブに監視することは、すべてのアラートをスパムとして無視するよりも重要です。
| アラートの設定 | コンフィギュレーション |
| アラートの送信時に使用する送信元アドレス | 自動生成 |
| 重複するアラートを送信するまでの初期待ち時間（秒） | 300 seconds |
| 重複したアラートを送信するまでの最大待ち時間（秒） | 3600 seconds |
可用性の監視
Webプロキシの可用性を監視するには、2つの方法があります。1つ目はレイヤ3(L3)モニタリングで、アプライアンスのIPアドレスがネットワーク上で到達可能かどうかをテストします。これをテストする最も簡単な方法は、ICMPエコー(ping)要求を一定の間隔でアドレスに送信し、応答パケットを確認することです。TTLや遅延などの応答の属性を解析して、ネットワーク層の状態を判別できます。
デバイスがpingに応答できても、プロキシプロセスが応答しない、または断続的になる可能性があります。このため、レイヤ7(L7)モニタを使用することをお勧めします。このモニタは、明示的なプロキシ要求をアプライアンスに送信し、200 OK HTTP応答コードを待ちます。これは、ネットワークインターフェイスの到達可能性だけでなく、プロキシサービスの応答性と、外部リソースが要求された場合のアップストリームサービスの実行可能性もテストします。このタイプのモニタリングは、通常、プロキシにリソースへの接続を要求する明示的なHTTP HEAD要求の形式をとります。HEADメソッドは、返されるヘッダーを要求しますが、クライアントはGET要求を送信する必要がありますが、応答ヘッダーのみが含まれ、データは含まれません。
L7モニタリングツールまたはスクリプトを使用する場合、トラフィックが認証から免除されていることを確認することが重要です。そうしないと、認証が定期的に失敗し、リソースが消費されます。モニタリングツールでカスタムユーザエージェント文字列を使用する場合は、トラフィックの識別に使用する必要があります。トラフィックは認証から除外されますが、アクセスポリシーを通じて不必要なインターネットアクセスから制限される可能性があります。
これらの方法を1つ以上使用する場合、管理者はプロキシ応答に関する許容可能なメトリックのベースラインを確立し、それを使用してアラートしきい値を設定する必要があります。このようなチェックの応答を収集し、しきい値とアラートの設定方法を決定する前に、時間を割いて収集する必要があります。
SNMPモニタリング
簡易ネットワーク管理プロトコル(SNMP)は、アプライアンスの状態を監視するための基本的な方法です。アプライアンスからアラートを受信したり（トラップ）、さまざまなオブジェクト識別子(OID)をポーリングして情報を収集したりできます。SWAには、ハードウェアからリソースの使用、個々のプロセス情報、および要求統計情報に至るまで、すべてをカバーする多くのOIDが用意されています。
ハードウェアとパフォーマンスの両方に関連する理由で監視する必要がある特定のMachine Information Base（MIB；マシン情報ベース）(MIB)が多数あります。MIBの完全なリストについては、https://www.cisco.com/web/ironport/tools/web/asyncosweb-mib.txtを参照してください。
次のリストは、監視に推奨されるMIBのリストであり、完全なリストではありません。
| ハードウェアOID | [名前(Name)] |
| 1.3.6.1.4.1.15497.1.1.1.18.1.3 | raidID |
| 1.3.6.1.4.1.15497.1.1.1.18.1.2 | raidステータス |
| 1.3.6.1.4.1.15497.1.1.1.18.1.4 | raidLastError |
| 1.3.6.1.4.1.15497.1.1.1.10 | ファンテーブル |
| 1.3.6.1.4.1.15497.1.1.1.9.1.2 | 摂氏 |
次に、status detail CLIコマンドの出力に直接マッピングされるOIDを示します。
| OID | [名前(Name)] | Status Detailフィールド |
| System Resources | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | perCentCPUtilization | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | perCentMemoryUtilization | RAM |
| 1秒あたりのトランザクション数 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruputNow | 最後の1分間の1秒あたりの平均トランザクション。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | cacheThruput1hrPeak | 過去1時間の1秒あたりの最大トランザクション数。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | cacheThruput1hrMean | 過去1時間の1秒あたりの平均トランザクション数。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.8.0 | cacheThruputLifePeak | プロキシ再起動後の1秒あたりの最大トランザクション数。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | cacheThruputLifeMean | プロキシ再起動以降の1秒あたりの平均トランザクション数です。 |
| 帯域幅 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.4.1.0 | cacheBwidthTotalNow | 最後の1分間の平均帯域幅。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.2.0 | キャッシュ帯域幅合計1時間ピーク | 過去1時間の最大帯域幅。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | cacheBwidthTotal1hrMean | 過去1時間の平均帯域幅。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | cacheBwidthTotalLifePeak | プロキシ再起動後の最大帯域幅。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | cacheBwidthTotalLifeMean | プロキシ再起動以降の平均帯域幅。 |
| 応答所要時間 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheHitsNow | 最後の1分間の平均キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | cacheHits1hrPeak | 過去1時間の最大キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.3.0 | cacheHits1hrMean | 過去1時間の平均キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.8.0 | cacheHitsLifeピーク | プロキシ再起動後の最大キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHitsLifeMean | プロキシ再起動以降のキャッシュの平均ヒット率です。 |
| キャッシュヒット率 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheHitsNow | 最後の1分間の平均キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | cacheHits1hrPeak | 過去1時間の最大キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.3.0 | cacheHits1hrMean | 過去1時間の平均キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.8.0 | cacheHitsLifeピーク | プロキシ再起動後の最大キャッシュヒット率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHitsLifeMean | プロキシ再起動以降のキャッシュの平均ヒット率です。 |
| 接続 | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | アイドル状態のクライアント接続。 |
| 1.3.6.1.4.1.15497.1.2.3.3.7.0 | cacheServerIdleConns | アイドル状態のサーバ接続 |
| 1.3.6.1.4.1.15497.1.2.3.2.8.0 | キャッシュクライアント総数 | クライアント接続の合計。 |
| 1.3.6.1.4.1.15497.1.2.3.3.8.0 | キャッシュサーバ総数 | サーバー接続の合計です。 |
結論
このガイドでは、SWAの設定、導入、およびモニタリングの最も重要な側面について説明します。リファレンスガイドの目的は、SWAを最も効果的に使用したい方に有益な情報を提供することです。ここで説明するベストプラクティスは、セキュリティツールとしてのデバイスの安定性、スケーラビリティ、および有効性にとって重要です。また、関連するリソースの今後の発展に合わせて、ネットワーク環境や製品の機能セットの変更を反映するために頻繁に更新する必要があります。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
25-Jul-2023 |
初版リリース |
1.0 |
10-Apr-2023 |
初版 |
フィードバック