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
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
2.2.22 as vulnerable.
The corresponding ChangeLog entry for Apache 2.2.22 says:
"""
Fix a regression introduced by the CVE-2011-3192 byterange fix in 2.2.20:
A range of '0-' will now return 206 instead of 200.
"""
https://issues.apache.org/bugzilla/show_bug.cgi?id=51878
http://seclists.org/nmap-dev/2012/q3/56. r29134 already addressed the issue but
was incomplete.
This replaces r29134 with an engine-agnostic approach, and additionally enforces
the reset of IOD flags before use or re-use.
Some scripts that had been previously modified were updated so that the debug output was consistent.
A few scripts were calling identify_404 with host.ip as opposed to the proper host object. This has been adjusted as well.
that were internally closed and replaced by other ones. This happened during
reconnect attempts.
--
When reconnecting with SSL_OP_NO_SSLv2 (nsock_core.c:472), the libary closes the
fd of the current IOD, and replaces it by a new one.
The man page for epoll_ctl states that a close() on a fd makes it removed from
any epoll set it was in. Therefore, if epoll_ctl(EPOLL_CTL_MOD, ...) returns
ENOENT, we retry with EPOLL_CTL_ADD.
