A portmap amplification attack works by asking an exposed rpcbind service to dump its entire table of registered RPC programs, rather than asking it where one program lives. Because the question travels over UDP with the victim's address forged as its source, the full answer lands on the victim, and a thorough DDoS test treats that as one of the Layer 4 reflection vectors worth exercising. The shared mechanics of spoofing and size asymmetry belong to the whole amplification attack family; what follows is what is particular to portmap.
What makes portmap amplification specific
The portmapper, now usually running as rpcbind and specified in RFC 1833, is the directory service for ONC RPC. It listens on port 111 over both TCP and UDP, and a client asks it which port a given program, such as NFS or mountd, is bound to. That normal lookup returns a single number and is useless to an attacker.
The DUMP procedure is different. It returns every mapping the host holds: each program number, version, protocol and port. A bare server registers only rpcbind itself, but an NFS server also registers mountd, nlockmgr, status and several versions of each over both transports, so its listing is many times the size of the request. The attacker's yield therefore depends on which hosts they find. US-CERT's advisory TA14-017A puts the amplification factor for portmap at 7 to 28 times, and that range is essentially the spread between a lightly and a heavily registered host.
Only the UDP side reflects. On TCP the handshake would fail against a forged source, so an exposed TCP 111 is an information leak but not a flood source.
The vector surfaced in live traffic in August 2015, when Level 3's threat research team published an early warning after seeing portmapper responses turn up in reflection floods on its backbone. The service had been reachable on the internet for decades by then; what changed was that attackers went looking for reflectors beyond DNS and NTP.
Why it matters under attack
The persistence of portmap as a reflector is mostly a packaging story. Many Linux distributions install rpcbind as a dependency of NFS client tools and enable it by default, and on systemd hosts it is socket-activated: disabling rpcbind.service alone leaves rpcbind.socket listening, and the next packet on port 111 starts the daemon again. An operator who believes they switched it off frequently has not.
On the receiving end, the flood carries a clean signature. Nothing legitimate on the public internet should be sending you UDP from source port 111, so an upstream ACL that drops that source port removes the vector cheaply and with almost no collateral. The catch is where that ACL sits. Applied at your own firewall it protects the host but not the link, which is already full by the time the packets are filtered, so the drop has to happen at the provider or scrubbing tier. Stopping the spoofed requests at their origin is BCP 38 territory and sits with other networks.
What a DDoS test measures
A test here asks three narrow questions. Does any host you run answer an rpcbind DUMP from outside, including hosts where the daemon was supposedly disabled. Does the upstream mitigation drop UDP from source port 111 before the circuit, rather than at the firewall behind it. And when portmap is mixed into a multi-vector flood, does that source-port rule still engage, or does it get lost behind a generic volumetric profile that throttles legitimate UDP along with it. Where portmap sits among the other UDP reflectors a test drives is laid out in Understanding DDoS Attack Vectors.