Best way to restrict "admin" logins to certain IPs.

priyansh

Verified User
Joined
Dec 10, 2021
Messages
13
Location
India
I saw this very old discussion: https://forum.directadmin.com/threads/restrict-admin-access-to-administrator-ip-s.14468/.

However, the number of people disagreeing with this idea is baffling (not surprising since it's 2008), considering how widespread this practice of restricting things to specific IP addresses for security has been.

I tried the solution of adding checking if the $caller_ip matches in all_pre.sh, however, that is not ideal as it lets you log in, just does not perform any functions + it breaks a lot of other stuff, such as JetBackup (all of my backup jobs started failing once I saved that script).

I'm looking for a solution that only applies to the login page of DA at 2222, not to every post request.

So, the question is, how do we prevent any login attempts on the DA login page with the username "admin" if the request is not from a specific set of IPs set by the server administrator?

This is an important feature, as it would reduce the attack surface significantly, right?
 
but they still can attack on ssh, ftp, email, ..etc..

so why you need to disabled only :2222, it make no sense that other service still can attacked.
 
I liked the post because you choose the correct way by creating a new thread and pointing to the old thread instead of upping an ancient thread. Compliments!

The idea is indeed not new, but a good solution for this really not existing still. I can imagine some would like to have such option.
It's possible to create a new admin with a new name and use that one.

But brute forces will never stop. A good firewall and reporting and blocking ip's does a good job too, but will also not fix it.

If I remember correctly I think I've seen somebody or heard of somebody who blocked all access to port 2222 on ip base.
It is possible for example:
Code:
iptables -A INPUT -p tcp --dport 2222 -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp --dport 2222 -j DROP
You have to add the ip of the customers then too. And then they are limited, just as admin, to login from 1 place. Not very handy when one has a dynamic ip which changes often.

Another way is to enable 2-factor authentication. This is new since the last discussion and with that active the bruteforces don't have any chance anyway.

When using another name as admin, when you keep the main admin account (which is used for several internal things), you could just put a long very hard pass on things there like pass: LKDsq2390EU;sdusfh12#$$^!s0glk12HN!qe9gub!@)*!##4020Ddszpbhyurhw
or something like that. Good luck on bruteforcing that one. :)
 
it possible, but You need to adjust all custom config for phpmyadmin, webmail, smtp, dovecot, ftp

phpmyadmin and roundcube is just modify php code and not affect other thing.

But I don't know when you force disable system user on other service, it could affect other thing.

if you want to try, this how dovecot handle user-auth.

if disable on dovecot and dosen't affect anything, you can trying to adjust Exim.

if it went well, start adjust FTP service.
 
It's possible to create a new admin with a new name and use that one.
Will renaming the "admin" user using the change_username.sh script break anything? What do you think?
You have to add the ip of the customers then too.
I manage some shared hosting servers with 500+ users, and doing this is not possible.
Another way is to enable 2-factor authentication.
Yes, that is undoubtedly a good workaround, but access control via IPs should be implemented into DA, at least for Admin users.

When using another name as admin, when you keep the main admin account (which is used for several internal things), you could just put a long very hard pass on things there like pass
We already use password managers (Chrome and Bitwarden) for saving the passwords, so brute-forcing was not my concern; I was more worried about Redline stealer and other malware which can affect the user's PC stealing all cookies/passwords saved in the browser, DA should essentially detect if the admin request is from allow listed IPs or not, if not then report the incident to the admin email and blocklist that IP from accessing the server altogether.
 
it possible, but You need to adjust all custom config for phpmyadmin, webmail, smtp, dovecot, ftp
I'm not worried about phpMyAdmin or mail or FTP of the admin user, as they don't pose a severe threat.

If a malicious user is able to log in as 'Admin' on DA, they can suspend/delete all user accounts, log in to the terminal and takeover the server using root esclation.
 
Hello,
I'm looking for a solution that only applies to the login page of DA at 2222, not to every post request.

1. Set admin password to something known only to you
2. Create a login key with a restriction to a list of allowed IPs (you might disable certain function, if you don't want your admin to create another administrator or change password for admin user)

That should work fine. See for more information: https://www.directadmin.com/features.php?id=1298
 
Will renaming the "admin" user using the change_username.sh script break anything? What do you think?
Probably, because many internal things are used via admin, which is why I like more the idea of a very difficult password on the default admin and then create a new admin with another name to work with.

But probably @zEitEr's idea with the login keys to restrict access is even a lot better.
 
But probably @zEitEr's idea with the login keys to restrict access is even a lot better.
Hmm, that's right. However, it might still not help (I've not tried this myself) if the cookies/session is stolen by malware or malicious script; strict IP-based control is a desired feature, and I hope DA can add it to their to-do list with the recently increasing attacks using simple stuff.
 
and I hope DA can add it to their to-do list with the recently increasing attacks using simple stuff.
That probably won't happen, because then they would have to build a routine for the username admin. Because admin and any user can login at anydomain:2222 or even server.domain.com:2222 with their credentials.
I also think there might not be that much interest in an option like that because it won't help a lot.

However, you can feel free to put in a request for it and see if it gets upvoted:
you need a seperate account to acces that.
 
if you want to hook "login_pre", "all_pre", these hook already deprecate.

But you can trying to use "session_create_pre".

so it should solve your issued when you followi with this guide


with session_create_pre hook.
 
Back
Top