Re: IPv6 OS Detection: Call for fingerprinters!!

["Luis MartinGarcia." <luis.mgarc () gmail com>]

Hi again, Dario

Sorry for taking so long to respond.


On 07/07/2011 08:37 PM, Dario Ciccarone (dciccaro) wrote:
> So, here attached, yet-another-diff, this one to be applied to ipv6fp.py
> revision 24716 - adding the Source Link-Layer Address option to the NS
> message. I also added a try/except clause, but it's kind of useless -
> there is no try/except on scapy, so if you happen to pass the script a
> malformed IPv6 address, scapy is going to traceback before we get here,
> so . . . Maybe you could do the try/except w/ inet_pton() right after
> parsing the command-line arguments, and before actually doing anything.
> Your's and David's call :)

I've tested it and If i pass bogus addresses the script fails early
(long before the first test is sent) so I don't think we need to worry
about it.


> Ah, yes, about that. I run the "broadcast NS" version against a bunch of
> devices (OpenSUSE, Thecus NAS, Mac OS/X, AppleTV, iPhone, HP LaserJet
> printer, multiple IOS versions). Almost all of them actually replied to
> the broadcast NS. Cisco IOS, tried three releases - two of them did
> reply with a NA to the broadcast NS, while one of them did not. 
>
> As you can already guess, the one that did NOT was the one I originally
> used to test the script against ;)

Are you planning to share the result files for all those boxes? We'd
certainly appreciate it if you sent us the results for that NAS,
AppleTV, iPhone, printer etc, as we don't have fingerprints for that
kind of systems yet.


> Nope, no ACL blocking any traffic - just different behaviour. Also saw
> this specific release doing things different than other IOS releases,
> but those are still under investigation.

The fact that different versions behave differently is good news, since
that allows OS detection engines to distinguish stacks at the version level.


> Talking about OS tests - I haven't had the time to look at all the tests
> that ipv6fp is performing, but one of the things I saw during my testing
> is that some OSes, on reception of the NS, would reply with a NA and
> issue their own NS, while others would issue the NS first and then
> answer the NA. In case you think it would be a worthwhile test to also
> try to distinguish between one IPv6 stack implementation and another -
> if they answer the NS first, before sending their NA, or after sending
> their own NS. As this is all local segment only, slim possibility of the
> test being messed up by latency/load/others, IMHO.

That is interesting. We have not yet decided if we are going to send
different probes when the target machine is on-link or off-link, but if
we end up doing that, this is something worth considering. Thanks for
the tip!

Best regards,

Luis MartinGarcia.




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/