-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
Changing the order of the IP ranges inside the excludefile changes the outcome. Having a smaller IP-Range which is included in a bigger IP-Range and both defined in the excludefile, might excludes everything, if small IP-Range is in front of the big IP-Range.
This can be a single IP Address as well instead of an IP-Range.
It only happens if the smaller range is included in the bigger range.
To Reproduce
Running: nmap --excludefile exclude.list 192.168.0.0/16 with the following two different excludefiles:
Small Range in front of Big Range:
-> % cat exclude.list.doesnotwork
192.168.1.64/25
192.168.1.0/24
-> % nmap --excludefile exclude.list.doesnotwork 192.168.0.0/16
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-25 10:28 CET
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.04 seconds
Small Range after Big Range
-> % cat exclude.list.works
192.168.1.0/24
192.168.1.64/25
-> % nmap --excludefile exclude.list.works 192.168.0.0/16 -vvv
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-25 10:37 CET
Initiating Ping Scan at 10:37
Scanning 4096 hosts [2 ports/host]
...
Expected behavior
It shouldn't matter which option the IP-Ranges are inside the excludefile.
Version info (please complete the following information):
- OS: Linux 5.8.0-43-generic
-> % nmap --version
Nmap version 7.80 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.1d nmap-libssh2-1.8.2 libz-1.2.11 libpcre-8.39 libpcap-1.9.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select
Same behaviour with: Nmap version 7.91