Re: Combinatorial Test with Nmap

[Daniel Cater <djcater () gmail com>]

I think some of the combinatorial stuff could be useful for looking for
bugs in Nmap (crashes, errors etc. due to unexpected combinations of
command line arguments).

But for host discovery, a lot of what you've got is redundant.

You've got 8 discovery techniques there (-PE, -PP, -PM, -PS, -PA, -PU, -PY,
-PO), which is good, but they are all independent as far as I know.
Combining them in different invocations of the command is just repeating
scans you've already done (e.g. you have ICMP Echo in 8 different
commands). You can probably just do each discovery type once and get the
same results.

As for the scans, some of the techniques are interesting and may possibly
find some interesting results in some environments (e.g. testing different
scan flags, fragmenting packets), but others are also redundant or
problematic. Examples:

- Doing both -sS and -sT - if you have the local privileges to perform a
SYN scan, you will not find any extra open ports by doing a TCP scan.
- Using -f with -sT doesn't make a difference, according to the man page
(it only applies to raw packets)
- Duplicating each scan with a different TTL (e.g. 25 and then 50). I can't
think of a scenario where this would make a difference?
- For the scanflags, you're not specifying a base scan type so it will
default to -sS. This may or may not make sense, depending on how you want
the responses to be interpreted into the different Nmap port states.
- You're doing data-length 0 and data-length 128. According to the man
page, this means you are never getting the protocol specific payloads,
which can help elicit responses for certain ports (e.g. sending a DNS
payload to UDP port 53). You're probably better off doing a scan without a
data-length parameter all to at least pick up some of the default protocol
payloads.

And actually, at the end of it, you're not scanning anything more than the
top 1000 most common ports anyway by the looks of it. You need something
like -p- / -p1-65535 or similar.

Overall, there are some interesting ideas but for the most part you are
drastically increasing the running time for minimal benefit, or in some
cases, worse results.

(For anyone reading, please correct me if I've gotten any of this wrong).


On Thu, 7 Mar 2019 at 20:34, Tim McLean <ifly53e () gmail com> wrote:

> Combinatorial Test (CT) techniques were used to exhaustively cycle through
> most Nmap options to statistically maximize host discovery and port
> scanning use cases.  I could use your experience to determine if invalid
> combinations were produced.  I could also use your opinions on how to prove
> if using CT with Nmap is a good or bad thing.
>
> Please check out my github repo for more information.  It has all 24 host
> discovery instances and all 88 port scanning instances derived from three
> way combinations of options.  I would appreciate your feedback.
>
> https://github.com/ifly53e/NmapBomb
>
> Thanks.
> Tim
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/