SOLVED Block abusive requests to website?

You could try something like

Code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*(12161=&add-to-cart=12183).* [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>

 

I wonder if you might get less server load if you used a ModSec rule ?

 

This htaccess redirect should deny (status 403) any GET request with BOTH add_to_wishlist AND add-to-cart QUERY_STRING ARGS.

Code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (?:^|&)add_to_wishlist= [NC]
RewriteCond %{QUERY_STRING} (?:^|&)add-to-cart= [NC]
RewriteRule ^(.*) - [F,L]
</IfModule>

It worked as designed when I tested it.

 

Using the [OR] operator on the code I submitted could prevent legitimate "Add to Cart" and "Add to Wishlist" functionality in the eShop in question if it uses...

Code:

GET /category/whatever/?add_to_wishlist=12161

and...

Code:

GET /category/whatever/?add-to-cart=12161

to do those things.
So I suggest you test.

 

For what it's worth you should be able to do it quickly and easily with modsecurity. This helps a lot especially if you use CSF/LFD.

Modsec's AND operator (basically) is "chain".

I would personally handle it with something like this:

Code:

SecRule QUERY_STRING "add_to_wishlist" "t:lowercase,id:29734,phase:1,chain,deny"
SecRule QUERY_STRING "add-to-cart" "t:lowercase"

In this case the request will be denied if both those strings are after the "?" in the URI.

In the top list of modsec operators you could also specify http error code to use with status:404 after chain,deny (or whatever status code you want, though I avoid 404 and usually try to find one that apache handles without invoking PHP for server load reasons).

 

If you use CSF, you can block the requests at the firewall before any processing is done for the ultimate reduction in server load.

Make a file /usr/local/csf/bin/csfpre.sh
Add the following code:

Code:

#!/bin/sh
iptables -A INPUT -p tcp --match multiport --dport 80,443 -m string --string 'add_to_wishlist' --algo bm -j DROP
iptables -A INPUT -p tcp --match multiport --dport 80,443 -m string --string 'add-to-cart' --algo bm -j DROP

Make file executable

restart CSF

 

There is a mistake in my previous post, I cannot seem to edit. Modsec uses the command "chain" as an "AND", not "OR". It is used so a request must match both lines of a chained rule (or every line if more than 2) to be blocked.

I like the method of doing in iptables too. I don't usually opt to do it myself, since with modsec you can also use "drop" instead of deny to drop the tcp connection from apache in phase 1. The advantage (in my opinion) is it still gets logged if you want and CSF will still count these as well as denies if LF_MODSEC is on, so repeat offenders would be blocked anyway with just the modsec rule.

 

@ quizknows

Might this work for mod_sec ? I haven't tried it !

Code:

SecRule QUERY_STRING (add_to_wishlist|add-to-cart) "t:lowercase,id:29734,phase:1,deny"

 

That would work to block either/or, but I believe the whole point here was to drop requests that had both of those in the same query string. Your proposed rule would block any request containing either (or both, technically). That is why I chained it for 2 separate conditions in the one modsec rule, so that the order of those strings in the URL (or symbols contained between the strings) do not matter, but the request is only blocked if both are present.

For demonstration sake you could do it with something like

Code:

SecRule QUERY_STRING (add_to_wishlist.+add-to-cart|add-to-cart.+add_to_wishlist) "t:lowercase,id:29734,phase:1,deny"

However, I believe this is less efficient for processing with all the regex match.

Modsec has an efficient method for chained rules. If you have a rule with 2 lines, if the first condition isn't met in the request, modsec knows to skip the remaining regex in the rest of the chained conditions. In short, that means it skips the rest of the rule and starts on the next one. In practice I use this to put the most unique info (or least likely to be in a non malicious request) on the 1st line, to maximize processing speed.

 

Sorry, I was working off the posters revised statement:

(I changed some text colour for clarity)

Any which way, all the scenarios are now covered by one or other rule