SOLVED Block abusive requests to website?

[Kent Brockman]

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!

 

[rpvw]

You could try something like

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

 

[Kent Brockman]

Nope. What I need is a rule to block it when param1 AND param2 are present. Is this possible?

 

[rpvw]

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

 

[fuzzylogic]

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

<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]

@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]

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]

Hello,

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

 

[fuzzylogic]

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...

GET /category/whatever/?add_to_wishlist=12161

and...

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

to do those things.
So I suggest you test.

 

[Kent Brockman]

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]

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:

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).

 

[rpvw]

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:

#!/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

 

[quizknows]

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]

@ quizknows

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

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

 

[quizknows]

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

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.

 

[rpvw]

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

 

[jeffschips]

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:

#!/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.

 

[jeffschips]

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

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]

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]

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:

#!/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:

https://DOMAIN.COM/wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php

I created an executable file /usr/local/csf/bin/csfpre.sh as you wrote with this script:

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