This vulnerability relates to Portmap services that are accessible to the internet.
As with other UDP based protocols, the Portmap service may be used as traffic amplifier for distributed denial-of-service attacks [2-3] as well as attacks against your own instance. If an instance is being exploited in this way, AARNET is likely to place a block on its IP address, which will effectively disconnect it from the internet until the issue can be investigated. NeCTAR may treat your instance as "compromised".
Portmapper (rpcbind) may also be used to gather information about instances, including details of NFS exports that the instance is making available. This may be sufficient to allow an attacker to gain access to your NFS file systems.
Checking to see if you are vulnerable
To manually test if a system is still vulnerable, you can use the command:
rpcinfo -T udp -p [ip]
If the portmapper service is not required it would be advisable to turn the service off. If it is required, the US-CERT recommends the following:
Source IP Verification
Because the UDP requests being sent by the attacker-controlled clients must have a source IP address spoofed to appear as the victim's IP, the first step to reducing the effectiveness of UDP amplification is for Internet service providers (ISPs) to reject any UDP traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force (IETF) released Best Current Practice 38 in May 2000 and Best Current Practice 84 in March 2004. These documents describe how an ISP can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet's path . Recommended changes would cause a routing device to evaluate whether it is possible to reach the source IP address of the packet via the interface that transmitted the packet. If it is not possible, then the packet most likely has a spoofed source IP address. This configuration change would substantially reduce the potential for many popular types of DDoS attacks. As such, we highly recommend that all network operators perform network ingress filtering if possible. Note that such filtering will not explicitly protect a UDP service provider from being exploited in a DRDoS because all network providers must use ingress filtering to eliminate the threat completely.
To verify your network has implemented ingress filtering, download the open source tools from the Spoofer Project .
Limiting responses to UDP requests is another potential mitigation to this issue. This may require testing to discover the optimal limit that does not interfere with legitimate traffic. The IETF released Request for Comment 2475 and Request for Comment 3260 that describe some methods to shape and control traffic . Most network devices today provide these functions in their software.