e107.org: Forums / Core Support / .htaccess for Flood Attack

e107.org :: Forums :: e107 Support :: Core Support		<< Previous thread \| Next thread >>
.htaccess for Flood Attack

Go to page [1] 2 3
Moderators: jalist, McFly, bkwon, streaky, C6Dave, SecretR, steved, bugrain, AndyDev, Hansi64, nlstart

Author

Post

Brad R

Fri Jul 09 2010, 07:41AM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

Updated 12 August 2010

(At septor's suggestion, I am posting this as a new thread.)

Here is my .htaccess file for web hosts that support mod_rewrite (which appears to be most of them). I'm trying this now on one web site and it seems to be working ok. My .htaccess file also has a long list of blocked IP addresses ("deny from xxx.xxx.xxx.xxx") but those are not ready to be shared just yet.

Important Notes for New Users

1. If you've just come here looking for how to fix a hacked e107 site, you should know that this .htaccess file won't help you if you haven't upgraded to the current e107 version! You must install 0.7.22. If you're running anything less, you will get hacked. This .htaccess is only to help mitigate Denial-of-Service attacks.

2. You should check first to see if your web host already has provided an .htaccess file for your account. If so, do not replace it, as it is probably necessary for your site to function. Instead, add these rules to your existing .htaccess file. If you're not sure how to merge your existing .htaccess file with this new one, post your existing .htaccess file to a new forum thread (not this one!) and ask for help.

# e107 .htaccess script for hosts with mod_rewrite # If e107 is not installed in the document root, then make RewriteBase # RewriteBase /your-e107-folder/ ErrorDocument 403 default RewriteEngine on RewriteBase / # 1. Deny access to all POST requests, except to certain files and folders # when referred from our site. e107_admin (or whatever you have renamed # it to) MUST be permitted. If you're not using news.php as your site's # main page, add your main page (e.g. page.php) to the permitted list. # NOTE: IF you are using PayPal payments, omit the following four lines! RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} !^/?(news\.php|signup\.php|e107_admin/|e107_plugins/forum/|e107_plugins/.*/.*config\.php) RewriteCond %{HTTP_REFERER} !^http://(.*\.)?your_site\.com [NC] RewriteRule .* - [F,L] # 2. Redirect all access to the following user agents and files RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.76\ \[ru\]\ $X11;\ U;\ SunOS\ 5\.7\ sun4u$ [OR] RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5.0$ [OR] RewriteCond %{HTTP_USER_AGENT} (Bot\ Search|kangen|CaSpEr|MaMa|crew|plaNETWORK|dex|perl\ post$) [NC,OR] RewriteCond %{REQUEST_URI} (contact\.php|help_us\.php|\.htaccess) RewriteRule .* http://%{REMOTE_ADDR}/ [R,L] # 3. Deny access to requests with contact.php or help_us.php in the query # string, UNLESS those are referred from our own site (e.g. search) RewriteCond %{QUERY_STRING} (contact\.php|help_us\.php|casper) RewriteCond %{HTTP_REFERER} !^http://(.*\.)?your_site\.com [NC] RewriteRule .* - [F,L] # 4. Redirect empty user agent, UNLESS it's accessing the RSS feed RewriteCond %{HTTP_USER_AGENT} ^$ RewriteCond %{REQUEST_URI} !^/?e107_plugins/rss_menu/rss.php RewriteRule .* http://%{REMOTE_ADDR}/ [R,L] # 5. Deny access to these files UNLESS referred from our site. RewriteCond %{REQUEST_URI} ^/?(top|download|user|search|submitnews|fpw)\.php RewriteCond %{HTTP_REFERER} !^http://(.*\.)?your_site\.com [NC] RewriteRule .* - [F]

There are five rewriting rules:

1. The first rule set blocks POST requests. POST attacks tend to be huge and bog down the server. The second line lists files and folders for which POST requests will be permitted. Your site's front page (e.g. news.php) must be one of these, or users won't be able to log in. e107_admin/ must also be in this list, or you won't be able to do any administration tasks, most of which use POST. I've added signup.php so that new users can register, and e107_plugins/forum/ so that users can post in the forum. If you have renamed e107_admin and e107_plugins to different names, you will have to adjust the .htaccess file to match. You may need to add other exceptions. The third line requires that POST requests come from internal site links -- change your_site\.com to your domain name. If you have too many problems with your users, or you, getting "403 Forbidden" messages, try deleting this first rule set entirely. The other four stand on their own.

2. The second rule set blocks known-bad user agents, and also any attempt to access contact.php or help_us.php. Instead of a 403 error, these get redirected back to the originating server's IP address.

3. The third rule set blocks any attempt to use contact.php or help_us.php in a query string. (We've seen a lot of attacks of this type.) The second line will allow those in a query if the request comes from an internal site link; this lets the Search function work. Bounced requests get a 403 Forbidden error -- as a rule, I prefer to send 403 when I think the bounced request might have come from a human being. Remember to edit your_site\.com to your actual domain name.

4. The fourth rule set blocks any requests with an empty (null) user agent, unless it's attempting to access the RSS feed. I need this because I have one e107 site reading the RSS feed of another e107 site, and the e107 reader sends an empty user agent. These get bounced back to the originating server.

5. The fifth rule set blocks access to the six most-attacked "legitimate" e107 pages, unless the request comes from an internal site link. (By now you should have renamed contact.php to something else, so it's not on this list.) Change your_site\.com to your actual domain name. These get a 403 Forbidden message.

This may need some tweaking, so please post here any experience you have with the rules not working correctly.

[ Edited Thu Aug 12 2010, 06:09PM ]

Brad R

Fri Jul 09 2010, 07:50AM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

Updated 12 August 2010

The .htaccess given in the previous post only works for those web hosts that have mod_rewrite (the Apache module that supports Rewrite rules) installed. Most web hosts seem to have this. However, for those that do not, here is a version of the .htaccess file that requires only mod_access (e.g. allow, deny) and mod_setenvif.

There are two limitations to this approach. First, it can only respond with 403 Forbidden -- it cannot redirect the attack back to the attacker's server. (There is another module, mod_alias, which provides the Redirect command, but it is quite a bit more limited than mod_rewrite.) This is only a minor disadvantage because it's no more work to send a 403 response than to send a redirect.

Second, and more important, this approach cannot filter based on the content of the query string. Rule set #3 can not be implemented. Some sites are seeing a lot of requests for valid e107 pages but with "contact.php" in the query string, and these will bog down your server if it happens to you. So if at all possible, get mod_rewrite installed so you can reject these requests.

Is this scheme better than mod_rewrite? I don't know. My web host thinks these rules run slightly faster than the equivalent mod_rewrite rules. But so far I haven't found any information on the web regarding the relative speed of mod_access vs. mod_rewrite. You can mix these rules with mod_rewrite rules if you like (for example, you can use mod_rewrite to provide the missing rule set #3).

# e107 .htaccess script for hosts with mod_access and mod_setenvif ErrorDocument 403 default Order Allow,Deny allow from all # 0. Deny access to specific IP addresses. This is not an exhaustive list; # these are examples showing different ways to specify IP address ranges. deny from 109.169.46.7 deny from 139.10. deny from 202.2.128.0/24 # 1. Deny access to all POST requests, except to certain files and folders # when referred from our site. This can be overridden by <Limit> commands # in subfolder .htaccess files. e107_admin (or whatever you have renamed # it to) MUST be permitted. If you're not using news.php as your site's # main page, add your main page (e.g. page.php) to the permitted list. # NOTE: If you are using PayPal payments, omit the following eight lines! SetEnvIfNoCase Request_Method POST BAD_POST_REFERER BAD_POST_URI SetEnvIfNoCase Referer "^http://(.*\.)?your_site\.com" !BAD_POST_REFERER SetEnvIf Request_URI "^/?(news\.php|signup\.php|e107_admin/|e107_plugins/forum/|e107_plugins/.*/.*config\.php)" !BAD_POST_URI <Limit POST> Order Deny,Allow Deny from env=BAD_POST_REFERER Deny from env=BAD_POST_URI </Limit> # 2. Deny all access to the following user agents and files SetEnvIf User-Agent "^Mozilla/4\.76\ \[ru\]\ $X11;\ U;\ SunOS\ 5\.7\ sun4u$" BAD_BOT SetEnvIf User-Agent "^Mozilla/5.0$" BAD_BOT SetEnvIfNoCase User-Agent "(Bot\ Search|kangen|CaSpEr|MaMa|crew|plaNETWORK|dex|perl\ post$)" BAD_BOT Deny from env=BAD_BOT <Files .htaccess> Deny from all </Files> <Files contact.php> Deny from all </Files> <Files help_us.php> Deny from all </Files> # 3. Deny access to requests with contact.php or help_us.php in the query # string, UNLESS those are referred from our own site (e.g. search) # NOT POSSIBLE WITH MOD_ACCESS - REQUIRES MOD_REWRITE # 4. Deny access to empty user agent, UNLESS it's accessing the RSS feed SetEnvIf User-Agent "^$" NULL_AGENT SetEnvIf Request_URI "^/?e107_plugins/rss_menu/rss.php" !NULL_AGENT Deny from env=NULL_AGENT # 5. Deny access to these files UNLESS referred from our site. SetEnvIf Request_URI "^/?(top|download|user|search|submitnews|fpw)\.php" ATTACKED_FILES SetEnvIfNoCase Referer "^http://(.*\.)?your_site\.com" !ATTACKED_FILES Deny from env=ATTACKED_FILES

Rule sets #1 through #5 correspond to the mod_rewrite rules, and are documented in the previous post. Note that there is no rule #3, because we can't implement it with just mod_access and mod_setenvif.

The logic of rule set #1 above is a bit complex. (Essentially this is because mod_access can do a logical "OR" but not a logical "AND".) You'll note that for POST requests the order has been changed to Deny,Allow. This allows .htaccess rules in subfolders to override this rule and allow more POST requests. This will come up later; don't worry about it now.

You'll see a "rule set #0". This shows three different ways to deny access by IP address. These are real "bad bots" that my web host has detected, but is only a tiny fraction of the full list. The three ways to specify IP addresses:

109.169.46.7 -- specifies a single IP address
139.10. -- specifies a range of IP addresses, in this case "any address starting with 139.10." (in other words, 139.10.xxx.xxx).
202.2.128.0/24 -- specifies a range of IP address in CIDR notation, in this case "any address matching the first 24 bits of 202.2.128.0" (in other words, 202.2.128.xxx).

It is much better to block IP addresses in your firewall, rather than your .htaccess file; but you'll probably have to ask your web host to do that for you.

I'm currently using this .htaccess successfully on one site. As always, if you have problems, please let us know in this thread.

P.S. Yes, I'm aware that there is a redundant SetEnvIfNoCase statement in rule set #5. I've written it this way to make the five rule sets clear.

[ Edited Thu Aug 12 2010, 06:10PM ]

Brad R

Fri Jul 09 2010, 07:56AM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

Some web hosts may support neither mod_rewrite nor mod_setenvif. If that's the case, you are going to get hammered with 'bot requests. But there are some things that can be done, and when I (or someone) figures them out, I'll post them here. This keeps everything grouped nicely at the top of the thread.

I hasten to add: even if your host doesn't allow you to write .htaccess rules at all, if you are running the latest version of e107, your site will not get compromised by this latest attack. What will probably happen is that your server will halt due to the tremendous flood of requests. The purpose of this thread is to offer protective measures against the flood, not protective measures against new hacks. See this thread

for how to "harden" your e107 installation against exploits, including some .htaccess changes you can make.

mojo88

Fri Jul 09 2010, 01:22PM

Registered Member #31793

Joined: Thu Oct 26 2006, 05:29PM
Location:
Posts: 16

Hi all,
Can you please clarify for us web designers who have suddenly become webmasters if we are supposed to use this script in our .htaccess file at the root level, or in the e107.htaccess file in the e107 directory (if we have one). I've been doing both because I am not sure.

Also, I was reading a post a few weeks ago that said that if you are running the newest version 7.22, and use the htaccess file, you DO NOT need to delete or rename the contact.php file. Is this true, or do we need to do all three - use the htaccess, rename the contact.php and delete the original? Thanks

Brad R

Fri Jul 09 2010, 01:40PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

Sure -- sorry for the oversight. The .htaccess file should go in your "document root" directory. This is the main directory where you will find all the e107_xxxx subdirectories (e107_admin, e107_themes, e107_plugins, etc., or whatever you have renamed them). The document root directory might be called "public_html" or "www" on your particular server.

You only need to supply the file .htaccess. The file e107.htaccess is an example file provided by the e107 developers, to show how to redirect error conditions (like 404 Not Found) to the e107 error page. For the duration of these attacks, you do NOT want to redirect 403 errors to e107's error.php; you want to use a simple 403.html file to display a text message instead. (Update: or set ErrorDocument 403 default in your .htaccess file.)

If your web hosting service has already provided an .htaccess file, you'll want to modify that so as not to lose anything important. I know that some cPanel options (such as redirecting web pages) will change .htaccess. In most circumstances you can safely add the rules given above to whatever .htaccess rules you already have.

It is true that, in version 0.7.22, contact.php is not vulnerable to the exploit. The bots can hit it all day long and they won't get in. The problem is, every visit to contact.php will run a PHP thread and access the MySQL database, and these take a significant amount of CPU resources. With the size of the attacks we have been seeing, even an up-to-date contact.php will bring your web server crashing down just from the load. If you don't need contact.php, delete it. If you do need it, rename it to something else (and do NOT mention on this forum what new name you have chosen -- the script kiddies read this forum). Then use .htaccess to return a 403 Forbidden error to anyone trying to access contact.php, or better still, redirect the request back to their own server.

Again, it's not that contact.php is vulnerable. It's that thousands of visits to contact.php will simply overload your web server. There's much less load if you turn away those requests at the .htaccess file.

Edited to add: Oops, I may have misunderstood your last question. If you are using .htaccess to block the file contact.php, then you don't need to delete or rename contact.php -- no one will be able to access it, period. But if you need to use the contact page, rename it, and continue to block the original name (contact.php) in your .htaccess.

[ Edited Sun Jul 25 2010, 03:52AM ]

mojo88

Fri Jul 09 2010, 01:43PM

Registered Member #31793

Joined: Thu Oct 26 2006, 05:29PM
Location:
Posts: 16

Thanks a lot! you have all been very helpful through this trying time.

bigbadwolf

Fri Jul 09 2010, 05:05PM

Registered Member #21221

Joined: Tue Sep 27 2005, 09:48AM
Location: Long Island NY
Posts: 106

If we have a site with subdomains, I assume a copy of this need to exist within each root folder. Is this correct?

So if we had the main domain as DOMAIN1 and sub domains, DOMAIN2 and DOMAIN3, this line:

!^http://(www\.)?your_site\.com [NC]

would be changed to

!^http://(www\.)?DOMAIN1\.com [NC] <- in main root htaccess
!^http://(www\.)?DOMAIN2\.com [NC] <- in subdomain1 htaccess root folder
!^http://(www\.)?DOMAIN3\.com [NC] <- in subdomain2 htaccess root folder

Thanks for your work!

[ Edited Fri Jul 09 2010, 05:08PM ]

septor

Fri Jul 09 2010, 05:58PM

Registered Member #37

Joined: Sun Aug 11 2002, 05:20AM
Location:
Posts: 700

I think subdomains are also covered by this. (Which kind of begs the question why the www bit exists?)

If not, I really do not understand why it's limited to just the www subdomain?

Edit: And to answer your post; that won't work like you think unless you have multiple domains you are trying to cover with one .htaccess file.

[ Edited Fri Jul 09 2010, 05:59PM ]

Security issue? e107 security is here to help.

My e107 related scripts can now be found on GitHub. Use at your own risk.
Public ready scripts will be pushed to plugins.e107 only.

mojo88

Fri Jul 09 2010, 06:25PM

Registered Member #31793

Joined: Thu Oct 26 2006, 05:29PM
Location:
Posts: 16

Hi again Brad,
this works perfect on *most* sites where the e107 files are installed directly in the root, and some don't work? Trying to figure out what these have in common.

I have noticed than it doesn't work for any of sites that I have installed in their own e107 folder. I already have a redirect in my .htaccess file. When I add your code I get an:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

You mentioned :

# Customize to include your site's front page.

in the top of the script, I thought this meant to make sure and change the 3 parts where a URL is in the code,

I have tried changing the code where we are supposed to add our web address:

RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site\.com [NC]

to be :
RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site\.com/e107/ [NC]

...but I guess that isn't correct. Is there some other place or another way to make sure the correct path to my site is included?

(I'm also asking my host if I can move the files so they are at the root level, so that might solve this problem too.)

I am not a programmer, and this whole incident is really stretching my limits, sorry to ask such simple questions.

Brad R

Fri Jul 09 2010, 06:41PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

@bigbadwolf: It depends on how your web host stores the files for the different domains. I'm going to assume your host works like my web host, and that DOMAIN1's files are stored in the document root /public_html/, and DOMAIN2 and DOMAIN3 are stored in subdirectories /public_html/DOMAIN2/ and /public_html/DOMAIN3/.

I'm also going to assume that your host translates a request for "www.DOMAIN3.com/news.php" to a request for the file /public_html/DOMAIN3/news.php. (There are other ways to make subdomains work, but this appears to be fairly common.)

What you need to know is that the web server software, Apache, will work its way down through the subdirectories, checking for an .htaccess file at each level, and applying them in order as it works its way down. (See official docs here:

) So to access /public_html/DOMAIN3/news.php it will evaluate, in order:

/.htaccess
/public_html/.htaccess
/public_html/DOMAIN3/.htaccess

So the .htaccess in your document root (/public_html/.htaccess) will be applied to ALL of your domains. Which means if you put a rewrite rule there that checks for a valid domain name, it had better check for all valid domain names.

And your supposition is correct. Each place in our example .htaccess where you would see the domain name, e.g.,

RewriteCond %{REQUEST_URI} ^/?(top|download|user|search|signup|submitnews|fpw)\.php
RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site\.com [NC]
RewriteRule .* - [F]

you should change it to have all of the domain names

RewriteCond %{REQUEST_URI} /?(top|download|user|search|signup|submitnews|fpw)\.php
RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site1\.com [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site2\.com [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_site3\.com [NC]
RewriteRule .* - [F]

If the request matches any of the domain names, the RewriteRule will not be performed.

There's one other small but important change there. I removed the ^ character from the first line, before /?(top|download|user|search|signup|submitnews|fpw)\.php The ^ character forces the match to occur at the start of the URI, that is, in the document root. Removing that character will match top.php, download.php, etc. in the top directory and any subdirectory. This is a quick fix, but I figure you want a quick response.

The "proper" solution would be to create .htaccess files in each subdirectory, but I'm not entirely sure how the Request_URI would appear in those cases, so I'm not (yet) ready to propose that solution.

zollk60

Fri Jul 09 2010, 06:46PM

Registered Member #27052

Joined: Thu Apr 27 2006, 07:11PM
Location: Northern NY
Posts: 66

When specifying a RewriteCond %{HTTP_REFERER} include subdomains in this manner:

RewriteCond %{HTTP_REFERER} !^http://(www|sub1|sub2\.)?YourSite\.com [NC]

RewriteCond %{HTTP_REFERER} !.*YourSite.com.* [NC]

The first statement doesn't always perform as intended, sometimes it will deny access to pages from within the site. If that is the case then use the second statement.

[ Edited Fri Jul 09 2010, 06:50PM ]

"Only those who fail greatly can ever achieve greatly" - Robert F. Kennedy
Microsoft Most Valuable Professional - Consumer Security (2007-2008)
Member - Alliance of Security Analysis Professionals - Since 2006

Brad R

Fri Jul 09 2010, 07:00PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

@mojo88, sorry if my initial post wasn't clear. You do NOT want to put the subdirectory names in the HTTP_REFERER lines. Only the site's domain name goes there.

When I said "customize for your site's front page" I meant this: most e107 sites that I've seen use news.php (the e107 default) for the site's main page. This is controlled by the "Front Page" setting in the Admin Area. If for some reason you used a Custom Page for your site's main page, you'd have to add page.php to the list of files in the RewriteCond %{REQUEST_URI} in the first rule set. Then your users can sign in.

Now a question. You say your e107 files are not at the root level, but in a subfolder. Is this because you are hosting multiple domain names in the account, and each domain name is getting its own subfolder? Or is it just that you decided to install e107 into a subfolder? If you have multiple domain names, see my previous reply.

If you've just installed e107 into a subfolder, let's call it FOLDER, then I think in rule set #1 and rule set #5, the two places where you see %{REQUEST_URI} ^/? , you have to add your subfolder name after the ^/?, e.g., %{REQUEST_URI} ^/?FOLDER/ and remember to put a forward slash after the FOLDER name. So the first line of rule #5 would read
RewriteCond %{REQUEST_URI} ^/?FOLDER/(top|download|user|search|signup|submitnews|fpw)\.php

Again, I think that will work. I haven't tried it.

Brad R

Fri Jul 09 2010, 07:03PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

@zollk60, thanks, I forgot about subdomain names. You're right. One quibble: I think the \. needs to be repeated for each subdomain. In other words,

RewriteCond %{HTTP_REFERER} !^http://(www\.|sub1\.|sub2\.)?YourSite\.com [NC]

Brad R

Fri Jul 09 2010, 07:16PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

By the way, to clarify what all those RewriteCond's are seeing, when you visit a URL like this:
http: //e107.org/e107_plugins/forum/forum_viewtopic.php?200849.last

It's broken down as follows:
HTTP_HOST==> e107.org
REQUEST_URI==> /e107_plugins/forum/forum_viewtopic.php
QUERY_STRING==> 200849.last

The REQUEST_URI is everything after the domain name, and before the ? mark (if any). The QUERY_STRING is everything after the ? mark.

HTTP_REFERER will be the complete URL of the web page that contained the referring link, including the http:// and the query string (if any).

mojo88

Fri Jul 09 2010, 08:21PM

Registered Member #31793

Joined: Thu Oct 26 2006, 05:29PM
Location:
Posts: 16

Hi Brad,
I have a dedicated server with about 100 unique websites on it, each one has its own domain, email accounts, ftp login, etc. Twenty-five are based on the e107 CMS so I think I need to apply all these security measures (listed on the flood attack post

) to each hosting account on my server. ie, I have to make 25 .htaccess files.

When I installed them, I had one reason or another for either installing e107 in the root or into its own folder. Now it seems that those reasons are not important and I am going to try moving a few into the root and see if the script works. I will also try your suggestion for altering the code on some that are in a subfolder and let you know how that goes.

zollk60

Fri Jul 09 2010, 08:53PM

Registered Member #27052

Joined: Thu Apr 27 2006, 07:11PM
Location: Northern NY
Posts: 66

If e107 is not installed in the document root, then RewriteBase must be declared.

RewriteEngine on
RewriteBase \e107 folder\

If e107 is in the document root, and mod_rewrite still does not seem to work. Then specify RewriteBase in this manner:

RewriteEngine on
RewriteBase \

mojo88

Fri Jul 09 2010, 10:42PM

Registered Member #31793

Joined: Thu Oct 26 2006, 05:29PM
Location:
Posts: 16

Well, I don't know what happened, but now it all seems to be working - even without moving the files to the root.

All I did was recopy the htaccess code from the box at the top and pasted it (again) into a wider notepad pane and now when I paste it in my htaccess file, it works! hopefully this can help someone else avoid many hours of frustration. I think the word wrap corrupted the formatting?!

Brad R

Sun Jul 11 2010, 08:21AM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

Updates: I've added the non-rewrite .htacess to the second post in the thread. I'm using this on one site as a test and it seems to work ok (though on my site I've added the rule set #3 using mod_rewrite).

I've also made the following changes to the mod_rewrite .htaccess:
Added RewriteBase with zollk60's comment.
In rule set 1: clarified the comment.
In rule set 3: added 'casper' as a denied query string.
In rule set 5: added fpw.php as a protected file. (Can only be accessed via an internal link.)
In rule sets 1,3,5: modified to allow any subdomains, e.g., your_site.com or anything.your_site.com.

BUG

Mon Jul 12 2010, 05:12PM

Registered Member #57538

Joined: Mon Jul 05 2010, 03:47PM
Location: USA
Posts: 12

I just updated my HTaccess to brads latest suggestions.

Just before this HT update I noticed some stuff is getting through the filter and not being 403'd.

78.24.217.49 - - [11/Jul/2010:00:21:17 -0400] "POST /news.php/contact.php HTTP/1.1" 302 204 "-" "Casper Bot Search"

That is getting a 302 error, and not a 403.

brad wrote ...
In rule set 3: added 'casper' as a denied query string.

will adding that turn the above 302 error into a 403?

I've also added "plaNETWORK" to my rule #2 and #3, as I had a few of those in the logs too.

on the good side, I took a sample from my log and looked at all of July 11 and attacks are down.
July 1, had about 12000 attacks.
July 11 had about 3000 attacks.

Brad R

Mon Jul 12 2010, 06:35PM

Registered Member #18939

Joined: Tue Jun 28 2005, 05:48PM
Location: Ontario, Canada
Posts: 197

The "bot search" rule will pick up any user agent with "bot search" (case-insensitive) in the name. Rule set #3 picks up "casper" in the query string, which is not what you are seeing there in your log.

The "302" is the redirect message. The RewriteRules that bounce the request back to %{REMOTE_ADDR} actually just send a 302 response; it's up to the requester (the bot) to decide whether or not to honor that redirection. But whether he honors it or not, the load on your server is the same.

Are you seeing plaNETWORK in the user agent, or the query string?

Go to page [1] 2 3
Jump: Back to top



e107, leading the cms revolution
Home Downloads Forums Misc Bugtracker Documentation/Wiki Plugins Themes Hosting Reviews