nmap "closed" ports?

Post by **ayu** » 08 Mar 2009, 05:47

This just came to mind ...

Sometimes when I scan a host with nmap, it lists some ports as "closed", why?

Post by **bad_brain** » 08 Mar 2009, 06:15

quote from the nmap documentation:

Closed – The port responds to NMAP probe requests but no application is using this port

sounds a little confusing, but it simply means the "answer" from that port was not as expected....this can have different reasons, either it's because of a security feature like portsentry (portsentry listens on multiple ports, if enough ports are triggered by the same IP it gets blacklisted), but no service is given on the listening ports, or it is because of the used scanning method....non-connect scans can give useless results because the probed port only replies with a "bye! for example, some services simply need a full connect to start working (SMTP servers often do for example).

it's nmap's way to say "um, there is something, but I have no idea what it is"...

Post by **ayu** » 08 Mar 2009, 06:19

ah ok, thanks ^^

Post by **DNR** » 08 Mar 2009, 11:38

true, you should not rely on one scanner result to tell you if the port is open or closed. Closed, as bb said can be just a unexpected banner or computer response to the port query. If the sysadmin changed the welcome banner from

220 ncsc.romulus.mil ESMTP Sendmail 8.9.3/8.9.3; Sun, 08 Mar 2009 01:45:38 -0500

to

Uncle Poopy's Email System version 1967 - login fool!

or even no banner..

The scanner does not interpet the banner, it rejected it and labled it closed.
I would try to connect to the port and see if you get a plain text response or run a sniffer to see the packet return itself (maybe it is a unexpected port daemon)

Never trust one scanner or tool.

DNR

Post by **bad_brain** » 08 Mar 2009, 12:12

yeah, service banners are very easy to spoof, it's even possible to spoof a complete OS with a kernel patch that allows to edit the behavior of the TCP/IP stack....and no scanner can evade it.
the most reliable results are always produced by a fll connect scan, but of course such scans leave the most log entries at the same time...