TCP 3-Way Handshake is Allowed to Match a Security Policy that Allows Application "ICMP" and Service "ANY"
22791
Created On 03/21/19 23:01 PM - Last Modified 04/02/19 18:13 PM
Symptom
From the traffic logs and session details on the session browser, CLI has observed that some TCP 3-way handshake connections match a security rule that allows only application ICMP.
For example, a telnet session to example.com on port 80 is being allowed through this security policy.
admin@PA> show session id 136043 Session 136043 c2s flow: source: 192.168.243.55 [Trust-Zone] dst: 93.184.216.34 proto: 6 sport: 53792 dport: 80 state: ACTIVE type: FLOW src user: unknown dst user: unknown s2c flow: source: 93.184.216.34 [Untrust] dst: 10.129.82.243 proto: 6 sport: 80 dport: 28507 state: ACTIVE type: FLOW src user: unknown dst user: unknown qos node: ethernet1/1, qos member N/A Qid 0 start time : Fri Dec 28 17:44:52 2018 timeout : 3600 sec time to live : 3569 sec total byte count(c2s) : 264 total byte count(s2c) : 264 layer7 packet count(c2s) : 4 layer7 packet count(s2c) : 4 vsys : vsys1 application : undecided <<<< Application is still undecided rule : test-icmp <<<< Rule is the security policy allowing ICMP service timeout override(index) : False application db : 0 app.id : c2s node (0, 0) s2s node (0, 0) session to be logged at end : True session in session ager : True session updated by HA peer : False address/port translation : source nat-rule : Outbound(vsys1) layer7 processing : enabled URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : False session traverses tunnel : False captive portal session : False ingress interface : ethernet1/1 egress interface : ethernet1/2 session QoS rule : N/A (class 4) end-reason : unknown
Environment
The firewall has a security rule with a non-TCP/UDP application (e.g., ICMP) and service set to "ANY."
TCP handshakes are observer as being allowed by this rule instead of a more appropriate rules further down the rulebase.
Cause
This behavior occurs when the service is set to "ANY" on the security policy.
Looking at the security policy from CLI, you may see the following:
admin@PA> show running security-policy
"test-icmp; index: 1" {
from any;
source any;
source-region none;
to any;
destination any;
destination-region none;
user any;
category any;
application/service 0:icmp/any/any/any; <<<< Application is ICMP, & Protocol IS ANY
action allow;
icmp-unreachable: no
terminal yes;
Though ICMP is a protocol, there is an application signature specifically for application ICMP. Hence, as long as the application for a session is undecided, the traffic will continue to match the security policy allowing application ICMP and service to be set to "ANY."
The IP protocol is determined by the service in PAN-OS and not by the application.
Resolution
If you wish to allow only ICMP traffic matching the specific policy, then set service to "application-default."
"test-icmp; index: 1" {
from any;
source any;
source-region none;
to any;
destination any;
destination-region none;
user any;
category any;
application/service 0:icmp/icmp/any/any;<<<< Application is ICMP & Protocol is ICMP
action allow;
icmp-unreachable: no
terminal yes;
Since the service field determines the IP protocol, when the service is set to application-default, the rule reflects the protocol ICMP.
Additional Information
TIP: A good practice is to always set application-default.