Security – .htaccess to deny access to most xml files

.htaccessjoomlaSecurity

I recently had a Joomla site hacked, so I'm trying to harden the site a bit.
There's a section in the recommended .htaccess that restricts outside access to the xml files that come with extensions. However, it also keeps my sitemap.xml file from being accessed.

How do I allow a certain file whiles keeping the rest?

here's the default code:

<Files ~ "\.xml$">
 Order allow,deny
 Deny from all
 Satisfy all
</Files>

and my modification that caused a 500 error:

<Files ~ "(?!sitemap)\.xml$">
 Order allow,deny
 Deny from all
 Satisfy all
</Files>

Best Answer

The FilesMatch line has an extra "<". It should be:

<FilesMatch "(?!sitemap)\.xml$">

Related Solutions

Security – allowing index access only with .htaccess

Maybe you are thinking to complicated, just deny all access and then allow access to index.php and the folder itself. For example:

Order allow,deny
Deny from All

<FilesMatch "^(index\.php)?$">
        Allow from All
</FilesMatch>

If you don't even want http://doma.in/folder/ to work you can replace the FilesMatch directive with Files index.php. Keep in mind that it depends on your DirectoryIndex directive what file will be displayed when accessing a folder without filename.

Edit: To answer the question in your comment, I think you will need a more powerfull .htaccess using mod_rewrite. You can't use Directory and DirectoryMatch in a .htaccess file accordingly to the Apache documentation. Because the request is being denied before the RewriteRule can add a trailing slash you can't add the trailing slash with mod_write.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !/index\.php$
    RewriteRule ^.*$ - [F]
</IfModule>

<IfModule !mod_rewrite.c>
    Order allow,deny
    Deny from All
</IfModule>

WordPress – How to obscure the WordPress install via htaccess

TLDR; It is not possible to obscure WordPress by only using directives in your .htaccess file.

Now cometh a tale of woe and horror. Our friend, fbh was right about the difficulty in hiding WordPress, it be not for yellow-bellied cowards. Arr! Here be the details of this (mis)adventure. Ye be warned!

Motivation

I'm one of those guys that likes things perfect. I will ~~spend~~ waste time over-engineering something to be the 'right way'. One of things I didn't like about the default WordPress setup was that a user could type in http://ex.com/wp-settings.php and then all this php jargon would spew all over the place. I eventually was able to turn off errors via PHP but that led to a greater desire to only have things that made since be locatable resources from the server...and that everything else would be 404/3'ified to our custom search page. After that I got this idea that I'd like to completely hide the underlying framework (i.e. WP)... anyways... if you want to hide WP it's possible. But it's really hard.

Steps to your doom

Modify your PHP ini settings appropriately. (i.e. turn display errors off) You might think this is unnecessary because if we're using .htaccess to reroute things, folks won't see errors because they can't access the error causing resources (I'm looking at you wp-settings.php). But errors could occur in displayed pages, so you definitely want them off. Just because WP_* directives are set doesn't necessarily mean that things will work the way you think they will. I found that on my server I had to set the display_errors to false FIRST, because WP_DISPLAY_ERRORS assumed that the default setting was false.

Controlling PHP ini settings may be something as simple as putting a directive in your .htaccess file. Or, in my case, as complicated as creating a CGI handler and then putting a php.ini file there. YMMV depending on your set-up.
Remove all access to files/directories with wp- prefix. The idea is that your WP deployment is about your content, not about WP (unless it's specifically focused on WP). It doesn't make sense for people to want to see what http;//ex.com/wp-cron.php has... unless they're up to no-good. I accomplished this via this:
```
 # If the resource requested is a `wp-*` file or directory, poop to a 403. 
 RewriteCond %{REQUEST_FILENAME} wp-.*$ [NC] 
 RewriteCond %{ENV:REDIRECT_STATUS} ^$ 
 RewriteCond %{REQUEST_FILENAME} -f [NC,OR] 
 RewriteCond %{REQUEST_FILENAME} -d [NC] 
 RewriteRule .* - [F,L] 
```
Learn how to just pass through mordor By removing all access to wp-* you can no longer gain access to the administrative part of WP. That really sucks. In addition to that downer, you've just realized that you don't know what RewriteCond %{ENV:REDIRECT_STATUS} ^$ really does. Well, what I tried to do is to give myself a 'secret' backdoor to the WP admin page. I used this code:
```
 # If the resource requested is 'mordor' (with or without an ending
 # slash) do a URL rewrite to `wp-login.php`. 
 RewriteCond %{REQUEST_URI} mordor/?$ [NC]
 RewriteRule mordor/?$ /wp-login.php [NC,L]
```
So the URL: http://ex.com/mordor should bring us to the login page. The reason why we had the REDIRECT line in the step above is that since this URL gets rewritten to a wp-* URL, we don't want the first rewrite rule to get it. Since it's being redirected internally, REDIRECT_STATUS will be set correctly and it won't push us to 403/4 land.
Remove wp-content Wordpress.stackexchange has a great article on removing wp-content. You have to redefine some WP constants and that pretty much works. You also have to redirect all accesses from wp-content to 'whatever-content`. This probably won't be an issue if this is a clean deployment. If you're modifying a pre-existing deployment you'll have to do some extra stuff.
Rewrite URLs to wp-content optional RewriteRule (.*)(wp-content)(.*) $1whatever-content$3 [NC,R,L]. This goes in your .htaccess file. If your user tries to access some old content via a wp-content URL, it will get redirected here.
Grep and replace all references to wp-content in your DB optional. You still have wp-content in your database. If you want to WP free you need to get rid of that stuff. I exported/mysql dumped my database, did a search and replace on the wp-content string to the new string. You might say... why do I have to do this if apache will rewrite my URLs? The problem is that the source code will contain these references so if you're really interested in obscuring WordPress, you need to do this. Note: At this point I should've just stopped and accepted the reality that this wasn't going to work. But I wanted Mr. T to pity me.
Replace all references to wp-includes and wp-admin in the source. A lot of the WordPress functionality depends on these two directories: wp-includes and wp-admin. This means these directory names are hardcoded in the source code. This means that you would have to create new directories (since PHP uses the underlying OS file system, not apache) to access these and then WRITES THESE OUT into the emitted html. This is just way too much trouble. I quickly gave up and went to the bathroom to take a poop.

Lesson

Sure, I could've just read http://codex.wordpress.org/Hardening_WordPress and followed those steps. But I wanted the perfect site. Now I just want all those hours back. The biggest thing that prevented me from stopping was that I didn't read anywhere on the internet that this was a lot of work and almost impossible to do. Instead I read of people trying to do it with no sense of if they were successful or not. So, to my past self, whom I will send this to via Apple's Time Machine, please don't try and obscure WordPress. It's not worth it.