Technical Tip: NGFW Security Policies may not being matched when Service is set to App Default (Known Behavior)

[pjang]

Description	This article describes a known behavior with NGFW policy-based mode where using a certain combination of Application signatures and settings in Security Policies can result in traffic not matching those policies. The following are a list of conditions that must be present for this article to apply: FortiGate (or VDOM) is in NGFW policy-based mode (behavior does not occur in NGFW profile-based mode). Application-based matching is used within the impacted Security Policy. Multiple Application signatures are specified within the impacted Security Policy. Both default-app-port-as-service (under config system settings) and enforce-default-app-port (AKA Service -> App Default in the GUI) are set to enable. Traffic is not matching the expected Security Policy and is either matching a policy further down on the list OR is matching the implicit-deny policy (ID 0).
Scope	FortiGate, NGFW Policy-based mode
Solution	NGFW policy-based mode allows the FortiGate to scan and match traffic to specific Security Policies based on the identified Application signature. Once a Security Policy is matched, traffic is then either accepted (and possibly subjected to further security inspection) or denied. See also: Technical Tip: How to block URL Category and Application in NGFW policy-based mode Application signatures on the FortiGate may have default ports associated with them. These default ports are viewable under Policy & Objects -> Applications in NGFW policy-based VDOMs by hovering over the signature entry (for NGFW profile-based VDOMs, it is instead under Security Profiles -> Application Signatures). These default ports can also be found for each app entry on the online FortiGuard Application Control database. It is critical to understand that not all applications have default ports set in the Application signature. For example, SSH (ID 16060) and HTTP.BROWSER (ID 15893) have default ports of TCP/22 and TCP/80, TCP/443, and UDP/443 respectively, whereas OpenVPN (ID 17244) and the entire family of the SSL (ID 15895) application signatures do not have default ports set. SSH Application (has default port TCP/22) SSL Application (has no default port specified) When default ports are present in a signature, it is possible to leverage a per-Security Policy setting called enforce-default-app-port. When this setting is enabled (along with the VDOM-wide setting of default-app-port-as-service being enabled), the FortiGate's Policy Match Engine (PME, handles Security Policy matching) will create a pre-match list for each Security Policy that aggregates all of the Application default ports. This list allows the FortiGate to immediately determine if incoming traffic will match the Security Policy or not, rather than needing to spend additional time scanning the traffic and matching it to an application. For example, consider a scenario where a single Security Policy is created that has the SSH signature applied (default port TCP/22), default-app-port-as-service left on the default of enable, and enforce-default-app-port is also set to enable. The following are some example outcomes that can occur: If a user attempts to initiate an SSH session using non-standard TCP/2222, then the pre-match list will determine that this traffic cannot match this Security Policy. If there are no other Security Policies that may be matched then the traffic is dropped by the implicit-deny policy (policy ID 0) and only a Forward Traffic log may be generated (the application is detected, but no Application Control log will be generated in this case). If the user attempted an HTTPS session (TCP/443), then that traffic would also not match this Security Policy due to the pre-match-list, similar to the above result. If the user attempted a Telnet session but using TCP/22 (i.e., an attempt to masquerade as SSH), then the pre-match list would allow the traffic through for further scanning since it matches the port list. However, the IPS Engine would quickly determine that the traffic was not matching the SSH signature, and so this Security Policy would not be matched. The Problem: As noted above, the pre-match list is populated based on the default ports associated with the application signatures specified within each Security Policy. However, not all applications have default ports, and so these applications do not add to the pre-match list. Combining these two types of applications in one Security Policy can cause a problem where traffic that should match a Security Policy based on the applied Applications will not actually match due to the destination port not being on the pre-match list. For example, consider the same scenario as before (default-app-port-as-service enable and enforce-default-app-port enable), but the Security Policy now has both the SSH and SSL signatures applied: The administrator would expect this Security Policy to match both SSH traffic and HTTPS traffic (since this traffic can be matched by the SSL signature). However, when attempting to send HTTPS traffic through, the HTTPS traffic is dropped by the implicit-deny policy. This occurs because the destination port of the traffic does not match an entry in the pre-match list, since SSL does not have default ports associated with it. To confirm this, the command diagnose ips pme policy def_port can be used to print out the pre-match port list for each Security Policy. Note how TCP/22 is present but no entries exist to allow HTTP/HTTPS ports: FortiGate (NGFW) # diagnose ips pme policy def_port policy id:1 vdom=1 name=Internet Access total_def_ports=1 TCP/22, FortiGate (NGFW) # The Solution: There are several options for solving this problem: On a per-Security Policy basis, set enforce-default-app-port to disable in the CLI. This can also be done in the GUI by changing the Service option from App Default to Specify. By disabling this option, the PME will not create a pre-match list for this Security Policy. Traffic will be allowed to pass for a brief period of time as the FortiGate identifies the application matching the traffic, then it will match to a Security Policy based on this identified application (even if a non-standard port is utilized). Disabling this option also requires setting a service object in the Security Policy before the change can be committed (e.g., ALL, HTTPS, ALL_TCP, etc.): config firewall security-policy edit <id> set enforce-default-app-port disable set service <Service1 Service2 [...]> next end To disable this behaviour VDOM-wide, run set default-app-port-as-service disable under config system settings. The enforce-default-app-port setting can still be set on the Security Policy, but it will have no effect if the VDOM-wide default-app-port-as-service setting is disabled. config system settings set default-app-port-as-service disable end Alternatively, administrators could carefully construct Security Policies to ensure that applications with default ports are never mixed with applications without default ports. This ensures that the pre-match list either does not exist for a policy OR that it exists and contains all default ports necessary to allow the configured applications. It is also possible to substitute some application signatures for others to solve this no-default issue. For example, the SSL family of signatures do not have default ports, but the HTTP.BROWSER family does have default ports of TCP/80, TCP/443, and UDP/443 and could be used to allow HTTP/HTTPS traffic. Related documents: Technical Tip: NGFW policy-based mode Resource List Add option to set application default port as a service port Technical Tip: Port enforcement check