Global protection of all wp-login.php files

Here’s another short post about protecting wp-login.php files on your server from Brute Force Attacks, which can drastically increase your server load. Mine was constantly up to 90% making my server completely inaccessible.

.htaccess or not .htaccess

Adding the following code to your .htaccess files is a solution, but if you have tons of sites like me, you don’t want to manually have to upload .htaccess and .htpasswd files. Instead, you want to handle this at once, globally and server-wide. Here’s how I did it:

First of all, you need to find out if your httpd.conf file is an autogenerated file, or if you can manually edit it (without it being regenerated after an update.)

Usually, modifications go into the pre_main_global.conf include file. If this is also the case for you, make sure this is included in your active httpd.conf file.

Edit pre_main_global.conf and add the following code:

<Files ~ "^\.ht">
Require all denied

<Files wp-login.php>
AuthUserFile /var/htpass/.htpasswd
AuthName "Private access"
AuthType Basic
require user yourloginname

Rename “yourloginname” to whatever login name you like.

Create the directory to store your .htpasswd file as follows:

mkdir /var/htpass/

You can generate a .htpasswd file here:, make sure to use the same login name as chosen before. Any password you want will do, also an empty password if that’s what you want.

Finally, save your .htpasswd file in the previously created directory, in this example we suggested /var/htpass/.

Assuming the pre_main_global.conf gets included as it should, the only thing left is to restart Apache. Use the following command to do so:

service httpd restart

Alternatively, you can restart Apache from DirectAdmin or WHM. Voila, you are now asked for a User Name and Password each time you access your wp-login.php file to login into WordPress.

Voila, you are now asked for a User Name and Password each time you access your wp-login.php file to login into WordPress.

Installing Fail2ban on CentOS

Here’s a short tutorial for those of you looking to install Fail2ban on an existing CentOS server or VPS.

First of all, you will have to determine which CentOS version you have, with the following command after starting an SSH session using a terminal window:

cat /etc/centos-release

The response will probably be something like this:

CentOS release 6.8 (Final)

Now that we know the CentOS version is 6, we will have to get the latest EPEL yum repository, using the following command:

rpm -Uvh

Next step is to install Fail2ban with the following command:

yum install fail2ban

When prompted Is this ok [y/N]: please type y and then hit enter.

This may take a few minutes, so sit back and relax waiting for the installation to finish.

The reasons you might want to protect your server or VPS using Fail2ban is because you are experiencing too many false logins attempts for WordPress, Proftpd, Exim2 or sshd4/sshd5 for example. To do so you will have to create the following local configuration file, using an editor such as nano:

nano /etc/fail2ban/jail.local

(Don’t have Nano? You can install Nano with the following command: yum install nano.)

Here is how to set-up an sshd jail to catch failed login attempts to SSH:

enabled = true
port = ssh
filter = sshd
logpath = /var/log/secure
maxretry = 3
findtime = 3600
bantime = 86400

Here is how to set-up an exim jail to catch failed login attempts to Exim:

enabled = true
port = smtp,465,submission
filter = exim
logpath = /var/log/exim/mainlog
maxretry = 3
findtime = 86400
bantime = 31536000

Now that we have created these jails, and saved our configuration file (ctrl+x) we have to restart our server or VPS with the following command:

service fail2ban start

If everything went as expected you should get the following response:

Starting fail2ban: [ OK ]

Using Fail2ban to block login attempts to WordPress

If additionally you also would like to protect your server or VPS from failed login attempts to WordPress, you should first create a filter.

Your filters are located here: /etc/fail2ban/filter.d/

Create a new filter named wordpress.conf using Nano as follows: nano /etc/fail2ban/filter.d/wordpress.conf

Copy and paste the following code into the newly created wordpress.conf filter file:

# Fail2Ban filter for wordpress


before = common.conf


_daemon = wordpress

failregex = ^%(__prefix_line)sAuthentication failure for .* from <HOST>$
^%(__prefix_line)sPingback error .* generated from <HOST>$

ignoreregex =

# Author: John Doe

Now that you have created the wordpress.conf filter, you will need to add a new rule to your jail.local file which you have previously created:

enabled = true
filter = wordpress
logpath = /var/log/secure
maxretry = 3
findtime = 86400
bantime = 31536000
action = iptables-multiport[name=wordpress,port="80,443"]

Finally, you will have to restart Fail2ban using the following command: service fail2ban restart

If everything went well, this is what the response should look like:

Stopping fail2ban: [ OK ]
Starting fail2ban: [ OK ]

Congratulations, your server or VPS is now protected against scum trying to make your life miserable!

Changing Hosts – Cloud Hosting at Rackspace

So, my current host, where I have a reseller account for ages, are acting link a bunch of bitches, after I’ve e-mailed them about a serious issue I encounter while loading my sites. It looks like something’s messed up with the server, as I frequently get prompted a message if I want to download a PHP file. Now, as I am not accessing any PHP files directly – I’m talking about random files which just make up the site, or even files that make up WordPress for that matter, and since PHP are not meant to be downloaded at all, I asked them how this could be, and if there was any chance that this would happen to others (my sites’ visitors) as well. Well, well, these ignorant scumbags told me that it ain’t their problem but mine, as no other clients noticed them about this. IMO, what seems to be the case is that their PHP set-up is hesitating and that it randomly treats PHP files as plain text files, but only every now and then. The PHP file, by the way, is completely blank if I confirm to download it.

Enough ranting… it’s really not important anymore! In fact, I am so happy to stand where I am standing momentarily.

Long story short, they keep ignoring there is a problem, and I ended being fed-up with them. So I am in the process of changing hosts, hence I contacted my best buddy (<- notice your first link love) for advice. He pointed me to Rackspace, who have several kinds of hosting products, for very reasonable prices. After some investigation, I ended up with a Rackspace Cloud Server account, which I will describe in-depth as this blog continues.

What I am going to do from here, is describing how I am going to move to the new Cloud Server. This means that I will go through each step of the process and write about everything that comes along until the site has been moved and runs smoothly. I’ll be straight, it’s will be a true challenge, as most of the work is done in a Terminal (Unix Shell), and I really have no experience at this moment. Hopefully, at the end of this blog post, I will 🙂

Setting up a Cloud Server

So yesterday night after we came back from a Donar, who got upset by Galatasaray (Istanbul, Turkey) in the final seconds of the game, I went to the Rackspace Cloud website and created an account. As this was post research, I knew exactly what I was looking for: a Linux Cloud Server, Fedora 14 to be precise. I chose the cheapest, starting at $11 a month, but as it is completely scalable, and paid by the hour, you can upgrade at any time you want. (Any time? Yes, any time…)

So what I got is 256 MB of RAM, and 10 GB space – that’s plenty for just one site I guess. This goes together with a private IP address and all the freedom I need.

After a few minutes, I received the verification e-mail containing my root user name and password, and I was set to go. As at this point I really didn’t have a clue, I contacted support – which are around 24/7 through live chat and phone. Curtis, the Rackspace representative, helped me get started by pointing out some Linux set-up guides and telling me the basics of working with the Terminal on my Mac. Before you knew it I was logged in at my own instance – it felt like a victory!

All of this together brings me to this very moment. I am about to continue setting up my Cloud Server. I am going to take you live through the next steps, bear with me…

Cloud Server Step by Step Guide

Step 1 – First you will have to log-in, hence you’ll have to use the following command in my Mac Terminal:

ssh root@

Obviously, I rather keep my IP address to myself. When you log-in from a certain location for the first time, you will get a warning, which you can simply ignore by typing ‘yes’. An RSA Key Fingerprint will be added to your local computer so that your computer becomes authenticated.

Step 2 – The first thing you want to do when you’re logged-in is changing your default root password.

passwd root (You will then be prompted for the password of your choice.)

Before we start with the hardcore work that is needed to set-up the Cloud Server as a host, we will have to customize it a little bit.

Step 3 – With the following command, we will be able to set-up a package of tools called development tools which come together with Fedora release 14.

sudo yum groupinstall 'Development Tools' (Answer ‘y’ when prompted in Terminal.)

sudo yum install links (Answer ‘y’ when prompted in Terminal.)

Are you still following me, you ol’ nerd? Well then, there’s only one more step to take before we get to the most important part of this Cloud Server Set-up Guide.

Step 4 – The following command will install the Screen application. Honestly, I have no idea what I am talking about, except that it’s used to allow virtual terminals to be opened in one console. If you follow the link you will find an in-depth Screen Tutorial.

sudo yum install screen

After actually playing around with the screen command, I found out that it lets you switch between instances of Terminal, but using one single console.

Now, after reading some more I found out that we needed to update the software between Step 2 and 3. As it doesn’t seem to hurt, we will be doing it now by using the following command.

sudo yum update (Answer ‘y’ when prompted in Terminal.)

Securing a Cloud Server

To keep douche bags, a.k.a. hackers, outside we want to secure our server as much as possible. Fortunately, there’s a build-in Firewal for Linux called iptables, which is pretty straight forward setting up.

Setting-up iptables on Fedora 14

If you are setting up a new Cloud Server at Rackspace, it is wise to have a look at the current firewall rules. What we want to accomplish is opening ports 80 (regular) and 443 (secure), which are closed by default. You can use the following command to have a look at the current iptables settings.

sudo /sbin/iptables -L

Let’s assume that you are setting-up up a Cloud server from scratch, just like me. That means that we want to get rid of the default settings. Use the following command to flush/delete them.

sudo /sbin/iptables -F

Here’s a default set of commands to install the proper iptables settings to open up the ports I just mentioned. Copy them as a whole and paste them into your Terminal.

sudo /sbin/iptables -A INPUT -i lo -j ACCEPT
sudo /sbin/iptables -A INPUT -i ! lo -d -j REJECT
sudo /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo /sbin/iptables -A OUTPUT -j ACCEPT
sudo /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo /sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo /sbin/iptables -A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT
sudo /sbin/iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
sudo /sbin/iptables -A INPUT -j REJECT
sudo /sbin/iptables -A FORWARD -j REJECT

At this moment I decided not to discuss the meanings of each of the commands, but I might get to it in an upcoming post. If you really need more information as we speak, I suggest you visit this page.

There’s actually one more line that should be added. As we need to be able to access the server over SSL, we need to keep port 22 open. You can use the following command. The ‘-I’ makes sure that it will be added to the top.

sudo /sbin/iptables -I INPUT -p tcp --dport 22 -j ACCEPT

Finally, you will need to save them, so they also remain intact when you’ll reboot your Cloud Server. Use the following command to do so.

service iptables save

Setting up an Apache on a Rackspace Cloud Server

In this part, I will try to explain how to set-up Apache on Fedora. Installing a basic set-up of Apache is really nothing to worry about. Please use the following command to install Apache together with the most common options (httpd and SSL).

sudo yum install httpd mod_ssl (Answer ‘y’ when prompted in Terminal.)

With the following commands, we will customize our web server.

sudo mkdir /etc/httpd/conf/custom (The ‘mkdir’ command creates the directory – in this case ‘config’.)
sudo nano /etc/httpd/conf/custom/servername.conf (The ‘nano’ command creates a file – in this case ‘servername.conf’.)

We will now have to give our web server a name, which will be stored in the config file we have just created.

ServerName 123abc (It goes without saying, but ‘123abc’ shall be replaced with whatever the choice of your server’s name is going to be. Hit CTRL-O to write the file, and CTRL-X to return to the command-line.)

The final step in this setting-up Apache on Fedora guide is editing the main Apache configuration file. Execute the following command to open the file that you’ll need to edit.

sudo nano /etc/httpd/conf/httpd.conf

Scroll down to the far bottom, or hit CTRL-W to search for ‘*.conf’, and find the line where Include conf.d/*.conf is written. Replace this line with the following, correct path, to the custom config file created above.

Include /etc/httpd/conf/custom/servername.conf (Save and exit the file.)

Congratulations! You have set-up a basic instance of Apache on Fedora. The only thing left is checking if the httpd service starts up automatically by using the following command.

sudo /sbin/chkconfig --list httpd

Your desired result is: httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

After each and every change, it is wise to test if our config file is free from errors. Use the following command to do so.

sudo /usr/sbin/apachectl configtest

If everything is alright, we can now restart the web server with the following command, which will gracefully restart Apache on Fedora for us.

sudo /usr/sbin/apachectl graceful

If everything went well, at least it did for me, you will now be able to access the server in a browser. Open a browser of choice (as long as it isn’t Internet Explorer – avoid at all costs) and enter your Cloud Server’s IP address. You will see now see an empty index page since we didn’t upload any files yet. I guess I can say I now understand some more about working in a Unix Shell, and setting up Apache, as well as making it accessible, but secure. I will definitely review this Cloud Server Guide during the following days, and probably end up extending it some more, or adding a few images. The next step, however, is setting up the individual modules for Apache, as there are many of them that I’ll need before I will be able to physically move Poker For Free.

If you appreciate this guide and have become interested in Rackspace’s Cloud Servers, please use my affiliate link: