Re: Is my home computer at risk knowing that nmap says...




"Moe Trin" <ibuprofin@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:slrne7pr32.mnf.ibuprofin@xxxxxxxxxxxxxxxxxxxx
On Tue, 30 May 2006, in the Usenet newsgroup comp.os.linux.security, in
article
<e5i7de$7nn$1@xxxxxxxxxxxxxxx>, Jay C. James wrote:

Has everyone considered yet how some firewall implementations can skew
nmap
results a bit, specifically with regards as to
how it determines OPEN/CLOSED/FILTERED port states?

Did you see the articles upthread? This started when the O/P ran nmap
from a site in Thailand against his system in Canada, and was terrified
to find 1659 ports reported as open. He then scanned a number of other
hosts on the same subnet, and got near identical results. He has a
firewall running, and doesn't have all that much stuff waving in the
breeze.

The suggestion was made that he's actually seeing a proxy run by his
Thai ISP, rather than the real system. The way to test this idea is to
look at the packets on the wire, and note what the TTL value is in the
IP header. He appears to be 25 hops away, so for a Linux box, the
observed TTL should be 64 - 25 or about 40 for TCP and UDP, and 255 - 25
or about 230 for ICMP. If he sees obvious differences (I was expecting
the proxy was within 8 hops maximum), this would be a reasonable answer.

Also, I did make three connection attempts from here (near Phoenix
Arizona) and saw that his firewall was DROPing connections to unused
ports - including two ports that nmap scans by default. The article
you responded to shows a reasonable response based on a minimal test
I made.

nmap is a really good tool, but it can be confused if there is a hidden
proxy intercepting the scan. Things _may_not_always_ be exactly as they
seem. Using nmap to identify the remote operating system (see the man
pages) may provide clues.

Old guy


Moe,
Thanks for filling in the early details. Great tool when used properly.



.