Vlatko reported that this script was taking an inordinate amount of time
even in typical scans. This patch reduces the number of domains tried by
default. The new http-vhosts.filelist script argument allows
substituting the original list or another of your choosing.
Patch by Vlatko.
http://seclists.org/nmap-dev/2012/q3/432
Scripts no longer need to implement caching of datafiles tables in the
registry, since the datafiles.lua library keeps its own cache in the
registry. A side-effect is that scripts should not change the tables
returned by datafiles.parse_{protocols,rpc,services,mac_prefixes}(), as
doing so will affect all other scripts that use those functions.
Show the uninterpreted remote URLs in every case. When matching specific
services, show the guesses about where the source might be hosted, but
remove verbose interpretation like "accessed over SSH".
Before:
| Remote: git@github.com:skullspace/breachdb.git
| GitHub remote: skullspace/breachdb (accessed over SSH)
|_ -> Source might be at https://github.com/skullspace/breachdb
After:
| Remote: git@github.com:skullspace/breachdb.git
|_ -> Source might be at https://github.com/skullspace/breachdb
According to rtnetlink(7), such routes are "an unreachable destination."
I get such a route when I ifdown my he-ipv6 interface:
$ /sbin/route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::/0 :: !n -1 1 26122 lo
The problem with not ignoring such routes is that Nmap will think that
the interface to use is lo, and consequently that all the targets are
localhost addresses. Ping scan will succeed with a localhost-response,
but trying to send any packets will fail with "destination unreachable."
Maybe we should do the same thing for these additional values of
rtm_type?
RTN_BLACKHOLE a packet dropping route
RTN_PROHIBIT a packet rejection route
This type is used by OpenVZ venet interfaces. We "handle" such an
address type just by blanking the MAC address field.
Lack of support for this type of interface was preventing Nmap from
working on certain systems.
http://seclists.org/nmap-dev/2012/q2/763
An earlier message about this same type of interface is
http://seclists.org/nmap-dev/2009/q3/303
