Security and .htaccess

About a month ago I started a WordPress blog on a hosted server related to a hobby. So, I am new to this at present.

Since I’m concerned about security, one thing I did was to install the plugin WP Security Scan. According to the plugin results, my site checks out except that I get this in the results as a red flag:

Read More

The file .htaccess does not exist in wp-admin/ (I ssh’d in there and it does not exist)

Ok, so I did a considerable search on the issue and find too much info on .htaccess. I’ve been through Hardening WordPress on the WordPress.org site, etc. And also ran into this article: http://digwp.com/2010/07/wordpress-security-lockdown/

Anyway, I’ve basically gotten confused with the plethora of information available.

What should the .htaccess file in wp-admin contain? I’ve read that this .htaccess file should password protect the wp-admin directory and I’ve also read that this can cause functionality problems.

Help with this is greatly appreciated.

Thanks.
-wdypdx22

Update Ok, so I’m not logged in to my blog and using a different computer than usual. I enter the url www.mysite.com/wordpress/wp-admin/ and there is a redirect to login. If that’s what happens, then is an htaccess file even needed in the wp-admin directory?

Related posts

Leave a Reply

4 comments

  1. UPDATE: When I first posted my answer I missed the crux of the question; my answer was about .htaccess security in general and is now listed below the double line (look down if it interests you.) Unfortunately I don’t have specific experience with securing /wp-admin/ using .htaccess so I’ll simply list the two resources I will pursue when and if I need it:

    The first one recommends the following (and here is some discussion about it.)

    <Files ~ ".(php)$">
    AuthUserFile /etc/httpd/htpasswd
    AuthType Basic
    AuthName "restricted"
    Order Deny,Allow
    Deny from all
    Require valid-user
    Satisfy any
    </Files>
    

    The latter has lots of information, especially in the comments, but admittedly providing you a list to read is not the answer you were looking for.

    Sorry I couldn’t have been more helpful on this one.

    ========================================

    Typically WordPress only has the following which handled permalink processing and is not related to security:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    

    Recently I’ve found the WP htacess Control plugin that manages a lot of .htaccess for you and I rather like it a lot. After tweaking it’s settings it added the following options:

    # WPhtC: Disable ServerSignature on generated error pages
    ServerSignature Off
    
    # WPhtC: Disable directory browsing
    Options All -Indexes
    
    # WPhtC: Protect WP-config.php
    <files wp-config.php>
    order allow,deny
    deny from all
    </files>
    
    # WPhtC: Protect .htaccess file
    <files ~ "^.*.([Hh][Tt][Aa])">
    order allow,deny
    deny from all
    </files>
    

    It also added these options which are about performance instead of security:

    # WPhtC: Setting mod_gzip
    <ifModule mod_gzip.c>
    mod_gzip_on Yes
    mod_gzip_dechunk Yes
    mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
    mod_gzip_item_include handler ^cgi-script$
    mod_gzip_item_include mime ^text/.*
    mod_gzip_item_include mime ^application/x-javascript.*
    mod_gzip_item_exclude mime ^image/.*
    mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
    </ifModule>
    
    # WPhtC: Setting mod_deflate
    <IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    Header append Vary User-Agent env=!dont-vary
    </IfModule>
    

    Beyond this one there are some plugins I haven’t tried but that are focused on security and that interact with .htaccess – you might try them each just to see what they do to the .htaccess file:

    Beyond that, if you want to know the (IMO) #1 expert resource on Apache security related to WordPress you can find it on AskApache.com; dude is hardcore! His blog won’t solve your “too much information” problem but at least you can view it as an authoritative resource!

    Here are some examples (though not all are directly WordPress related they all are applicable):

    Anyway, hope this helps.

  2. The idea behind it, if you have strangling files hanging behind from past upgrades or for zero-day attacks, your system could be hacked. Also securing the wp-admin by another method will help against brute-force attacks.

    One Idea) If it is just you editing the site you can limit access to the folder by ip doing something like

    <Files *>
    Order deny,allow
    Deny from All
    Allow from 1.2.3.4
    </Files>
    

    To make it a bit more tolerable for dynamic IP systems; you should be able to allow from a subblock, so if you IP pool is always from 1.2.3.128 – 1.2.3.255, then you could do something like 1.2.3.128/25

    Another Idea) require HTTPS, give a permissioned denied if they try it over http. But don’t redirect them to the https. You can use a self-signed cert or one from CA Cert to get by without buying one.

  3. I always include a .htaccess file in wp-admin, even if I never put anything in it, since it negates the root directory’s file. Some people use the wp-admin .htaccess file to hide the whole directory from all but one IP address, others use it to password protect the directory.

    However, password protecting the admin section with .htaccess will disable ajax communications, since they interact with wp-admin/admin-ajax.php.

    Generally, I don’t see much reason to add anything to the admin .htaccess file unless you’re extremely paranoid. Attacks usually target wp-content anyway.