muliple host IPs: Feature request to scan all IPs per default or at least offer a cmd line switch

[drwetter]

Hello there,

I have a target which resolves to multiple IP addresses, let's say 1 through 4. There are two things I don't get and wasn't able to find in the man page.

1. it just scans IP number 1 when I supply a host name.
2. how can I tell nmap to use the given host name for target when scanning target IPs 2-4. This is handy for web server vhosts e.g.

For 1) it would be great to have a switch at least so that I can tell nmap to scan all IPs and not only one.

For 2) a switch would be great like --servername (see openssl s_client).

Cheers, Dirk

[djcater]

@drwetter For part 1 you can use the "resolveall" script like so:

nmap --script="resolveall" --script-args="newtargets" multiple-ip.example.com

This will add all resulting IP addresses to the target list, not just the first one.

For part 2, I thought Nmap did use the hostname for SNI if it was specified as a hostname in the target list, but I haven't actually verified that.

[nnposter]

Nmap will use stdnse.get_hostname for both SNI and the HTTP Host header. See the link for details on what gets returned. To my best knowledge, there is no ability to override this directly, akin to --servername in s_client.

One hack could be to instrument a lightweight resolver, such as dnsmasq.

[drwetter]

@drwetter For part 1 you can use the "resolveall" script like so:

nmap --script="resolveall" --script-args="newtargets" multiple-ip.example.com

This will add all resulting IP addresses to the target list, not just the first one.

yes, thx. But a) I am wondering whether scanning all IPs shouldn't be the default. b) also if not: The solution you suggested may have side effects, depends on the scripts invoked.

For part 2: my mistake, I looked at the wrong scan. You're right.

[dmiller-nmap]

Just added this today after some refactoring over the weekend. New syntax "*all" appended to target name will result in scanning all IP addresses for the target. Each one will have the same targetname, so SNI and HTTP Host header for vhosts should work perfectly.

Remaining issue: requests made through http.get are cached by hostname and port, so there will be cross-caching. I think we should split the http cache into separate ones in each host registry (if present), and only fall back to the global cache if host cache is unavailable. That way large parts of the cache drop out when each host is done scanning. Thoughts, @nnposter?

[nnposter]

I do not quite follow what you mean by

I think we should split the http cache into separate ones in each host registry (if present), and only fall back to the global cache if host cache is unavailable.

Namely, what would populate the global cache vs. the host-specific one and under what condition the host cache would not be available.

Trying to contemplate the issue completely independently, I think that the best approach might perhaps be to:

• Implement host-specific cache that captures only requests generated in the course of running NSE scripts against the current host and where the origin (i.e., the destination of the request) is also the current host.
• Implement global cache for all other requests.

This way the localized instance-specific findings will not get polluted by simultaneous scanning of sibling instances while we still optimize for a situation where multiple hosts/targets might be invoking the same script that is then repeatedly requesting some third-party data.

[dmiller-nmap]

That's exactly what I was trying to describe, thanks. The host cache is unavailable from the point of view of the http library when the "host" is a string and not a table with a registry subtable (i.e. not a NSE host object passed to a script by NSE). This would be the case when using http.get_url and possibly some other scripts that may mistakely call http.get(host.ip, port.number, path).

[drwetter]

Thx btw!