Skip to content

excludefile order matters if smaller range is included in bigger range #2257

@nv1t

Description

@nv1t

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions