Strange output from Nmap

[_slv_]

Hi

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

[gwesson · Accepted solution]

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

[gafrol]

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.

[gwesson]

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

[_slv_]

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

[gwesson]

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

[mikand]

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).

[gwesson]

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