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

On 29 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1148889897.890006.213270@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, GM wrote:

4) "ping" does not echo anything... Nor does "hping2", which I did
download and install (thanks for that info)

I rarely use hping2, but that can be configured to do a traceroute-LIKE
run using tcp (I normally use 'tcptraceroute' for that). A quick test
suggests the syntax '/usr/sbin/hping2 HOSTNAME -p 80 -n -t 1 --traceroute'
may be what you want. See the man page and other documentation. The
problem with 'ping' is that many people block or ignore the protocol
because of past abuse. At least the version of hping2 that I have is not
as useful to me as tcptraceroute, because it is sending unusual packets
that don't look normal (port 0 and zero data content). These packets may
be treated differently from a "normal" TCP/IP packet to your FTP server or
what-ever.

5) If I "traceroute" to my computer, I see, (well I do publish here the
hosts in between):

That's only a small part of the answer. See below

1 0 0 0
2 2 2 2
3 835 829 828
4 827 825 977

Is hop 2 <-> 3 a dialin link? That's what it looks like

6 964 962 1963
7 1961 1959 1957
8 1956 1954 1952
9 1638 1637 1636

There is where I would be concentrating my search. Either the system at
hop 6/7 is very busy, or it is the proxy server.

This is providing no information of interest to me. What you should be looking
at is the ICMP type 11 (and type 3) packets. Do this using tcpdump WHILE you
are running a traceroute. See the man page, but the syntax is likely

/usr/sbin/tcpdump -n -v icmp

66.193.205.105 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 249, id 0)
66.192.247.80 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 248, id 0)
66.192.251.20 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 247, id 0)
66.192.251.33 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 246, id 0)
209.245.88.109 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 245, id 0)
4.68.102.129 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 244, id 0)
209.247.11.117 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 243, id 0)
4.68.114.222 > MY.IP.ADR: icmp: time exceeded in-transit (ttl 242, id 0)

Notice the time to live value on the right. It is stepping smoothly. Make
sure this is occurring. Make note of where the ICMP packets are coming from.
Does it look reasonable? Also, look at this same tcpdump output when you
nmap your "home system". Do the TTLs match what you expect?

TTLs start at some nice round number - above is pretty obvious to have
started with '255', and this value gets decremented at each router. This
means that the first hop I show above (66.193.205.105) is 255 - 249 or
six hops away. For "normal" TCP and UDP packets (not ICMP), the starting
TTL is usually 30, 32, 60, 64, or 128 - the nmap documentation has more on
this subject while discussing fingerprinting the remote system.

4) The services I want to run on this computer are: ssh, lpd, nfs and
samba for the inside network only and ftp and http for the outside and
inside.

That's fine - I prefer to have a separate box connected to the Internet
that is a firewall, and forwarding packets to the servers that are
hidden behind the firewall. This means that your inside services would
not be detectable from outside. I have a ancient laptop connected to the
Internet and through a second network interface to my household LAN.

7) As for conclusion so far, I do not quite understand then the output
from nmap. And then, I am not quite sure of a "proxy" making, - if I
understand well -, nmap reporting here bad results.

nmap can only report what it sees. The person running the tool must be
able to interpret those results. The fact that nmap is reporting something
outrageous should make you look more closely. One way to do so (which is
not very nice, but...) is to scan other systems and compare results. You
did this, and discovered nearly identical results from all. _One_possible_
interpretation_ of that result is that your packets are being intercepted
by a proxy server. This is not unheard of. Some entities do this to save
bandwidth (they only need to get one copy of a web page for everyone),
while others do this for censorship ("bad sites" have the "bad" information
missing).

Old guy
.

Relevant Pages

  • Re: Firewall Scan
    ... don't think this is nmap getting confused as hping produces similar ... Try setting some TCP options. ... packets where the TCP header is 20 bytes. ... I was doing a normal TCP Scan on port 5900, when I found a strange result: ...
    (Pen-Test)
  • Re: Is my home computer at risk knowing that nmap says...
    ... nmap your "home system". ... Do the TTLs match what you expect? ... Thailand to know where to send those packets. ... Assuming your home system is Linux, ...
    (comp.os.linux.security)
  • RE: Firewall Scan
    ... Several firewall and IPS vendors now incorporate nmap signature detection ... it hits port 5900, your IP has been blocked for a short time....but, ... packets transmitted, 1 packets received, 0% packet loss ... Information Assurance Certification Review ...
    (Pen-Test)
  • Re: Firewall Scan
    ... This can help with systems that block ping and mix up Nmap. ... I was doing a normal TCP Scan on port 5900, when I found a strange result: ... packets transmitted, 1 packets received, 0% packet loss ... Information Assurance Certification Review Board ...
    (Pen-Test)
  • Re: Linux zero IP ID vulnerability?
    ... to perform an idle scan with nmap, ... packets tramitted, 1 packets received, 0% packet loss ... Many people use -P0 w/Idlescan to prevent pings from their true ... from the Linux kernel developers nor from Cisco (other vendors may also be ...
    (Bugtraq)