If, like us, you’re running a shared hosting platform on Amazon EC2, and have many clients requiring SSL certificates, you’ll probably be using Elastic Load Balancers to do the SSL termination for you, since you can’t have multiple Elastic IP’s associated with a single instance.
However, when you reach either 5 or 10 ELB’s, you’ll be greeted with this error message when trying to create another one:
Error: TooManyLoadBalancers: undefined
Amazon define relatively low quotas for new AWS accounts, which are usually fine for most users. However, some use cases apply where you need these limits to be increased. The problem with the ELB limit, is that there’s not very much documentation explaining that there is a limit, nor how to request to increase it. The answer lies hidden away here on Amazon’s AWS site. This is the form you need to fill in to request an increase on the account’s ELB limit.
I realise that I’ve been neglecting my blog for a while now, with my last post published at the end of March. Quite frankly, I’ve not had anything interesting to write about. However, career starting pastures new, I’m starting to have interesting things to write about again. Over the course of time, I’ll probably post a lot of stuff about Amazon Web Services (AWS), Zend Framework, amongst other things. Today’s babble though is about implementing AWS as your core hosting infrastructure, and the benefits and downsides to it. I’ll also post my findings about the best way (in my opinion) to implement certain requirements.
Continue reading “Amazon Web Services – A Guide to Implementation” »
I was recently recommended some software to prevent (or at least act on) automated hack/DoS attacks on services. The usual suspects triggered this, dictionary attempts on common usernames on servers, “admin”, “administrator”, “root”, etc. Up until now, I’ve been monitoring for unusual network activity. When the traffic reached a certain peak for a specific length of time which was out of the ordinary, I knew something was going on. The hard job then was trying to find out which service was being targeted. I started on the usual suspects, proftpd, ssh, httpd. What I wasn’t expecting at this particular point was someone trying to hack open apache.
Anyway, I digress. The software is called fail2ban. Basically, it’s a python daemon which you configure to sit and monitor the log files from all your exposed services. It uses various timestamp algorithms along with checking using regex for failed auth attempts (configurable). In the regex, it also uses extraction parentheses to extract the host/IP address, then automatically turns to iptables and bans the host within a certain number of failed auth attempts. It defaults to 3 failed attempts getting you a 10 minute ban, but again this is configurable. I’ve set mine to 3 failed attempts with a 30 minute ban, and it seems to be quite happy with that. Since then I’ve actually noticed server load go down a touch, which tells me how many times my servers were being targetted without me even knowing it!
And since it’s configurable for practically every service that logs to a file, it’ll also work for custom applications that do the same thing, no matter what they are. I’ll have to bear this in mind when I write stuff in the future that could be prone to hack attempts.
Check it out: fail2ban