Block abusive requests to website?
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!
-
You could try something like RewriteEngine On RewriteCond %{QUERY_STRING} ^.*(12161=&add-to-cart=12183).* [NC] RewriteRule ^(.*)$ - [F,L]0 -
Nope. What I need is a rule to block it when param1 AND param2 are present. Is this possible? 0 -
I wonder if you might get less server load if you used a ModSec rule ? 0 -
This htaccess redirect should deny (status 403) any GET request with BOTH add_to_wishlist AND add-to-cart QUERY_STRING ARGS. RewriteEngine On RewriteCond %{QUERY_STRING} (?:^|&)add_to_wishlist= [NC] RewriteCond %{QUERY_STRING} (?:^|&)add-to-cart= [NC] RewriteRule ^(.*) - [F,L]
It worked as designed when I tested it.0 -
@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 0 -
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! 0 -
Hello, I'm glad to see those rules helped. Thank you for updating us with the outcome. 0 -
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.0 -
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 ;) 0 -
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).0 -
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 CSF0 -
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. 0 -
@ 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"0 -
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.0 -
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 :-D0 -
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.0 -
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.0 -
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:0 -
I too am in search of a fix for this. I presume the iptables rule you adapted is for a query string on the URL and not the filename itself however I am not familiar with the syntax.
Hi @pyrographics I blocked it via ModSecurity Home "Security Center "ModSecurity" Tools "Rules List, Add ruleSecRule REQUEST_URI "@contains YOUR-URL" "id:1001,phase:1,t:lowercase,log,deny,msg:'Warning, Access Denied'"
ModSecurity - version 30 -
Hi @pyrographics I blocked it via ModSecurity Home "Security Center "ModSecurity" Tools "Rules List, Add rule
SecRule REQUEST_URI "@contains YOUR-URL" "id:1001,phase:1,t:lowercase,log,deny,msg:'Warning, Access Denied'"
ModSecurity - version 3
Ok, that seems to work for a single URL... but what if I have a list of about 500+ files that hackers/brute force attackers are scanning my site for (they keep trying to access files like x.php, shell.php, z.php, etc) that I want to set the ModSec rule for to 1) block them from accessing the file, even if it exists and 2) add their IP to blacklist in firewall on first attempt at this so they are blocked the second they try to access any of these 500+ blacklisted files in whatever list / wherever that may be stored, so they never get past the 1st attempt and through the list? Any ideas? I'm willing to pay for a working solution to the above as well, if there is someone who knows how to implement it efficiently.0
Please sign in to leave a comment.
Comments
21 comments