Recently there has been a surge in the use of UDP amplification based distributed denial of service (DDoS) attacks on the Internet. So much so, that the US-CERT has issued a couple of advisories to highlight the issue. The are available at:
- TA14-017A: UDP-based Amplification Attacks https://www.us-cert.gov/ncas/alerts/TA14-017A
- TA14-013A : NTP Amplification Attacks Using CVE-2013-5211 https://www.us-cert.gov/ncas/alerts/TA14-013A
- TA13-088A : DNS Amplification Attacks https://www.us-cert.gov/ncas/alerts/TA13-088A
Firstly, some terminology.
- Denial of service attacks are attacks against some infrastructure whereby the volume of traffic (in some cases legitimate) is used to overwhelm either the target device itself or upstream devices resulting in the target device being unable to provide “typical” or “acceptable” levels of service to the intended audience.
- Distributed DoS attacks make use of a number of attacking machines as opposed to just one source. These attacking machines are generally hijacked PCs controlled by a “botnet” controller.
- Spoofing is a technique whereby the source address in transmitted IP packets is not the IP address of the sending machine. It could be termed “computer identity fraud”, since the source address is typically faked, or spoofed, to be that of the target of an attack
- UDP is “easy” to use for this class of attacks since it is connectionless and does not require a connection set-up handshake as TCP does.
- Amplification attacks are attacks whereby an attacker can use the behaviour of a, typically an intermediary, host to generate more “reply” or “response” traffic than “attack” traffic. In other words, for each “attack” packet an attacker sends, the “amplifier” host generates multiple packets in response. These response packets are sent to the source address in the attack pack.
So, based on the above we can link the components together to explain this type of attack which is under way. Attackers are currently using their botnets to generate “attack” traffic, from multiple source machines, with the IP packets’ source address field containing the victim’s IP address. The traffic is sent to hosts which can be used to amplify the traffic. These hosts are typically, currently DNS or NTP servers. These servers generate multiple packets in response to a single “attack” packet. These reply packets are sent to the victim’s IP address, which is included in the attack packet. All these reply packets coming from multiple amplification hosts typically swamp the victim resulting in an unusable host.
Why is NTP used to do this? Well, in years gone by when the Internet was considered safer, various protocols had diagnostic and informational commands or options available to assist with troubleshooting or just to provide further information about a server’s status. One such option for an NTP server was that used by the ntpdc command “monlist”. This command returns information about all the recent clients which have communicated with an NTP server, and this list of clients can be quite long. Typically, one NTP query packet sent to an NTP server with the “monlist” command code can result in many packets in response. Since UDP is not connection orientated, the client and server do no initial handshake and hence the server “trusts” that the indicated source IP address of the query is actually the “real” source IP address. Unfortunately, attackers know this weakness and exploit it by spoofing the traffic with the victim’s IP address.
How can we avoid situations like this? Well, two simple things can be done to mitigate many of these attacks
- Implement traffic filtering to limit IP address spoofing. Egress and, if possible, ingress filtering should be put in place as appropriate.
- Limit publicly exposed IP based services – block or disable everything and enable on a port by port (case by case) basis. Ensure that those services which are exposed are configured securely and limit their functions to those necessary.
If “consumer” ISPs (i.e. ISPs providing service to end users) were to implement ingress filtering from their customers then many of these attacks would cease since spoofing would not be possible. If these same ISPs were to filter their egress traffic then their customers would only be able to spoof the address of other customers. I don’t understand why more ISPs do not implement proper filtering. Ingress and egress filtering has been mentioned for many years now, so I don’t understand why more ISPs don’t implement it. I do understand that carrier ISPs cannot always implement suitable filtering, but ISPs for end users should be able to!
The second point is more tricky. So many devices are exposed to the internet these days. NAT has limited the number of devices “directly attackable” from the outside, so we are lucky in that regard. However there are plenty of publicly accessible devices which are not configured correctly, either due to lack of interest, ignorance or error.
That last word “error” is what prompted me to write this post. Early this morning I started receiving some Nagios warnings about ping failures to one of my VPS servers. Given traffic limits on the VPS, I implemented rate filtering on the VPS to limit my exposure to unexpected traffic bills. Upon investigation I discovered that it was being used as an NTP amplifier. Hmm. Turns out, when I configured the VPS I had used
restrict default kod nomodify notrap nopeer nomodify
restrict default kod nomodify notrap nopeer noquery
OOPS! As a result the evil attackers out there were able to use the VPS to generate amplified traffic. Yes, there are IP filters in place, but this VPS did need to be exposed for NTP service unfortunately so couldn’t be blocked entirely. Needless to say, with the correct configuration in place the traffic levels have dropped off and the server is accessible once more.
So people, we need to be ever more vigilant on this big-bad Internet. Make sure traffic filtering is in place to prevent spoofing. Filter unnecessary traffic where possible. Configure services securely.