Backoffice login security

[Jeffrey de Bruijn]

Hi, I am concerned about the security of the backoffice login page:

I do not believe there is any sort of application-level rate limiting on the login page. Anybody could reach that page and attempt to log in, and thirty bees would not stop an attacker from attempting hundreds of logins per minute. There is no 2-factor authentication available either.

This is why I would limit access to the backoffice route to a small number of trusted IP addresses, using apache's require IP directive.

Recently however, I have moved to another country and the ISP here do not provide static IP addresses. The IP address I am given changes rather frequently and I am unable to use the require IP directive to protect the backoffice login page.

Am I mistaken? Are there application-level mitigations for bruteforce attacks on the backoffice login page?

How do I make sure attackers cannot attempt logins like that?

[the.rampage.rado]

Install the TB recaptcha module.

Also you can lock your folder with a password - they have to bruteforce this password first, if it's strong enought this will cause some server load but not as much as having your admin open to the public.

Then you have google's recaptcha, use 'strange' admin email (NOT admin@, sales@, office@ john@, etc) and strong password.

I doubt anybody will be entusiastic enough to go through this.

[Jeffrey de Bruijn]

7 hours ago, the.rampage.rado said:

Install the TB recaptcha module.

Also you can lock your folder with a password

I wasn't aware the recaptcha module would add a captcha on the admin login page. However, I still do not believe recaptcha is a suitable solution.

Locking the folder with a password is another thing I never considered because the password should be shared across all admin users, and the chances of it leaking are higher. It still seems better than nothing, though a rate-limit on attempts and/or 2FA is the gold-standard way to handle this problem nowadays, is there really no such implementation for tb?

[Jeffrey de Bruijn]

I am attempting something different, but I am stuck.
In order to keep the benefit of public key authentication via SSH, I am using SSH port forwarding this way:
 

ssh -L 9999:fqdn.server.domain:443 [email protected]

And, by resolving the domain name to 127.0.0.1 by adding this line to the /etc/hosts file
 

127.0.0.1 server.domain

It is possible to reach the thirtybees website through the SSH port forwarding. All it takes is to get the following url
 

https://server.domain:9999

Unfortunately it seems thirtybees redirects the request with code 302. I am certain there is no code 302 in my virtual host configuration so I am certain it is thirtybees doing the redirect. Is there any way to disable that redirect?
 

wget https://server.domain:9999/
--2023-04-01 21:29:03--  https://server.domain:9999/
Resolving server.domain (server.domain)... 127.0.0.1
Connecting to server.domain (server.domain)|127.0.0.1|:9999... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://server.domain/ [following]
--2023-04-01 21:29:04--  https://server.domain/
Connecting to server.domain (server.domain)|127.0.0.1|:443... failed: Connection refused.

 

Edited April 1, 2023 by Jeffrey de Bruijn

[nickz]

12 hours ago, Jeffrey de Bruijn said:

I do not believe there is any sort of application-level rate limiting on the login page. Anybody could reach that page

Once you renamed the admin folder to xcsgsfatehsb no one can guess that folders name.
If you paranoid, redirect 302 the admin page to index over .htaccess and dishabilitate all ftp accounts. Than all you need to do is the enable ftp, comment the redirect,

[Cassim]

you can always limit the access to specific folders by .htaccess if you really don't want anyone to visit that page other then you