Limiting root login for security - possible?

[Stilez]

In case of attempts to brute force a login on a password-secured system, it adds a layer of security for an attacker to have to guess an account name, not just a password. The "root" login name will be a "well known login" for OPNSense. It's possible to create an arbitrary named user in the admin group, that is actually used for console or webUI logins, but I'm stuck there and wondering if more is possible in two areas:

• The root account can still login via web, remote SSH (if enabled) or console. if the sysadmin does not believe that accidental lockout is a problem (e.g., they have a backup config and can happily reinstall), they might want to limit the root account's login to just console, or just some specific method/source IP, or block it completely other than locally as needed for OPNSense's own operations. But I can't find a way to reduce any of the root account's login rights.
   
• Similarly, I can set up other admin accounts, but even allowing login group = "wheel,admins", I can't get my alternative admin to directly login to the opnsense shell. The best I can do is login to csh and then su, which gets me there, but as a member of "admins" shouldn't it gain access to the main opnsense shell as well?
   
• Lastly, I can't find any way to specify which login routes a specific account can use - for example I might want to allow "dailyadmin" (a member of "admins") to use web + SSH from specific IP ranges, but not the system console, or allow root to use local console only as a kind of "emergency user" rarely used if locked out all other ways, that can't login from any remote system.

Can any of these be done? If not, are there good reasons why enhancement in this area would be a bad idea?

[franco]

Hi Stilez,

1.) You can disable root account via checkbox in its settings. Password will be disabled (unreachable "*" password hash in Unix). This doesn't disable root completely but makes login impossible (disabling root has operational consequences that must be avoided, e.g. cron jobs stop working). Or you set a scrambled random password if that is a reasonable approach for you. Both from the user's settings. In both cases, sudo still works for your real admin account, it just needs to be configured.

2.) sudo su / sudo opnsense-shell / whatever is shorter you can only operate opnsense-shell cleanly with root rights.

3.) That's not really supported in a PAM-based system where even the GUI integrates, but you can strip users of all of their GUI rights and do selective SSH access via authorized_keys meaning no key no login. Suffice to say SSH password login is clearly discouraged. Console login is trickier... if user is enabled and has a password he will be able to login.
Hope that helps.


Cheers,
Franco