Re: SYN/FIN scans in nmap?

[Fyodor <fyodor () insecure org>]

On Mon, 4 Dec 2000, Ryan Permeh wrote:

> this is all well and good, but it's not quite as simple as that.  what
> criteria would you use to define open ports?  you would need a much more
> robust definition of a scan, including not only the outgoing packets,
> but
> also pertinenet returned packets to define things like port state(open,

Yes, that is exactly the reason that Nmap isn't going to offer arbitrary
packet generation capabilities.  You should use a lower level tools like
hping + tcpdump for that.

HOWEVER, there are several neat scans you can do which are identical to
supported scans except for one minor change.  Paul gave the example of
SYN|FIN scans which are for all intents and purposes identical in behavior
to SYN scans except for the TCP flags of the sent packet.  So why would
you use such a SCAN?  Because some IDS vendors are stupid^H^H^H^H^H^H lazy
and only write rules for scan types they find in the Nmap man page.  
Also, this can exploit poorly configured firewalls/filters.  Lets say our
novice admin wants to ban incoming connections and so he rejects any
packets with the SYN flag set.  Oops!  There goes outgoing connections due
to the SYN|ACK part of handshaking.  So our "clever" admin then goes "Aha!  
What I want to do instead is drop packets with ONLY the SYN flag instead."  
That way SYN|ACK can come in while those naked SYN packets which signify
an incoming connection are disabled.  Obviously this admin has left
himself open to SYN|FIN scanning (and connections).

And this is far from an isolated case.  Here is another example:  Replace
the FIN flag in FIN scans (-sF) with the PSH flag.  The scan works just
fine except your scan is "off the beaten path" and perhaps less likely to
be recognized as such.

Modifying a SYN or FIN (etc) scan to use different flags is a trivial 1-3
line change to the Nmap source code.  I know people who do it religiously
whenever they upgrade to a new version.

So I probably will add a feature like this at some point.  Don't expect it
to be documented though.  It will be more of an "easter egg" for the
Nmap-dev community :).

Cheers,
-F



---------------------------------------------------------------------
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).