7G Addon: Stop Aggressive Scanning for Uploads-Related Targets
Around the end of December 2019 and then now well into January of 2020, I’m seeing a massive spike in aggressive malicious scanning for uploads-related targets. In particular, there are massive numbers of requests for URL targets involving uploadify, plupload, and similar. Typical scans hitting upwards of 30K–50K requests per attack. Just relentless exploit scanning on steroids.
Getting hit with 30K–50K scans across all domains, all web hosts. So to minimize the drain on server resources, I put together a mini firewall to block them.
.well-known requests (among other things), which are required for sites using SSL/HTTPS Let’s Encrypt certificates. So if your site uses Let’s Encrypt, either skip this technique or remove any lines that block .well-known requests.Stop the madness
Thousands of redundant, exploit-seeking requests hitting your server every minute is a bad thing, and should be stopped at the server level asap. Save those precious resources for legitimate visitors. To help with this, I developed the following Apache/.htaccess ruleset. It straight up blocks about 90% of the latest uploads-related malicious scanning. Here it is, short & sweet:
# 7G Addon: Stop Aggressive Scanning for Uploads-Related Targets
# https://perishablepress.com/stop-aggressive-scanning-uploads/
<IfModule mod_rewrite.c>
# RewriteCond %{REQUEST_URI} /php(unit)?/ [NC,OR]
# RewriteCond %{REQUEST_URI} \.(aspx?|env|git(ignore)?|phtml|rar|well-known) [NC,OR]
# RewriteCond %{REQUEST_URI} /(cms|control_panel|dashboard|home_url=|lr-admin|manager|panel|staff|webadmin) [NC,OR]
# RewriteCond %{REQUEST_URI} /(adm(in)?|blog|cache|checkout|controlpanel|ecommerce|export|magento(-1|web)?|market(place)?|mg|onli(n|k)e|orders?|shop|tmplconnector|uxm|web?store)/ [NC,OR]
RewriteCond %{REQUEST_URI} (_timthumb_|timthumb.php) [NC,OR]
RewriteCond %{REQUEST_URI} /(install|wp-config|xmlrpc)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(uploadify|uploadbg|up__uzegp)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(comm\.js|mysql-date-function|simplebootadmin|vuln\.htm|www\.root\.) [NC,OR]
RewriteCond %{REQUEST_URI} /(admin-uploadify|fileupload|jquery-file-upload|upload_file|upload|uploadify|webforms)/ [NC,OR]
RewriteCond %{REQUEST_URI} /(ajax_pluginconf|apikey|connector(.minimal)?|eval-stdin|f0x|login|router|setup-config|sssp|vuln|xattacker)\.php [NC]
RewriteRule .* - [F,L]
</IfModule>I’ve added this mini firewall to most all of my sites. The result? It stops about 90% of those massive uploads attacks at the server level. So downstream resources like PHP and MySQL aren’t called, thus saving tons of memory, bandwidth, and other server resources. It is proving to be very effective, at least on my own Apache-powered sites. Of course, your mileage may vary.
Changelog
- 2020/01/28 — removed
plupload - 2020/02/02 — removed
upload.php - 2020/08/13 — removed
clipboard.min.js
About the code
What’s happening with the code? I’m glad you asked. Here is an overview:
- First, check if
mod_rewriteis enabled via<IfModule> - Next there are four lines/conditions that are disabled (commented out)
- Then there are six lines/conditions that are enabled
- Next, any matching requests are denied access via 403 forbidden status (via the
RewriteRule) - Lastly, close the opening
<IfModule>container
So now the interesting bits.
The four commented-out lines (conditions) are there for your consideration. Each or all of these four lines may be enabled only IF you are sure that none of the matching patterns could block any legit requests on your site. For example, I leave the first line disabled because otherwise it would block requests for my PHP category. If you look at that linked URL, you will notice it includes /php/, which is one of the patterns blocked in that first commented-out rule. The four rules are very powerful and block a LOT of bad requests, but they also have the potential to produce false positives. So you want to be extra careful before enabling.
Then for the six active conditions. These lines alone effectively stop most of the aggressive uploads-related scanning. If you examine the patterns (regex) in the rules, you will find that many of the targeted keywords and phrases are matched and blocked. Even though I am running these conditions without issue on my own WordPress-powered and regular/vanilla HTML sites, it is recommended to test thoroughly and report any false positives or bugs, etc.
For more details about how the above mini firewall works, check out some of the related posts in the nG tag archive. Tons of useful/relevant information and other techniques are yours to discover.
The worst part
The worst part of such aggressive scanning is the redundancy. The idiots running these attacks are doing it “brute force” style with hundreds or even thousands of identical/repeat requests for the same targets. This is wasteful for everyone, including the attackers. Repeatedly requesting the same set of URLs over and over and over again.. you’re just wasting your own resources (CPU, RAM, bandwidth, energy, time, etc.). Especially when the requests are only a few minutes or even seconds apart. Why don’t you morons try remembering the responses you’re getting from your target servers. Would save you TONS of time and resources, especially when cranking out 30,000 to 50,000 or more requests per scan. Seriously. At least act like you’ve got a clue and aren’t a complete waste of human existence.
</rant>
19 responses to “7G Addon: Stop Aggressive Scanning for Uploads-Related Targets”
Hi Jeff, I dayly check my apache log files, and add patterns in the referrer, URI and UA blocks of yout 7G-Firwall.
Your 7G concept works perfect and I am very satisfied.
And I also raise my question, why are these stupid fools not able to check the 403 errors they get back and save power for theis servers as well by eliminating those useless requests.
Regards Bernd
Thanks Bernd, I appreciate the great feedback.
Jeff, I just observe something making me suspicous. In my server log I have this entry, soemone klicked on my Name above which is a link to my website:
We see the right referrer from this/your page, but the User Agent is empty. Is this a Problem related to your site or to the browser of the visitor? Therefor he got a 403 Error from my server (I check against empty UA, additionally I had by fault your URL perishable in my exclusion list for referrers. But my question is related to the empty UserAgent.
I just klicked on my namelink above and I am getting this log entry, which is correct
It is my own Browser’s UserAgent, but the referrer looks different, only the main URL with no pageURL
For the request data shared in your first comment, it looks like maybe a bot or savvy user, reporting a blank/empty user agent. This is typical on the Web these days, which is why I don’t recommend blocking blank UAs in general. You just end up with a lot of false positives. Most of which happen without notice, which means possible loss of legit traffic.
Sounds the same on my end.
My access logs seem to have grown over the last several months. – Somewhere in the neighborhood of 2 – 3 MB in size – in ONE month! And I don’t get very many visits to it yet anyway.
So I have also been keeping up on my firewalling rules and fine-tuning my custom firewall app.
– It’s a never ending process.
Also, many of the alternative news blogs have been getting pummeled, as I have been told through an email conversation yesterday. Seems like there is one big “bullseye” on American sites these days.
I would also HIGHLY recommend you check what they are trying with the “HTTP_HOST” header!
That’s why I have been using something like:
( This is only a concept. Your needs may vary. )
As one of my mainstays.
– Jim S.
Interesting. What is it you are seeing with HTTP_HOST ?
Sometimes I will find attempts at trying to inject “non-standard” characters (like :0x0d, and other non-printables).
Though they should never make it to my server, it seems that certain data sometimes “slip through”.
I have also had to pay very close attention to attempts at using non-standard “http-methods” as well as embedded code within the “user-agent” field.
One filter for user-agents I had to employ (a couple of years ago):
SetEnvIfNoCase User-Agent [^0-9a-z;:.,/s()+_'@-]+|('(.+)') bad_bot_head=BAD-USER-AGENT-"$0"I tested the bad user-agent I found in the log, and it was severely messing up page accesses through the resultant poisoned “referer”! ( The reason I also started checking for contents within single-quotes too. ) – Of course, I had to make an exception for Let’s Encrypts unusual user-agent string.
It’s amazing how creative some of these “kiddies” have gotten with their attempts! – Some of the “suspect PHP files” you mentioned you started seeing attempts for, I was already seeing these exploit attempts several years ago. There again, that all depends on what type and service you have your hosting through. Mine is on a VPS and without “tunneling” through a CDN (because I can not yet afford a full CDN package yet).
So I DO see a lot of what many regular web-hosting services already filter out.
Running a VPS or dedicated server hosted site does mean a bit of extra work, but this has also served me very well as far as learning a LOT about “hard-core” server security, and securing web-apps.
So, becoming a solid expert on htaccess files and other firewalling techniques becomes very important. So thank you for the great suggestions, techniques, and insights. A lot of what started me on my “journey” towards better security was from YOUR blog, askapache.com (GREAT SITE!), and a few other blogs devoted to firewalls (like corz.org – “Antihammer”).
I hope to get to working on my own e-book for hard-core server-side and web security very soon. I would definitely invite some of your insights and critiques to it. Basically, I want to do my “public service” part of contributing to a “more-secure internet”.
I will check out your 7G firewall shortly, BTW.
– Jim S.
It’s funny that you are planning a book on security. I sent you an email a couple/few weeks ago asking if you wanted to co-author with me on a security book that I am planning. Never got a reply though, so I guess we’ll be competing in the same book arena..? Either way, thanks again for the great comments on my posts, really great to hear your ideas. Cheers.
Oh?
I never received that email.
I keep telling Yahoo that emails from you are NOT spam, and it seems that your emails and other perfectly valid emails STILL get sent either to “spam” or the “trash” folder!
I guess it’s time I see about moving myself over to ProtonMail then. Wonder how many other important emails I have been missing? ? ?
– Jim S.
Thanks for this update Jeff….I appreciate your continued efforts….When I purchased your book and other products I made a wise choice……
This latest piece for 7G had one glitch with the Short-Pixel plugin…..3rd line of code in the 2nd part
RewriteCond %{REQUEST_URI} /(upload|uploadify|uploadbg|up__uzegp).php [NC,OR]blocked access to any Media Library functions. I removed it and it is working fine……courtney
Thanks Courtney, I appreciate the good feedback and also report about the Short-Pixel plugin. Cheers.
I don’t know if it is part of WordPress Core, Gutenburg, or some other plugin we have, but when I tested these on both of our main sites they broke post editing and setting of the feature image. Maybe more, but I fixed it before finding more issues. :)
The part that affected us was the inclusion of ‘plupload’. After taking that out, everything seems to be working fine.
Yeah I found the same thing yesterday, updating the code now. Thanks for reporting Steve.
Hi Jeff
Thank you for this code. Will try it.
Hi Jeff,
Been testing your 7g firewall and this add-on, we noticed in our server logs an attacker hitting our website just over 1000 requests in a space of a 1 minute period. Your 7g firewall just added a 403 response to every single request the attacker made. Is there a way we could just break the connection and stop them doing a brute force attack. Your 7g firewall replied to every single request and returned a 403, but used up a lot of cpu power to return over 1000 403 responses to a single ip address hitting our website with adminer attack.
Yeah Apache/.htaccess can only respond to requests, just part of how it works. If a request comes in, Apache must respond somehow. What you are describing is a service such as Cloudflare or similar, where requests are checked and vetted before allowed (or not allowed) access to the server. Btw, responding with a 403 (or similar) status requires far fewer server resources than responding with 200 status and loading up PHP, MySQL, etc. for each request.
No problems with Gutenberg anymore,Jeff ,after removing upload.php!
Thanks a bunch!
Yeah that was removed awhile ago, check the changelog in the post and make sure to grab the latest version. Cheers!