is this htaccess correct?

[keneso]

Hi.

My sites have been hacked (details at this thread: [webmasterworld.com...] I have deleted all, and want to reload the sites, hopefully with better protection.

I noticed that the hack had altered the htaccess adding this line:

# For security reasons, Option followsymlinks cannot be overridden.
#Options +FollowSymlinks
Options +SymLinksIfOwnerMatch

Which of course due to my very limited knowledge I don't know about, so I'm open to enlightment.

Anyhow this is the file I think could help, but again done by me, might be totally wrong, so I am open to all suggestions, which hopefully will explain things in a comprehensive way in case.

As you can guess I did a patchwork by googling, till I came to conclusion it's better ask the experts, since I do need to specifically deny access to few eastern countries to limit the threats, and would appreciate if you tell me what's the best way.

# secure htaccess file
<Files .htaccess>
 order allow,deny
 deny from all
</Files>

<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
 Order Allow,Deny
 Deny from all
</FilesMatch>

RewriteEngine on

# www
rewritecond %{http_host} ^example.com [nc]
rewriterule ^(.*)$ http://www.example.com/$1 [r=301,nc]

# allow all except those indicated here
<Limit GET POST PUT>
 order allow,deny
 allow from all
 deny from 78.158.11.226
 deny from 123.125.71.109
 deny from 220.181.108.151
 deny from 220.181.108.151
 deny from 213.186.122.3
 deny from 193.106.136.62
 deny from 114.79.3.182
 deny from 93.182.136.176
 deny from 208.115.113.*
 deny from 222.38.98.*
 deny from 113.157.220.*
 deny from .*alexiadns\.com
 deny from .*evuln\.com.*
 deny from .*ahrefs\.com.*
</Limit>

# deny access to evil robots site rippers offline browsers and other nasty stuff
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Anarchie [OR]
RewriteCond %{HTTP_USER_AGENT} ^ASPSeek [OR]
RewriteCond %{HTTP_USER_AGENT} ^attach [OR]
RewriteCond %{HTTP_USER_AGENT} ^autoemailspider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xenu [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus.*Webster [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]

[lucy24]

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Belt and suspenders? You're securing htaccess twice. There's an alternative command for blocking all files with leading dot. Was going to go look up the precise wording, but Apache just scared me out of my wits by being unavailable :) and this is not a time for "If I remember correctly..." (Can't quote my own htaccess because the host has this bit in the config file.)

<Limit GET POST PUT>

Why limit them? These are people you want to lock out unconditionally, right? Commands other than GET should be constrained as tightly as possible.

ymmv, but long strings of OR-delimited RewriteConds might work better using SetEnvIf. Flag each one separately as "bad_bot" or "keep_out" or other name to taste, and let your Deny from directive include a single "Deny from env=keep_out" line.

BrowserMatch Zeus keep_out
...
Deny from env=keep_out

Like that.

Your list of UA rules is pretty much useless as written, since they all come with opening anchor. And "Zeus.*Webster" is included in "Zeus" so why both?

[keneso]

Belt and suspenders? You're securing htaccess twice. There's an alternative command for blocking all files with leading dot. Was going to go look up the precise wording, but Apache just scared me out of my wits by being unavailable :) and this is not a time for "If I remember correctly..." (Can't quote my own htaccess because the host has this bit in the config file.)

Please do tell when it'll be available.
And about belt, and suspenders, does it create a conflict, or is just overkill, and harmless?

Why limit them? These are people you want to lock out unconditionally, right? Commands other than GET should be constrained as tightly as possible.

And how would that be done? I remind you I did a patchwork, I am a complete illiterate ... well I do know how to read, and write ;)

ymmv, but long strings of OR-delimited RewriteConds might work better using SetEnvIf. Flag each one separately as "bad_bot" or "keep_out" or other name to taste, and let your Deny from directive include a single "Deny from env=keep_out" line.

Can you please cut it down more, I understand your suggestion to use SetEnvIf, but didn't get how to do it correctly.
Also would that be applied to a long Deny list?

[g1smd]

Don't do redirects with RewriteRule before blocking access with RewriteRule. Why redirect something you then block?

Change the order of the rules:
- block with deny/allow
- block with RewriteRule
- redirect with RewriteRule

RewriteRule ^.* - [F,L]

simplifies to

RewriteRule .* - [F]

[keneso]

Don't do redirects with RewriteRule before blocking access with RewriteRule. Why redirect something you then block?

Do you mean this

rewritecond %{http_host} ^example.com [nc]
rewriterule ^(.*)$ http://www.example.com/$1 [r=301,nc]

should go after this

# deny access to evil robots site rippers offline browsers and other nasty stuff
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Anarchie [OR]
RewriteCond %{HTTP_USER_AGENT} ^ASPSeek [OR]
RewriteCond %{HTTP_USER_AGENT} ^attach [OR]
RewriteCond %{HTTP_USER_AGENT} ^autoemailspider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xenu [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus.*Webster [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]

[g1smd]

Yep.

Block first then redirect only the remaining valid requests.

[lucy24]

Belt and suspenders? You're securing htaccess twice. There's an alternative command for blocking all files with leading dot. Was going to go look up the precise wording, but Apache just scared me out of my wits by being unavailable :) and this is not a time for "If I remember correctly..." (Can't quote my own htaccess because the host has this bit in the config file.)

Please do tell when it'll be available.

They were only down for a minute or two, but I had an appointment :( Anyway, after much frustration at apache dot org I had an inspiration and looked in my MAMP config file. They've got simply

<FilesMatch "^\.ht">
 Order allow,deny
 Deny from all
 Satisfy All
</FilesMatch>

I don't know what the "Satisfy..." line is doing there. Normally it means there's more than one permitted way to get in, so the line will be either "Satisfy Any" or "Satisfy All". (For example, you can get to a particular page either by being a registered member or by being the googlebot.) But if there's no "Allow from..." exception, what's to satisfy?

And about belt, and suspenders, does it create a conflict, or is just overkill, and harmless?

Here it's just redundant. It's not like blocking someone by two entirely different ways, like by IP and by UA so you get two chances to nab them. It won't do any harm except for an added nanosecond of server time.

Why limit them? These are people you want to lock out unconditionally, right? Commands other than GET should be constrained as tightly as possible.

And how would that be done? I remind you I did a patchwork, I am a complete illiterate ... well I do know how to read, and write ;)

Simply leave out the <Limit> ... </Limit> envelope. There may be situations where the envelope is essential to the operation of a rule, but I can't think of any. Well, except where the envelope itself is part of the rule, like <Directory> (config file only) or <Files> / <FilesMatch>. In my case:

<FilesMatch "(forbidden|goaway|missing|cell)\.html">
Order Allow,Deny
Allow from all
</FilesMatch>

<Files "errorstyles.css">
Order Allow,Deny
Allow from all
</Files>

<Files "robots.txt">
Order Allow,Deny
Allow from all
</Files>

You have to make sure that anyone who gets locked out is still allowed to see your 403 document, and it's recommended that you let everyone get to robots.txt. It's plain-text file by definition, so they can't do much to it. I unblock the error-document stylesheet because it's a way of cross-checking whether I've inadvertently locked out a human. Robots rarely ask for stylesheets.

Your exact handling of POST requests will depend on how your site is set up: for example, do people submit forms or fill out Comment boxes? If you have a locally based analytics program like piwik, it will need an exemption in order to do its stuff.

ymmv, but long strings of OR-delimited RewriteConds might work better using SetEnvIf. Flag each one separately as "bad_bot" or "keep_out" or other name to taste, and let your Deny from directive include a single "Deny from env=keep_out" line.

Can you please cut it down more, I understand your suggestion to use SetEnvIf, but didn't get how to do it correctly.
Also would that be applied to a long Deny list?

Yup. You set the variable for each unwanted visitor; this part uses mod_setenvif. Then, when Apache gets to the core directives-- these come last of all-- everyone gets the door slammed in their collective faces. Like this:

BrowserMatch ^-?$ keep_out
BrowserMatch "America Online Browser" keep_out
BrowserMatch Clipish keep_out
BrowserMatch Covario keep_out
{snip}
BrowserMatch Wget keep_out
BrowserMatch Wikimpress keep_out
BrowserMatch Yahoo keep_out

Order Allow,Deny
Allow from all

# specific addresses or conditions

Deny from env=keep_out

Deny from 23.19
Deny from 31.214.128.0/17
Deny from 37.59
{et cetera}

Note that first line btw. ^-?$ is for robots who don't send a user-agent at all. For some reason this includes google's faviconbot, but other than that it's all visitors you don't want.

---

- block with deny/allow
- block with RewriteRule

This bit threw me because to me "deny/allow" refers to core-level directives like IP blocks and those don't execute until after all the modules, do they? Well, they'd have to execute after SetEnvIf or it wouldn't work.

---

As always: If g1 comes along and disagrees vigorously with anything I've said here, he's right and I'm wrong. Well, possibly not if something applies specifically to shared hosting, because the grownups tend to forget how it works ;)

[g1smd]

The deny/allow stuff is listed first merely to get it out the way of the RewriteRules. You could list it last.

The important point is that RewriteRules that block access are listed before RewriteRules that redirect and those are listed before RewriteRules that internally rewrite.

[keneso]

Thank you all so far.

I have to read the posts few times, as I'm almost more confused ... not for the posts, which are obviously competent, but due to my lack of knowlege.

[aristotle]

I have to read the posts few times, as I'm almost more confused ... not for the posts, which are obviously competent, but due to my lack of knowlege.

Most webmasters who have only a few sites don't have the time or interest to become proficient in Apache code just to do a few .htaccess files. So it becomes a tedious annoyance for them to have to deal with it.