I have a server that is exposed to the internet and I would like to provide some protection against DDOS attacks. Currently, I am considering using either fail2ban and/or snort. I know that they have different approaches to how they work. From what I understand, Fail2Ban monitors log files to determine intrusions and snort monitors incoming packages.

Should I be using both? Is using only one of them sufficient? What functionality is uniquely one, but not the other? One concern that I have is performance. Is snort likely to slow down our network?

  • 1
    Neither tool will protect you against DDoS attacks. The only protection which works is to have a bigger network than the attacker.
    – kasperd
    Mar 27, 2017 at 21:22

1 Answer 1


I would start with fail2ban if I was you.

Both can be a drain on your resources if they aren't configured properly, but I suspect the caveats of working with regex will be more familiar to you.

fail2ban is easier to make immediately useful (in my eyes at least).

It is much simpler to setup to actually block malicious sources than snort, and you can configure fail2ban to scan snort logs, in order to ban them.

Neither will in all likelihood actually protect you against DDoS as such, but both could, in their equivalent to blocking mode, be used to prevent non-network resource exhaustion, by (in effect) avoiding interactions with actual application servers.

One issue with snort is that it is somewhat non-trivial to have it work in IPS mode (i.e. actually blocking traffic) - AFAIK, much more common is to run it as an IDS (i.e. only detecting malicious traffic).

fail2ban is, as you say, essentially just a script that does regex on log files, extracts malicious sources from those logs (e.g. failed SSH login, web client triggering repeated 4xx or 5xx respones, or having a user-agent associated with known attacker profiles). It integrates with iptables (and whatever might be running on top of iptables, e.g. firewalld, shorewall), in order to block traffic related to malicious hosts. Those blocks tend to be implemented either as simple iptables rules, or as an iptables rule + an ipset.

snort (and suricata, and other IDSen) actually inspect various aspects of traffic flows, in order to detect potentially malicious traffic. It uses rules in a domain-specific format, which can also do IP address (and/or hostname/domain) matching, as well as packet inspection, reassembly, and more. A fairly widely used ruleset in EmergingThreat's - you might want to read through (some of) them, to get a feel for snort's capabilities.

One consideration is that fail2ban will generally be useful out of the box, where that isn't entirely the case for snort - you generally need to tune its rules (and possibly add some of your own) in order to balance event volumes with their actionability.

Personally, a setup that works for me while I spend some time getting better on snort, is:

  • setup fail2ban with ssh and relevant web jails
  • create a jail reading the IDS alert log (in my case, that's suricata, but that's a detail), notably looking for Prio 1 alerts, and also looking at any hosts that flagged as DROP (yes, I could just load the relevant ipsets)
  • let fail2ban do the rest.

That may or may not work for you, but it means you get some extra protection from snort without needing to become particularly knowledgeable of its internals.

However, I would mention that snort rules can seem a little more alarmist than might be warranted - having some idea of what threats they are pointing to, and how to understand/interpret alerts, is generally worth the effort.

Once you get more comfortable with snort, tune it, first, and then consider whether you want to allow it to deal with things directly (e.g. put it in IPS mode).

In passing, you may want to consider how a WAF could be part of the picture, if a lot of your exposed assets are web-based.

  • Thank you for your detailed answer. I was leaning towards starting with fail2ban only. And this provides excellent background as to why it's a good idea. Mar 27, 2017 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.