[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nmap-hackers
Subject:    Adding optional data to UDP-scans
From:       Hank Leininger <hlein () progressive-comp ! com>
Date:       2000-12-11 23:10:58
[Download RAW message or body]

On a recent engagement, we discovered that a packet-filtering device
reacted differently when udp-scanning hosts behind it with nmap v2.5mumble
vs udp_scan from Satan (don't ask!).  udp_scan would correctly detect
listening ports on hosts behind the filtering device, while nmap would find
nothing.  Watching tcpdumps gave a probable explanation: udp_scan sends UDP
packets with one byte of data (a zero); nmap sends zero bytes of data.  The
filtering device was returning unreachables for all no-data packets, but
actually applying its ruleset (and allowing some traffic through) from the
one-byte packets.

Now, that behavior (by the filtering device) probably breaks RFC's.  And,
nmap's current default of sending zero-data packets probably has fewer
unintended side effects when poking at badly written UDP services.  But,
it'd be nice to have options to nmap to say "stick (some|this many) bytes
of (random|this) data in the UDP packets."  I'll work on a lame proof of
concept, but it'll probably not be as flexible as the nicetohave I just
described, nor coded prettily ;)

I'm also curious if some filtering devices have similar properties wrt ICMP
traffic; Ofir are you listening? ;)

--
Hank Leininger <hlein@progressive-comp.com>

--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to 
nmap-hackers-help@insecure.org . List run by ezmlm-idx (www.ezmlm.org).

[prev in list] [next in list] [prev in thread] [next in thread]