Page 3 of 5
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Tue Jan 25, 2022 8:46 pm
by JNeuhoff
Further to this: Though the intent is that of a bruteforce attempt, it also has the effect of a DDoS attack because it quickly creates thousands of session entries in the 'oc_session' DB table, causing the OpenCart-based web server to slow down and eventually to become non-responsive. I have changed the forum thread title accordingly.
Also, unless the attacker has changed his script, according to our own past observations he also uses different randomly created user names, not only 'admin', as well as randomly generated passwords.
The good news is that, even if in the extremely unlikely event of using a correct user/password, the VQmod XML script from antropy, or our suggested modification of the 'admin/index.php', would still repel this attacker!
It's just simply a waste of network resources for everyone involved in this.
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Wed Jan 26, 2022 8:49 am
by pipoy
Thank you @paulfeakins for relaying me to this thread.
I didnt actually read the whole thing. But reading this now, I am partially relieved that the attack didnt happen just to my friend's website.
We thought we are being hacked by a competitor.
If only I saw this thread earlier, I wouldnt have a day and a half troubleshooting.
I have 6 Opencart websites including I manage for a friend. 5 of them have hidden admin. 1 of them does was not and the attack only happened to it.
So hiding the admin helps.
But I am happy the community is doing something about this.
Re: Warning: DDoS against OpenCart based websites
Posted: Mon Feb 07, 2022 1:12 pm
by tiredman
JNeuhoff wrote: ↑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!
The above code didn't work for me... after changing the 'HTTP_USER_AGENT' string. I had a similar attack on Friday, and it increased the access log by 10MB/ hr. Here's a sample of my logs:
Code: Select all
218.76.202.167 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.213
195.87.182.10 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10030 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.715
94.139.170.82 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.054
8.142.35.42 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10034 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.705
113.20.31.19 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10029 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.683
47.243.135.104 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.677
It started to slowly diminish after isolating the IPs into a banned table for the firewall to handle. My usual dashboard "PEOPLE ONLINE" is about 150, that time it went to 2500, and I even saw 2800.
It has since stopped. In order to buy some time, and because I don't have a lot of customer logins in a day, I
temporarily added a line in catalog/controller/account/login.php just under the 'validate' function. I'm not sure what the implications are except transfer the attacker back to itself, but I noticed that it stopped very quickly.
Code: Select all
protected function validate() {
exit(header("Location: http://" . strval($_SERVER['REMOTE_ADDR'])));
I think the long term solution is to ban the IPs using the firewall.
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Mon Feb 07, 2022 7:50 pm
by JNeuhoff
tiredman : This is a different bruteforce attack targeting the frontend account/login. What exact POST requests did you get (query params, query string)?
I am thinking about adding some protection for these kinds of bruteforce attackers to our SpamBot Buster, shouldn't be too hard because these bruteforce POST requests usually don't involve keyboard/mouse/touch events, unlike with genuine human users.
I like your idea of transferring the attacker back to itself
Re: Warning: DDoS against OpenCart based websites
Posted: Mon Feb 07, 2022 8:38 pm
by ADD Creative
tiredman wrote: ↑Mon Feb 07, 2022 1:12 pm
The above code didn't work for me... after changing the 'HTTP_USER_AGENT' string. I had a similar attack on Friday, and it increased the access log by 10MB/ hr. Here's a sample of my logs:
Code: Select all
218.76.202.167 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.213
195.87.182.10 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10030 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.715
94.139.170.82 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.054
8.142.35.42 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10034 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.705
113.20.31.19 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10029 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.683
47.243.135.104 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.677
It started to slowly diminish after isolating the IPs into a banned table for the firewall to handle. My usual dashboard "PEOPLE ONLINE" is about 150, that time it went to 2500, and I even saw 2800.
It has since stopped. In order to buy some time, and because I don't have a lot of customer logins in a day, I
temporarily added a line in catalog/controller/account/login.php just under the 'validate' function. I'm not sure what the implications are except transfer the attacker back to itself, but I noticed that it stopped very quickly.
Code: Select all
protected function validate() {
exit(header("Location: http://" . strval($_SERVER['REMOTE_ADDR'])));
I think the long term solution is to ban the IPs using the firewall.
A firewall would be a long term solution. However, baning by IP address wouldn't. These these types of brute force attempts usually come from multiple compromised addresses that change all the time.
If the IP addresses you access the admin from doesn't change it is best to add an allow list and ban all others.
One short term solution is a more general ban for old user agents (or even an allow list) in htaccess. Most bots seem to pretend to be older versions of web browsers. So you can use something like the code below in htaccess.
Code: Select all
SetEnvIfNoCase User-Agent "^.*Chrome/[1-8][0-9]\..*$" bad_bot
SetEnvIfNoCase User-Agent "^.*Firefox/[1-8][0-9]\..*$" bad_bot
Deny from env=bad_bot
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Mon Feb 07, 2022 10:25 pm
by tiredman
The store is running off on a Nginx web server. It doesn't have .htaccess file.
This time the operator is acting as a customer trying to log in, in the hope of scoring an entry through a customer's weak credentials. I kinda think he is polling for some sort of success response, and not expecting a redirect to itself. All the IPs are proxy IPs, so the machines are innocent cover-ups for it, and when enough comes back to hit itself, they'll sooner than later realize that they have been used... and he can't risk that happening – just my guess, what do I know.
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Mon Feb 07, 2022 10:41 pm
by tiredman
JNeuhoff wrote: ↑Mon Feb 07, 2022 7:50 pm
tiredman : This is a different bruteforce attack targeting the frontend account/login. What exact POST requests did you get (query params, query string)?
I am thinking about adding some protection for these kinds of bruteforce attackers to our SpamBot Buster, shouldn't be too hard because these bruteforce POST requests usually don't involve keyboard/mouse/touch events, unlike with genuine human users.
I like your idea of transferring the attacker back to itself
I wished I had harvested the POST body request, but did not... I'm not sure if the database logs them. I did not check. The attacks are so fast that it crashed the php-fpm service. I was alerted only when Monit restarted it and notified me.
I'm halfway through it now. It has to do with geo-locating the IP addresses. This
https://www.ipqualityscore.com/ will be it for me.
Re: Warning: DDoS against OpenCart based websites
Posted: Sat Feb 12, 2022 11:30 pm
by khnaz35
MaxD wrote: ↑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.
This will work if the request is empty
Re: Warning: DDoS against OpenCart based websites
Posted: Sun Feb 13, 2022 12:14 am
by khnaz35
Hi @OSWorX ,
I send you PM have a look into it.
Thanks in advance
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Sun Feb 13, 2022 12:46 am
by EvolveWebHosting
You're going to pull all of your hair out trying to manually keep up with the attackers! They're very clever and very fast.
Re: Warning: DDoS against OpenCart based websites
Posted: Sun Feb 13, 2022 1:09 am
by OSWorX
khnaz35 wrote: ↑Sun Feb 13, 2022 12:14 am
Hi @OSWorX ,
I send you PM have a look into it.
Thanks in advance
Read my answer there ..
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Sun Feb 20, 2022 9:03 pm
by khnaz35
Update on this thread regarding recent attacks on Open-cart base websites. I have face the one and sharing my solutions to the follow community as well.
Most of us we are all aware of the DDOS attack on admin is common where the attacker/stress send million of empty get requests on the admin url but this time I face posit of it on the front end.
Attacker used legals method to crawl website/bots but illegal way and the site went crashing because all the resources we exhausted during the attack.
When site went crash the front end was throwing the error
Code: Select all
Fatal error: Uncaught Exception: Error: Could not make a database link using _____________________@localhost! in /home/xyz/public_html/system/library/db/mysqli.php:19 Stack trace: #0 /home/xyz/public_html/system/library/db.php(31): DB\MySQLi->__construct('localhost', 'abcd', 'efgh'ijkl, '3306') #1 /home/xyz/public_html/system/framework.php(80): DB->__construct('mysqli', 'localhost', ...................thrown in /home/xyz/public_html/system/library/db/mysqli.php on line 19
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.
mistake: error_log setting was kept on from the php.ini
We do use cloud flare for our website once notice the attack haded to the cloudflare and start implementing the rules.
- 1.Change the ip of my website.
2. Proxy my ip from cloudflare.
3. Buy the pro plan in cloudflare
4. Added the code in admin index.php and index.php
5.Block all the country on base of cloudflare access data
6.Turn on i am under attack challenge
7.Turn on the DDos protection from the cloudflare.
8.Setup the rules in cloudflare system to block some browser which was being used in malicious activities.
9.Changed the username and password for the database
10.Enable the WAF in cloudflare too.
11. Also I cleared the session table as well. Because of this activity the session table was going crazy. I have code for it to be cleared every day twice as per my needs.
12.Changed all my username and passwords in my all accounts
13. Modify my .htaccess file
14. Allowing Cloudflare IPaddresses
P.s also contacted @osworx regarding the Mysqli.php. Thanks for his help
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Sun Feb 20, 2022 9:15 pm
by ADD Creative
khnaz35 wrote: ↑Sun Feb 20, 2022 9:03 pm
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.
mistake: error_log setting was kept on from the php.ini
It's not the error_log setting that is the problem it's the displaying of errors.
You need make sure display errors in set to off in all 3 places. Your PHP settings, in system/config/default.php and in the settings. Not only can this cause minor notices and warnings to cause bigger errors, is also be a security risk.
1. In your PHP settings make sure display_errors is set to Off. Use
phpinfo() to check. It should be off by default, but there are lots of rubbish hosts out there.
2. In system/config/default.php set error_display to false.
3. In your OpenCart Setting on the server tab set Display Errors to No.
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Sun Feb 20, 2022 9:33 pm
by khnaz35
ADD Creative wrote: ↑Sun Feb 20, 2022 9:15 pm
khnaz35 wrote: ↑Sun Feb 20, 2022 9:03 pm
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.
mistake: error_log setting was kept on from the php.ini
It's not the error_log setting that is the problem it's the displaying of errors.
You need make sure display errors in set to off in all 3 places. Your PHP settings, in system/config/default.php and in the settings. Not only can this cause minor notices and warnings to cause bigger errors, is also be a security risk.
1. In your PHP settings make sure display_errors is set to Off. Use
phpinfo() to check. It should be off by default, but there are lots of rubbish hosts out there.
2. In system/config/default.php set error_display to false.
3. In your OpenCart Setting on the server tab set Display Errors to No.
That's correct!
Was just generalising it
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Tue Feb 22, 2022 8:19 pm
by Khal
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;
}
}
I added this code to the .htninja file and it would not let me access the Ninja firewall dashboard. The Ninja Firewall support said that the following code is blocking access and it needs to be removed:
Code: Select all
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (empty($_GET)) {
header('HTTP/1.0 403 Forbidden');
exit;
}
}
Just wanted to let others know in case they are having the same issue.
Re: [SOLVED] Warning: DDoS against OpenCart based websites
Posted: Thu Mar 03, 2022 9:43 pm
by ri2k
Has anyone used this? Does it work?
Do you guys recommend this?
Re: [SOLVED] Warning: DDoS against OpenCart based websites
Posted: Fri Mar 04, 2022 12:39 am
by johnp
ri2k wrote: ↑Thu Mar 03, 2022 9:43 pm
Has anyone used this? Does it work?
Do you guys recommend this?
Never used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.
Re: [SOLVED] Warning: DDoS against OpenCart based websites
Posted: Fri Mar 04, 2022 11:58 am
by ri2k
johnp wrote: ↑Fri Mar 04, 2022 12:39 am
ri2k wrote: ↑Thu Mar 03, 2022 9:43 pm
Has anyone used this? Does it work?
Do you guys recommend this?
Never used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.
I installed it but couldn't get it to work. I signed up but then it didn't login from Opencart admin panel.
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Mon Apr 04, 2022 4:45 pm
by thanos74
I have the same problem....
Which is the better code to avoid Bruteforce in /admin ?
admin/index.php
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;
}
}
or
from @antropy
https://www.opencart.com/index.php?rout ... n_id=43261
Code: Select all
<![CDATA[
if (defined('HTTPS_CATALOG') && defined('DIR_CATALOG') && $_SERVER['REQUEST_METHOD']==='POST' && empty($_GET)) {
http_response_code(403);
die;
}
Re: Warning: Bruteforce/DDoS against OpenCart based websites
Posted: Mon Apr 04, 2022 6:11 pm
by ADD Creative
thanos74 wrote: ↑Mon Apr 04, 2022 4:45 pm
I have the same problem....
Which is the better code to avoid Bruteforce in /admin ?
They both do the same thing. It is probably more efficient to do the same in htaccess. That was the server doesn't have to start a PHP process.
viewtopic.php?f=179&t=225771&start=20#p836216
If the IP addresses you access the admin from doesn't change it is best to add an allow list and ban all others.