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.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.
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:JNeuhoff wrote: ↑Wed Nov 24, 2021 10:27 pmI 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:But such a rule should really be implemented on a firewall level!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; } }
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 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 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
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.tiredman wrote: ↑Mon Feb 07, 2022 1:12 pmThe 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: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.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 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.I think the long term solution is to ban the IPs using the firewall.Code: Select all
protected function validate() { exit(header("Location: http://" . strval($_SERVER['REMOTE_ADDR'])));
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
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.
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.JNeuhoff wrote: ↑Mon Feb 07, 2022 7:50 pmtiredman : 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'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.
This will work if the request is emptyMaxD wrote: ↑Tue Jan 25, 2022 6:18 amI 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.
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
I send you PM have a look into it.
Thanks in advance
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
Opencart Hosting Plans, Domain Registration, Microsoft and Google Email and More
Visit our website for great deals and most importantly, fast and friendly support - www.evolvewebhost.com
Read my answer there ..
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
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
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
Attachments
image002_1.png (61.16 KiB) Viewed 11875 times
image001.png (33.91 KiB) Viewed 11875 times
image001_1.png (33.91 KiB) Viewed 11875 times
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
It's not the error_log setting that is the problem it's the displaying of errors.khnaz35 wrote: ↑Sun Feb 20, 2022 9:03 pmThe 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
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!ADD Creative wrote: ↑Sun Feb 20, 2022 9:15 pmIt's not the error_log setting that is the problem it's the displaying of errors.khnaz35 wrote: ↑Sun Feb 20, 2022 9:03 pmThe 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
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.
Was just generalising it
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
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: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;
}
}
Code: Select all
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (empty($_GET)) {
header('HTTP/1.0 403 Forbidden');
exit;
}
}
Never used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.ri2k wrote: ↑Thu Mar 03, 2022 9:43 pmHas anyone used this? Does it work?messor wrote: ↑Fri Nov 05, 2021 3:49 amYou can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor
Do you guys recommend this?
Opencart 1.5.6.5/OC Bootstrap Pro/VQMOD lover, user and geek.
Affordable Service £££ - Opencart Installs, Fixing, Development and Upgrades
Plus Ecommerce, Marketing, Mailing List Management and More
FREE Guidance and Advice at https://www.ecommerce-help.co.uk
I installed it but couldn't get it to work. I signed up but then it didn't login from Opencart admin panel.johnp wrote: ↑Fri Mar 04, 2022 12:39 amNever used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.ri2k wrote: ↑Thu Mar 03, 2022 9:43 pmHas anyone used this? Does it work?messor wrote: ↑Fri Nov 05, 2021 3:49 amYou can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor
Do you guys recommend this?
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;
}
}
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;
}
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.
Users browsing this forum: Dragon Lady and 98 guests