Action Configured in Security Rules and Seen in Traffic Log is Inconsistent

Symptom

In some situations there can be a traffic log entry for a session, where the application is recognized as insufficient data, logged as "allow" while matching a drop rule.

For example:

Take FTP traffic from a zone "replay_eth2" to a zone "replay_eth3".

This FTP traffic will be incomplete; a RST packet will be sent by the client at the beginning of command session (dport 21).

This incomplete FTP transaction will allow the session to be recognized as insufficient-data.

The decoder attached to the FTP application did not receive enough data to achieve compliancy checks and validate the FTP application.

Note: FTP is not mandatory, it can happen for all applications with a decoder.

The security rulebase on the Palo Alto Networks firewall is shown in the example below:

In security rulebase, it is important to have the following:

• One rule denying traffic for 'any' application
• One rule above allowing traffic for a specific application
  • Flow tuples (sip, szone, dip, dzone) for FTP traffic will have to match this rule. It will allow App-ID to kick in.
  • If there is no such rule, traffic will be dropped before App-ID starts

Under these conditions, if FTP traffic is generated from zone "replay_eth2" to zone "replay_eth3", this will be blocked with the following log entry:

Cause

This behavior can be explained as the following:

• In that very specific scenario, Palo Alto Networks firewall does not have all the information needed to take final action configured in "Deny All" rule (Deny)
• The final action is taken once the application decoder will have validated the application (running some compliancy test against transaction)
• The final rule match and action will be deferred after this validation

When the RST packet is received, the session ends with these states:

• Insufficient-data
  FTP session is incomplete and not validated
• Matching "Deny All" rule with "allow" action
  Action was temporarily set to "allow" for App-ID to be achieved (within 4 data packets or 2000 bytes of payload), and the "Deny All" rule was the best potential match.

owner: nbilly