2

First approach to DoS attack detection: There are techniques for intrusion detection, and of course DoS attack, in which for each packet (or flow) some features are calculated, then based on some classification algorithm, it is determined whether this flow is anomaly or not. This way specific flow is flagged as anomalous.

Second approach: For DoS attack, there is this technique in which network traffic is aggregated according to some features (e.g. SYN flag set) and then using signal processing or other techniques like simple threshold, they find out if there is any anomaly in this time slot or not. However, this way we can't determine which flow is anomalous. There are techniques that further process that time slot, to find anomalous flow or if anomaly is DoS (maybe by implementing the first approach for this specific time slot).

The first approach is not implemented in Snort, as I asked previously here. I don't know whether commercial products use this approach or not.

Did I understand the trends right? Why is the second approach interesting at all, if the first approach works (Or is it simply because the first approach doesn't work?). To limit the search space to a specific time slot? Is there any deference here between IDS/Firewall? Are there any other approaches?

Community
  • 1
Yasser
  • 353
  • 1
  • 3
  • 8
  • Is your question about DoS or also about DDoS? – user857990 Nov 29 '12 at 09:38
  • In papers I have read, for example, it has been mentioned that these features can detect DoS/DDoS, Worm spreading, etc. For the first approach since the papers I read were mostly on KDD CUP'99 and there were no DDoS attacks back then, maybe it is limited to DoS. – Yasser Nov 29 '12 at 09:48
  • As people have said before, the old papers and KDD CUP'99 data set are poor quality and _barely_ applicable to modern DoS / DDoS attacks. – Polynomial Nov 29 '12 at 09:52

2 Answers2

6

DoS attacks are simply massive floods of data being sent to your server. Something as simple as a Nagios rule can be set up to detect an abnormal traffic load.

Here are some example rules for basic traffic stats monitoring:

  • "If I'm receiving more than 80Mbps of incoming traffic, send an alert." - useful for known average traffic rates that don't vary much.
  • "If my incoming traffic rate exceeds 60Mbps and the average incoming traffic rate over the last 10 minutes exceeds the average incoming traffic rate over the last 4 hours by more than 70%, send an alert." - Useful for situations where traffic varies, but a reasonable baseline threshold is available.
  • "If the number of SYN packets received in the last 5 minutes exceeds the number of ACK packets received by a factor of 10 or more, send an alert." - Useful for catching SYN floods.

If we consider IDS rules instead, we can look into more specific rules about individual clients:

  • "If any one IP has contributed to 100MB or more of traffic in the last 20 minutes, send an alert." - Useful for catching individual DoS attempts, or possible data exfiltrations. Obviously this won't work too well if you're offering large files to users.
  • "If any one IP has sent more than 40MB of UDP traffic in the last 10 minutes, send an alert." - Useful for catching UDP floods, since UDP traffic isn't really expected on most web servers.

Obviously these are just examples.

The difference between an IDS and a firewall is primarily that an IDS is passive (i.e. it looks at traffic and produces alerts when bad things happen) and a firewall is active (i.e. it drops packets that match a rule). However, a firewall usually has much more simple rules, often based around metadata like the source IP, protocol type, port number, TCP sequence number, etc. An IDS usually focuses on the payload, rather than the packet. Some firewalls include IDS features, and an IPS is essentially a combination of the two that can manipulate traffic based on more complex rules.

In terms of flow analysis vs. packet analysis, both styles of mitigation work, but they work even better when combined. Your flow rules are likely to catch DDoS attacks once they've started to affect your system, whereas your packet analysis rules are likely to catch DDoS attacks in their infancy. The false-positive rate on packet analysis is quite high, so using both as an indicator makes more sense.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • Thanks for your examples. They ware so helpful, since I don't see any examples in papers. Thanks. However, the examples for network traffic stats could be considered as the second approach I mentioned in my question. The IDS rules are again threshold based aggregating network traffic by IPsrc/IPdst. I also had not heard about flow vs packet analysis and their impact on false positive rate. Thanks. – Yasser Nov 29 '12 at 13:02
4

Snort isn't very good at keeping state over a longer period of time than a tcp session. Snort is very much signature based. What you want is more of a flow/heuristic based IDS. I run Snort AND the somewhat unknown and very under-rated Bro IDS:

http://bro.org

This provides MUCH better coverage and visibility into your network than Snort alone.

http://www.youtube.com/watch?v=WfejHkFu1u0

http://www.youtube.com/watch?v=7DCPuHdCbpw

I currently run them both in Security Onion but may someday deploy my own dedicated bro/snort hosts once I become a little more familiar with both of them. I am just getting started with BNPL but have high expectations for the kinds of things I will be able to detect with it.

Tracy Reed
  • 618
  • 4
  • 5