FastNetMon

Monday 8 December 2014

Детектирование DDoS атак на отраженном и ответном трафике

Рекомендую к прочтению очень полезную информацию о том, как косвенно фиксировать атаки: http://labs.spritelink.net/clever-ddos-detection

Чтобы не потерялось привожу здесь:

The detection of DDoS attacks is typically based on some form of threshold value and typically on traffic that is going to a potential target, ie to the host that we want to protect from attacks.
It can be a threshold value for total traffic or for a certain traffic class, like UDP packets, and the actual threshold value can either be configured statically or it can be more dynamic and based on previously collected data, ie baselining and from that finding anomalous traffic patterns.
Using traffic classes can help us differentiate between a large file transfer and a large DNS reflection & amplification attack but not all attacks are that easy to filter out.
One approach is simply to let the end hosts tell us when they are under attack. A server knows what traffic it wants and anything else would be counted in an "unwanted" bucket and once we see enough unwanted traffic it could notify the DDoS mitigation system via an API. This approach requires integration with the end hosts though and while it might be possible in a homogeneous environment it can be very difficulty in a mixed environment.
How do we know when a host is receiving unwanted packets?
A normal TCP stack sends TCP RST packets for incoming TCP packets it doesn't want and similarly a firewall will send ICMP administratively prohibited messages.
By analysing TCP RST & ICMP messages we should be able to get a hint on when an attack is occurring and we could hone in classic threshold based methods for an end result which should be a highly accurate DDoS detection system.
So how can we collect the information? NetFlow collects flows on the router which it then exports to the collector and while this is great for traffic statistics it doesn't lend itself very well for this type of DDoS detection. We will not be able to see inside that ICMP message to see what packet caused the sending of the ICMP packet. sFlow on the other hand provides just this possibility as it merely send the N first bytes of a sampled packet.
Further, Netflow is inherently slow. Most router implementations allow a minimum timer of 60 and 15 seconds for active and inactive flows respectively. Packets are put in a flow table and subsequent packets in the same flow will increase the bits and number of packets seen for that flow. Once the expiration timer is hit the flow is exported. That means you will have to wait up to a minute before you receive data at your collector.
sFlow on the other hand works completely differently. It takes the first N bytes of a packet and sends it off directly to the collector allowing you to do analysis on just seconds old data.
When it comes to DDoS detection the difference between minutes and a few seconds means the world.
By analysing TCP RST and ICMP via sFlow one should be able to build a DDoS detection system without match... or has anyone already done this?

No comments :

Post a Comment

Note: only a member of this blog may post a comment.