SOLVED Block abusive requests to website?

Kent Brockman

Well-Known Member
PartnerNOC
Jan 20, 2008
1,257
60
178
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
Hello guys, I'm not sure if this is the right place to ask, but I bet you can help me solving this. I need some ideas please

Increasingly, I’m noticing waves of requests coming to one customer’s store with the following format:
example.com.com/category/whatever/?add_to_wishlist=12161&add-to-cart=12183

This produce a high load, overloading the server. I’ve already looked at the logs and these requests come from hundreds of distinct IPs, from lots of countries which definitely are not the target of the store. All at the same time. So it must be a botnet. I need to block it.

So... How can I block this bad behaviour using .htaccess rules to deny a request when the TWO exact parameters concur in the same requested URL? Do you know how to accomplish this?

Thanks in advance!
 
Last edited by a moderator:

rpvw

Well-Known Member
Jul 18, 2013
1,101
458
113
UK
cPanel Access Level
Root Administrator
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>
 

rpvw

Well-Known Member
Jul 18, 2013
1,101
458
113
UK
cPanel Access Level
Root Administrator
I wonder if you might get less server load if you used a ModSec rule ?
 

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
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.
 

Kent Brockman

Well-Known Member
PartnerNOC
Jan 20, 2008
1,257
60
178
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
@rpvw: I do use Mod Security rules in all the servers, but given this is not an attack to the same URLs and is always coming from distinct IPs, looks to it like just high traffic.


@fuzzylogic: I'll try your code and let you know if it works. In the meantime, I analyzed hundreds of IPs and discovered all of them belong to OVH France, so blocking a dozen of their IP ranges in CSF helped minimize the load. Although, there is a minor number of IPs that will only be blocked using rules like yours in .htaccess
 

Kent Brockman

Well-Known Member
PartnerNOC
Jan 20, 2008
1,257
60
178
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
UPDATE:
@fuzzylogic: your rules worked like a charm. Ultimately I had to change the [NC] to [NC,OR] because the botnet automatically changed its behaviour and switched to use one or the other parameter, LOL. Now, both are blocked and the site is stable, and a bit more secure (by now).

Thanks!
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
Hello,

I'm glad to see those rules helped. Thank you for updating us with the outcome.
 

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
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.
 

Kent Brockman

Well-Known Member
PartnerNOC
Jan 20, 2008
1,257
60
178
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
Yes, I've thought of it and tested it. The local browsing of the site won't never use those parameters as these are used and recommended only to trigger the add-to-cart/wishlist remotely or from within a link in the content, which is never used in this case. So it's safe to block those kind of requests ;)
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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).
 
Last edited by a moderator:

rpvw

Well-Known Member
Jul 18, 2013
1,101
458
113
UK
cPanel Access Level
Root Administrator
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
 
  • Like
Reactions: Shood and quizknows

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 

rpvw

Well-Known Member
Jul 18, 2013
1,101
458
113
UK
cPanel Access Level
Root Administrator
@ 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"
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 
Last edited:

rpvw

Well-Known Member
Jul 18, 2013
1,101
458
113
UK
cPanel Access Level
Root Administrator
Sorry, I was working off the posters revised statement:

UPDATE:
@fuzzylogic: your rules worked like a charm. Ultimately I had to change the [NC] to [NC,OR] because the botnet automatically changed its behaviour and switched to use one or the other parameter, LOL. Now, both are blocked and the site is stable, and a bit more secure (by now).

Thanks!
(I changed some text colour for clarity)

Any which way, all the scenarios are now covered by one or other rule :-D
 
Last edited:
  • Like
Reactions: quizknows

jeffschips

Well-Known Member
Jun 5, 2016
159
13
18
new york
cPanel Access Level
Root Administrator
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
Hi, I'm trying:
iptables -A INPUT -p tcp --match multiport --dport 80,443 -m string --string 'wp-login’ --algo bm -j DROP

but no joy. Yes, I get a 403 error code, but nothing in messages of my centos 7 messages log shows a block of any kind. I'm originating form an ip address that is not whitelisted in csf.

would like ot make this work outside mod_sec and prefer a firewall rule. Any suggestions much appreciated.
 
Last edited by a moderator:

jeffschips

Well-Known Member
Jun 5, 2016
159
13
18
new york
cPanel Access Level
Root Administrator
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 :-D
As well, I've seen suggestions to use /etc/csf/csfpre.sh rather than /usr/local/csf/bin/csfpre.sh, but regardless both ways do not block anything for me, just produce 403 error codes whereas I think it's supposed to time out, or at least show a block in the message logs, which it doesn't.
 

WebJIVE

Well-Known Member
Sep 30, 2007
72
7
58
As well, I've seen suggestions to use /etc/csf/csfpre.sh rather than /usr/local/csf/bin/csfpre.sh, but regardless both ways do not block anything for me, just produce 403 error codes whereas I think it's supposed to time out, or at least show a block in the message logs, which it doesn't.
What you can do is set CSF to watch logs for excessive 403's and temp block the IP's. What we do for a lot of rules where you can tell a bot is scraping or scanning.
 

Shood

Well-Known Member
Aug 12, 2015
84
17
133
Middle East
cPanel Access Level
Root Administrator
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
Hello @rpvw
I got a lot of attack reports via CXS watch about trying to upload a script in this form:

I created an executable file /usr/local/csf/bin/csfpre.sh as you wrote with this script:
Code:
iptables -A INPUT -p tcp --match multiport --dport 80,443 -m string --string 'wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php' --algo bm -j DROP
Also I moved the csfpre.sh file to /etc/csf/csfpre.sh
that didn't work
Someone adviced me that this may doesn't works because the request is for HTTPS
I appreciate any suggestion
Regards
 
  • Like
Reactions: Kent Brockman