How-To: Fix WordPress plugin updates and DB backups not working

If you, like me, got too big for your boots and tried to lock down your server using ‘best practice’ pre-rolled apache server config settings without fully understanding how they work – then good on us both for trying, but let’s never do it again.

Specifically, I tried to lock-down click-jacking like this in my httpd.conf:

There’s lots to read about click-jacking, but what was most important to me was that it pretty much knackered my WordPress install to the point where I could only update a single plugin at a time, and after every plugin updated I had to delete the “.maintenance” file to get the site back running. That and WordPress and theme updates would complete, but never TELL me they’d completed, so I’d just have to wait a while then go back to the admin page and hope for the best.

Anyway – if you have this issue, and have used X-Frame twiddling stuff in your apache config, the short answer is: Don’t.

How To: Compress web page data transfer with mod_deflate and mod_headers

Since I rebuilt my VPS the other day there a number of tweaks and changes I need to make which can speed up the website – one of the easiest ones with the biggest effect on pageload time is to have apache serve compressed versions of pages to users. Here’s how to do it, and test that it’s working.

Enabling mod_deflate and mod_headers

Chances are good that you already have mod_deflate and mod_header on your server (they typically come with the apache install) – so all you need to do is enable them. To do so, open your main apache config (for example, on mine it’s /etc/httpd/conf/httpd.conf and uncomment the LoadModule lines for each module, so that they end up like this:

With that done, you can head down to the bottom of the config file and add the following section to enable compression of all html, css, js, xml and such.

Restarting apache and testing it out

With those changes made, save the file, restart apache (for example, via: sudo systemctl restart httpd.service if you’re on a systemd-using machine), and then go to: http://www.whatsmyip.org/http-compression-test/

Plug in your URL and hit submit, and you should see some good news similar to this:

A page saying that we are successfully serving compressed webpages.

Very nice =D

Many thanks to: brighterlamp.com for the original article this one is based on.

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

Site Change Pending – Welcome to 2011

I managed to break this site the other day when the theme I’m using (Freshy 2) decided to use a different set of options. I obviously triggered it somehow, but I’ve no idea how – and then it all got confused about which options and CSS adjunct to use, and didn’t want to work with the customize plugin and… yeah, it all went a bit Pete Tong. Given that the Freshy 2 theme is unsupported and doesn’t really work that well past WordPress 2.7 (which is pretty legacy), it’s no wonder strange things have been just waiting to occur, but I’ve got it back to a semblance on sanity (as you might be able to tell since you’re reading this, and noticing it doesn’t look a million miles different from before – apart from comment threading, promise me you won’t look!). I even backed up the entire www folder three days before it all went to hell, but when I restored the backup it’s still shafted, so the Freshy options must be stored elsewhere (like in the database somewhere)… but anyway, I digress; it’s time to shake things up.

Kicking and Screaming

I started reading about CSS3 the other day, and began knocking up examples of all the cool things you can do with opacity and 2D transitions and stuff – and it’s awesome. I had absolutely no idea you could do such cool stuff without JavaScript or Flash, and if you apply it to the experience layer (as opposed to the core functionality layer), then even if people are viewing your site in older browsers it can gracefully degrade and leave those running some archaic IE variant none the wiser that should they be seeing the site in Chrome or FF5 or such it’s got a lot more swish. I might even try some HTML5 shenanigans…

This isn’t going to change the core content for the better (sadly), but if the medium is truly the message, then perhaps by giving the medium an overhaul and a good lick of paint I can emphasize the message to a certain extent.

I don’t want to even think about how much time I could waste on 3D transitions… the sky’s the limit, ya know?

Stepping Up

So, to get the site all sorted, I have a (not especially cunning) plan:

  1. Get an offline version of the site running locally so I can twiddle the hell out of it. [COMPLETE]
  2. Rip the Freshy theme to bits, and combine all the CSS and CSS adjucts (which get pulled in and override the core styles) into a single CSS file. [COMPLETE – 2011-08-08]
  3. Remove all the cruft from the Freshy CSS and PHP. And there’s a lot of it. Tons. [96% COMPLETE 2011-08-10]
  4. Rewrite the core layout utilising CSS3 and perhaps HTML5 elements to make it look beautiful. [60% COMPLETE 2011-08-09]
  5. Bask in the radiant glory of a modern, dynamic website. [PENDING]
  6. Write good articles =P [ARGUABLE]

Speaking of which, I’ll write an article on getting an offline version of a site running soon – it actually took me a couple of hours to get everything installed, configured, database suitably modified (to keep me on the local copy at all times) & imported into MySQL etc. But now I have, I don’t have to do surgery on a live site, and can thus afford to break the hell out of my local copy, because things tend to get a lot worse before they get a lot better, and this version will still be up and running in 99% “good enough” mode.

Honestly though, CSS3 is amazing – check it out. I can’t wait to see what I can come up with =D

How to: Use mod_rewrite to stop hotlinking in Apache

If you find that people are hotlinking to images on your site, and assuming you have mod_rewrite enabled and working, then just add the following to your root level (i.e. /var/www or such) .htaccess file to cut that crazyness right out:

So, for example, on this site, I’m using:

I’m just returning a [F] (forbidden) message to the hotlinking web server (so they don’t get an image returned to them), but you can always send them alternate images if you’re feeling vindictive… In fact, there’s lots of neat stuff you can do with mod_rewrite =D

P.S. For a full list of rewrite flags (i.e. [R,L,NC] etc.) and what they do, try this.,