Running nmap, masscan and zmap from a VPS without getting null-routed

Most hosts do not ban scanning because they disapprove of it. They ban it because a scan and a SYN flood look identical to a flow-based detector, because the abuse desk gets an automated report from every network you touched, and because dealing with that costs more than your VPS earns. Understand those three mechanisms and you can run authorised scans for years without an incident.

This guide is about staying online while you work: the permission paperwork, the settings that keep you under the detector, exclusion lists that are not optional, and the tool-specific flags that matter — for nmap, masscan and zmap.

Before any packet leaves: the paperwork

An abuse complaint is won or lost in the first reply. If you can answer within an hour with a scope document, a date range and a client contact, the report is closed as authorised testing. If you cannot, your IP gets null-routed while somebody figures out what you are.

So before the engagement starts, keep on the box:

• Written authorisation naming the exact ranges and hostnames in scope, signed by someone with authority over them, with a start and end date.
• An explicit out-of-scope list. Third-party services the target uses — their CDN, their payment processor, their SaaS mail — are somebody else’s assets and are not covered by your client’s signature.
• A contact on both sides who can be reached out of hours, because that is when the pager goes off.
• Your own log of what you scanned, from which IP, at what rate and when. Reconstructing this from shell history three weeks later is miserable.

Tell your host before you start, not after

Scanning from a general-purpose VPS on a provider’s clean IP range is how you get suspended, even when the work is legitimate: the range is shared with customers whose mail deliverability depends on it, so the provider’s incentive is to cut first.

VMHeaven separates that explicitly. The Pentesting KVM line permits zmap and masscan scanning and web scraping, and sits on an isolated network segment rather than the regular customer ranges — the abuse policy for it is written for security work instead of copied from a shared-hosting template. For longer-running lab infrastructure, Pentesting Dedicated is the single-tenant version, with no neighbours to bother. On any other line, open a ticket and describe the work before the first packet — the answer is frequently yes, and it is a different conversation once an upstream has already complained.

Make your scanner identifiable

This is the highest-value, least-practised step in the whole process. An anonymous IP hammering port 443 across a /16 is an attacker. The same traffic from an address that explains itself is a researcher, and a large share of recipients will never file a report at all.

• Set reverse DNS that says what it is — something on the order of scanner-01.research.example.com. Anyone who sees your address in a log looks it up first. Reverse DNS is set from the control panel on your provider’s side, not on the server.
• Serve a page on port 80 explaining who is scanning, why, how to read the logs they are seeing, and how to opt out. One static file.
• Publish a monitored abuse address on that page and answer it fast.
• Identify yourself in the protocol too where the tool allows it — a descriptive User-Agent for HTTP-layer work costs nothing and prevents a lot of misreading.
• Honour opt-outs permanently and automatically. One network that asks to be excluded goes into the exclusion file for every future run, not just this one.

Exclusion files are not optional

Every wide scan needs a blocklist, and every tool supports one. Skipping it is how people accidentally scan their own provider’s management network, a neighbour’s VMs or somebody’s honeypot farm.

zmap ships a sane default at /etc/zmap/blocklist.conf, built from the IANA special-purpose registry. It is the right starting point for the others too:

0.0.0.0/8           # "this host on this network"
10.0.0.0/8          # RFC1918 private
100.64.0.0/10       # RFC6598 carrier NAT
127.0.0.0/8         # loopback
169.254.0.0/16      # link-local — includes cloud metadata at 169.254.169.254
172.16.0.0/12       # RFC1918 private
192.0.0.0/24        # IETF protocol assignments
192.0.2.0/24        # TEST-NET-1
192.88.99.0/24      # 6to4 relay anycast
192.168.0.0/16      # RFC1918 private
198.18.0.0/15       # benchmarking
198.51.100.0/24     # TEST-NET-2
203.0.113.0/24      # TEST-NET-3
224.0.0.0/4         # multicast
240.0.0.0/4         # reserved
255.255.255.255/32  # limited broadcast

Add to it, every time, three more categories:

• Your own provider’s ranges. Scanning the network you are sitting in is the fastest route to a suspension, and it triggers internal alarms that are not subject to anyone’s judgement.
• Everyone who has ever asked to be excluded. Keep the file in version control with a date and a reason per entry.
• Anything out of scope on the engagement. Put the client’s out-of-scope list into the exclusion file rather than trusting yourself to remember it at 2am.

Rate is the number that decides whether you survive

DDoS mitigation in front of a hosting network mostly counts packets per second and new flows per second, not intent. A scan at a few hundred packets per second is invisible traffic. The same scan at a hundred thousand packets per second is, to a scrubbing appliance, an outbound flood — and the automated response is to null-route the source, which is you.

• Start an order of magnitude below what you think you need and ramp up over several runs, watching for anything that changes. A scan finishing in six hours instead of forty minutes is not a problem; losing the IP is.
• Spread wide rather than deep. Randomising target order — which masscan and zmap do by default — means no single destination network sees a concentrated burst, and concentrated bursts are what generate reports.
• Watch connection tracking on your own box. If the server runs a stateful firewall, every probe consumes a conntrack entry and the table fills long before the uplink does.

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
sudo dmesg | grep -i "nf_conntrack: table full"

If those numbers meet, packets get dropped silently and your results quietly go wrong. Raise net.netfilter.nf_conntrack_max, or — better for a dedicated scanning box — stop tracking the scanner’s own outbound traffic at all. A UFW setup that is closed inbound and untracked outbound is the right shape for this machine.

nmap: precise, scoped, slow on purpose

nmap is the wrong tool for the whole internet and the right tool for a scope list. Give it a target file, an exclusion file and an explicit rate ceiling:

sudo nmap -sS -Pn -n \
  --top-ports 1000 --open \
  -iL scope.txt --excludefile exclude.txt \
  --max-rate 500 --max-retries 2 --host-timeout 15m \
  -oA runs/2026-09-20-scope1

• -sS is the SYN scan — it needs root and never completes the handshake, which is both faster and gentler on the target than -sT.
• -Pn skips host discovery. Use it when the scope says the hosts exist; it avoids a separate discovery sweep that looks like its own scan.
• -n turns off reverse DNS. It removes a large, chatty side channel of queries to somebody else’s resolvers and speeds the run up considerably.
• --max-rate is the flag that keeps you employed. -T4 and friends are templates that adapt to the network; --max-rate is an absolute ceiling, and an absolute ceiling is what an abuse desk understands.
• -oA writes normal, grepable and XML output from one run. Always keep all three: the XML is what you feed into anything else, and the normal file is what you paste into the report.

For a quieter pass, --scan-delay spaces probes out deliberately, and --max-retries 1 stops nmap from re-probing filtered ports — retransmissions are a surprisingly large share of the packets a careless scan emits.

masscan: its own TCP stack, and what that implies

masscan is asynchronous and carries its own network stack, which is why it is fast and why it has one famous gotcha: when a target answers your SYN with a SYN-ACK, the Linux kernel — which knows nothing about the connection masscan invented — replies with a RST and kills it before a banner can be read.

The fix documented by masscan itself is to keep the kernel out of the way, either by giving masscan its own source IP or by firewalling the source port it uses:

# pick a port outside the kernel's ephemeral range
cat /proc/sys/net/ipv4/ip_local_port_range      # e.g. 32768 60999

sudo iptables -A INPUT -p tcp --dport 61000 -j DROP
sudo masscan 198.51.100.0/24 -p80,443 --banners --source-port 61000 \
  --rate 1000 --excludefile exclude.txt -oX runs/masscan.xml

Three more flags worth knowing before a long run:

• --rate is packets per second and defaults to a deliberately tiny 100. It is the only throttle that matters; set it consciously every time.
• --open-only (also spelled --open) drops closed-port lines from the output, which on a wide scan is the difference between a readable file and a gigabyte of noise.
• Ctrl-C writes paused.conf, and masscan --resume paused.conf picks the scan back up. Use it — restarting a wide scan from the beginning doubles the traffic everyone sees.

zmap: single-packet, single-port, stateless

zmap is built for one port across a very large address space and is the most polite of the three by default: it randomises the whole address space, ships a blocklist, and will not start without you thinking about rate.

sudo zmap -p 443 \
  -b /etc/zmap/blocklist.conf \
  -B 10M \
  -n 1% \
  -o runs/zmap-443.csv

• -b / --blocklist-file is the exclusion list, and -w / --allowlist-file constrains the scan to ranges you are allowed to touch. On an authorised engagement, use the allowlist — a positive scope list cannot leak the way a negative one can.
• -r / --rate sets packets per second and -B / --bandwidth sets bits per second with K, M and G suffixes. Bandwidth is usually the one you actually want to cap on a shared uplink.
• -n / --max-targets accepts a count or a percentage of the search space, which makes “scan 1% of this and see what happens” a one-flag experiment.
• -d / --dryrun prints the packets instead of sending them. Run it once before every new scan shape — it catches an inverted allowlist before the internet does.

zmap bypasses the kernel stack for sending in the same way masscan does and uses its own source port range, so the same principle applies: if you are doing anything that needs the response to stay alive, make sure the kernel is not answering on those ports.

When the abuse report arrives anyway

It will, eventually, and it is not a crisis if you handle it like routine work.

• Answer within hours. Speed matters more than eloquence — an unanswered report escalates automatically.
• Have a template ready: who you are, what the traffic was, the authorisation behind it, the exact window, and the opt-out you have already applied.
• Apply the opt-out first, then reply. “Already excluded” ends a thread that “we will exclude you” does not.
• Pause the run if the complaint is about volume. Turning the rate down before you are asked is what distinguishes a research operation from a problem.

Checklist before the next run

• Written authorisation on the box, with dates and an out-of-scope list.
• Host told, on a line where this work is allowed.
• Reverse DNS, an explanation page on port 80, a monitored abuse address.
• Exclusion file current — baseline, your provider, every past opt-out.
• Rate set explicitly and deliberately low for the first run.
• Conntrack headroom checked, results written to a file, run logged.

Keep the scanner on its own machine, hardened like anything else exposed to the internet — key-only SSH and the rest of the base setup — and rebuild it between engagements so findings from one client never sit next to another’s. A fresh box per engagement is a minute of provisioning and removes an entire category of problem.

Frequently asked