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_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Dec 06 2000
Intro
