When using F2B on servers that sit behind Amazon ELBs (and probably load balancers of other types), the client IP in the error log is usually that of the load balancer. Banning the load balancer from access is probably not a good idea…
It looks like the current way to go is to use the Apache module mod_remoteip. Unfortunately this seems to be available on 2.3 upwards. And though a backport is available for 2.2, I don’t like messing about too much with unofficial patches on a production system.
So the alternative is the Apache mod_rpaf module, which seems to work quite easily, though it is a little inflexible. On Ubuntu this was enabled by:
sudo apt-get install libapache2-mod-rpaf sudo vi /etc/apache2/mods-available/rpaf.conf # Then edit the RPAFproxy_ips line to contain the IP of the load balancer sudo service apache2 reload
Also note that there is a big in mod_rpaf on Ubuntu (for 12.04 server only IIRC) where the module name is incorrect in rpaf.conf. It should read:
# Wrong! <IfModule mod_rpaf.c>> # Right <IfModule mod_rpaf-2.0.c>
This is not particularly flexible as the load balancer IP is hardcoded, but it is a solution to avoiding mistakenly banning the ELB. However, it does mean that any attacks that come through the ELB cannot be blocked. So this is something I need to revisit at a later date.
This does not look like a good idea to be honest: For example fail2ban will use then the (correct) IPs to block them using iptables. But iptables will only see traffic coming from IP-Adress from the LoadBalancer as well. So no malicious traffic will be blocked at all.
Unfortunately – I don’t think there is a non-deep-packet-inspection like solution for that.
The main point here is that we do not want Fail2Ban to ban the load balancer. It’s not clear from the post that this will mean that no attacks through the ELB will get caught by F2B, so I’ll add that for clarification.
Here’s a tool I made for those looking to use Fail2Ban on aws with apache, ELB, and ACL: https://github.com/anthonymartin/aws-acl-fail2ban