Htaccess

Htaccess can be used to manage multiple usernames/passwords, thereby enhancing information protection on the web server by controlling access through HTTP protocols. When used in conjunction with a browser encryption method such as SSL, it is possible to make htaccess authentication a robust method of protecting directories. However, out of the box, htaccess is prone to several problems, namely: packet-sniffing, IP hijacking, replay attacks, and brute force. Cryptography, (SSL and one-time pads) can solve all but one of these problems - brute forcing.

Brute forcing takes a number of forms, and is a well-known and well-used attack against htaccess. Brute force is usually a minimal knowledge attack, requiring only the URL for the password-protected directory to work. In their most malevolent form, brute force attacks simply check the headers returned by the server. If the program sees that its request was favorable (the server returned a 200 OK response), it will mark the password as being valid. This can wreak havoc on a server. It can even cause denial of service when the brute force program disconnects after viewing the headers (as the server is not allowed to print out the rest of the content and the daemon cannot kill its children efficiently.)

This article is the first in a three-part series that will provide a way to harden htaccess (in coordination with a SSL and a one-time pad token type authentication mechanism) to make it more stable and lessen the chances of successful brute force attacks. This installment will offer a brief overview of htaccess, particularly why it is prone to attacks by brute force, and a look at a couple of hacking tools and methodologies to which htaccess is susceptible.

The Problem

There are literally dozens of on-line documents on securing htaccess (hyper-text access) scripts and directories. There are equally as many papers that have a large portion of the topic glossed over or missing on the topic. Most of them go along the lines of:

make sure unauthorized users cannot read the .htaccess script by using the httpd.conf or httpds.conf file to secure any files beginning with '.ht';
make sure all '.ht' files are readable by the server;
make sure the right deny/allow order is set;
etc., etc.

By the way, in case you didn't know how to do this here is a config file snippet:

Order allow, deny Deny from all

Note: The reason .htaccess starts with a '.' is because in Unix it is a tradition that files starting with a '.' are "hidden" files or configuration files that aren't supposed to be edited by anyone who doesn't know better. Really this doesn't mean anything other than that users have to type a switch when doing a directory listing to view these files. It is a convention worth noting, however, as even its name implies that it shouldn't be viewed.

Users will also need to have this line in the httpd/s.conf file to tell Apache to look at the .htaccess file for access control information:

AccessFileName .htaccess

That stuff is all fine and dandy, but what are the real life concerns of htaccess? What are its real strengths and weaknesses?

There are numerous ways to secure data, but the only way to secure large quantities of data and data types (this is important) is to either set up scripts to act as a proxy script - to filter who can and cannot see the data - or to use something more global like a password protected directory. The standard out-of-the box method to password protect directories is to use an .htaccess script. In reality, this is exactly the same thing as setting up a script to monitor who can and cannot view data. But let's suppose, for the sake of this paper, that it is different.

The typical system administrator or web-application engineer can look at each of these options and, depending on his or her skill level and time constraints, will more often than not decide on the easier out-of-the-box solution provided by htaccess scripts. These are well supported and well documented by both Apache and Zeus web servers. (Due to its popularity and the fact that it is open source, I'll be using Apache in this series to explain htaccess.)

The problem is not that htaccess is unsupported, but that it is misunderstood. The benefits of htaccess are that it is easily maintained, easily understood (at least on how to write .htaccess scripts), and the two major browsers (IE and Netscape) have very predictable responses in success and failure of password authentication. Well, this is true in almost all cases, but we are getting ahead of ourselves.

Hardening WordPress with htaccess

A few emails have come through about how user’s WordPress installations have been compromised, or where an attacker has found resources he/she shouldn’t have. This article will discuss some security techniques to better harden and secure your WordPress blog; this is especially effective in a hosted environment.

Let me start by saying this guide may not be for everyone, and chances are that it may break some third party plugins and templates.

It is not all doom and gloom; if you are able to use this guide it will significantly increase the security of your blog. It will prevent many attacks including brute force attacks, plugin enumeration, directory listings, sensitive information disclosure and file include vulnerabilities. Additional hardening guides will be required for different circumstances, so if this is not for you let us know so we can plan additional guides to meet user requirements.


Important Note: Please ensure that your WordPress files and database are backed up before attempting any of these changes.
Step 1 – Restricting wp-content and wp-includes

Using htaccess directive, we can restrict all files accept images, CSS and JavaScript. The .htaccess file will look as follows:

Order Allow,Deny
Deny from all

Allow from all


If we want to allow certain plugins such as Democracy, we can append the following to our wp-content/.htaccess file:


Allow from all


Put this into your .htaccess file within your wp-content and wp-includes directories. As a side note, you can also allow specific files to get your plugins and/or templates to work, if needs be. This is a much cleaner method to do it then discussed in a previous version of this document.

If you got through that, well done.
Step 2 – Restricting access to wp-admin

Now to restrict wp-admin you have two choices. Put a .htaccess file into your wp-admin directory with one of the two choices below.

You can resrict it by IP:

order deny,allow
allow from a.b.c.d # This is your static IP
deny from all

The above code will prevent browser access to any file in these directories other than "a.b.c.d" which you should change to be your static IP address.

OR restrict the directory with a password:

AuthUserFile /etc/httpd/htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any

OR improved version:

There is a bug where the above rules will cause a password box to appear to the user if they submit a comment without an e-mail address. This occurs, because some CSS and image files are located inside the wp-admin directory. To get around this we can wrap the above rule set in a file directive which disallows .PHP files but permits the rest. This still prevents alot of direct attacks and also provides alot of additional features.


AuthUserFile /etc/httpd/htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any


Thats it! you now have a more secure blog and hopefully everything still works for you.