I've got some pretty specific firewall rules for machine in our DMZ, and I noticed some intriguing log entries while checking into an (unrelated) issue today.
I get a log entry which reads like this
02/27 11:42:30 end outside DMZ <source_ip> <destination_ip> 1433 incomplete allow <rule_name> 152
(I've obfuscated the IP addresses etc).
Why doesn't this show as a "deny" when the application doesn't match one on the permitted list for this rule? Even the port doesn't match one covered by any of the allowed applications in the rule.
It's not effecting anything, I'm just curious.
Solved! Go to Solution.
Incomplete either means that the 3-way TCP handshake didn't fully complete, or it completed without any additional data packets. The App-ID engine identifies the actual application based on the actual data traffic after the 3-way TCP handshake. If there was a partial handshake, or a complete handshake without any additional data traffic, the application will be marked as incomplete.
Yes, I understand why they show as "incomplete" - what I want to know is why they are logged as ALLOWED by the firewall, not logged as dropped. Surely, the logic would be "if it matches, allow, if it doesn't match, or doesn't complete, then drop"?
When the session is established and packets come in to the firewall.
Initially the traffic has to be leaked to make the determination of the application.
It is allowed on the most open security rule from top to bottom and left to right.
If the traffic is incomplete or insufficient traffic, it means the determination of the application could not be made or the tcp handshake did not complete.
Since the traffic was initially leaked to make the determination for the application and no further processing happened on it since it was allowed.
It shows up as allowed in the traffic logs.
Hopefully this explains it.
>Since the traffic was initially leaked to make the determination for the application and no further processing happened on it since it was allowed.
> It shows up as allowed in the traffic logs.
But the actual traffic *is* dropped, yes? I'd hate to think some of this stuff actually leaks to the servers inside the DMZ!
Let's look at this from two different perspectives:
The "old-school" port-based firewall. You'd have a rule that says "permit from any to dmz_server tcp/1433". If someone sends a tcp/syn on 1433 and stops there, would this firewall let it through? Yes. If someone sends a syn, gets a syn/ack back, and then sends an ack, does that get through? Yes. What about after the handshake and then they send MS-SQL data to the server, does that get through? Yep. What about telnet or ssh, does that get through? Yes. (of course, that assumes there's a telnet or ssh daemon listening on that port) - but the firewall is clueless at this point. As long as it saw a tcp handshake on tcp/1433, it will let ANY application through that rule.
Now let's look at this from a Palo Alto Networks firewall perspective. You have a rule that says "permit from any to dmz_server ms-sql on tcp/1433". Now, if someone sends a tcp/syn on 1433, that gets through (just like above). What about syn, syn/ack, ack? Yes, that gets through as well. What about if, after the handshake, someone sends MS-SQL data to the server, does that get through? Yes - and if they do, it will be logged as ms-sql. What about telnet, or ssh, does that get through? NO, it won't. That's where the big difference is.
I wouldn't call it "leaking" data. It allows a handshake on that port, and then validates the application after the handshake takes place. Unfortunately, there is no way to know what the application is until after the tcp handshake happens. What you're seeing is tcp handshaking that is allowed under that rule. The firewall didn't block it, but it would have validated the application and blocked any app that doesn't match the security policy.
Doesn't that kind of imply that if what you're saying is true, a simple SYN scan of a PAN firewall's external IP address would show hundreds of ports open?
That's assuming the 'Service' column in the firewall policy is set to any I suppose, not 'application-default' or specifically 'tcp-1433' (using your example of MS SQL)
> I wouldn't call it "leaking" data. It allows a handshake on that port, and then validates the application after the handshake takes place.
But the port upon which the handshaking is taking place is *not* in the allowed list. It's not an issue is the app identification occurring after the handshake - the initial (SYN, I assume) is being logged as "allowed" on a port which is *NOT* in the list of ports covered by the "allow" list.
In the example I originally quoted, the port identified is 1433 - MS-SQL - but the allow list for the rule concerned consists of
subversion (tcp/3690, udp/3690)
webdav (tcp/443, tcp/80)
There is no allow for tcp/1433 which can possible be allowed under those rules.
> Just out of curiosity, what does your 'Service' column look like in your rule base? Is it set to 'application-default'?
Damn, you're right, and I'm a butthead.
It is set to "any", Because I'm a bloody idiot and missed changing that when i set up this (and a couple of other) rules.
It'll shortly be set to "application default" and, I hope, resolve the issue.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!