DDoS Identification through Backscatter Detection
A very interesting, an often underused method, of detecting DDOS attack traffic is to monitor your perimeter for packet backscatter. This could be in the form of ICMP or RST packet backscatter whereby packets are sent to the victim from sources which have been used as reflection points as part of the attack. Monitoring for ICMP and RST packets gives you the ability to detect and confirm attack traffic and enable you to define the attack vector used by the threat actor.
The main aim of a DDOS attack is to render the underlying server useless to legitimate traffic. Bad guys can employ a range of techniques and can deliver a very wide range of attack types to your door. It is common for bad guys to use Botnets to distribute their traffic and a very common technique is the use of Reflection.
A reflected DDOS can be imagined as per the following diagram which shows an example of DNS Reflection. The same principle applies to a reflected TCP attack as well:
In this case a bad guy sends a packet to an open DNS resolver and spoofs the source address (i.e. where the replies will be sent to) to be that of the victim. The open DNS resolver replies to the victim, therefore they are reflecting the traffic to the victim.
What bad guys will do however is use a large number of targets to reflect off, and some of these targets may no longer be reachable, exist or serve the responses to the given query. If that is the case, the server may respond with an ICMP packet, which we can use as warning for malicious traffic.
So, continuing the example of a DNS Reflection attack, what happens when you send a DNS query to an IP address that does not respond to DNS queries? Let's craft a DNS query and view the output in Wireshark:
dig ANY colin.guru @126.96.36.199
Here, if I were a bad guy I'd be using an IP of an open DNS resolver, but to demonstrate the point I chose 188.8.131.52 as it's an IP I know full well is not a DNS resolver:
dig ANY colin.guru @184.108.40.206 ; <<>> DiG 9.8.3-P1 <<>> ANY colin.guru @220.127.116.11 ;; global options: +cmd ;; connection timed out; no servers could be reached
Good, so it failed to resolve the DNS query as expected, what happened in the pcap?
So, you see the DNS packet was retried a few times, but with the same result. The DNS packet was sent, but on each occasion the server returned an error in an ICMP packet. In this case the error was port unreachable, as the IP is not listening on 53 for incoming connections.
This means you can monitor your perimeter for an influx of ICMP messages. You should baseline your own threshold and trigger an alert for a review of the traffic. This will likely, in a lot of instances, give you a view of an attack directed at your door.
Other protection and detection mechanisms will of course be required, so this method should be treated as another feather in the cap of your armour.
So we've had a quick run through of a DNS Reflection attack which is widely used by Threat Actors. By using many open DNS resolvers, bad guys can craft an attack using a botnet of machines under their control to direct DNS query responses to the victim's server. The result can be an overwhelming amount of traffic which can take a server offline if the volumetrics are large enough.
There are pretty easy defences to this kind of attack, but to get an alert to the traffic itself, detecting ICMP backscatter is an excellent idea. This will give you a heads up on attack type, vector and what prevention mechanisms you need to initiate if you haven't already.
Note, backscatter does not just apply to DNS Reflection attacks, you may observe backscatter as a result of a TCP based attack, whereby RST packets may be observed from sources that know they aren't part of the handshake the bad guy is attempting to emulate.
You should definitely research feeding your Network Intrusion Detection System (such as SNORT) with a signature to look for backscatter. Your preparation on this now could save you valuable time, money and important, reputation. :)