Post by JNeuhoff » Mon Oct 04, 2021 7:42 pm

We have recently came across a new DDoS attacks on some of our clients OpenCart-based websites, resulting in reduced performance and MySQL issues.

All the attacker does is to send simple HTTPS POST requests to /admin , without any query strings. On average 5 requests per second. The raw access log typically contains entries like these:

Code: Select all

....
xxx.xxx.xxx.xxx - - [27/Sep/2021:16:51:14 +0100] "POST /admin/ HTTP/1.1" 200 4016 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
....
The requests come from random fake IP-addresses. Each request causes OpenCart to create a new PHP session and to store the session details into the 'oc_session' database.

We are now repelling these malicious requests with 0 bytes responses and status 403 Forbidden, with this script at the beginning of the admin/index.php:

Code: Select all

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
If anyone has a better solution, ideally preventing these malicious requests on the network level, let me know!
Last edited by JNeuhoff on Tue Jan 25, 2022 8:36 pm, edited 3 times in total.

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Johnathan » Mon Oct 04, 2021 9:11 pm

An htpasswd on that directory would also help.

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by straightlight » Mon Oct 04, 2021 9:13 pm

JNeuhoff wrote:
Mon Oct 04, 2021 7:42 pm
We have recently came across a new DDoS attacks on some of our clients OpenCart-based websites, resulting in reduced performance and MySQL issues.

All the attacker does is to send simple HTTPS POST requests to /admin , without any query strings. On average 5 requests per second. The raw access log typically contains entries like these:

Code: Select all

....
xxx.xxx.xxx.xxx - - [27/Sep/2021:16:51:14 +0100] "POST /admin/ HTTP/1.1" 200 4016 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
....
The requests come from random fake IP-addresses. Each request causes OpenCart to create a new PHP session and to store the session details into the 'oc_session' database.

We are now repelling these malicious requests with 0 bytes responses and status 403 Forbidden, with this script at the beginning of the admin/index.php:

Code: Select all

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
If anyone has a better solution, ideally preventing these malicious requests on the network level, let me know!
As per the readme file of the Opencart Github repository, better to follow these instructions where these hack attempts should rather be posted for further investigation ...

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by OSWorX » Mon Oct 04, 2021 10:03 pm

straightlight wrote:
Mon Oct 04, 2021 9:13 pm
As per the readme file of the Opencart Github repository, better to follow these instructions where these hack attempts should rather be posted for further investigation ...
1. how many users read that?
2. how many users are on GitHub?
3. "per the readme" is good: https://github.com/opencart/opencart/bl ... /README.md (cannot detect any about such ..)

The only about similiar:
If you would like to report a serious security bug please PM an OpenCart moderator/administrator on the forum. Please do not report concept/ideas/unproven security flaws - all security reports are taken seriously but you must include the EXACT details steps to reproduce it. Please DO NOT post security flaws in a public location.
And this is not a "security bug" - moreover a 'usual' on a daily base seen behaviour of some script kiddies.

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


User avatar
Guru Member

Posts

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

Post by OSWorX » Mon Oct 04, 2021 10:04 pm

Johnathan wrote:
Mon Oct 04, 2021 9:11 pm
An htpasswd on that directory would also help.
As long as the system does not provide a simple function to create such from the backend, doing so is for too many a "miracle".

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


User avatar
Guru Member

Posts

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

Post by JNeuhoff » Mon Oct 04, 2021 10:22 pm

And this is not a "security bug" -
Correct, there were no security issues, just a slowdown in performance. We are now looking for a better web application firewall.

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Mon Oct 04, 2021 11:45 pm

OSWorX wrote:
Mon Oct 04, 2021 10:03 pm
straightlight wrote:
Mon Oct 04, 2021 9:13 pm
As per the readme file of the Opencart Github repository, better to follow these instructions where these hack attempts should rather be posted for further investigation ...
1. how many users read that?
2. how many users are on GitHub?
3. "per the readme" is good: https://github.com/opencart/opencart/bl ... /README.md (cannot detect any about such ..)

The only about similiar:
If you would like to report a serious security bug please PM an OpenCart moderator/administrator on the forum. Please do not report concept/ideas/unproven security flaws - all security reports are taken seriously but you must include the EXACT details steps to reproduce it. Please DO NOT post security flaws in a public location.
And this is not a "security bug" - moreover a 'usual' on a daily base seen behaviour of some script kiddies.
1. Which is why the forum can still guide the users via this readme. The mount of registered users is not required to read the README file.
2. Not important since the file can be accessed publicly (with guidance, if users don't know)
3. The portion of that README is the right location to what I was referring

As for all security reports, according to the first post, exact details were posted and asked for suggestions / proposal for rectification. In addition, it also state NOT to post security flaws in a public location. My reply on the above did simply suggest to submit this DDoS attack tactic by following the README since DDoS attacks can still be used as potential security flaws; may be not in Opencart specifically but not explicit either.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by straightlight » Mon Oct 04, 2021 11:46 pm

JNeuhoff wrote:
Mon Oct 04, 2021 10:22 pm
And this is not a "security bug" -
Correct, there were no security issues, just a slowdown in performance. We are now looking for a better web application firewall.
Might be a good idea here, however, but can still be found a security issues (false / positive probably at times).

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Tue Oct 05, 2021 12:06 am

I am happy to post it on github if I ever find a solution for this simple DDoS attack. However, it almost certainly won't be possible to do it within the OpenCart source code. It's more about preventing malicious DDoS requests reaching an OpenCart-based website in the first place!

One thing is for sure though: If it hasn't yet been in the maintenance branch, there needs to be mechanism to prevent the 'oc_session' DB table from growing like crazy. I have my own OCmod XML bugfix scripts for the latter for OC 3.0.20, I'll have to check whether there is a solution for this now implemented in the maintenance branch.

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by JNeuhoff » Tue Oct 05, 2021 12:51 am

An htpasswd on that directory would also help.
How so? The DDoS doesn't care what response it gets from the server, the DDoS just keeps on hammering the website with fake requests.

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Johnathan » Tue Oct 05, 2021 5:07 am

JNeuhoff wrote:
Tue Oct 05, 2021 12:51 am
An htpasswd on that directory would also help.
How so? The DDoS doesn't care what response it gets from the server, the DDoS just keeps on hammering the website with fake requests.
My thought was that it would be similar to giving a 403 response like you suggested, in case they figure out they can just use "admin/index.php?route=common/login" instead (which would negate your fix). That being said, I'm not sure that will actually help with a DDoS attack, so if I'm wrong about how htpasswds work feel free to let me know. If they're actually trying to brute force your admin login (which I assume they are) then an htpasswd would help with that as well, but if they're just trying to DDoS you then you're right that it might not be very helpful.

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by OSWorX » Wed Oct 06, 2021 2:23 pm

Johnathan wrote:
Tue Oct 05, 2021 5:07 am
.. That being said, I'm not sure that will actually help with a DDoS attack, ..
What really helps, is a hardware firewall (e.g. from fortigate).
Costs a lot per month, but worth any cent.
We have currently over 100.000 attacks per day, sometimes much more.
The firewall blocks all of them.

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


User avatar
Guru Member

Posts

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

Post by JNeuhoff » Wed Oct 06, 2021 7:29 pm

@OSWorX: Yes, I think you are right. A good firewall or WAF is the correct approach. Up until yesterday, we had over 400 000 attacking requests per day on several websites. We ended up using Bitninja which appears to deflect almost all of them. I'll mark this forum thread as [SOLVED].

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Hillbilly57 » Fri Oct 08, 2021 9:17 am

Thank you JNeuhoff! Same thing happened to me and your script was a godsend! Now to harden my VPS...

A hillbilly in America


Newbie

Posts

Joined
Thu Dec 13, 2018 11:27 am

Post by d3z1gnr » Fri Oct 08, 2021 12:56 pm

JNeuhoff wrote:
Wed Oct 06, 2021 7:29 pm
@OSWorX: Yes, I think you are right. A good firewall or WAF is the correct approach. Up until yesterday, we had over 400 000 attacking requests per day on several websites. We ended up using Bitninja which appears to deflect almost all of them. I'll mark this forum thread as [SOLVED].
I think this is brute force more than ddos? We currently getting same POST traffic to admin, your wee bit of script for the index has actually helped a lot thanks :)

Mike Little
Director / Developer / Makes the coffee
Creative Digital Limited
http://www.creativedigital.co.nz


User avatar
Active Member

Posts

Joined
Mon Jan 18, 2010 2:59 pm
Location - Auckland, New Zealand

Post by d3z1gnr » Sat Oct 09, 2021 5:37 am

Actually sorry, the brute force attack was against our customer login - not admin.

Out of interest, we used Cloudflare's we are under attack mode for the admin directory and it worked an absolute treat. Complete shut down.

Mike Little
Director / Developer / Makes the coffee
Creative Digital Limited
http://www.creativedigital.co.nz


User avatar
Active Member

Posts

Joined
Mon Jan 18, 2010 2:59 pm
Location - Auckland, New Zealand

Post by messor » Fri Nov 05, 2021 3:49 am

You can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor

User avatar
Newbie

Posts

Joined
Thu Dec 17, 2020 10:00 pm
Location - USA, Seychellesm

Post by jrr » Tue Nov 16, 2021 3:51 am

JNeuhoff wrote:
Mon Oct 04, 2021 7:42 pm
We have recently came across a new DDoS attacks on some of our clients OpenCart-based websites, resulting in reduced performance and MySQL issues.

All the attacker does is to send simple HTTPS POST requests to /admin , without any query strings. On average 5 requests per second. The raw access log typically contains entries like these:

...

If anyone has a better solution, ideally preventing these malicious requests on the network level, let me know!
I'm not sure if this is a better solution, but I have my actual 'admin' directory renamed and hidden, and an empty directory named admin for the annoying people to try and find. Seems to work.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by JNeuhoff » Thu Nov 18, 2021 5:42 pm

I'm not sure if this is a better solution, but I have my actual 'admin' directory renamed and hidden, and an empty directory named admin for the annoying people to try and find. Seems to work.
Yes, that will work, too. The server will then respond with standard 404 messages. However, you'll still have an inflated raw access log where all the POST requests coming from the attacker are included in there, too.

Hence, solutions based on a firewall are still the best approach.

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


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Zanato » Fri Nov 19, 2021 5:40 pm

JNeuhoff wrote:
Thu Nov 18, 2021 5:42 pm
I'm not sure if this is a better solution, but I have my actual 'admin' directory renamed and hidden
Yes, that will work, too. The server will then respond with standard 404 messages.
I've renamed my Admin directory successfully and visiting /admin on a browser shows a 404 but the logs still show a 200 HTTP response. How come?

New member

Posts

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

Users browsing this forum: No registered users and 23 guests