Post by CJC » Fri Dec 03, 2021 11:20 pm

Hi All,
While looking at recent AWStats for one of our OC sites I noticed a huge uptick in traffic for what is basically a very little visited site. The traffic is 99.9% going straight to /admin. Does OC have any ability to block repeated login attempts from specific IP addresses?

Image

CJC
Active Member

Posts

Joined
Wed Jun 03, 2020 5:51 am

Post by moshair » Fri Dec 03, 2021 11:29 pm

change "admin" folder to something else and change the word "admin" to that folder name in admin/config.php.
create empty admin folder and protect it with firewall from cpanel.
or put .htaccess file in admin folder and deny visits from ip addresses don't belong to you in case you are the admin. search google for how to do that.

New member

Posts

Joined
Sun Jul 21, 2019 3:27 pm

Post by CJC » Fri Dec 03, 2021 11:58 pm

Thanks. I understand about changing the admin directory name to something else. But why bother creating a new empty admin directory? Wouldn't it be better to present the hacker with a 504 error?
moshair wrote:
Fri Dec 03, 2021 11:29 pm
change "admin" folder to something else and change the word "admin" to that folder name in admin/config.php.
create empty admin folder and protect it with firewall from cpanel.
or put .htaccess file in admin folder and deny visits from ip addresses don't belong to you in case you are the admin. search google for how to do that.

CJC
Active Member

Posts

Joined
Wed Jun 03, 2020 5:51 am

Post by moshair » Sat Dec 04, 2021 12:58 am

to make the hacker busy with admin folder after few days will stop attepts 🙂

New member

Posts

Joined
Sun Jul 21, 2019 3:27 pm

Post by CJC » Sat Dec 04, 2021 1:45 am

I like it! Thank you.
moshair wrote:
Sat Dec 04, 2021 12:58 am
to make the hacker busy with admin folder after few days will stop attepts 🙂

CJC
Active Member

Posts

Joined
Wed Jun 03, 2020 5:51 am

User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by by mona » Sun Dec 05, 2021 1:39 am

Hack attempts? those look like just probes.
Bots trying to find out what you have so they can better target your system, legit bots to determine how many websites run a particular software for census reasons or even security bots looking for vulnerabilities.

Over time you will see thousands of such probes including for admin from thousands of different ip addresses so blocking ips is futile whether via htaccess or firewall, unless you are DDOS-ed and nobody DDOSes OC sites.

For admin access only ip whitelisting is feasible as far as ips are concerned.

you will see many probes like:

Code: Select all

[GET /.env HTTP/1.1]
[GET /phpmyadmin/ HTTP/1.1]
[GET /admin/uecjwalletbackup.dat HTTP/1.1]
[GET /owa/auth/x.js HTTP/1.1] HTTP/1.1]
[GET /wp-login.php HTTP/1.1]
[GET /backup.sql HTTP/1.1]
[GET /upload/hmtmbitcoin.dat HTTP/1.1]
[GET /admin/config.php HTTP/1.1]
[GET /site.bak HTTP/1.1]
[GET /index/Mobile/fenshi?code=sz002405 HTTP/1.1]
[GET /index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1]
[GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1]
[GET /api/mobile/checkStrategyHistory HTTP/1.1]
[GET /assets/extension/market/css/mt4.css HTTP/1.1]
[GET /api/user/dataDictionaryService/list HTTP/1.1]
[GET /admin HTTP/1.0]
[GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0]
[GET /static/js/main.62b1528b.chunk.js HTTP/1.1]
[POST /admin HTTP/1.1]
etc, etc, etc.
in fact those requests will far outnumber your "legitimate" requests and there is nothing you can do about that.

You do however have certain control over how you deal with those requests.

for admin you can:
1) if you have a fixed ip address, whitelist that for the admin section
2) change the name to something else.
3) add directory authentication to the admin directory
4) use the user agent as an additional admin check.

1) the best option if you have a fixed ip address

you could use:

Code: Select all

	<RequireAny>
		Require ip xxx.xxx.xxx.xxx
	</RequireAny>

which would produce a 403 for others or you could use:

Code: Select all

# 451 Unavailable For Legal Reasons, will return code but zero content
ErrorDocument 451 %{unescape:%00}

# everybody is not admin
SetEnvIfNoCase Remote_addr "." !admin
# except this ip address
SetEnvIfNoCase Remote_Addr "xxx\.xxx\.xxx\.xxx" admin

# give 451 response if not admin
RewriteCond "%{ENV:admin}" "!=1"
	RewriteRule ^ - [R=451,L]
which would produce any response code you like for others, 451 in this case.

2) Be aware that many extensions still have "admin" hardcoded and OC upgrades may also fail.
adding a dummy admin folder is futile really as these are bots - computers - they do not really care about effort and they do not get tired !

3) use basic directory authentication on top of the admin login which is annoying for admin

Code: Select all

	<RequireAll>
		AuthType basic
		AuthName "Password Required"
		AuthUserFile "location of your user file"
		Require user xxxxx
	</RequireAll>

4) most browsers allow you to change your user agent so use it to your benefit.
use a secret code or generate a random string, add it to the user agent of the browser you use to access admin.
Then check in the OC admin whether the user agent contains that secret code, if it does not, block the attempt

Code: Select all

if (!stristr($this->request->server['HTTP_USER_AGENT'],'MY_SECRET_CODE')) {
	header($_SERVER['SERVER_PROTOCOL'] . " 406 Not Acceptable", true);
	exit;
}
use this only as an additional, not your only security



additional notes on probes, beyond the admin issue:

Most cheap probes use cheap proxies which use http/1.0, no current browser or legitimate bot does. So check if the request comes over http/1.0 and block it.
(add the check for a language accept header to be extra sure it is a useless bot and not a user with a very very old browser)

Code: Select all

	# http 1.0 - http version not supported empty response
	ErrorDocument 505 %{unescape:%00}

	RewriteCond %{THE_REQUEST} HTTP/1\.0
	RewriteCond %{HTTP:Accept-Language} ^$ [NC]
		RewriteRule ^ - [R=505,L]
most probes also do not bother to check for the domain they are probing, they just scan on ip address. All legit browsers and bots will request the host containing your domain.
So check which host they address and if it does not contain your domain (most likely it is just your server's ip address), block it.

Code: Select all

	#ErrorDocument 421 "Misdirected Request"
	ErrorDocument 421 %{unescape:%00}
	
	Rewritecond %{HTTP_HOST} !YOUR_DOMAIN
		RewriteRule ^.*$ - [R=421,L]

many probes do not bother to even set a user agent and since no legit browser or bot omits one, block those as well

Code: Select all

SetEnvIfNoCase User-Agent  ^$ noagent	
and either use:

Code: Select all

		<RequireAll>
			Require not env noagent
			Require all granted
		</RequireAll>
to give a 403 or:

Code: Select all

# give noagents a 451 unless they want the robots.txt file
RewriteCond "%{ENV:noagent}" "=1"
RewriteCond %{REQUEST_URI} !^/robots\.txt$
	RewriteRule ^.*$ - [R=451,L]
More about effort than security:
Probes for assets which you do not have generally will produce a 404 by the web-server, OC is not even involved in that process.
That changes when you enable OC's htaccess for seo urls, then all requests for assets you do not have (except ico gif jpg jpeg png js css files, no idea why those are there) are seen as potential seo urls.
Those are passed to OC's index.php and processed eventually resulting in a nicely generated 404 page response.
So if you use seo urls, better change this in htaccess:

Code: Select all

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
to

Code: Select all

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(env|php|xml|ashx|cfg|DS_Store|dat|ico|cur|txt|mp3|webp|svg|ttf|eot|woff|woff2|gif|jpg|JPG|jpeg|JPEG|png|js|cfg|css|pdf|zip|env|tar|sql|gz|tar|exe|rar|arj|cab|iso|rpm|tbz|tgz|old|bak|backup|dump|db|7z|asp|aspx|exp|html|htm)$
	RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

so that all requests for assets you do not have containing those extensions (and you will get a lot of those requests) will not go to OC but receive a 404 immediately from the web-server itself, saves you a lot of useless OC processing.

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 CJC » Wed Dec 08, 2021 5:55 am

@mona, thanks for the very detailed info. I'll have to digest all of that.

CJC
Active Member

Posts

Joined
Wed Jun 03, 2020 5:51 am

Post by johnp » Wed Dec 08, 2021 6:56 am

I use Ninja Firewall. Works like a charm:

https://nintechnet.com/ninjafirewall/pro-edition/

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


User avatar
Active Member

Posts

Joined
Fri Mar 25, 2011 10:25 am
Location - Surrey, UK

Post by JNeuhoff » Wed Dec 08, 2021 8:17 pm

I use Ninja Firewall. Works like a charm:
We canceled the Ninja Firewall PRO subscription for most of our clients' websites. It's just not suitable enough for certain bruteforce attacks. It uses an old reCaptcha, and it's built-in honeypot trap is not fully reliable. And it won't allow you to define your own simple custom rules (a custom rules editor is on their to-do list but won't be available any time soon).

If the OP (CJC) has entries like these in the server's access log:

Code: Select all

80.252.180.250 - - [08/Jan/2021:10:15:43 +0200] "POST /admin/ HTTP/1.1" 406 455 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
122.173.51.255 - - [08/Jan/2021:10:15:46 +0200] "POST /admin/ HTTP/1.1" 406 418 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
then this simple modified admin/index.php repels this attacker quite efficiently:

Code: Select all

<?php
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
	.....

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 by mona » Thu Dec 09, 2021 10:49 am

A firewall is always a good idea but I don’t believe it has any bearing on this topic and yes but then they just POST to /admin/index.php?route=common/login or /admin/?route=common/login or /admin/?x=y, etc.etc.etc. and that fix goes out the window ..

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 JNeuhoff » Thu Dec 09, 2021 6:03 pm

Agreed. The anti-attacker rules need to be defined on a firewall level. All I am saying is that Bitninja wasn't the right tool for this particular bruteforce attack.

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 by mona » Thu Dec 09, 2021 8:23 pm

@JNeuhoff
True, that Ninja FW is basically a wannabe mod_security with 10% of the functionality and a little GUI thrown in.

Yet any firewall is the wrong tool to block admin login attempts.
Use fixed ips or 2FA, but as long as your admin login is on the internet for your admin to sign in, it is also there for everybody else.

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 JNeuhoff » Thu Dec 09, 2021 8:54 pm

by mona wrote:
Thu Dec 09, 2021 8:23 pm
@JNeuhoff
True, that Ninja FW is basically a wannabe mod_security with 10% of the functionality and a little GUI thrown in.

Yet any firewall is the wrong tool to block admin login attempts.
Use fixed ips or 2FA, but as long as your admin login is on the internet for your admin to sign in, it is also there for everybody else.
Even if we change the admin to something else, it won't deter the attacker, he'll just get 404 responses, but will still run this for weeks before realizing he's wasting everybody's time, including his own :)

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 EvolveWebHosting » Fri Dec 10, 2021 12:46 am

CJC wrote:
Fri Dec 03, 2021 11:20 pm
Hi All,
While looking at recent AWStats for one of our OC sites I noticed a huge uptick in traffic for what is basically a very little visited site. The traffic is 99.9% going straight to /admin. Does OC have any ability to block repeated login attempts from specific IP addresses?

Image
I wouldn't even try blocking IP addresses. Hackers use random ones all the time which makes the process even more annoying. Your options are to use a firewall as mentioned such as Astra or try blocking access to the admin folder using .htaccess (you'd have to remove the block every time you wanted to access the admin area). Trying to keep up with this by writing different .htaccess rules all of the time will make you go insane.

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 pjdm » Sat Dec 25, 2021 11:17 am

the answer for this type of attack is fail2ban which can be implemented on servers, I have help with mine but I also do my own rules. For this /admin attack, I simply have a rule that immediately blocks the offending ip for 8 weeks and reports to abuseipdb.com. Over a few days the drop to very small numbers. At one point there was a DDOS on my opencart and fail2ban quickly blocked those IP addresses. For reference my files are:
entry to my jail.local
[opencart-admin]
enabled = true
logpath = /var/log/virtualmin/myopencart.com_access_log
maxretry = 1
findtime = 30d
bantime = 600
bantime.rndtime = 100
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 6w
# Report ban via abuseipdb.com.
#
# See action.d/abuseipdb.conf for usage example and details.
#
action_abuseipdb = abuseipdb
action = %(known/action)s
abuseipdb[abuseipdb_apikey="my key", abuseipdb_category="18,21"]

and the filter file that scans for attempts is opencart-admin.conf
# Fail2Ban filter for opencart domain lancairparts, abuse of /admin attempts
#

[INCLUDES]
before = common.conf
[Definition]
datepattern = \[(%%d/%%b/%%Y:%%H:%%M:%%S %%z)\]
failregex = <HOST> .*"POST /admin/.*$
# <HOST> .*"GET /wp-login.php.*$
# <HOST> .*"GET /wp-content/.*$
ignoreregex =

Newbie

Posts

Joined
Thu Jan 25, 2018 10:38 am
Who is online

Users browsing this forum: No registered users and 102 guests