Re: studies/papers/etc. on getting best results w. nmap?

["Michael Pattrick" <mpattrick () rhinovirus org>]

With regards to points 1&2, I'm afraid no such thing exists, and I doubt
it could exist. A generic guide to network mapping would necessarily have
to encompass all the specific cases for all network equipment between the
scanner and the target. This becomes a futile effort in combinatorics for
scans that go past two hops. Furthermore, most network appliances can be
configured such that an administrator can change their fingerprint on a
whim.

Consider a hypothetical scan of TCP ports 110-140. 110 is open, 113 and
135-140 are filtered, and the remaining ports are closed. This result may
be due to, but is not limited to, one of the following:
1. Your ISP is blocking port 113 out, the target networks gateway router
is blocking MS active directory on all hosts, and the target host really
only has one port open.
2. You ISP isn't blocking any ports, the target host(ip address) is
actually composed of multiple systems that the target network gateway is
load distributing across multiple hosts(producing different results). The
local NNTP cache(port 119) appears closed because you aren't inside the
network, not because it isn't serving anything
3. The target network actually has a firewall which is blocking port 113
inbound(as well as several other ports), in between the firewall and the
target machine is a router full of ACL's. This network only allows active
directory connections in from specific IP ranges.
4. The network's firewall detected a port scan, and dropped all packets
from the last few ports scanned, which happen to be the active directory
ports.

> From just the scan it is impossible to determine which scenario this scan
falls into, or if it's something completely different. Tools like
qscan.nse to figure out if it's a port forwarded *host* and tricks like
grabbing the POP3 banner may reveal some of the networks topology. But
these aren't generic, those two steps are very specific to this scenario.

If you don't have any insight into the networks topology then you will
always be stuck with some ambiguities. That said, it may be of benefit to
create a "troubleshoot your scan results" checklist, which would include
ideas on how to reduce or conceptualize ambiguities in scan results.

-M

On Mon, September 3, 2012 9:37 pm, ^..^ wrote:
> I have read the book.  It's a fine work, and does have some tips on how to
> better gain information (stateful vs. stateless, source port manipulation,
> etc., etc), but it doesn't have anything like how much better these might
> be in terms of %'ages or surveys or what is better except in very general
> terms that might be interpreted by an expert; the little case studies
> (e.g. the IP ID trick, which basically says "start by using your
> experience as someone who has a deep knowledge of packets and networks")
> are marvelous for one-offs or analyzing specific scans, but not as a
> general rule or something to rely on when looking at large data sets.  It
> also doesn't have any specific vendor differences that I can recall, and
> certainly not a survey of them.  Nor does it speak about the differences
> of the platform you're scanning from and the effects on nmap itself.
>
> So no, I don't believe the book is any help to answering any of my
> questions.
>
> I was asking if anyone had any #'s/statistics/etc on whether or not
> certain things mattered, not what the certain things were.  If no one has
> ever done a study on it, fine, but I'm not looking for one-off tricks of
> analysis that may or may not be a good fit.
>
> --d
>
> ^..^
>
> On Sep 3, 2012, at 6:04 PM, "DePriest, Jason R." <jrdepriest () gmail com>
> wrote:
>
> > Fyodor's book Nmap Network Scannings has plenty of examples and
> > specifically talks about scanning through firewalls.
> >
> > http://nmap.org/book/
> >
> > Give it a look.
> >
> > -Jason
> >
> > On Mon, Sep 3, 2012 at 5:02 PM, ^..^ <> wrote:
> > > Hey folks -
> > >
> > > Have there been any studies done on the accuracy of nmap, or ways to
> > > improve the same?  I've done a bit of searching but certain types of
> > > things are harder to find than others, and nmap shows up everywhere for
> > > just about any search term ;)  If I've missed anything obvious, my
> > > apologies, an RTFM or link would be awesome.
> > >
> > > I'm on a project where many of the targets are probably behind
> > > firewalls/network devices, and I've 3 very basic q's.   I'd love to be
> > > pointed at any discussions or papers on any of theem (or feel free to
> > > speak up with your own opinions ;)   As a test I've started assigning
> > > weights to various results (e.g. closed is more closed than filtered),
> > > and it's showing at least some promise.
> > >
> > > 1) Any references on whether closed (or other results) are more
> > > open/closed than all the various outputs you can get - e.g. filtered,
> > > close|filtered, etcetera.
> > >
> > > 2) And are there any archives/talks/papers/DBs about what individual
> > > routers/fw implementations tend to return?  E.g. "cisco's tend to
> > > return closed|filtered where junipers tend to use "open|filtered" or
> > > anything?
> > >
> > > 3) Purely based on my own tests over the years I believe pretty
> > > strongly that I get different results when scanning from different OS's
> > > (e.g. scanning from Linux vs. OS X, with all other factors taken under
> > > consideration), and some scans are faster - at times substantially so -
> > > on one vs. the other.  Are some OS's (and/or versions within, aka 64
> > > vs. 32 bit, or using different compilers, having more memory, whatever)
> > > seen as better nmap scanners than others?  It'd be nice to be able to
> > > optimize for nmap scanning, or even some types of scanning.  If there
> > > were a place to dump results of various sorts of scans I'd certainly
> > > contribute my own timings and such.   (I think this question is
> > > independent of the performance tips @
> > > http://nmap.org/book/man-performance.html, but presumably some options
> > > there work better in some situations as well.)
> > >
> > > Thanks for all the hard work on nmap!
> > >
> > > dan
> > >
> > > ^..^
> > >
> > > _______________________________________________
> > > Sent through the nmap-dev mailing list
> > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > Archived at http://seclists.org/nmap-dev/
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


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