ports unknown allowed

[panfw_notify]

Hi all,

We have an application group that specifies the applications to allow from untrust to our DMZ. Mostly its just web browsing, ssl, pop and smtp. We are not allowing ms smb port 445 or Port 135 msrpc.

Our recent PCI security scans are telling us these ports are accessible. if I look in the monitor logs I can see msrpc (port 135) and ms-ds-smb (445) are being denied as expected. With that said, the firewall is allowing those ports if the application is seen as incomplete. This raises a concern. Why is the firewall allowing access through these ports especially if we have explicitly specified the applications to allow? Do I need to create another policy to deny these ports using an application override?

[gwesson]

Unless you explicitly deny ports 139 and 445, the firewall must analyze the traffic to see if web-browsing, ssl, pop, smtp, or any other application may be being accessed on those ports. Until the firewall can be sure (it may take a few packets), those must be allowed through.

You can deny those ports specifically, but then you'll also block legitimate traffic that you do want to allow which may be using ports 139 or 445.

Hope this helps,

Greg

[panfw_notify]

Hi gwesson we do want to deny those ports access to our webserver. I assume I would need to create a deny policy using an application override or can I use a service override? Right now we have one policy rule that specifies what applications are allowed from untrust to DMZ to our webserver. Can I just add the port denial on that same policy using a service?

[kbe]

Are you allowing the desired apps with service any or with service application default?

If you use application default (e.g. "from untrust" "to dmz" "app webbrowsing" "service application default" "action allow") you do not need another special deny rule.

But if you use "app webbrowsing" "service any" your config should be reviewed.

HTH

[_slv_]

Hi

I had the same questions, please read my topic

Strange output from Nmap

I hope that it will explain your problem

Regards

Slawek

[panfw_notify]

kbe, we have an application group defined (Untrust-to-DMZ - Allowed) which is set to allow applications (ftp, icmp, ping ssh, ssl, web-browsing, ftp) We added flash individually but we'll probably change that and add it to our app group. Services however are set to "any" not application default. Perhaps that is the problem? I believe we did this because we have a web server app that had no app definition in the PA-500. We would need to create a custom app and over ride. Our assumption was that ports would only be allowed for the apps specified.

So does setting services to "application-default" instead of "any" force allowing ports only for those apps specified as being allowed?

[panfw_notify]

slv post is interesting. thanks for the link
Strange output from Nmap

We are not specifying application default which is possibly the problem?. gwesson mentions that this may not work if there is not a secondary policy after that deny's all to DMZ. We do have a deny all policy at the end our other policies,

And this is a log example for Port 445. The Deny all to the DMZ policy does block port 445 recognized as ms-smb. I would have expected this for the untrust-to-DMZ policy to our website but it is allowing request for 445 traffic as unknown.

[jvalentine · Accepted solution]

The best way to explain what is happening here is to read your security policy while ignoring the "application" part of the rule for a minute.  When you do that, your policy reads:

"permit from untrust to dmz any service(port#)"

Which is not what you were specifically intending to do.  So now, re-read your policy with the application back in there:

"permit from untrust to trust specific applications on any service(port#)"

But that's not also what you intended... right now, anyone can connect to any port on your server, do a TCP 3-way handshake, and then when the application does not match the list of approved applications, then the firewall will block that traffic.

The right answer is to use "application-default" on the service column.  This will only open the port(s) required for the applications that you've specified... this is a major difference from using "any" in the service column.  If you wanted to further restrict, you could manually specify TCP/UDP ports/port-ranges instead of taking Palo Alto Networks' "application-default".

The net-net here is NEVER NEVER NEVER EVER use "any" on the service for untrust-to-dmz|internal|trust|etc.  It's okay to have it as "any" for outbound rules...  if you're going to let a user run SSH out of your environment, do you care if it's TCP/22 vs TCP/23? Probably not, as it doesn't change your visibility or control one bit. 

[panfw_notify]

Thanks jared. Yeah we need to hone our rules down a bit more. The default application on the services makes sense.

[kbe]

Could not have explained it better then Jared.

Do never use "any" for service on incoming rules and try to use "app default" wherever possible to get tight control on your network traffic.

And concerning one of your questions about a deny-all rule:

The PA has an implicit rule that you can not see and that does not show up in log files. This rule is deny any nter-zone and allow-all intra-zone traffic.

If you create a deny-all rule (also known as clean-up rule) you have to make sure that you allow required intra-zone traffic that is needed.

I use a cleanup as last rule with any-any-any-deny.

Others don´t.

There is no best practise for that but alot people prefer to have a clear rule set with explicit conditions and no implicit rules.

HTH