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
<1148946079.863066.283120@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, 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
.

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: 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)
  • Re: drop or reject
    ... It's a D-Link DI-604 Router on a home system. ... >There are three very simple rules about services and open ports: ... >look in the logs, ... >unwanted packets you are going to save your bandwidth, ...
    (comp.security.firewalls)