4

My web servers are behind ELB, I want to block traffic from some specific user agent which is a DDOS attack. Apache always see ip address of ELB as an end user so I tried below attempts:

  1. Blocking IP address at ELB level is not possible because it has limit of 20 IP addresses and IP addresses change at every attack.

  2. Block access using rewrite condition, this works but if lot of hits come then server load goes beyond 100 and all apache threads become busy in serving tons of 403 so site appears down for legitimate requests.

    RewriteCond %{HTTP_USER_AGENT} ^SomeThing

RewriteRule ^(.*)$ - [F]

  3. Block with mod_sec does same thing of serving 403 which create same effect as #2 above.

  4. Block packets with iptables string module: Block packets which have specific user agent. In this scenario iptables sends DROP/ REJECT to attacker, apache doesn't get signal that the connections is now dead and waits for a timeout which cause all apache threads in use for timeout, so this method is not useful here.

    iptables -I INPUT -i eth0 -p tcp --dport 80 -m string --algo bm --string 'user-agent: SomeThing' -j REJECT

Can I use iptables such way that it will get IP address from first packet which has user-agent: SomeThing and block all the next packets which has X-Forwarded-For: someIP for 4-5 hours. I don't want to keep the IP address blocking always as these IP Addresses can be assigned to some legitimate users and that will be blocked.

Or is there any other better way to handle this attack ?

Deepak Deore
  • 691
  • 1
  • 9
  • 16

3 Answers3

3

Alternatively, don't use ELB but roll out your own load balancer using HAProxy.

If you've been deploying your site using AWS OpsWorks, you should be aware that AWS OpsWorks supports a HAProxy-based Load Balancer Layer.

Yes, preparing a HAProxy Load Balancer Layer is much more involved than simply spinning up an ELB set, but ultimately it allows you to fully customize the iptables setting, even using fail2ban.

Edit: If configuring Chef recipes is not your dish (:D), I have an alternative. I've just created a FOSS project called haproxy-autoscaling, hosted on bitbucket, if anyone care to check it out. It's almost finished. Already usable, but needs some manual manhandling.

URL: https://bitbucket.org/pepoluan/haproxy-autoscaling/overview

pepoluan
  • 5,038
  • 4
  • 47
  • 72
0

Blocking the ip's in iptables is a good plan since it will minimize the impact on your server. But the rules in iptables are there forever so you need something else to manage the expiration of the blacklist. fail2ban seems like the easy solution to this. Another problem is that the source IP's will be the internal ELB IP's so you need to do the filtering in a security group in front of the ELB.

chicks
  • 3,793
  • 10
  • 27
  • 36
0

The original client IP is provided by ELB in the X-Forwarded-For header.

You can use the X-Forwarded-For in your rewrite rules.

thexacre
  • 1,849
  • 13
  • 14
  • Apache can't handle flood of requests so I want to avoid processing on Apache level – Deepak Deore Dec 12 '14 at 04:27
  • @Nix, the fact that Apache can't handle the requests doesn't change the fact that you have to block them at the HTTP level. You could either use something like mod_security which might improve the performance of blocking it with Apache, or you might have to put a reverse proxy like NGINX in front of it to do the blocking. – thexacre Dec 12 '14 at 23:30
  • mod_security also gives 403, my load test showed all apache level blocking makes apache threads busy in service 403 to DDOS attack requests. I will give a try to NGINX though. – Deepak Deore Dec 13 '14 at 02:45