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

Before I continue, let me tell that my home computer is some 10,000 km
away from me at the moment. My thinking goes: is it at risk knowing
that I here see, to my great surprise, on my linux laptop,
xxx.xxx.xxx.xxx being my IP at home:

nmap xxx.xxx.xxx.xxx | grep open | wc -l
1659

What ? 1659 open ports ? Sure looks to me as if the firewall went down.
This is *not-at-all* what I did expect... Ok then. I have Tripwire
running on a daily basis and mailing me the results. Everything here
seems fine (no change for the last two months). Also, as for services,
this computer is mailing me the running services, which did not change
either as I can read

netstat --inet -a | grep LISTEN | awk '{printf ("%s %d %d %s %s
%s\n",$1,$2,$3,$4,$5,$6)}'
tcp 0 0 *:1024 *:* LISTEN
tcp 0 0 *:printer *:* LISTEN
tcp 0 0 *:netbios-ssn *:* LISTEN
tcp 0 0 *:1006 *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
tcp 0 0 *:http *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:https *:* LISTEN

Yes, I know this is to be taken with a BIG grain of salt if the system
has ever been compromised. And well, if the firewall is down, well then
I can maybe ssh to my system as nmap report to me:
22/tcp open ssh

But I can't:
ssh xxx.xxx.xxx.xxx
ssh_exchange_identification: read: Connection reset by peer

Well, perhaps my ssh is configured for access only from my internal
network. Now two tests I do; (Yeah, the first is a bit not so much
netiquette maybe. But I am a bit paranoïd and want to be sure about my
home computer)
I run:
#!/bin/bash
i=yyy
while [ $i -lt zzz ] ; do
echo $i
nmap xxx..xxx.xxx.$i > nmapxxx.xxx.xxx.$i
i=$[i+1];
done

where (zzz==yyy+20) then scanning around my Ip for other results from
nmap. It turns out that all these show nearly the same output (to my
surprise):
wc -l nmapxxx.xxx.xxx.y[10]*
1665 nmapxxx.xxx.xxx.y00
1665 nmapxxx.xxx.xxx.y01
1592 nmapxxx.xxx.xxx.y02
1665 nmapxxx.xxx.xxx.y03
1665 nmapxxx.xxx.xxx.y04
1665 nmapxxx.xxx.xxx.y05
1665 nmapxxx.xxx.xxx.y06
1665 nmapxxx.xxx.xxx.y07
1665 nmapxxx.xxx.xxx.y08
1634 nmapxxx.xxx.xxx.y09
1665 nmapxxx.xxx.xxx.y10
1665 nmapxxx.xxx.xxx.y11
1665 nmapxxx.xxx.xxx.y12
1665 nmapxxx.xxx.xxx.y13
1635 nmapxxx.xxx.xxx.y14
1665 nmapxxx.xxx.xxx.y15
1665 nmapxxx.xxx.xxx.y16
1665 nmapxxx.xxx.xxx.y17
1665 nmapxxx.xxx.xxx.y18

I have a hard time believing all these computers around mine ALSO have
virtually no firewall... I can recognize my IAP name through reverse
DNS on each of the above IP. So what ? Could it be that my IAP
provider can "intercept" a scan and "report" spoofed results ? I doubt.

My IP here is aaa.bbb.ccc.ddd. Running.
nmap aaa.bbb.ccc.ddd

also gives tons of output (like 1600 lines showing "open" ) But, then,
I log to http://www.grc.com and ask for a scan of my ports on
aaa.bbb.ccc.ddd here. It says all ports except #2(closed) are stealth.
So what ? There is something from nmap that I don't understand.

Is my home computer at risk knowing that "nmap" on it reports 1659 open
ports ???

Any answer or comments on the above are most welcome. Thanks.

Gaetan

Hello,

> Well, perhaps my ssh is configured for access only from my internal
> network.

If you don't know *that*, then I would suppose that your computer indeed
might be at risk.


> Could it be that my IAP
> provider can "intercept" a scan and "report" spoofed results ? I doubt.

To find out (and to gain further information about the situation) I
would suggest to use hping2 to perform a manual "scan" on a single port
of which you are sure it is not (better: should not be) open. The result
should bring some light in this situation.

Kind regards
Christian Huetter

On 28 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1148807608.057988.272630@j55g2000cwa.googlegroups .com>, GM wrote:

>What ? 1659 open ports ? Sure looks to me as if the firewall went down.

Not only the firewall, but everything else - yeah, that would not be good.

>Also, as for services, this computer is mailing me the running services,
>which did not change either as I can read
>
>netstat --inet -a | grep LISTEN | awk '{printf ("%s %d %d %s %s
>%s\n",$1,$2,$3,$4,$5,$6)}'

OK - you know what you are doing. That helps tremendously.

>Yes, I know this is to be taken with a BIG grain of salt if the system
>has ever been compromised.

Do you really need all those services running? Yes, I'd hope they are
restricted by a firewall or libwrap/tcp_wrappers, but just the same...

>And well, if the firewall is down, well then I can maybe ssh to my system
>as nmap report to me:
>22/tcp open ssh
>
>But I can't:
>ssh xxx.xxx.xxx.xxx
>ssh_exchange_identification: read: Connection reset by peer

/usr/sbin/tcpdump -n -v -s 1500

Yes, ssh is encrypted, but see what you can see. Pay particular attention
to the TTL

>Well, perhaps my ssh is configured for access only from my internal
>network.

One would hope so. Two things - I don't run ssh on port 22, and I use
port-knocking.

>Now two tests I do; (Yeah, the first is a bit not so much netiquette
>maybe. But I am a bit parano<EF>d and want to be sure about my home computer)

>I run:
>#!/bin/bash

[...]

>where (zzz==yyy+20) then scanning around my Ip for other results from
>nmap. It turns out that all these show nearly the same output (to my
>surprise):

That smells strongly of a proxy. I'd be sniffing the wire and looking at
the TTLs. Also, you are flogging the crap out of the Internet, and if you
haven't been shut down locally for abuse, try using nmap to ID the operating
system of "your" home computer. man nmap and look at -sO and -O

>I have a hard time believing all these computers around mine ALSO have
>virtually no firewall... I can recognize my IAP name through reverse
>DNS on each of the above IP. So what ? Could it be that my IAP
>provider can "intercept" a scan and "report" spoofed results ? I doubt.

You are posting from Thailand. I don't _know_ that they have proxy servers,
but it's certainly not impossible. Singapore certainly does.

>My IP here is aaa.bbb.ccc.ddd. Running.
>nmap aaa.bbb.ccc.ddd
>
>also gives tons of output (like 1600 lines showing "open" ) But, then,
>I log to http://www.grc.com and ask for a scan of my ports on
>aaa.bbb.ccc.ddd here. It says all ports except #2(closed) are stealth.
>So what ? There is something from nmap that I don't understand.

Well, grc.com sucks black holes through bucky-tubes, but this is suggesting
that what ever you are actually nmap'ing is one proxy server. Look really
hard at those TTLs, and compare them to what you see if you traceroute to
various destinations.

Old guy

Thanks very much for your kind answers...

1) I can not see (so far..) anything here obviously showing that my
computer has been compromised.

2) In the meantime, since yesterday, I could make a phone call to my
home to ask for an on-site hand verification. This did show that the
firewall is still up.

3) Looking at the nmap output yesterday, I certainly overreacted and
maybe "panic" was the right word for qualifying this reaction. A scan
of ip's around mine is certainly not what I would normally do...

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

5) If I "traceroute" to my computer, I see, (well I do publish here the
hosts in between):
/usr/sbin/traceroute xxx.xxx.xxx.xxx | awk '/^ *[0-9]/{printf ( "%2d
%4d %4d %4d\n", $1, $(NF-5), $(NF-3), $(NF-1))}'
1 0 0 0
2 2 2 2
3 835 829 828
4 827 825 977
5 974 967 966
6 964 962 1963
7 1961 1959 1957
8 1956 1954 1952
9 1638 1637 1636
10 1633 1631 1630
11 1623 2720 2717
12 2716 2714 2712
13 2711 3069 2803
14 3066 3064 3061
15 1290 1288 1287
16 1283 1282 1796
17 1585 1583 1581
18 1578 1577 2092
19 2090 2089 2086
20 2083 2082 2081
21 1450 1449 1447
22 1445 1598 1596
23 1521 1518 1517
24 1587 1585 1582
25 1580 1579 1577
26 1575 1574 1572

.... but well, that does not mean much to me. However, of course, in the
complete output, I do recognize names until I get near my home city,
toward the last lines.

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. I want ssh for administration, lpd because there is a shared
printer, samba because there is in the internal network this other
computer that uses this other OS. ftp and http are allowed both in and
out also because I have information here I want to make available to
other peoples (news to friends etc). No other services are needed at
this point. Maybe I will allow ssh in the future, but certainly not
before I know better ... I think my netstat output (previous post) does
reflect these expectations of mine. If not, your kind comments are most
welcome.

5) I will try to find a friend (a linux friend, that is) in my home
country that can run a nmap scan for me and report the results to see
if that is different from the one I can run here. I may report that
here some time from now.

6) I will physically be at my home in two weeks from now to audit my
system. Maybe I will also report some more information then.

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.

Thanks,
Gaetan

> 3) Looking at the nmap output yesterday, I certainly overreacted and
> maybe "panic" was the right word for qualifying this reaction. A scan
> of ip's around mine is certainly not what I would normally do...

Well the output you found was alarming. Don't worry, everyone gets scanned
sometimes. Most of them probably have no idea.

--
To reply by email, change "deadspam.com" to "alumni.utexas.net"

On 29 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1148889897.890006.213270@j73g2000cwa.googlegroups .com>, 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

Very interesting. Hop 2-3 a dialing link. Well I think so, yes (see
below)

> 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?

Yes-yes. The only trouble here is I don't know what to expect... (!)
Your remark on "hop6/7" also make sense; this is what I can recognize
from our IAP. The complete traceroute output is:

traceroute to 64.6.196.207 (64.6.196.207), 30 hops max, 40 byte packets
1 router (192.168.39.1) 0.985 ms 0.636 ms 0.654 ms
2 our_gateway (10.142.170.113) 3.202 ms 2.193 ms 2.839 ms
3 192.168.5.13 889.343 ms 889.158 ms 888.693 ms
4 192.168.100.14 885.440 ms 883.861 ms 882.051 ms
5 192.168.100.18 881.153 ms 879.320 ms 1181.450 ms
6 inet-TOT-IPstar.inter.net.th (203.151.72.141) 1180.673 ms
1178.886 ms 1177.090 ms
7 203-154-152-201.inter.net.th (203.154.152.201) 1176.163 ms
1174.187 ms 1172.555 ms
8 203-151-72-30.inter.net.th (203.151.72.30) 1169.568 ms 1167.831
ms 1474.569 ms
9 203-150-222-9.inter.net.th (203.150.222.9) 932.377 ms 930.234 ms
928.780 ms
10 61.19.15.253 927.135 ms 926.265 ms 921.041 ms
11 202.47.253.138 916.432 ms 914.835 ms 1221.659 ms
12 202.47.253.233 1532.653 ms 1530.273 ms 1528.470 ms
13 ge-1-6.r01.lsanca03.us.bb.verio.net (204.1.253.17) 1525.583 ms
1523.703 ms 1521.384 ms
14 xe-0-1-0.r21.lsanca03.us.bb.gin.ntt.net (129.250.5.46) 1518.997 ms
1516.689 ms 1825.108 ms
15 p64-2-1-0.r21.mlpsca01.us.bb.gin.ntt.net (129.250.5.22) 1553.579
ms 1551.943 ms 1549.578 ms
16 p64-0-0-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.22) 1858.269
ms 1547.197 ms 1854.621 ms
17 xe-1-3-0.r21.sttlwa01.us.bb.gin.ntt.net (129.250.4.17) 1537.562 ms
1535.718 ms 1842.443 ms
18 p64-0-0-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.5.17) 1841.747
ms 1840.465 ms 1838.016 ms
19 xe-4-1.r03.nycmny01.us.bb.gin.ntt.net (129.250.2.221) 1836.751 ms
1834.576 ms 1833.082 ms
20 ge-0.group.nycmny01.us.bb.gin.ntt.net (129.250.10.174) 1829.529 ms
1827.341 ms 1827.304 ms
21 POS7-0.WANA-MTRLPQ.IP.GROUPTELECOM.NET (66.59.191.173) 931.720 ms
1241.903 ms 931.254 ms
22 216.18.72.146 1242.108 ms 1241.142 ms 1238.960 ms
23 h216-18-114-18.gtconnect.net (216.18.114.18) 1238.106 ms
1235.625 ms 1233.313 ms
24 h66-201-197-6.gtcust.grouptelecom.net (66.201.197.6) 1232.390 ms
1230.494 ms 1228.975 ms
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Running tcpdump (as you did type it; I must admit I did did not man
much) while running traceroute reveal plenty of interesting thing,
interesting in the way that I understand as much of it as I do
understand thaï; I mean not too much! But I can sure read that TTL, for
example, decrease to 241... then go back up to 243... (?huh?) On the
other hand, the output from a nmap gives me a single line... (see way
below in this long appendix...) My feeling is that is a bit strange to
have a single line... Trying the same tcpdump while running ftp also
reveals little. On the other hand, if I type tcp instead of icmp, I get
plenty of stuff. The same holds if I use tcp while running nmap...

Thanks. I think I learned something today...
Gaetan

(I tried to symplify the listing by running some s/time exceeded
in-transit/time/ and
s/ offset 0, flags \[none\], length: 56)/ off0,/)

colibri:/home/gaetan # /usr/sbin/tcpdump -n -v icmp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
96 bytes
05:27:19.311500 IP (tos 0xc0, ttl 64, id 35981, offset 0, flags
[none], length: 96) 192.168.39.1 > 192.168.39.199: icmp 76:time
05:27:19.313429 IP (tos 0xc0, ttl 64, id 35982, offset 0, flags
[none], length: 96) 192.168.39.1 > 192.168.39.199: icmp 76:time
05:27:19.314917 IP (tos 0xc0, ttl 64, id 35983, offset 0, flags
[none], length: 96) 192.168.39.1 > 192.168.39.199: icmp 76:time
05:27:19.317116 IP (tos 0xc0, ttl 254, id 24138, offset 0, flags
[none], length: 96) 10.142.170.113 > 192.168.39.199: icmp 76:time
05:27:19.317495 IP (tos 0xc0, ttl 254, id 24139, offset 0, flags
[none], length: 96) 10.142.170.113 > 192.168.39.199: icmp 76:time
05:27:19.320475 IP (tos 0xc0, ttl 254, id 24140, offset 0, flags
[none], length: 96) 10.142.170.113 > 192.168.39.199: icmp 76:time
05:27:20.061319 IP (tos 0x0, ttl 252, id 11549, off0, 192.168.100.14 >
192.168.39.199: icmp 36:time
05:27:20.061726 IP (tos 0x0, ttl 252, id 11550, off0, 192.168.100.14 >
192.168.39.199: icmp 36:time
05:27:20.061927 IP (tos 0x0, ttl 252, id 11551, off0, 192.168.100.14 >
192.168.39.199: icmp 36:time
05:27:20.062129 IP (tos 0x0, ttl 251, id 58993, off0, 192.168.100.18 >
192.168.39.199: icmp 36:time
05:27:20.062566 IP (tos 0x0, ttl 251, id 58994, off0, 192.168.100.18 >
192.168.39.199: icmp 36:time
05:27:20.062769 IP (tos 0xc0, ttl 253, id 18054, off0, 192.168.5.13 >
192.168.39.199: icmp 36:time
05:27:20.062968 IP (tos 0xc0, ttl 253, id 18055, off0, 192.168.5.13 >
192.168.39.199: icmp 36:time
05:27:20.063164 IP (tos 0xc0, ttl 253, id 18056, off0, 192.168.5.13 >
192.168.39.199: icmp 36:time
05:27:20.372017 IP (tos 0x0, ttl 251, id 58995, off0, 192.168.100.18 >
192.168.39.199: icmp 36:time
05:27:20.372439 IP (tos 0x0, ttl 250, id 16858, off0, 203.151.72.141 >
192.168.39.199: icmp 36:time
05:27:20.372640 IP (tos 0x0, ttl 250, id 16859, off0, 203.151.72.141 >
192.168.39.199: icmp 36:time
05:27:20.372840 IP (tos 0x0, ttl 250, id 16860, off0, 203.151.72.141 >
192.168.39.199: icmp 36:time
05:27:20.373038 IP (tos 0x0, ttl 249, id 36268, off0, 203.154.152.201 >
192.168.39.199: icmp 36:time
05:27:20.373471 IP (tos 0x0, ttl 249, id 36269, off0, 203.154.152.201 >
192.168.39.199: icmp 36:time
05:27:20.373673 IP (tos 0x0, ttl 249, id 36270, off0, 203.154.152.201 >
192.168.39.199: icmp 36:time
05:27:20.373874 IP (tos 0x0, ttl 248, id 35707, off0, 203.151.72.30 >
192.168.39.199: icmp 36:time
05:27:20.682641 IP (tos 0x0, ttl 248, id 35710, off0, 203.151.72.30 >
192.168.39.199: icmp 36:time
05:27:20.683003 IP (tos 0x0, ttl 248, id 35709, off0, 203.151.72.30 >
192.168.39.199: icmp 36:time
05:27:28.449948 IP (tos 0x0, ttl 247, id 0, off0, 203.150.222.9 >
192.168.39.199: icmp 36:time
05:27:28.450358 IP (tos 0x0, ttl 247, id 0, off0, 203.150.222.9 >
192.168.39.199: icmp 36:time
05:27:28.450549 IP (tos 0x0, ttl 247, id 0, off0, 203.150.222.9 >
192.168.39.199: icmp 36:time
05:27:28.450732 IP (tos 0x0, ttl 246, id 0, off0, 61.19.15.253 >
192.168.39.199: icmp 36:time
05:27:28.450918 IP (tos 0x0, ttl 245, id 0, off0, 202.47.253.138 >
192.168.39.199: icmp 36:time
05:27:28.451386 IP (tos 0x0, ttl 245, id 0, off0, 202.47.253.138 >
192.168.39.199: icmp 36:time
05:27:28.451575 IP (tos 0x0, ttl 246, id 0, off0, 61.19.15.253 >
192.168.39.199: icmp 36:time
05:27:28.451763 IP (tos 0x0, ttl 246, id 0, off0, 61.19.15.253 >
192.168.39.199: icmp 36:time
05:27:28.760433 IP (tos 0x0, ttl 245, id 0, off0, 202.47.253.138 >
192.168.39.199: icmp 36:time
05:27:29.071234 IP (tos 0x0, ttl 241, id 0, off0, 129.250.5.46 >
192.168.39.199: icmp 36:time
05:27:29.071631 IP (tos 0x0, ttl 241, id 0, off0, 129.250.5.46 >
192.168.39.199: icmp 36:time
05:27:29.071820 IP (tos 0x0, ttl 243, id 13390, off0, 204.1.253.17 >
192.168.39.199: icmp 36:time
05:27:29.072004 IP (tos 0x0, ttl 243, id 13392, off0, 204.1.253.17 >
192.168.39.199: icmp 36:time
05:27:29.072188 IP (tos 0x0, ttl 243, id 13391, off0, 204.1.253.17 >
192.168.39.199: icmp 36:time
05:27:29.072606 IP (tos 0x0, ttl 244, id 0, off0, 202.47.253.233 >
192.168.39.199: icmp 36:time
05:27:29.072793 IP (tos 0x0, ttl 244, id 0, off0, 202.47.253.233 >
192.168.39.199: icmp 36:time
05:27:29.072978 IP (tos 0x0, ttl 244, id 0, off0, 202.47.253.233 >
192.168.39.199: icmp 36:time
05:27:29.381801 IP (tos 0x0, ttl 241, id 0, off0, 129.250.5.46 >
192.168.39.199: icmp 36:time
05:27:37.459890 IP (tos 0x0, ttl 241, id 62430, offset 0, flags [DF],
length: 168) 129.250.5.22 > 192.168.39.199: icmp 148:time
05:27:37.460299 IP (tos 0x0, ttl 241, id 62431, offset 0, flags [DF],
length: 168) 129.250.5.22 > 192.168.39.199: icmp 148:time
05:27:37.460499 IP (tos 0x0, ttl 241, id 62432, offset 0, flags [DF],
length: 168) 129.250.5.22 > 192.168.39.199: icmp 148:time
05:27:37.460701 IP (tos 0x0, ttl 240, id 4586, offset 0, flags [DF],
length: 168) 129.250.4.22 > 192.168.39.199: icmp 148:time
05:27:37.461107 IP (tos 0x0, ttl 240, id 4588, offset 0, flags [DF],
length: 168) 129.250.4.22 > 192.168.39.199: icmp 148:time
05:27:37.461310 IP (tos 0x0, ttl 240, id 4589, offset 0, flags [DF],
length: 168) 129.250.4.22 > 192.168.39.199: icmp 148:time
05:27:37.770597 IP (tos 0x0, ttl 239, id 34111, offset 0, flags [DF],
length: 168) 129.250.4.17 > 192.168.39.199: icmp 148:time
05:27:37.771017 IP (tos 0x0, ttl 239, id 34112, offset 0, flags [DF],
length: 168) 129.250.4.17 > 192.168.39.199: icmp 148:time
05:27:37.771221 IP (tos 0x0, ttl 239, id 34138, offset 0, flags [DF],
length: 168) 129.250.4.17 > 192.168.39.199: icmp 148:time
05:27:37.771383 IP (tos 0x0, ttl 237, id 0, off0, 129.250.10.174 >
192.168.39.199: icmp 36:time
05:27:37.771569 IP (tos 0x0, ttl 237, id 0, off0, 129.250.10.174 >
192.168.39.199: icmp 36:time
05:27:37.772063 IP (tos 0x0, ttl 237, id 0, off0, 129.250.5.17 >
192.168.39.199: icmp 36:time
05:27:37.772295 IP (tos 0x0, ttl 237, id 0, off0, 129.250.5.17 >
192.168.39.199: icmp 36:time
05:27:37.772495 IP (tos 0x0, ttl 237, id 0, off0, 129.250.5.17 >
192.168.39.199: icmp 36:time
05:27:37.772680 IP (tos 0x0, ttl 237, id 11092, off0, 129.250.2.221 >
192.168.39.199: icmp 36:time
05:27:37.772865 IP (tos 0x0, ttl 237, id 11094, off0, 129.250.2.221 >
192.168.39.199: icmp 36:time
05:27:37.773050 IP (tos 0x0, ttl 237, id 11093, off0, 129.250.2.221 >
192.168.39.199: icmp 36:time
05:27:37.773237 IP (tos 0x0, ttl 237, id 0, off0, 129.250.10.174 >
192.168.39.199: icmp 36:time
05:27:41.187995 IP (tos 0x0, ttl 238, id 0, off0, 66.59.191.173 >
192.168.39.199: icmp 36:time
05:27:46.158965 IP (tos 0x0, ttl 238, id 0, off0, 66.59.191.173 >
192.168.39.199: icmp 36:time
05:27:47.401746 IP (tos 0x0, ttl 238, id 0, off0, 66.59.191.173 >
192.168.39.199: icmp 36:time
05:27:47.402140 IP (tos 0x0, ttl 235, id 56690, off0, 66.201.197.6 >
192.168.39.199: icmp 36:time
05:27:47.402325 IP (tos 0x0, ttl 236, id 8916, off0, 216.18.114.18 >
192.168.39.199: icmp 36:time
05:27:47.402513 IP (tos 0x0, ttl 236, id 8918, off0, 216.18.114.18 >
192.168.39.199: icmp 36:time
05:27:47.402995 IP (tos 0x0, ttl 237, id 10068, off0, 216.18.72.146 >
192.168.39.199: icmp 36:time
05:27:47.403184 IP (tos 0x0, ttl 237, id 10067, off0, 216.18.72.146 >
192.168.39.199: icmp 36:time
05:27:47.403373 IP (tos 0x0, ttl 236, id 8917, off0, 216.18.114.18 >
192.168.39.199: icmp 36:time
05:27:47.404249 IP (tos 0x0, ttl 236, id 10066, off0, 216.18.72.146 >
192.168.39.199: icmp 36:time
05:27:47.712356 IP (tos 0x0, ttl 235, id 57896, off0, 66.201.197.6 >
192.168.39.199: icmp 36:time
05:27:47.712707 IP (tos 0x0, ttl 235, id 57897, off0, 66.201.197.6 >
192.168.39.199: icmp 36:time

72 packets captured
72 packets received by filter
0 packets dropped by kernel


tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
96 bytes
05:34:51.800847 IP (tos 0x0, ttl 52, id 41968, offset 0, flags [none],
length: 28) 192.168.39.199 > 64.6.196.207: icmp 8: echo request seq
36887

On 29 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1148946079.863066.283120@u72g2000cwu.googlegroups .com>, GM wrote:

>Very interesting. Hop 2-3 a dialing link. Well I think so, yes (see
>below)

Looks that way to me too.

>> Does it look reasonable? Also, look at this same tcpdump output when you
>> nmap your "home system". Do the TTLs match what you expect?

Try again - you want to look at those ttls on all packets coming back from
Canada, not just the ICMP. More below.

>Yes-yes. The only trouble here is I don't know what to expect... (!)
>Your remark on "hop6/7" also make sense; this is what I can recognize
>from our IAP.

Hop six seems to be a box that is doing NAT at the very least. That
would explain the extra delays. I'd also expect that this would confuse
nmap scans.

>The complete traceroute output is:

OK - rather than me repeating back everything (this is going to be long
anyway), let me comment on this:

Hops 1 to 5 are all using RFC1918 addresses. This is fine within the
turf of the ISP (inter.net.th). They know where to route things - so
there isn't a problem. From out here, I can't send anything to those
addresses, because there is no way for any router between here and
Thailand to know where to send those packets.

Hop 6 to 9 is the ISP, bouncing around Thailand. Hops 10, 11, and 12 are
CAT Telecom in Bangkok, and to my limited understanding of the Thai
network, these guys are one of the backbones and the link out of the
country. That's good, because hop 13 to 15 are near San Francisco,
and you then hit Seattle (hop 16 and 17) and New York City (hops 18 to
20) via Nippon Telephone/Telegraph of America (who is tangled up with
Verio - the former Bell Atlantic of New York), before hitting GroupTelcom
in Montreal at hop 21. I assume you know the rest of the way home. ;-)

>Running tcpdump (as you did type it; I must admit I did did not man
>much) while running traceroute reveal plenty of interesting thing,
>interesting in the way that I understand as much of it as I do
>understand tha=EF; I mean not too much!

Quick answer - nothing looks to bad. The thing we are interested in is that
time to live figure, and for this traceroute, it appears normal. You might
try repeating this test using hping2 in the tcp and traceroute modes to see
if someone in Thailand is handling (what I presume to be) UDP packets from
a traceroute verses TCP packets from anything else in a different manner.

>But I can sure read that TTL, for example, decrease to 241... then go back
>up to 243... (?huh?)

Not impossible. That would be 12-14 hops away, and what _could_ have
happened is that the route in use changed, or (more likely) the route from
your location in Thailand to San Francisco is not the same as the route
from San Francisco to Thailand. Routing is not always the same in both
directions.

>On the other hand, the output from a nmap gives me a single line... (see
>way below in this long appendix...) My feeling is that is a bit strange to
>have a single line...

Is that this line?

>tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
>96 bytes
>05:34:51.800847 IP (tos 0x0, ttl 52, id 41968, offset 0, flags [none],
>length: 28) 192.168.39.199 > 64.6.196.207: icmp 8: echo request seq
>36887

Your system sent a ping (ICMP Type 8 Code 0) out, and nothing came back.
This could be a firewall someplace along the line, or the fact that
64.6.196.207 isn't responding to pings (it isn't, though I can see it
one hop beyond 66.201.197.6). This is an option in nmap - see the -P0
section on the man page.

>My feeling is that is a bit strange to have a single line...

man nmap - the section on -sP option.

>Trying the same tcpdump while running ftp also reveals little.

Meaning? What you want to see in the tcpdump is that the TTLs of the
packets coming back from afar at in the correct range. Do not include the
'icmp' option to tcpdump, as this is telling tcpdump to ignore all packets
that are not icmp. Assuming your home system is Linux, the "normal" TTL
starts at 64 for TCP and UDP packets (ICMP starts at 255), so you should
see TTLs in the low 40s - I'd expect 43 based on the traceroute.

>On the other hand, if I type tcp instead of icmp, I get plenty of stuff.
>The same holds if I use tcp while running nmap...

That's to be expected. Look at those TTLs. Connecting to your system in
Canada should show packets coming back with a TTL around 43 - let's say
40 to 46. If you see something else, it's highly probably that you are
NOT connecting directly. You can also try connecting to other sites -
mirrors of the Linux Documentation Project. What we're looking for is
those TTL figures. If every website you connect to has a TTL of 58 or
something, it's time to start waving the red flag of warning.

>Thanks. I think I learned something today...

Networking is a _very_ interesting subject that covers a lot of things we
take for granted. It's not totally complicated, but not many users look at
it because they have little need. If you look at the documents that govern
the contents of the packets, and how the hosts (end points, routers, and
gateways) do things, then you see basic rules - a lot of them.

0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896
bytes) (Also STD0006) (Status: STANDARD)

0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)

0792 Internet Control Message Protocol. J. Postel. September 1981.
(Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950)
(Also STD0005) (Status: STANDARD)

0793 Transmission Control Protocol. J. Postel. September 1981.
(Format: TXT=172710 bytes) (Updated by RFC3168) (Also STD0007)
(Status: STANDARD)

1122 Requirements for Internet Hosts - Communication Layers. R.
Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated by
RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

1123 Requirements for Internet Hosts - Application and Support. R.
Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates
RFC0822) (Updated by RFC1349, RFC2181) (Also STD0003) (Status:
STANDARD)

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644) (Status: PROPOSED STANDARD)

That's about 32000 lines (533 pages) 159,000 words, or about 1.25 megabytes
of text before we start including the 'Updated by' and so on. No, I don't
have it memorized. ;-)

Old guy

On Mon, 29 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
<slrne7nbb2.76i.ibuprofin@compton.phx.az.us>, I wrote:

>>On the other hand, the output from a nmap gives me a single line... (see
>>way below in this long appendix...) My feeling is that is a bit strange to
>>have a single line...
>
>Is that this line?
>
>>tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
>>96 bytes
>>05:34:51.800847 IP (tos 0x0, ttl 52, id 41968, offset 0, flags [none],
>>length: 28) 192.168.39.199 > 64.6.196.207: icmp 8: echo request seq
>>36887
>
>Your system sent a ping (ICMP Type 8 Code 0) out, and nothing came back.

It dawns on me - I looked at port 80 - what do the other ports look like?

13 POS7-0.WANB-MTRLPQ.IP.GROUPTELECOM.NET (66.59.191.177) 239.811 ms
219.398 ms 229.750 ms
14 216.18.72.154 (216.18.72.154) 229.697 ms 239.395 ms 229.718 ms
15 h216-18-114-42.gtconnect.net (216.18.114.42) 229.773 ms 239.443 ms
229.752 ms
16 h66-201-197-6.gtcust.grouptelecom.net (66.201.197.6) 239.709 ms
239.400 ms 229.722 ms
17 * * *

Now, I happen to know from another test that hop 17 for me is the
destination. Bingo - your firewall rules are set to 'stealth mode'
(which in iptables is 'DROP' or in IPCHAINS is 'DENY'). You won't see a
reply from this host unless you look at an open port. Thus, the
symptom you see above (no ICMP output when using nmap) is correct.
This host won't send a FOAD packet - it just ignores things.

OK - nothing wrong with your host - now find out what it is that nmap
is seeing. My guess is that it is something funny set up on the NAT
box at the ISP in Thailand.

Hmmm, now that is _two_ virtual Molsons (or Singha's - I like them too)
that you owe me ;-)

Old guy

Molsons; I don't have at hand right now. But Singha, yes I do. And I am
glad to send!

And yes, firewall rules are set to "DROP".

By the way, I could also receive another nmap output, this one executed
right in my home town and the result is what I was more expecting to
see (below)

Great thanks again for this insight
Gaetan

nmap -sS -O -p 1-1024 xxx.xxx.xxx

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-05-29
21:28
EDT
Warning: OS detection will be MUCH less reliable because we did not
find
at least 1 open and 1 closed TCP port
Interesting ports on xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx):
(The 1022 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20, Linux 2.4.10 - 2.4.18, Linux 2.4.19
(x86)
Uptime 24.828 days (since Fri May 5 01:37:31 2006)