Date: Tue, 27 Mar 2018 21:06:58 +0100 From: Jamie Landeg-Jones <jamie@catflap.org> To: rfg@tristatelogic.com, jamie@catflap.org, freebsd-net@freebsd.org Subject: Re: Same host or different? How can you tell "over the wire"? Message-ID: <201803272006.w2RK6xu2051790@donotpassgo.dyslexicfish.net> In-Reply-To: <22999.1521916685@segfault.tristatelogic.com> References: <22999.1521916685@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ronald F. Guilmette" <rfg@tristatelogic.com> wrote: > In message <201803241747.w2OHlupR069759@donotpassgo.dyslexicfish.net>, > Jamie Landeg-Jones <jamie@catflap.org> wrote: > > >Have you thought of examining the TCP timestamp field? Not necessarily > >for accurate uptime, but a way to determine if the hosts are the same. > > No, I certainly didn't, but that appears to be the exact kind of thing > I was looking for, so thanks! (I will have to look into it some more. > I have just skimmed RFC 1323 for the very first time ever, and it will > take me awhile to fully grok this stuff.) > > >Or some of the other fingerprinting methods? nmap has options for uptime > >and other fingerprinting : https://nmap.org/book/osdetect-usage.html > > I'm not seeing a separate option just for the uptime, apart from the > full blown OS detection. Did I just miss it? Sorry for the delay in replying. You're right - I don't think nmap has a seperate option, which seems strange to me, but still, the extra information may also help - especially for systems that block timestamp information leakage. 2 other ideas: You could also try checking the IP ID in a returning packets header. Used primarily for identifying fragments of a fragmented datagram, hosts traditionally increment (and wrap) this 16 bit value for each packet they send. Some hosts randomise this value, making this technique useless, but for those that don't, try this: # ping catflap.dyslexicfish.net & ping catnip.dyslexicfish.net & ping catseye.dyslexicfish.net All 3 should respond. If that's the case, leave that running, and in a new window, do: # tcpdump -lnv icmp and src host catflap.dyslexicfish.net or src host catnip.dyslexicfish.net or src host catseye.dyslexicfish.net | awk '($0 !~ "^[[:blank:]]") {printf "\n"} {printf "%s", $0}' (note the 'v' flag on the tcpdump to show the IP header information. The awk script is just to stop tcpdump wrapping output lines) You'll see something like this: 21:01:34.809142 IP (tos 0x0, ttl 56, id 43497, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 628, length 64 21:01:34.877061 IP (tos 0x0, ttl 50, id 28626, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 628, length 64 21:01:34.945069 IP (tos 0x0, ttl 54, id 25030, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 628, length 64 21:01:35.813005 IP (tos 0x0, ttl 56, id 43508, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 629, length 64 21:01:35.881953 IP (tos 0x0, ttl 50, id 28640, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 629, length 64 21:01:35.949967 IP (tos 0x0, ttl 54, id 25035, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 629, length 64 21:01:36.861471 IP (tos 0x0, ttl 56, id 43520, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 630, length 64 21:01:36.929752 IP (tos 0x0, ttl 50, id 28657, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 630, length 64 21:01:36.997415 IP (tos 0x0, ttl 54, id 25045, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 630, length 64 21:01:37.866177 IP (tos 0x0, ttl 56, id 43526, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 631, length 64 21:01:37.936751 IP (tos 0x0, ttl 50, id 28669, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 631, length 64 21:01:38.004537 IP (tos 0x0, ttl 54, id 25050, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 631, length 64 21:01:38.922487 IP (tos 0x0, ttl 56, id 43538, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 632, length 64 21:01:38.992473 IP (tos 0x0, ttl 50, id 28683, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 632, length 64 21:01:39.059168 IP (tos 0x0, ttl 54, id 25058, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 632, length 64 21:01:39.978330 IP (tos 0x0, ttl 56, id 43565, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 633, length 64 21:01:40.047226 IP (tos 0x0, ttl 50, id 28705, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 633, length 64 21:01:40.114158 IP (tos 0x0, ttl 54, id 25078, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 633, length 64 21:01:41.032534 IP (tos 0x0, ttl 56, id 43577, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 634, length 64 21:01:41.101740 IP (tos 0x0, ttl 50, id 28730, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 634, length 64 If you look at the first id field in each line, you'll clearly see that these are 3 different hosts, as we have id's from 43497-43577, 28626-28730 and 25030-25078. ("missing" id's are simply due to the host replying to other packets, so this can also give a rough idea how busy a host is... If there are no missing id's, you're the only active connection!) The other idea: https://nmap.org/p60-12.html - This has details to help you can detect if any sort of load balancer/firewall etc. exists between you and the target, which is useful as they could cause false positives and false negatives. Hope this helps! Cheers, Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803272006.w2RK6xu2051790>