One of the servers I use is hosted on the Amazon EC2 cloud. Every few months we appear to have a DDOS attack on this sever. This slows the server down incredibly. After around 30 minutes, and sometimes a reboot later, everything is back to normal.

Amazon has security groups and firewall, but what else should I have in place on an EC2 server to mitigate or prevent an attack?

Preventing it is nearly impossible but you could certainly decrease your vulnerability.
–
Belmin FernandezDec 13 '11 at 1:35

1

Very true. And I would be happy with answers that discuss decreasing vulnerability :)
–
cwdDec 13 '11 at 1:46

In order to know how to prevent it, one would need to know more about the nature of the attack. Was it a syn-flood? Was there a web page that is expensive that was being hit? was it some other service?
–
stewDec 13 '11 at 1:58

I think it was a webpage but am not sure. I would also welcome tips on monitor and investigating these. Some of the access logs have already been deleted - what else should I be looking for?
–
cwdDec 13 '11 at 2:03

and actually, if a reboot fixes the problem, then I don't know what it could be, except perhaps your server has a resource leak somewhere. A reboot certainly cannot stop a DDoS on its own. How do you know this is a DDoS at all?
–
stewDec 13 '11 at 2:25

6 Answers
6

A DDOS (or even a DOS), in its essence, is a resource exhaustion. You will never be able to eliminate bottlenecks, as you can only push them farther away.

On AWS, you are lucky because the network component is very strong - it would be very surprising to learn that the upstream link was saturated. However, the CPU, as well as disks I/O, are way easier to flood.

The best course of action would be by starting some monitoring (local such as SAR, remote with Nagios and/or ScoutApp) and some remote logging facilities (syslog-ng). With such setup, you will be able to identify which resources get saturated (network socket due to Syn flood ; CPU due to bad SQL queries or crawlers ; ram due to …). Don’t forget to have your log partition (if you don’t have remote logging enable) on an EBS volumes (to later study the logs).

If the attack come through a web pages, the access log (or the equivalent) can be very useful.

You can also further isolate your EC2 instances by putting them behind an Elastic Load Balancer and only accepting traffic from the ELB instance. This puts more of the onus on Amazon to manage DDOS attacks.

I assume that you'll still have SSH open to all, so it's likely you'll still see some rogue traffic coming in there, unless you can lock down that port to some static IPs. You could change the SSHd port to something more obscure (i.e., something other than 22) to further reduce DDOS hits (most bots only check known ports).

I'll also mention fail2ban, which can monitor logs and temporarily modify your ip tables to block specific IPs (for instance, if there have been 6 failed attempts to SSH into your host from a single IP address, it can block that IP for 30 minutes or so).

I am biased, as I work for a content delivery network as a security Presales engineer.

However, leveraging a Ddos mitigation solution on a content delivery network ensures that you never run out of resources at the origin. It's similar to putting an F5 load balancer in front of your site, but spread to thousands of locations around the world.

A good cdn will allow you to cloak the origin with a whitelist which you install on the aws firewall. So when attackers perform their reconnaissance on Amazon, your IP address will come up empty as everything will be blocked.

So the Ddos attacks are blocked when the traffic hits a node as close as possible to the attacker. This ensures you mitigate Ddos attacks as far away from the asset you are trying to protect.

A good cdn can also perform health checks and failover traffic to other locations eg another ego on in ass, Azure, rack space, soft layer, a physical dc etc. It should also have a WAF to ensure you can block application layer exhaustion attacks like RUDY, slowpost, slowloris as well as sqli, xss, rfi, lfi etc.

By default the cdn also blocks network layer attacks like teardrop, icmp attacks, synfloods etc.
A cdn is able to mitigate Ddos attacks because trey have vast amounts of capacity to accept the requests, filter out bad traffic and pass on the good traffic.
So amplifying attacks like ntp, DNS, ssdp, chargen and snmp volumetric attacks can be blocked.

The largest attack I have seen to date has been 321gbps in July 2014. During this attack there was also a DNS protocol attack at 20gbps. So you will need to ensure you DNS infrastructure is also resilient to withstand a huge number of requests.

From the description you provided, it looks like you were subject to an exhaustion attack, where thr attacker opened up lots of threads such that all the threads were consumed up on the web server, app server or firewall. It's similar to something like a slowpost, slowloris or RUDY.

To block against application layer exhaustion attacks you will need to get a web application firewall (WAF). A typical network firewall (including amazons firewall and next generation firewalls) won't be able to block it. Sent work firewalls these days can only block about 30% of all the attacks these days (Nov 2014).

Welcome to Server Fault! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
–
Scott PackOct 10 '13 at 17:14