probes that will be sent and calculate from that. This makes the 100%
completion match up closely with the end of the scan, as the estimate gets
better as the scan gets closer to finishing. It also works against filtered
hosts. There is still the related problem that the completion time estimate
uses a global average to estimate completion rate, so it tends to
underestimate.
estimates, and don't consider the number of outstanding probes or number of
retries. The old code would overestimate completion, causing a period of 99.99%
completion at the end of a scan (which caused earlier estimates to be too
soon). For a long UDP scan this puts the completion estimate right on after a
little time to allow for convergence. See
http://www.bamsoftware.com/wiki/Nmap/CompletionTimeEstimates.
instead of a custom hash table and an STL list instead of a custom linked list.
The biggest gain comes from using the list.sort method rather than inserting
ports in sorted order (equivalent to insertion sort). The new code passes
Doug's p-switch-tests.
Here are time comparisons, using the old and new services code, and using the
standard nmap-services file and the 65535-port nmap-services-huge. The times
are the duration of the call to nmap_services_init. Three trials were done for
each case, except for the old-code/nmap-services-huge case.
nmap-services:
old code: 0.215 0.201 0.227 (average 0.214 s)
new code: 0.025 0.022 0.023 (average 0.023 s)
nmap-services-huge:
old code: 441.014 (average 441.014 s)
new code: 0.984 0.975 0.978 (average 0.979 s)
the present. This allows the sending rate to temporarily exceed the
maximum to keep from being slowed too much by other delays in the scan
engine. See the discussion at http://seclists.org/nmap-dev/2008/q3/0236.html.
liblua and libm. This is necessary for static builds of Nmap, such as RPM
builds. Before this the error that was caused looked like
SCRIPT ENGINE: error while initializing script rules:
error loading module 'bit' from file '/usr/libexec/nmap/nselib-bin/bit.so':
/usr/libexec/nmap/nselib-bin/bit.so: undefined symbol: lua_pushnumber
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/share/nmap/nselib/packet.lua:12: in main chunk
[C]: in function 'require'
/usr/share/nmap/scripts/rpcinfo.nse:10: in main chunk
[C]: ?
[C]: in function 'Entry'
/usr/share/nmap/scripts/script.db:8: in main chunk
[C]: ?
[C]: ?
probes, especially IP protocol probes.
Previously if IP protocol ping (-PO) was used anywhere in a host
discovery scan, any response was treated as a protocol response. (The
handlers for other response types had an explicit check for this.) This
means that if you did
nmap -PS -PO
and got back a SYN/ACK in response to the -PS probe, it would be marked
with a reason of proto-response rather than syn-ack. Now, because the IP
protocol response handler matches so broadly, it is given the last
chance at handling a response, only if no interpretation makes sense.
Now the aforementioned scan will give a reason of syn-ack.
The old behavior was not only misleading with respect to reasons, it had
a minor and subtle bug. Consider the following packet trace:
SENT (2.0990s) TCP 192.168.0.21:42205 > target:25 S ttl=40 id=39342 iplen=44 seq=114128202 win=1024 <mss 1460>
SENT (2.2560s) TCP 192.168.0.21:42205 > target:53 S ttl=40 id=51247 iplen=44 seq=114128202 win=1024 <mss 1460>
SENT (2.3280s) TCP 192.168.0.21:42206 > target:25 S ttl=37 id=31111 iplen=44 seq=114062667 win=2048 <mss 1460>
RCVD (2.3530s) TCP target:53 > 192.168.0.21:42205 SA ttl=51 id=0 iplen=44 seq=4159224453 win=5840 ack=114128203 <mss 1460>
ultrascan_host_probe_update called for machine target state UNKNOWN -> HOST_UP (trynum 1 time: 25123)
Ultrascan DROPPED probe packet to target detected
Changing ping technique for target to tcp to port 25; flags: S
Why is the received packet marked as a drop? And why is the ping
technique change to SYN to port 25 when the response came back from port
53? The reason is that the IP protocol response handler caught the probe
and decided it was in response to one of the sent TCP probes--any of the
TCP probes. It selected the probe to port 25 essentially at random and
used that as the relevant probe. The result is that a drop is wrongly
recorded (slowing down the scan), and a worse than useless ping probe is
used (worse than useless because it will cause another drop any time
it's used).
I found this while trying to emulate PortBunny's default ping scan,
which is
-PS80,25,22,443,21,113,23,53,554,3389,445 -PA3333,11 -PE -PP -PU161,162 -PO51
though not in the same order Nmap uses.
