topic Strange output from Nmap in General Topics

Strange output from Nmap

_slv_ — Tue, 24 Sep 2013 12:22:03 GMT

I have PA200 with 5.0.7 with latest updates and I try to nmap scan (from untrust zone) one of my servers from DMZ. Output is strange

Nmap scan report for X.X.X.X

Host is up (0.020s latency).

Not shown: 965 filtered ports

PORT STATE SERVICE

21/tcp open ftp

30/tcp open unknown

80/tcp open http

443/tcp open https

548/tcp open afp

666/tcp open doom

1062/tcp open veracity

1084/tcp open ansoft-lm-2

1110/tcp open nfsd-status

1719/tcp open h323gatestat

1974/tcp open drp

2030/tcp open device2

2525/tcp open ms-v-worlds

2869/tcp open icslap

4045/tcp open lockd

5825/tcp open unknown

5901/tcp open vnc-1

5902/tcp open vnc-2

6004/tcp open X11:4

6025/tcp open x11

7443/tcp open oracleas-https

8090/tcp open unknown

8222/tcp open unknown

9100/tcp open jetdirect

9200/tcp open wap-wsp

9502/tcp open unknown

10025/tcp open unknown

10082/tcp open amandaidx

10566/tcp open unknown

18101/tcp open unknown

20221/tcp open unknown

30000/tcp open unknown

32774/tcp open sometimes-rpc11

44442/tcp open coldfusion-auth

50002/tcp open iiimsf

Nmap done: 1 IP address (1 host up) scanned in 6.05 seconds

Usually when I did another scan the output was correct or the list of "open ports" is much shorter.

According to the Security Policy Guidelines configuration should be as :

Could You confirm that this is proper behavior of nmap in this situation?

With regards

SLawek

Re: Strange output from Nmap

gwesson — Tue, 24 Sep 2013 22:57:12 GMT

If you have those ports listening on your server, the firewall will not immediately block the 3-way TCP handshake. With the default nmap settings, it's just establishing a TCP handshake, not actually doing an in-depth analysis like a penetration test where actual requests are sent. Thus, the firewall does not know what application the handshake is within those first 3 packets.

If the test were to include, say, an HTTP GET request, the majority of those ports would not show as open at that stage. Even more in-depth penetration testing involving requests and responses would filter even more.

Hope this helps,

Greg Wesson

Re: Strange output from Nmap

gafrol — Wed, 25 Sep 2013 06:54:19 GMT

Hmm, but in his policy he has configured service "application-default" which should limit communication to the standard ports of the protocol, eg. ssl = 443, web-browsing = 80 etc. However I tend to use only ports not apps for inbound traffic.

Re: Strange output from Nmap

gwesson — Wed, 25 Sep 2013 17:30:57 GMT

gafrol that's true when the session begins, such as with an HTTP GET or an FTP command. But with just the 3-way handshake the firewall has no way of knowing what the application is.

The security policy is matched twice per initial packet: Once if a policy would allow the traffic if there were no applications selected, and again when the application is determined. If this was the only rule in the policy (something that's not clear from the screenshot), then it would make sense that it should be blocked as it is not the default app for those ports. I think there is probably a rule above or below that, if there was no application, would allow the traffic to the server.

-Greg

Re: Strange output from Nmap

_slv_ — Wed, 25 Sep 2013 18:21:12 GMT

gwesson this is only rule in security policy that are applied to traffic from untrust to DMZ for this particular host in DMZ.

Thank You for explaining us these problem.

Regards

SLawek

Re: Strange output from Nmap

gwesson — Wed, 25 Sep 2013 19:37:31 GMT

As a test, I set up something similar with a server I have running behind my test firewall. The server is listening on 22, 25, 80, 443, 4443, and 5001, and I set up the same policy as you, except I also added a rule right below that one that denies all traffic to that IP.

When I run nmap on that system, it gives me the following (I obfuscated the names since it's my personal server):

~ $ nmap x.x.x.x

Starting Nmap 6.00 ( http://nmap.org ) at 2013-09-25 12:26 PDT

Nmap scan report for x-x-x-x.abc.def.example.com (x.x.x.x)

Host is up (0.027s latency).

Not shown: 997 filtered ports

PORT STATE SERVICE

21/tcp closed ftp

80/tcp open http

443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 4.03 seconds

As you can see from that, it is only showing the services defined in my allow rule with application_default as the service. When I delete the rule below the allow rule (the one that blocks everything else), my other rules allow all the configured ports to reply. Here's the output when I add the "application_default" rule:

Not shown: 994 filtered ports

PORT STATE SERVICE

21/tcp closed ftp

25/tcp open smtp

80/tcp open http

443/tcp open https

5001/tcp open commplex-link

8080/tcp closed http-proxy

Nmap done: 1 IP address (1 host up) scanned in 4.53 seconds

And with my default rule set:

Not shown: 994 filtered ports

PORT STATE SERVICE

22/tcp open ssh

25/tcp open smtp

80/tcp open http

4443/tcp open pharos

5001/tcp open commplex-link

8080/tcp closed http-proxy

Nmap done: 1 IP address (1 host up) scanned in 5.89 seconds

One thing you'll notice is that with your test rule in place, port 21 is explicitly reset (showing closed). When that rule is gone, the port 21 traffic is just dropped since I don't have that port listening on the server.

Best regards,

Greg

Re: Strange output from Nmap

mikand — Mon, 30 Sep 2013 09:47:50 GMT

I wonder if this really is true?

Looking at the slides for how packets are being processed by PA the first check is to look at ip and ports. If there are no security rules matching this criteria the packet is imediately dropped.

That is if you for example only has a single allow rule "app: web-browsing" with "service: application-default" and application-default for web-browsing would mean (example) TCP80 and TCP8080. Then if a packet arrives to the PA matching this rule (regarding incoming/outgoing zone) this packet will be dropped (assuming your rules is to allow traffic with a last rule to drop anything else) UNLESS the dstport was TCP80 or TCP8080 (in this particular example). That is having a last rule which block and log through "any any deny".

Now the 3-way handshake is performed and depending on application PA could drop the first packet AFTER the handshake is performed or it will take a few more packets before PA knows what appid it is (depending on which appid you wish to allow/block).

However as your test points out there is a last hidden rule (well rules) that for example will allow intrazone traffic etc. As a best practice I always recommend admins to ALWAYS put a last (manual) rule in order to block (and log) "any any deny". The default (hidden) last rules is probably what causes the PA to somewhat incorrectly (or at least undesired) allow traffic through which shouldnt be allowed through (and is taken care of if you setup a manual last rule to block and log).

Re: Strange output from Nmap

gwesson — Mon, 30 Sep 2013 17:04:12 GMT

mikand - You're absolutely correct about the deny happening if there are no other rules to allow the traffic. If no rule matches a port to allow the traffic, it will be denied. I suspect that a review of the full security policy will show what is happening.

As for the manual rule at the end, it can cause significant trouble if implemented incorrectly. I have often run into things like GlobalProtect failing because the initial Portal request is same-zone, but an any-any-deny rule would block that traffic. We recommend against the default rule at the bottom since the firewall already blocks inter-zone traffic. There's a CLI logging option if you want to log that traffic (up to 5 minutes at a time) to do any rule-based troubleshooting:

set system setting logging default-policy-logging <0-300sec>

This lets you check for default deny hits without logging everything all the time, or denying traffic unexpectedly. For customers who must log all denies, I recommend instead of a generic any-any-deny to put in inter-zone specific denies:

From External; to [internal/vpn/dmz]; deny

From Internal; to [External/vpn/dmz]; deny

From dmz; to [Internal/vpn/external]; deny

From vpn; to [internal/dmz/external]; deny

This lets the logging take place, and mimics the default behavior by allowing same-zone traffic. Your mileage may vary, it's just an observation

Cheers,

Greg