1) Setting Security Group is easy and important layer of security. If you are running any web app than port 80/443 are one that to be open to the world and 22 for accessing server remotely via ssh should be allowed from a particular IP address only. Other than these 3 ports all traffic will be blocked. You can test with Port Scanning or NMAP tool.
2) Limit access for SSH to a your static IP address only and also for accessing EC2 Instance via ssh you need a key. If attacker somehow get to know your IP address he/she cannot access your server without key.
Note :- If you are using CDN(CloudFlare) than your EC2 Static IP is already hidden.
3) You can limit the amount of concurrent connections from the same IP address to your server.
You can use linux firewall rules for that :-
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP
iptables-save >/etc/iptables.up.rules
The first line will Watch the IP connecting to your eth0 interface.
The second line will Check if the connection is new within the last 60 seconds and if the packet flow is higher than ten and if so it will drop the connection.
The third line will Make the rules persistent in case of a reboot.
To verify the number of concurrent connections from all clients that are connected to your server :-
netstat -tn 2>/dev/null | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
It will show a list of the current active connections by IP address and the offending IP is usually the one with a high number of connections.
12 10.1.1.1
160 162.19.17.93
In the example above the first number is the number of connections followed by the Originating IP address.
Note :- In a heavily loaded server the number of connections may be above 100, but during DDOS attack the number will go even higher. For an average host, if you have more than 30 connections from a single IP, chances are you are under attack. If more than 5 such IP/Host connected from same network , that's a very clear sign of DDOS attack.
Output of lsof
,netstat
and tcpdump
are very useful in detecting such type of issues.
Now you get the IP address of the client you can use IPtables to block that IP or tcpkill command to do so. TCPKILL is part of dsniff package.
apt-get install dsniff
Then issue :-
tcpkill host x.x.x.x
The above method is good and it will help you to mitigate small DDOS Attack if applied correctly. Now if you are using CDN ( CloudFlare ) than you can block the attacker at that level only. You can use CloudFlare API to block the IP address. In this traffic will not come to you server.
Read more at CloudFlare API Doc
Refer to above method and create a script that will help you in automation.
4) In my opinion CloudFlare is better than CloudFront. CloudFlare is easy to setup and from one control panel you can handle everything. Even if you find heavy amount of unnecessary traffic than cloudflare "I am Under Attack" mode will mitigate it in under 5-10 seconds.
Read more about DDOS and I'm Under attack mode in Cloudflare Blogs.
5) You can setup AWS Alarms to stop/Terminate EC2 instance if your Network Bandwidth exceeds the limit.
AWS Alarm Sample
Edit:- One important thing is try to setup Monitoring tool (Like Nagios) and Log Management tool of web app access. This will help you to find the bottleneck.
Best Answer
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:
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.