mailing list archives
TCP retries and OS type detection
From: "Ronald F. Guilmette" <rfg () monkeys com>
Date: Wed, 27 Feb 2002 11:18:14 -0800
I was just mucking about with a program I'm working on that uses
sockets, and an idea occured to me regarding some ways that various
protocol stacks might give additional clues to what they are...
above and beyond the things that Nmap already checks for.
Basically, while testing error handling in a program I'm working
on, I was able to watch a log of the packets that were being sent
out when my test program simply tried to do an outbound connect(2)
to a non-responsive port on some system elsewhere.
I watched the retries occuring, first on a FreeBSD system, and then
later on a Linux system.
Anyway, unless I wasn't seeing the results of my tests correctly, I
have to say that it appears to me that various TCP implementations may
perhaps perform differing numbers of retries (for what they percieve
as dropped packets) and/or they may send retries at varying rates,
or with varying timings for the first, second, third retries, etc.
Of course, trying to gleen information from either the apparent number
of retries, or the timing of those retries might be highly unreliable,
given that some or all of the retry packets could themselves be either
dropped or delayed, but it still seems to me that it might be worthwhile
to try to gather this type of information (when doing OS fingerprinting)
anyway. If it comes down to a choice between the OS fingerprinting
saying either "I haven't the vaguest idea what this is." or "I can't
tell for sure, but my best guess is that the target is running ZZZUnix,
Version 9999." then I for one would prefer the latter.
Please feel free to tell me if this is a dumb idea. I will freely admit
to not knowing a lot of the deep details of TCP, so maybe I'm all wet
for even suggesting this idea. I'm just trying to help.
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).
- TCP retries and OS type detection Ronald F. Guilmette (Feb 27)