The most token of token gestures

Due to regular disruptions in the Sony PlayStation Network (PSN), Sony have kindly offered to extend my PlayStation Plus membership by one single day.

I know the DDOS attacks on their network weren’t their fault, and I don’t condone the actions of imbeciles with axes to grind. But a PlayStation Plus membership currently costs $69.95AUD. Divide that by 365 days in a year and you get: 0.19 cents. Sorry for messing you around, but here’s 19 cents.

I’m not even going to waste my time typing in that code for 19 cents. So if anyone else wants it, please, have my code, it is (as posted) un-redeemed:

Sony 1 day extension

Thanks, Sony.


Addendum: My VPS provider, Linode, were also under sustained DDOS attack over the Christmas period. I wasn’t aware of this when I sent them a support request wondering why this site was getting rather wobbly, but they explained the situation and I let them deal with it and ride it out. When it was over, I received an email saying that they were sorry for the disruption to service (again, entirely not their fault) – and that they’d credited me $10 on my VPS hosting:

Support Ticket [REDACTED] regarding account ‘[REDACTED]’ has been updated by ‘tkelso’

————————————————–
Hi,

You recently requested a credit for the downtime that your Linode(s) incurred. First we would like to start by apologizing for the outages and the disruptions the downtime may have caused. As you may already know the downtime was caused by multiple large scale DDoS attacks. We’ve done our best to communicate the details of these attacks on our status page, and we’ll be releasing a full post mortem.

http://status.linode.com/incidents/mmdbljlglnfd

We’ve put various safeguards in place to protect our infrastructure and above all else you, our customer, from being negatively impacted by future attacks. It’s our belief that the considerable protections we’ve leveraged have already been successful in deterring further attempts to disrupt our networks. Because of this we’re now able to precisely calculate the amount of downtime suffered by each Linode.

In accordance with our SLA, each Linode that experienced disruption of service would be entitled to a credit based on its established hourly rate, for however long the downtime occurred outside of the 45 minute window defined by our 99.9% uptime guarantee. However since this was a departure from the standard of reliability you’ve come to expect from us, we’ve chosen to exceed our SLA guarantees. Instead we’ve made an effort to offer reimbursement that demonstrates our appreciation for the patience and understanding you’ve shown, as well as for your continued business. With that in mind, we have applied the following credit to your account for your Linodes in London:

$10.00

We consider it a privilege to be your hosting provider, and we’ll continue working to ensure that you’re receiving the best service possible. If you have any questions or concerns, please feel free to let us know.

Kind Regards,
Tim

I didn’t request a credit at all – I just enquired why the site seemed to be up/down/up/down a lot – and they explained the situation and gave me a generous credit instead of a token gesture – which is why Linode have yet again grown in my estimation, and Sony have not.

How To: Stop Apache DOS attacks with Fail2Ban

I had to install and configure fail2ban yesterday to stop some hacking attempts on my FTP server, and when I was looking through the fail2ban configs I saw that you could stop DOS (Denial of Service) attacks with it too. As this site’s been hit by the occasional DOS from people with an axe to grind and too much time on their hands, I thought I may as well set up a DOS mitigation strategy while I was at it. Here’s how:

  1. Install fail2ban through the method of your choice.
  2. Edit the file /etc/fail2ban/jail.local and add the following section:

  3. Don’t forget to replace YOUR_WEB_SERVER_ACCESS_LOG with the actual access log for your webserver! Note: This doesn’t have to be an apache log, I just happen to be using apache.

  4. Now we need to create the filter file, so create the file /etc/fail2ban/filters.d/http-get-dos.conf and place the following contents in it:

  5. Now we just need to restart fail2ban for the new jail & filter to come into affect:

  6. Or if your machine is on systemd, use:

    Also on systemd, if you want fail2ban to start on boot (and the chances are that you do), run the additional:

    With all that done your site should be pretty safe from casual DOS attacks, although you’d likely need more stringent maxretry and findtime settings to really help against Distributed DOS (DDOS) attacks.

Testing

To check if fail2ban is seeing the logs, check out /var/log/fail2ban.log and you should see things like:

showing up as visitors view your site.

If you want to test if it’s really working, a nice way to do so is to use ab (Apache Benchmark – part of the apache2-utils package), like this:

This will kick off 500 page-loads in 10 concurrent connections against your site. When the ban kicks in the page-loads will stop (as incoming GET requests from your IP will be dropped), then when the bantime expires you’ll be able to access the site again. If you then take a look in your /var/log/fail2ban.log file you should see something like this:

Pretty neat, huh?

Many thanks to the authors of the following great articles for helping me to get this set up in no-time:
http://www.dedmeet.com/software-projects-mainmenu-12/fail2ban-to-limit-ddos-attacks– on-webserver.html
http://go2linux.garron.me/linux/2011/05/fail2ban-protect-web-server-http-dos-attack-1084.html

Cheers! =D