OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: namezero111111 on January 24, 2018, 07:34:34 pm
-
HI,
when creating a new user with no privileges assigned, this user can SFTP to the OPNsense and browse anywhere outside its home directory, e.g. /conf and happily retrieve the config.xml with keys and TLS and everything.
Again; "System: Shell account access" privilege is not needed.
The user has no privileges assigned at all.
How to reproduce:
1. System->Access->Users
Create user "test", assign no privileges
2. Login via SFTP with the username and password.
This surely cannot be desired/intentional ?
-
If you enable SSH and password login this is what happens, yes.
Also, if you have sensitive security questions, it could be beneficial to not post them on the forum without consultation. ;)
Last but not least, what would you have us do differently?
Cheers,
Franco
-
@franco PM per mail
-
As briefly discussed with Fabian... the trail leads to Internet topics asking how to fix this on Linux spanning multiple years with answers ever so unsatisfyingly.
It's agreed that something should be changed, but what that is eludes the last 30 minutes spent pondering about it.
In any case: password logins for SSH/SFTP are bad.
Cheers,
Franco
-
SSH can easily be protected with security keys (specifically/distinctively assigned to users) and/or 2FA (besides standard user/pwd auth). Even fw rules. And it's just good practice to do so. 2FA is easy and accessible to anyone and OPNsense is awesome because it can offer this. Yubikeys can also help. Sessions can be hijacked whatever the auth method (though fw rules can help in some cases). As long as you are connected to a network, you can never be 100% safe. Security through obscurity is one of the best alternative methods.
-
Agreed, and apologies for posting here.
It might be a bit more intuitive to prevent the sftp for users who do not have the ssh privilege set.
Here, login is set to /sbin/nologin.
For sftp, subsystem sftp could be set to /bin/false for example, or at least the user being Chrooted to their home directory.
It seems like there is no way to piggy tail custom sshd config on either since the config file is written solely by the gui logic. Are there provisions for an sshd_extra file?
This seems as if it could easily be integrated in the config generation, but might be going down an xy problem road...
-
No worries. I don't think disabling SFTP with a knob in the GUI helps here at all.
I like the chroot, but it is very restrictive and, generally, shell access for users means read access to most of the system already so fixing it this way will just shift the inconsistent behaviour elsewhere. Shell access is dangerous, also for merely operating the priv-sep daemon within its defined boundaries as that can have DoS-style issues.
The selective SFTP seems the best way forward, most likely according to wheel group to give consistency with the shell behaviour, which is what you rightfully noted at the very beginning.
If you need you can easily edit the configuration by temporary adjusting /usr/local/etc/inc/plugins.inc.d/openssh.inc in the block that writes the config to force the expected behaviour for now.
We will try to get this done next week and incorporate it for 18.1.1 if all goes well.
Cheers,
Franco
-
I tried a few things: "ForceCommand" overrides the shell, "Subsystem" can't be used with "Match", "AllowGroup" seemed to work but then didn't...
... so ended up locking myself out for now apparent reason. To be continued. 8)
Cheers,
Franco
-
What about setting MaxSessions to 0 for non-SSH users?
ForceCommand should work, but I believe the last Match block supersedes previous ones.
-
Doesn't ForceCommand prevent login for SSH then?
So this is what Fabian and me have come up so far:
https://github.com/opnsense/core/commit/2fc86a72
It's not perfect. There is general ambiguity between shell access and what an admin is... Generally admins are the only ones who should have accounts as you can read the configs like you found earlier. Unfortunately now, SSH login for shell privilege but no admin use is prevented.
Well, to be continued.
Cheers,
Franco
-
I like the idea of allowing only the wheel group.
I agree on the ambiguity.
In case of a firewall, a user account that is incidental (such as someone just creating vouchers, or an account just for VPN login) surely should not be able to retrieve certificates et al.
I suppose the "root issue" in this case would be of historic nature that shell access allows access to /conf. Possibly the assumption that only admin users would be created anyway on a firewall system.
The issue for us came up because we used to have a user forced into a certain directory for backup retrieval, but changed in the transition to OPNsense to the backup script pushing the config via SFTP. We like to give minimal access to service accounts if possible.
Btw, I really appreciate your responsiveness to issues here instead of wiking off with "by design"...
-
The issue for us came up because we used to have a user forced into a certain directory for backup retrieval, but changed in the transition to OPNsense to the backup script pushing the config via SFTP. We like to give minimal access to service accounts if possible.
The problem here is a user having access to the config can do anything with the appliance. A more secure backup variant is coming in the future to do automatic backups via SCP so OPNsense will log into your backup server and copy the config onto it. This works perfectly with your minimal access principle because you can set the user shell to scponly (if that works maybe with chroot).
https://github.com/opnsense/plugins/tree/master/sysutils/scp-backup (https://github.com/opnsense/plugins/tree/master/sysutils/scp-backup)
Please note that this is a work in progress.
Btw, I really appreciate your responsiveness to issues here instead of wiking off with "by design"...
We do our best to keep OPNsense one of the most secure open source firewall systems available.
-
It was suggested here that user shell is locked to /bin/csh:
https://forum.opnsense.org/index.php?topic=7035.0
How about we ditch the user shell privilege and simply set a shell per user? That would also enable other user shells wether we have them or not is a different question... reading /etc/shells is a good starting point. ;)
With that or on top we could add a "remote" group and give that group SSH rights so no users without a proper shell will be able to login through SFTP and SSH?
Cheers,
Franco
-
With that or on top we could add a "remote" group and give that group SSH rights so no users without a proper shell will be able to login through SFTP and SSH?
The name is bad as it does not tell what it is doing - I prefer the name of my original patch.
-
"ssh-users" from your patch does not reflect sftp very well, nor what this group does on a conceptual level.
But in any case after a sleepless night I've come to realise that we need something like we have done for IPsec, OpenVPN and Captive Portal: let the user decide which group SSH will allow, unsetting will allow all users. Then we pin the default config.xml to "admins" and that's not a default issue anymore but users are free to change it.
This, coupled with the user shell selection, should be a future-proof and secure solution for everybody?
Cheers,
Franco
-
sounds good. but I would hardcode "wheel" to prevent a lockout of root and a user may add additional groups.
-
That should make sure of it?
https://github.com/opnsense/core/blob/master/src/etc/rc.subr.d/recover#L34
And all GUI groups are added to the system, so that should all play out as it should.
Cheers,
Franco
-
I mean the sshd_config setting should be "AllowdGroups wheel custom_group1 custom_group2" where the default is "admin" as the first custom group so it is as hardened as possible and it will be hard to lockout root without changing the code.
-
Good point, sure.
But we have to do stuffing in that case:
Setting is on, e.g. "admins":
AllowedGroups wheel admins
(does not support multi-select)
Settings is off:
#AllowedGroups nope
(not restricted as it is now)
Cheers,
Franco
-
As discussed.... https://github.com/opnsense/core/commit/4cdfe13bc
I don't think this will hit 18.1.1, but 18.1.2 is likely.
Cheers,
Franco
-
Awesome; I'm excited about the response :}