If you are a web developer, in this day an age, you will at some point swim a bit in the waters of the land of AWS. It is a fertile land, with many fruit, and exciting things to do, and once there, you will eventually work some with S3. S3 is fairly straight forward in it’s basic use-cases, with s3fs it’s basically just another drive, with the added bonus that you can share that drive across multiple systems and share files, like cached images or pages.

When you host a WordPress site, you should consider that you are pretty much opening a backdoor to your server. It’s not quite that simple, but, as one of the most widely-used Blogging and “CMS” platforms, it is regular target for hackers, and when you consider the vast ecosystem of 3rd party Plugins and Themes (one of the main driving points of it’s popularity), hackers have a massive surface area to attack. Because of this, it is important to do what you can to protect WordPress installations from exploit and abuse. In this post I am not going to go over securing the code that runs on WordPress, but I am going to mention two things you can do using Fail2Ban to protect against unauthorized logins, and abuse of xmlrpc.php.

If you find yourself spending a lot of time working with/on web-facing servers, you have probably heard of or used this awesome little thing called fail2ban. I am not going to get in to what it is or what it does, if you have never heard of it, you should look into it, as it is a pretty helpful tool for protecting your web-connected machines. I have been using it for some time on my AWS and personal boxes, and considered myself fairly adept at it up until the other day, when I discovered a few little tricks to slimming my jail configurations considerably.