changes. The first is that Port objects don't allocate memory for
service and RPC results unless that information is set. This reduces the
size of a bare Port from 92 to 40 bytes on my machine. The second change
is that PortList now has the notion of a "default port state," which is
the state of any ports that didn't receive a response. These ports don't
need an allocated Port object, which saves a lot of memory in scans
where most ports didn't get a response.
message once per host, not one per hostgroup. Include the IP address and
tryno in the message. It now looks like
Warning: 64.13.134.52 giving up on port because retransmission cap hit (0).
This was suggested by Chris Clements.
because of a lack of responses. Otherwise there is no way for that
number to decrease after moving on to the next port, leading to an
infinite loop. Lionel Cons reported the problem and provided a debug log
at http://seclists.org/nmap-dev/2009/q4/364.
test that was applied to packets returned in ICMP error messages.
Because some operating systems modify the IP ID outside of Nmap's
control, the apply_ipid_match function had a built-in heuristic whereby
it would deactivate itself (always return true) if this seemed to be
happening. What this meant in practice was that every time a successful
match was made, a counter was incremented, and if the ratio of
successful matches to successful matches was over 80%, IP ID matching
was enforced.
The matching and heuristic could cause relevant probes to be dropped in
some cases. See http://seclists.org/nmap-dev/2009/q2/665 for an example
of this and discussion. The IP ID match was always done in combination
with other tests; so even without it we are still dealing with a
relevant probe. The IP ID distinction could at best distinguish between
retransmissions of the same probe, and it was not necessary for that in
every case, such as with most TCP probes where we can use the SEQ field.
I thought this small benefit was not worth the risk of potentially
losing replies that we care about.
/nmap-exp/david/nmap-token. This brings in the following changes:
Use a strict tryno equality test in check_tryno_pingseq. This appears to
have no effect in the current code, because the way we traverse the
probe list backwards ensures that probes with a higher tryno are tried
first. However this protects against matching the wrong tryno if that
behavior is ever changed.
Factor out the code that checks for a match of a TCP packet.
Add some extra checks when matching up TCP probes, to avoid confusing
responses to SYN and ACK probes when they are sent to the same host on
the same port, with the same tryno and pingseq, in a ping scan that
includes both -PS and -PA. I think this is the only case where there can
be confusion. The new rules are: A SYN/ACK can only be matched to a SYN
probe. A RST/ACK can only be matched to a SYN or FIN. A bare RST cannot
be matched to a SYN or FIN.
Make an important change in the way the tryno and pingseq are encoded
for TCP probes with the ACK flag set when --source-port is in effect.
According to RFC 793, responses to ACK packets on an unestablished
connection (CLOSED and LISTEN states in particular) should send a RST
response with a SEQ value the same as the received ACK value. So for
example, if it's in the CLOSED state and wants to send a RST, it sends
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
if the received packet does not have the ACK flag set, but
<SEQ=SEG.ACK><CTL=RST>
This caused a problem because in the second case, the response does not
reflect our sent SEQ value, which is where the tryno and pingseq are
encoded. The response's acknowledgement number, while not valid because
the ACK flag is not set, is typically 0. Decoding this with seq32_decode
would result in a decoding error, leading to a
Bad Sequence number from host
message. In this case the probe was allowed to match any TCP probe with
the same ports and address, even though the pingseq and tryno might be
off or the probe is a different kind of probe entirely (like a SYN
probe).
Here's a summary of what has changed, with <tryno,pingseq> standing for
an encoded tryno and pingseq.
Before:
Non-ACK probes sent with SEQ=<tryno,pingseq>, ACK=0.
ACK probes sent with SEQ=<tryno,pingseq>, ACK=random
Probes matched against ACK and ACK - 1.
Now:
Non-ACK probes sent with SEQ=<tryno,pingseq>, ACK=0.
ACK probes sent with SEQ=0, ACK=<tryno,pingseq>.
Probes matched against ACK, ACK - 1, and SEQ.
Matching against the SEQ field may also help in some other weird cases.
In the LISTEN state, the receiving TCP is supposed to check that "the
security/compartment on the incoming segment does not exactly match the
security/compartment in the TCB," and if it doesn't, return
<SEQ=SEG.ACK><CTL=RST>
just like in the ACK case. I don't know how common that sort of thing is.
Nmap used two functions: one of them, hdump(), just printed raw hex bytes
(no ASCII equivalents) and the other one, lamont_hdump() had a bug when
printing buffers where bufflen%16==3. A new function has been implemented
from scratch, that basically produces the same output as Wireshark.
Output looks like this:
0000 e8 60 65 86 d7 86 6d 30 35 97 54 87 ff 67 05 9e .`e...m05.T..g..
0010 07 5a 98 c0 ea ad 50 d2 62 4f 7b ff e1 34 f8 fc .Z....P.bO{..4..
0020 c4 84 0a 6a 39 ad 3c 10 63 b2 22 c4 24 40 f4 b1 ...j9.<.c.".$@..
Changes:
- The new hexdump() function has been added to nbase.
- Old hdump() and lamont_dump() have been removed from nmap's code.
- A wrapper to the new hexdump(), called nmap_hexdump(), has been added
to nmap's utils.cc. The wrapper basically prints the buffer returned
by hexdump() using nmap's log_write() function.
including alias extension, in several places to avoid this error message
when an alias has an IP address but the primary interface doesn't:
Failed to lookup subnet/netmask for device (venet0): venet0: no IPv4 address assigned
The patch also considers an interface alias if the primary interface
does not appear in the list of interfaces (perhaps because it does not
have an IP address assigned) when building the table of routes.
target address address field, not the destination address in the
enclosing ethernet frame. Some operating systems, including Windows
7 and Solaris 10, are known to at least sometimes send their ARP
replies to the broadcast address and Nmap wouldn't notice them. The
symptom of this was that root scans wouldn't work ("Host seems
down") but non-root scans would work. Thanks to Mike Calmus and
Vijay Sankar for reporting the problem, and Marcus Haebler for
suggesting the fix.
o Fixed a log_write call and a pfatal call to use a syntax which is
safer from format strings bugs. This allows Nmap to build with the
gcc -Wformat -Werror=format-security options. [Guillaume Rousse]
code to increase the scan delay if tries increased too much. But the
main loop did an unconditional continue before incrementing tries, so it
was always 0. I looked back at the history and saw that it was always
like this for RPC scan. tries was only incremented for the other scan
types handled by pos_scan, which now are done by ultra_scan. So I
removed the tries accounting and dependent code.
a layer 4 protocol used mostly for telephony related applications.
This brings the following new features:
o SCTP INIT chunk port scan (-sY): open ports return an INIT-ACK
chunk, closed ones an ABORT chunk. This is the SCTP equivalent
of a TCP SYN stealth scan.
o SCTP COOKIE-ECHO chunk port scan (-sZ): open ports are silent,
closed ports return an ABORT chunk.
o SCTP INIT chunk ping probes (-PY): host discovery using SCTP
INIT chunk packets.
o SCTP-specific IP protocol scan (-sO -p sctp).
o SCTP-specific traceroute support (--traceroute).
o The ability to use the deprecated Adler32 algorithm as specified
in RFC 2960 instead of CRC32C from RFC 4960 (--adler32).
o 42 well-known SCTP ports were added to the nmap-services file.
Part of the work on SCTP support was kindly sponsored by
Compass Security AG, Switzerland. [Daniel Roethlisberger]
right type of probe (0 with 8, 14 with 13, 18 with 17). With the new
default ping, I was scanning a network where an echo reply would
mistakenly be interpreted as a response to a timestamp request, even
though that host didn't respond to timestamp requests. That host would
become the global ping host, and all its probes would be dropped,
slowing the scan way down. A ping scan of a /24 took over 1,000 seconds
when it should have taken about 10.
exhaustive testing of 90 different probes, this one emerged as the
best four-probe combination, finding 14% more Internet hosts than
the previous default, -PE -PA80. The default for nonroot users is
-PS80,443, replacing the previous default of -PS80. In addition,
ping probes are now sent in order of effectiveness (-PE first) so
that less likely probes may not have to be sent.
Found whacked packet protocol 17 in get_ping_pcap_result
and rewrite it
Received packet with protocol 17; ignoring.
The message is printed when we receive a packet we can't use during a
ping scan, but it's not "whacked" to receive a UDP packet during a TCP
scan for example.
that it is set properly for ping scan. Previously status reports during
ping scan always looked like
Stats: 25:34:33 elapsed; 991232 hosts completed (72530 up), 0 undergoing Ping Scan
Note the "0 undergoing". Now that number will be set to 4096 or whatever
the current ping scan group size happens to be.
increases the scan dealy with an increase in max_successful_tryno. When I
reverted a bunch of changes in r11651, I removed the moved code, leaving the
scan delay increase nowhere. This puts it back in ultrascan_port_probe_update
where it was before.
Don't make a host the global ping host until it moves to the completed
hosts list, and only change the global ping probe if the new probe is no
worse than the old (according to pingprobe_is_better).
Restore the ping magnifier for host congestion window updates.
Ignore the timing of certain ICMP errors that are likely to be rate
limited and don't change the port or host state. Avoid making timing
pings out of probes that elicit such errors. This used to be done only
for port scans and only at -T4 and above (and didn't prohibit the
creation of timing pings). Now it is done for host discovery too, and at
all timing levels.
Gracefully handle updates from the recent past in RateMeter. Doesn't
affect performance, but avoids a rare assertion failure.
num_probes_active == 0 in HostScanStats::completed. The reason for this is
fairly subtle and I didn't realize it at first: We have to make sure there are
no active probes because once in the completed list, probes don't time out.
Probes that are active stay active in the count. If the congestion window ever
falls below the number of these active probes, the program will hang waiting
for them to time out.
We could get away with this in the case of up hosts, because we call
HostScanStats::destroyAllOutstandingProbes in that case. We could do that in
the down case too, but that would prohibit a down host from being found up
later on. That's currently a matter of some luck; we don't keep sending probes
after a host is down but will accept replies to any other probes that have
already been sent.
source address didn't match the target address. Fyodor correctly pointed out
that this is wrong for UDP scans, when we need to slow down for a firewall
sending unreachables to know which probes don't elicit one. I'm going to try
something a little different in nmap-perf.
is up or down, we can move it to the completed list, regardless of any active
probes. However I can imagine changing this so that we move it when it is found
up, or when it is found down and there are no probes left to send. That would
give a down host a chance to become up with a different probe later on.
