キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

ASA: TCPステートバイパスを有効時の注意点と、設定と確認

 

  
   

TCPステートバイパスとは

ASAはデフォルトで以下の機能が動作しており、通過するTCP通信の正規化とセキュリティ向上に貢献しています。 通常、これらデフォルト機能は問題無く動作し、気にする必要はありません。

TCPノーマライザ
  ・ TCP通信のフラグやシーケンスの変遷の監視・制御と、各種セキュリティチェック

TCPシーケンス番号ランダマイゼーション
  ・ TCP通信のシーケンス番号のランダム化による秘匿と、それによるセキュリティ向上

アプリケーションインスペクション
  ・ 一部通信(FTPやSMTP、SIPなど)のDeep Inspectionによるセキュリティチェックやコネクション制御、NATサポート

   
しかし、利用のアプリケーションの特性や、通信構成(主に非対称ルーティング時)により、これらセキュリティチェックが、パフォーマンス低下や通信トラブルの原因となることがあります。

本ドキュメントでは、この「TCPの正規化とセキュリティチェック機能」を無効化する、TCPステートバイパス機能の有効時の注意点、および、その設定と確認方法について紹介します。

本ドキュメントは ASAバージョン 9.6(2)を用いて確認、作成しております。

   

    

TCPステートバイパスの適用を検討する通信・構成

ASAを通過前後で、パケットがドロップしたり、パフォーマンスが大きく低下するなど問題が発生時は、該当通信のみTCPステートバイパスを有効化することで、問題・速度が改善することがあります。

   
ASAでパケットがドロップしているか否かは、inside側とoutside側の指定通信のキャプチャを比較する事でわかります。 調査方法について詳しくは ASA: パケットキャプチャ機能の活用(CLI) を参照してください。

ASAを経由するとパフォーマンスが低下するかの確認は、そのアプリケーションや通信試験を "ASAを経由しないローカル試験環境"でも実施し、速度の比較や、ASA経由時と非経由時の同じ通信のパケットキャプチャを取得し、比較することが有効です。

  
以下は実際にTACに問い合わせのあった、トラブルと改善例です。

   
1. SSL-VPNクライアントなどの暗号化TCP通信の場合

 VPNリモートアクセスは、アプリケーションにもよりますが、元のデータトラフィック(HTTPやFTPやTelnet等)を、(強引に)TCPやUDPに暗号化しているケースがあり、一般的なTCPアプリケーションの通信とは かなり異なる挙動を取る事があります。 これらTCPの特殊通信が、セキュリティ製品(FirewallやIPSなど)のセキュリティチェックとドロップの原因となり、一部通信欠けによる再送や、それに伴うパフォーマンス低下につながる事があります。
 当問題が発生時は、セキュリティ装置側で該当通信のセキュリティチェック処理のバイパスをする事で改善することがあります。

   
2. 古いアプリケーションの特殊な通信の場合

 稀にあるケースですが、アプリケーション側の不具合 もしくは 通信実装の影響で、特殊なTCP通信の挙動となるケースがあります。 RFCに準拠した挙動でないケースもあります。 これら特殊なアプリケーションを 閉じたLAN内で利用していた際は問題は発生しなかったが、FirewallやIPSを経由する構成になった場合に問題が顕在化するケースもあります。
 当問題が発生時は、アプリケーション側での調査・改修が望ましいのですが、アプリケーション側が開発終了などにより改修が難しい場合は、ASAのTCPステートバイパスの有効化を検討します。

 
3. 非対称ルーティング構成の場合

 ASAは行きと戻りのパケットを常に監視し、フローベースでセキュリティチェックを実施してます。 何らかの理由で、パケットが片方向、もしくは パケットの一部しかASAを通過できない構成の場合、正しいフローの組み立てと セキュリティチェックができず ドロップにつながる事があります。 詳しくは TCP state bypass による非対称ルーティング を参照してください。
 なお、冗長WAN構成での 非対称ルーティング(asymmetrical routing)発生時は、そのソリューションに、本件のTCPステートバイパス、もしくは Traffic Zone機能が利用できます。 Traffic Zoneについて詳しくは、ASA: Traffic Zone: 冗長WANの 非対称ルーティング環境の設定と動作確認 を参照してください。

   

    

TCPステートバイパスを有効にした場合、無効になる機能

以下機能が、TCPステートバイパスを利用する通信では無効になります。

    • TCPノーマライゼーション
    • TCPシーケンス番号ランダマイゼーション
    • TCP Interceptや、Maximum embryonic connection limit 
    • サービスモジュールでの検査 (FirePOWERやCSC-SSM、IPS)
    • ステートフルフェイルオーバー

  
ステートフルフェイルオーバーが無効になるのは、TCPのステート監視をしなくなるためです。 結果、TCP通信を、SYNによるThree-way Handshaking から始める必要がなくなります。 例えば、Failoverが発生しSecondary機がActiveになった場合、TCPステートバイパスの適用対象のTCPパケットの場合、非SYNパケットの通過でも、すぐにコネクションが再生成されます。

   

    

TCPステートバイパス適用の際の注意点

ASAは、デフォルトで TCPノーマライゼーションなどによるセキュリティチェックや、特定通信(FTPやSMTP)のアプリケーションインスペクションが動作しており、これらは、クライアント・サーバー側双方のTCP通信のセキュリティ向上に役立ちます。 TCPステートバイパスを有効化することで、これらチェックがバイパスされ、結果的にセキュリティは低下します。

つまり、TCPステートバイパスを特定通信に有効化は、有効化後のメリットと、セキュリティ低下のデメリットの トレードオフとなります。 適用対象の通信の特性を十分に理解した上で、必要時にその特定通信にのみ、TCPステートバイパスを有効化されることを お勧めします。

    

     

TCPステートバイパスの設定と動作確認例

本例では、以下構成の SSL-VPN通信(TCP=443)の TCPステートバイパスの有効化と動作確認例を紹介します。

   
 クライアントIP         : 192.168.110.1
 SSL-VPNサーバIP : 1.0.0.2

  
なお、TCPステートバイパスは Modular Policy Framework(MPF)を用いて設定します。 MPFの動作概要や設定例については、以下ドキュメントを 一読いただくことをお勧めします。

ASA: MPFを用いたサービスポリシーの設定例と動作確認
https://supportforums.cisco.com/ja/document/12555131

     

設定例

まずTCPステートバイパスを適用する通信をACLで定義します。 本例では、クライアントIP 192.168.110.1から、SSL-VPNサーバ 1.0.0.2宛の、TCP443通信のみマッチするACLを設定します。

access-list ACL-TCP-BYPASS-01 extended permit tcp host 192.168.110.1 host 1.0.0.2 eq https

   
クラスマップを作成し、マッチ対象に 作成したアクセスリストを指定します。

class-map CMAP-TCP-BYPASS-01
match access-list ACL-TCP-BYPASS-01

   
ポリシーマップを作成し、クラスマップを紐づけ、TCPステートバイパス(set connection advanced-options tcp-state-bypass)を有効化します。

policy-map PMAP-TCP-BYPASS-01
class CMAP-TCP-BYPASS-01
set connection advanced-options tcp-state-bypass

    
ポリシーマップ(サービスポリシー)をインターフェイスに適用します。 指定Interface もしくは Global(全体)に適用できます。 本例では、指定Interface(inside)から開始通信のみ適用するため、インターフェイス insideを指定します。

service-policy PMAP-TCP-BYPASS-01 interface inside

     

動作確認

設定状況は show service-policyコマンドで確認できます。

ASA# show service-policy
--- snip ---
Interface inside:
Service-policy: PMAP-TCP-BYPASS-01
Class-map: CMAP-TCP-BYPASS-01
Set connection policy: drop 0
Set connection advanced-options: tcp-state-bypass

    
通信が想定通りに定義した Modular Policy Framework(MPF) にマッチするかの確認には、Packet Tracer機能が便利です。

以下は クライアントIP 192.168.110.1から、SSL-VPNサーバ 1.0.0.2宛の、TCP443通信の疑似パケットの生成とマッチング結果の出力例です。 Phase3にてTCP State Bypassが適用され、Phase4にてNAT(送信元変換)、最後のResultで ActionがAllowであることを確認できます。

ASA# packet in inside tcp 192.168.110.1 12345 1.0.0.2 443 detail

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 1.0.0.2 using egress ifc outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group IN in interface inside
access-list IN extended permit ip any any
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f7e221630f0, priority=13, domain=permit, deny=false
hits=0, user_data=0x7f7e120c9800, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map CMAP-TCP-BYPASS-01
match access-list ACL-TCP-BYPASS-01
policy-map PMAP-TCP-BYPASS-01
class CMAP-TCP-BYPASS-01
set connection advanced-options tcp-state-bypass <---- TCP STATE BYPASS
service-policy PMAP-TCP-BYPASS-01 interface inside
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f7e221638a0, priority=8, domain=conn-set, deny=false
hits=0, user_data=0x7f7e222152b0, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=192.168.110.1, mask=255.255.255.255, port=0, tag=any
dst ip/id=1.0.0.2, mask=255.255.255.255, port=443, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
object network PAT
nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 192.168.110.1/12345 to 1.150.xx.xx/12345
Forward Flow based lookup yields rule:
in id=0x7f7e2227ed70, priority=6, domain=nat, deny=false
hits=2273, user_data=0x7f7e2227d280, cs_id=0x0, flags=0x0, protocol=0
src ip/id=192.168.0.0, mask=255.255.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=outside

   --- snip ---

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

  
以下は実際にクライアント192.168.110.1から SSL-VPNサーバ 1.0.0.2宛の HTTPS443コネクションが発生時のコネクション情報です。 show conn longコマンドで確認します。 TCPステートバイパス対象の通信は flagsが "b"になります。

ASA# show conn long
5 in use, 59 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - LISP triggered flow owner mobility
M - SMTP data, m - SIP media, n - GUP
N - inspected by Snort
O - outbound data, o - offloaded,
P - inside back connection,
Q - Diameter, q - SQL*Net data,
R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, u - STUN,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow

TCP outside: 1.0.0.2/443 (1.0.0.2/443) inside: 192.168.110.1/3291 (1.150.xx.xx/3291), flags b , idle 7s, uptime 7s, timeout 5m0s, bytes 0, xlate id 0x7f7e202be2c0

    
以下はTCPステートバイパス対象のコネクションが生成時と、ダウン時の、show logの各シスログメッセージの抜粋です。

Sep 17 2016 05:12:59: %ASA-6-302303: Built TCP state-bypass connection 16737 from outside:1.0.0.2/443 (1.0.0.2/443) to inside:192.168.110.1/3291 (1.150.xx.xx /3291)
Sep 17 2016 05:18:40: %ASA-6-302304: Teardown TCP state-bypass connection 16737 from outside:1.0.0.2/443 to inside:192.168.110.1/3291 duration 0:05:40 bytes 11 Connection timeout

    

    

よくある質問

inside側にTCPステートバイパスを有効化した場合、コネクションが無い状態での逆方向(outsideからinside)の通信はバイパス対象になるか

ASAは、既存コネクションが無ければ、次に Routing(or 宛先NAT)と ACLチェックを行います。 ACLで拒否されれば パケットはドロップされ、通信は確立できません。 

仮に逆方法(outsideからinside)の通信がACLで許可されたとしても、TCPステートバイパスのサービスポリシーをインターフェイス insideに定義している場合は、outside側から開始された通信はMPFにマッチせず、結果 TCPステートバイパスの対象にはなりません。

     

TCPステートバイパスのアイドルタイムアウト値の変更は可能か

デフォルトのアイドルタイムアウトは5分です。 ポリシーマップ内で set connection timeoutコマンドで、当アイドルタイムアウト値は変更可能です。 例えば以下は20分に変更時の設定例です。

policy-map PMAP-TCP-BYPASS-01
class CMAP-TCP-BYPASS-01
set connection timeout idle 0:20:00
set connection advanced-options tcp-state-bypass

各コネクションに適用されたタイムアウト時間は、show conn long コマンドのtimeout値から確認できます。 以下はその抜粋です。

TCP outside: 1.0.0.2/443 (1.0.0.2/443) inside: 192.168.110.1/3304 (1.150.xx.xx/3304), flags b , idle 12s, uptime 1m12s, timeout 20m0s, bytes 0, xlate id 0x7f7e202be2c0

なお、アイドルタイムアウト時間が延びるほど、コネクションの滞留によるパフォーマンス低下や、セキュリティ低下につながります。 そのため、タイムアウト時間の延長は慎重に検討してください。

   

     

参考情報

ASA 8.2.X TCP 状態バイパス機能の設定例
http://www.cisco.com/cisco/web/support/JP/108/1089/1089248_asa-tcp-bypass-00.html

TCP state bypass による非対称ルーティング
https://supportforums.cisco.com/ja/document/47046

ASA: MPFを用いたサービスポリシーの設定例と動作確認
https://supportforums.cisco.com/ja/document/12555131

ASA9.6 Configuration Guide: Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass)
http://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/firewall/asa-96-firewall-config/conns-connlimits.html#ID-2068-00000337

ファイアウォール トラブルシューティング
https://supportforums.cisco.com/ja/document/12725841

バージョン履歴
改訂番号
2/2
最終更新:
‎08-31-2017 10:45 AM
更新者:
 
ラベル(1)
寄稿者: