Bastillion
Bastillion copied to clipboard
bastillion-io
Should Bastillion be used as root on Systems?
Hello,
We're testing Bastillion internally and one of the things that really bothers me is the fact that - from my understanding until now - Bastillion should be used/connected as "root" on all assigned Systems.
I couldn't find any way of creating UNIX Users + SSH Keys via Bastillion, or allow each Bastillion user to login as a specific UNIX user/sudoer. So basically everybody is using the root user, with each user's Bastillion SSH Key just being added to the root user.
This poses two huge/basic security holes:
- Allow remote root access. Disabling remote root access is one of the first one should do, so basically Bastillion is using/basing on a "industry no-no".
- Add many keys to the root user. This is also a "industry no-no". A basic good practice is that a system should multiple sudoers, each one of them having their own SSH Key in order to login tot SSH, plus a password in order to be able to "sudo execute". In Bastillion you just add SSH Keys to root, over and over.
The only method for "securing" this would be to restrict SSH logins to specific IPs (presumably Bastillion's), which is another "no-no" in the agile industry; also it'll not solve the problem, just workaround it and add another point of failure.
Or maybe I'm not understanding Bastillion's logic/basics correctly?
Thank you!
I too am wondering this. I emailed the email address on the contact page asking about this. I really don't want to enable to root user on all my servers. If that is the only way of doing it, this product is a no go for me and my org.
You have the option to set the user when registering the systems. It doesn’t have to use root.
Sent from my iPhone
On Jul 12, 2019, at 12:41 AM, cb3inco [email protected] wrote:
I too am wondering this. I emailed the email address on the contact page asking about this. I really don't want to enable to root user on all my servers. If that is the only way of doing it, this product is a no go for me and my org.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
You have the option to set the user when registering the systems. It doesn’t have to use root.
In such a scenario we have two options:
- add the Bastillion key to a sudoer, and ... share its password. Which kinda defeats the entire purpose of Bastillion
- add the Bastillion key to a sudoer that's allowed to su without a password, which represents a security risk
The proper way of doing this is to allow each user to login as "himself", then sudo. But Bastillion doesn't have any kind of user management, hence our dilemma.
if a user will has sudo access anyways and still be able to assume root acces, then my question to you is what is difference to having direct root login access?
please answer that questions
people complain about root login access BUT forget to realize no difference if your user has sudo access. And without sudo access i mean am not sure what the user can really do on that system other than mostly doing read-only tasks
then my question to you is what is difference to having direct root login access
The difference is the (sudoer) user's password.
Having direct root acces is a big "no-no" in the opsec world, because it's basically a "level zero" access layer. That's why the basic good practice is to key-login to a sudoer, than sudo via pass (vs login directly as root).
PS: never do sudo without a password.
if an attacker got access for the sudo user, how do you know they dont have the password for the user? you can think not having direct root access is a great security but i will tell you i dont worry about it much..i worry about other layers of security..if an hacker can get on the server with a sudo user, you might as well count your security as total fail..not sure what else you think you protecting from there
i think people over exaggerate the protection of not having direct root access..it probably helps 1% in my book which is no farther from 0%
if an hacker can get on the server with a sudo user, you might as well count your security as total fail
Sure, please go ahead and generate a file named encryptblockr in /root. You can find all the necessary details here, including IP, username, private key, public key etc. The user has full superuser access.
Don't worry about breaking anything. I give you 48 hours. Good luck. :)
PS: please don't do anything stupid/DDoS other targets from the VM etc.
lol..well my point is if someone gets your private key, how are you sure they dont have the password of the user? i mean most people setup passwordless sudo access as well for convenience and i hope you dont do that either
wither way my point is there are several other ways and layers of other things to worry about other than root access when it comes to security
Some of us have been through this with other systems, such as Jenkins and Tomcat, that have access to sensitive logs. Even if the code is good, it is always dangerous to run daemons as root that do not need to run as root. The use of the "JETTY_USER" should, ideally be a default rather than an unsupported option without filesystem permissions set for that user.
At a minumum, the PID should be in /var/run/bastillion/, with that directory owned by ghe $JETT_USER, and various jetty/logs/ and other directories have group write permision with pwermissoins set to 2770 to keep non-authorized users out of the logs and to permit the $JETTY_USER to write there.
I'm personally a bit short of time to do this, but I recommend this based on dozens of Linux daemons I've deployed or migrated in my work, including Samba, OpenSSH, Tomcat, and Jenkins.
Agreed enormous difference between daemon running as root and certain users having sudo access. Consider accountability and identification and audit. Can't believe a KEY manager system is built on this quicksand.
Agreed enormous difference between daemon running as root and certain users having sudo access. Consider accountability and identification and audit. Can't believe a KEY manager system is built on this quicksand.
I'm following this project for 3-4 years. Unfortunately the devs stopped developing this and/or adding new features, which is a shame because it was looking really promising. We ended up buying Termius 'till a more suitable solution pops out.
If you know any alternative/s please let me know. Thank you!
On Tue, Aug 17, 2021 at 5:26 AM Razvan Rosca @.***> wrote:
Agreed enormous difference between daemon running as root and certain users having sudo access. Consider accountability and identification and audit. Can't believe a KEY manager system is built on this quicksand.
I'm following this project for 3-4 years. Unfortunately the devs stopped developing this and/or adding new features, which is a shame because it was looking really promising. We ended up buying Termius 'till a more suitable solution pops out.
If you know any alternative/s please let me know. Thank you!
I was introduced to "bastion" by someone else's use, and would appreciate a safer key management security model. I'd happily send long my RPM building tools for bastillion. I've had some success with NoMachine's tools, though they've stopped keeping the free servers up-to-date.
https://www.nomachine.com/
The NoMachine clients are much heavier weight than simply using the web browser based access of Bastillion, but that tool includes a good X server for the remote clients, effective even when many commercial X servers simply don't follow the specs and do a poor job.
This looks more like a Guacamole alternative? I'm looking for an SSH gateway, not a full-blown remote desktop solution. Thank you
On Wed, Aug 18, 2021 at 11:51 AM Razvan Rosca @.***> wrote:
This looks more like a Guacamole alternative? I'm looking for an SSH gateway, not a full-blown remote desktop solution. Thank you
The NoMachine server is the gateway in this case. It also supports shared sessions, and throttling number of connections, and limited hours of operation, just the sorts of things Bastiallion might benefit from in a production environment.