PA incorrectly matching rule, lets C&C traffic out

[jambulo]

One of our other IDS tools detected C&C traffic outbound.  After further investigation, this traffic was allowed out through the Palo Alto because it matched on a rule that should have allowed ONLY the App-ID "github".  The App-IDs that the PA was detecting and allowing were...

-incomplete

-insufficient-data

-non-syn-tcp

...why did this C&C traffic match this rule which specifies ONLY the "github" App-ID?

[gwesson]

There are a few things that need to happen for an application to be identified, mainly for TCP traffic there needs to be at least the TCP handshake and another packet or more.

"non-syn-tcp" is blocked by default, so your firewall seems to have that enabled. Check the Device > Setup > Sessions tab. If you've got it set to allow, the firewall will let a connection be established, and if it's possible to identify the traffic it will do so.

"incomplete" is traffic that did not actually complete the TCP handshake. That you likely don't have to worry about.

"insufficient-data" is traffic that has not had enough packets to identify what it is. Some traffic can be identified easily on the 4th packet (web-browsing, for example has an HTTP GET or similar as soon as the TCP handshake is done), but other traffic may take some time to identify. In the case of github, if it's going on port 80 as your traffic log shows, there has to be some additional traffic before it can be identified. It will have to go through git-base initially, and then be identified as github after git-base is identified.

In your screenshot, it never gets that far. Likely there are only a couple packets, which is common for C&C traffic, and so the firewall is unable to identify it positively as github by the time the traffic is done.

My recommendation is to disable non-syn-tcp in the session to start, but that may impact other applications so check to see why that was enabled to begin with. The rule in your screenshot doesn't have the last 2 columns, so if there is no AV/Vuln scanning, you'll want to add that as well. Beyond that, if you want to restrict the rule further by adding a URL category or a specific URL for the destination traffic, that may help.

Best,

Greg

[kadak]

Hello jambulo,

Yes this is expected for incomplete, insufficient data and non-syn-tcp.  Before the 3-way handshake completes and the session's application is detected as incomplete the security policy lookup for the session will match the first security policy which matches all attributes except application.  Once the 3-way handshake completes and the firewall sees a data packet which can be used to identify the app the session will shift the application to the appropriate value and do another security policy lookup.

If a session never completes the 3-way handshake the application will stay as incomplete and the session will be logged after the timeout with the policy which the session first hit.

Maybe an easier way to explain it.  When the first TCP packet is received (SYN), the firewall must setup a session.  Since the application can not be detected on a TCP session until at least one data packet traverses the device the application will be incomplete.  For the firewall to determine if it should even allow the SYN packet through it must do a security policy lookup.

Because the application is not known when the SYN packet is received the application portion of the security policies can not be applied.  As a result, the security policy lookup is performed against the 6 tuples of the session, source and destination IP and port, ingress interface (actually zone) and protocol.  The first policy which matches these 6 tuples will be used to allow the SYN and any additional packets that traverse the firewall before the application is identified.

Hope that helps!

Thanks and regards,

Kunal Adak

[mikand]

Actually any ip based filters should be able to kick in BEFORE the handshake is completed.