Forensic Analysis of a DDoS Attack
In this blog post we are going to do a forensic analysis of a DDoS attack. The DDoS analysis is supported by screenshots captured from a LANGuardian system that was monitoring network edge traffic via a SPAN port at the time of the attack.
The purpose of our DDoS analysis is to demonstrate how DDoS monitoring can identify an attack in progress. With the information gathered by using a DDoS attack monitor, we can then take steps to mitigate against these types of DDoS attacks.
Why DDoS Monitoring is Important
Over the past ten days in Ireland, numerous online services and public networks have been targeted by DDoS attacks. A recent article from the BBC also suggests that website-crippling cyber-attacks are to rise in 2016 – the organization itself having been taken offline by a massive DDoS attack at the end of last year.
The majority of the recent attacks in Ireland were NTP amplification attacks. NTP is a popular vector for DDoS attacks because, like DNS, it is a simple UDP-based protocol that can be persuaded to return large replies to small requests. It has been estimated there are over a hundred thousand abusable NTP servers with administrative functions incorrectly open to the general Internet.
Using LANGuardian as a DDoS Attack Monitor
All of the following screenshots were taken using LANGuardian as a DDoS attack monitor on a real network. The network was one of many that suffered multiple DDoS attacks during January 2016. The first image below shows traffic associated with this network at a time when it was not under attack. What I am watching out for here is:
- The majority of the traffic is IPv4.
- Over 97% of traffic is TCP with small amounts of UDP. This is very normal and what I would expect.
- Drilldown on the UDP traffic shows the majority is DNS. For most networks DNS Would be the most active UDP protocol. Exceptions this this would be on networks where applications like Bittorrent are allowed.
The next screen shot shows the network traffic profile during a time when the network was under attack. The main thing that stands out is the UDP traffic is now the majority. This is the classic fingerprint of a UDP based amplification attack. You can read more about amplification attacks here and here.
Drilling down on the UDP traffic reveals that the network is receiving large amounts of NTP and DNS traffic. Both of these are important protocols so you cannot just block them. The other issue is that the network packets will contain spoofed IP addresses so basic firewall rules are useless.
Composed of legitimate-appearing requests, massive numbers of “zombies” and spoofed identities that make it virtually impossible to identify and block these malicious flows.
Drilling down further reveals that the traffic appears to originate from 4700 different servers. We can do a WHOIS by IP address and determine that these are valid NTP servers, owned by reputable organizations.
It’s unlikely that 4700 reputable NTP servers are compromised and targeting an attack at the network, so something else is happening here.
The NTP protocol is based on UDP, a connection-less protocol. This means that a malicious client can create an NTP request, but instead of using its own IP address as the source, it uses the IP address of the target network. The NTP server assumes the request is genuine and responds, sending the response, not to the originating client, but to the target network.
This is known as a reflection attack. We can determine this is occurring, because our network has not sent any NTP packets to the NTP servers in question (zero packets sent, zero bytes sent) as seen here.
Further, we can calculate that the average received NTP response packet size is about 440 bytes, significantly larger than a standard NTP response packet (about 90 bytes). The 440 byte packet is likely a response to a ‘monlist’ request, a remote command in older NTP servers to return a list of the last clients to contact it. The ‘monlist’ command returns multiple packets of this size in response to a single request. This is known a amplification, where a small request generates big responses.
Finally, what of the client that originated the NTP request? We have no information about that client, as it successfully forged the source IP address in the original NTP request. We can assume that the client was a member of a botnet and was issued commands to target this network. There can be many thousands of compromised clients in a given botnet.
The scenario is shown in the diagram below, showing how a single C&C, controls many zombie clients, to generate malformed NTP requests to many servers, which in turn send amplified responses to the target network. Click on image to zoom in.
Any local servers shown in the reports would need to be checked for malware activity. It could end up as a zombie host in a botnet or it may also be serving up Malware.
Using DDoS Analysis to Mitigate Against DDoS Attacks
When it comes to mitigating against DDoS attacks, you do have a number of options. It does depend on what stage you are at. If you are presently under attack, you may need to weather the storm a bit and avoid any rush decisions. Blocking traffic for example may only introduce other problems and you may end up with a network cut off from the outside world.
It is critical that you have some type of network activity monitoring in place prior to and during an attack. Make sure you can see where the traffic is coming from and what servers are being targeted. To try and mitigate against an attack you should consider the following.
- See if your ISP can black hole the suspicious traffic. Most will not get involved but if you are an education or government institute you may be able to address the issue at an ISP level.
- If you host your own web applications or servers you could consider a local DDoS protection system. These high-performance appliances enable attack traffic analysis and cleaning of the traffic, enabling a defense against large-scale DDoS attacks. Good traffic goes one way and bad traffic is dropped.
- If your website is hosted externally you could consider something like the Cloudflare DDoS protection infrastructure. They do the job of sorting out the good traffic from the bad in the cloud.
- In some extreme cases I have heard of companies changing their ISP to get away from the problem. Their public IP addresses seem to be a constant target to the only way out is to change them by moving to a different ISP.
Do you have any tips for mitigating against DDoS attacks? Comments welcome.
Sorry. No data so far.