Post by JNeuhoff » Fri Nov 19, 2021 6:04 pm

Perhaps your 404 page triggers additional requests to retrieve other components of your 404 page. But you should always see an initial 404 responses in your access log.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by JNeuhoff » Wed Nov 24, 2021 10:27 pm

I just changed the original thread title, removing the '[SOLVED' prefix.

Reason for this: We have tried the Bitninja WAF. It repels about 90% or so of the bruteforce attackers' POST requests, but that still leaves too many to slip through to our websites. Some of Bitninja's rules are based on an old Google reCaptcha, and invisible captcha, and/or a honeypot trap. These may be good enough for rejecting simply spambots, but are insufficient for bruteforce attacks. Ours resulted in over a million gray-listed IP addresses in a matter of a few weeks.

Also, the Bitninja caused some 405 errors, especially for Safari web browser users. Safari has known autofill bugs anyway, so server-side honeypot traps often result in false rejections for Safari.

So it's back to square one: A decent WAF is needed here!

BTW.: This simple PHP script in our admin/index.php rejects the bruteforce attackers' POST requests to the /admin quite effectively:

Code: Select all

if ($_SERVER['HTTP_USER_AGENT'] == 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0') {
	header('HTTP/1.0 403 Forbidden');
	exit;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
But such a rule should really be implemented on a firewall level!

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by OSWorX » Wed Nov 24, 2021 11:25 pm

JNeuhoff wrote:
Wed Nov 24, 2021 10:27 pm
..
So it's back to square one: A decent WAF is needed here!
..
As written prior: viewtopic.php?f=179&t=225771#p829883
May cost around 250,- Euro per month (and you should own the server by yourself), this money is worth every Cent.

Because: those stupid script kiddies will never give up.

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Guru Member
Online

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by Zanato » Fri Nov 26, 2021 9:28 pm

Astra offer a firewall for $20/month. I've no affiliation and haven't used them myself. I'm just shopping around and they look good.

https://www.getastra.com/pricing

New member

Posts

Joined
Fri Oct 04, 2013 4:58 am
Location - Dublin, Ireland

Post by EvolveWebHosting » Sat Nov 27, 2021 11:33 am

Zanato wrote:
Fri Nov 26, 2021 9:28 pm
Astra offer a firewall for $20/month. I've no affiliation and haven't used them myself. I'm just shopping around and they look good.

https://www.getastra.com/pricing
Astra is very good and we are partnered with them. $20 / month is if you pay for a year up front. Now through Nov 30th, we are offering 1 year for $179.88 - After Nov 30th, 1 year will be $16.99/month paid Annually ($203.88)

https://www.evolvewebhost.com/security/astra

2 Week FREE Trial of our Shared Hosting plans (DIrectAdmin or cPanel) for new customers
2 Week FREE Trial of Astra Firewall and Malware Scanner
Visit our website for full details and to start your trial today - www.evolvewebhost.com


User avatar
Active Member

Posts

Joined
Fri Mar 27, 2015 11:13 pm
Location - Denver, Colorado, USA

Post by Khal » Wed Jan 12, 2022 1:12 am

@JNeuhoff
BTW.: This simple PHP script in our admin/index.php rejects the bruteforce attackers' POST requests to the /admin quite effectively:
Code: Select all

if ($_SERVER['HTTP_USER_AGENT'] == 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0') {
header('HTTP/1.0 403 Forbidden');
exit;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (empty($_GET)) {
header('HTTP/1.0 403 Forbidden');
exit;
}
}
But such a rule should really be implemented on a firewall level!
I have the BitNinja firewall and have been having hack attempts on Admin and the front-end. Can I just paste that code into my admin/index.php file like that?
What do you mean it has to be implemented on a firewall level?
I have oc 2.0.1.1
Thank you

Active Member

Posts

Joined
Thu May 24, 2012 9:24 pm
Location - Teesside, UK

Post by JNeuhoff » Wed Jan 12, 2022 1:48 am

Yes, just put this script at the beginning of your admin/index.php .

We gave up on Bitninja, it's not up to task with this kind of bruteforce attacks. It relies too much on outdated captchas.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Khal » Wed Jan 12, 2022 2:10 am

Thank you foe getting back to me.
I've added that code- hopefully it will stop some of the attacks.

BTW I meant I have Ninja Firewall, not BitNinja lol
I just added it today so I don't know how well it is performing.

I seem to notice small changes to some pages over a day or two, then the entire website is taken over. This has just started happening recently in the past week or so. But hopefully the firewall and this script will be enough to resolve it. I have also added the latest Google recaptcha 3

Thank you for the help

Active Member

Posts

Joined
Thu May 24, 2012 9:24 pm
Location - Teesside, UK

Post by JNeuhoff » Wed Jan 12, 2022 2:26 am

Just a quick thought: If you use the Ninja Firewall, then you could also add our script to its '.htninja' file. This way, you won't get an inflated server raw access log, because these rules would be on the firewall level now, instead of in the admin/index.php, see this docs.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Khal » Wed Jan 12, 2022 2:51 am

JNeuhoff wrote:
Wed Jan 12, 2022 2:26 am
Just a quick thought: If you use the Ninja Firewall, then you could also add our script to its '.htninja' file. This way, you won't get an inflated server raw access log, because these rules would be on the firewall level now, instead of in the admin/index.php, see this docs.
Sounds good, I'll do that. Thank you!

Active Member

Posts

Joined
Thu May 24, 2012 9:24 pm
Location - Teesside, UK

Post by joeantropy » Mon Jan 24, 2022 7:00 pm

Hi all,

We're seeing a resurgence of this attack on a number of OpenCart websites this morning. If this is happening to you, the attached vQmod file should stop the attackers in their tracks. Tested on OpenCart versions from 2.0.1.1 to 3.0.3.8, but should work on earlier versions as well. You will need vQmod installed to use this - copy the attached file in the vqmod/xml directory as standard.

You can now also download this fix from the OpenCart Marketplace: https://www.opencart.com/index.php?rout ... n_id=43261
Last edited by joeantropy on Mon Jan 24, 2022 8:15 pm, edited 1 time in total.

Newbie

Posts

Joined
Mon Mar 02, 2020 10:19 pm

Post by by mona » Mon Jan 24, 2022 7:16 pm

would not a [404 not found] not be better than a [403 forbidden] ?
They are the types who get encouraged easily after all ..

DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.


https://www.youtube.com/watch?v=zXIxDoCRc84


User avatar
Expert Member

Posts

Joined
Mon Jun 10, 2019 9:31 am

Post by Khal » Mon Jan 24, 2022 7:17 pm

Thank you for that!

Active Member

Posts

Joined
Thu May 24, 2012 9:24 pm
Location - Teesside, UK

Post by ADD Creative » Mon Jan 24, 2022 8:00 pm

You could also do the same in htaccess.

Code: Select all

RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^admin/.*$ - [F]

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by tpcx » Tue Jan 25, 2022 1:21 am

I'm seeing the same kind of attack against our sites. So here's what happened:

1. noticed the sites went unresponsible, and checked the logs, and sure enough, there were loads of login attempts
2. moved admin-folder (should have done this ages ago...)
3. server load still high, since opencart handles the 404-page
4. added apache-rule to deny access to /admin/
5. at this point there was about 80 attempts per second, and apache was completely saturated (at 50 active processes), although still functioning

I have fail2ban already enabled for this, but it couldn't keep up with the attack rates. I resorted to manually extracting all offending ips from the log and blocking them in the firewall, and now things are mostly back to normal again.

- I have banned exactly 5647 IP-addresses
- most of these ips (like 95+%) resolves to ec2-instances att amazon
- It looks like the attack is still ongoing, and has been for the last ~19 hours, at high rates
- I have reported abuse to AWS, but hours has gone by, and I haven't heard from them, except for an automated reply

We had a similar attack a few days ago (January 20 i think), but that time the source-ips were more random (i.e. most of them doesn't resolve to AWS).

Newbie

Posts

Joined
Tue Jan 25, 2022 1:05 am

Post by MaxD » Tue Jan 25, 2022 6:18 am

I have seen this today on few client's shops. Request rate is so high that shops go down.

Here is my one-line solution for any configuration including renamed or password-protected admin folder.

Add this line to the beginning of index.php and admin/index.php:

Code: Select all

if (!empty($_POST) && @$_SERVER['REQUEST_URI'] == '/admin/') exit;

The response code doesn't matter, it seems that the bruteforcer doesn't analyse the answer.
Last edited by MaxD on Tue Jan 25, 2022 11:16 am, edited 1 time in total.

User avatar
Active Member

Posts

Joined
Fri Jul 06, 2012 6:37 pm


Post by EvolveWebHosting » Tue Jan 25, 2022 7:45 am

A quick way to slow this down (if you don't want to add a firewall or other extensive coding) is to add a .htaccess file to the admin folder (if one doesn't already exist) and then inside the file add:
Require ip <your ip address>

All other requests will be givin a 403 error. You can add as many addresses as needed for those who need access to /admin

2 Week FREE Trial of our Shared Hosting plans (DIrectAdmin or cPanel) for new customers
2 Week FREE Trial of Astra Firewall and Malware Scanner
Visit our website for full details and to start your trial today - www.evolvewebhost.com


User avatar
Active Member

Posts

Joined
Fri Mar 27, 2015 11:13 pm
Location - Denver, Colorado, USA

Post by Gilmore » Tue Jan 25, 2022 10:22 am

I have a couple of sites getting hammered! I use Cloudflare and have Under Attack enabled, Bots enabled and have set a firewall block using URI /admin/ running it that way since 3pm yesterday and still getting hit hard.
Unique Visitors
7.51k
Total Requests
1.03M
in 24 hours.

Renamed admin. Added the .htaccess

Code: Select all

RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^admin/.*$ - [F]
and added this fix found here too.

Code: Select all

if ($_SERVER["REQUEST_METHOD"] == "POST" && $_SERVER["REQUEST_URI"] == "/admin/") exit;
*Not showing what me new admin name is!

We'll see how they do over the next hour or so.

A BIG thanks to MaxD and ADD Creative for contributing to the fixes!

Thanks!

Gilmore


User avatar
Active Member

Posts

Joined
Thu Aug 12, 2010 7:33 am

Post by JNeuhoff » Tue Jan 25, 2022 6:19 pm

tpcx wrote:
Tue Jan 25, 2022 1:21 am
- I have banned exactly 5647 IP-addresses
That's nothing, we had over a Million IP-addresses blocked at some stage, via BitNinja, and it still didn't stop it.

As was suggested on this forum thread, add rules to the effect to immediately respond with a 403 or 404 status if it is a POST-request to /admin with empty query string. Do it either in the '.htaccess', or in the 'admin/index.php'. This rule works, but expect the attacks to continue for at least a few weeks, on our sites it lasted for 3 months!

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by joeantropy » Tue Jan 25, 2022 8:28 pm

Update to the above - further analysis shows that this is a brute-force attack rather than a DDoS attack.

We were noticing the number of login attempts for admin panel users named 'admin' were constantly getting maxed out, while all other admin users remained unaffected. Checking the POST data, the attackers are sending username 'admin' and various dictionary words as the password. So it looks like a dictionary attack where they try loads of common passwords in the hopes of finding one that will let them into someone's admin panel.

It is almost certainly a generic attack against any site and not a targeted attack against OpenCart sites in particular, as they're just sending POST requests to /admin/ as a commonly used entry point. This is lucky for OpenCart in that they should never be able to gain access without the 'index.php?route=common/login' at the end, but very bad due to how it handles failed login attempts as detailed earlier in this thread (creates a new session for every attempt, etc).

Our free brute-force and DDoS blocking extension is available on the OpenCart marketplace here: https://www.opencart.com/index.php?rout ... n_id=43261

We'll also be putting up an article on our blog with all our findings so far and more details on this attack - will update this post once it is live.

Newbie

Posts

Joined
Mon Mar 02, 2020 10:19 pm
Who is online

Users browsing this forum: No registered users and 25 guests