linux security and root access question....
I'm setting up a server that has a validator node running on it for a substrate-based blockchain. I was trying to harden the security of my server. I set up ufw for all ports but those necessary for the node to operate. I set up 2FA, SSH with ed25519, and then I was spending time trying to figure out, if for some crazy reason someone got in... how could I stop someone from using systemctl or poweroff with sudo privilages. The goal is maximize uptime and remain in sync with the other nodes at all times.
Anyways, I started blocking bash commands for the user account that allows SSH and blocked SSH to root. Then I blocked a few more commands and thought, what if someone could find their way around this? So, I just started blocking too many things lol. Even though I disabled sudo for the user and blocked a number of commands the user could still use systemctl and stop the service for the node. Eventually I found this guide on how to only allow a few commands for a user.
Update: I didn't properly remove the user from the sudo group. Afterwards they could still use systemctl but the system then allowed systemctl to pop up with an input for the root user password for authentication. Anyways, I just wanted something simple yet secure sooo....
I ended up removing all of the commands from the user and symlinked the su command and renamed it to a random command that only I know. All of the other commands done by the user respond with
-rbash: /usr/lib/command-not-found: restricted: cannot specify /' in command names
I took away bash history and bash autocomplete/tab completion. Now the only thing you can do is guess commands that will get you to the point where you still have to get past my root password. Is there a way for hackers to scan for available commands when there is only one available that is masked in this way?
Anyways, I'm saying all of this because I have always heard best security practices involve "disabling root". Sometimes I see it as just disable root SSH, which i already have done, but sometimes i read it like disable the root account. Some say disable the password and try to divvy it up with sudo privileges so it's more traceable to individual users.
In my case I need to preserve root access in some way but I basically hid everything within the root user. So, if anyone gets access to root it's over. But, it's behind 2FA, SSH, and an unknown command that just gets to where you can try a password to access root.
Am I thinking about this "disable root for security" all wrong and I should disable it completely or does it make sense what I've done so far?
You can also create a SSH key and use this to login to a Linux server, instead of using a password, and do not share your private key.
The following link is a tutorial on how to create a SSH key one, https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/
You could also add user filtering with AllowUsers option in sshd_config file:
AllowUsers admin1#192.168.1.* admin2#192.168.1.* otherid1 otherid2
This allows admin1 and admin2 only from 192.168.1.* addresses and otherid1, otherid2 from anywhere.
Related
Let's state a situation:
I have the possibility to run arbitrary commands on a server as an unprivileged user, through "unconventional means".
I do not have the possibility to login using ssh to that server, either as my unprivileged user or anything else. So I do not have currently a CLI allowing me to run any commands I would like in a "normal" way.
I can ping that server and nothing prevents me to connect to arbitrary ports.
I still would like to have a command line to allow me to run arbitrary command as i wish on that server.
Theoretically nothing would prevent me to launch any program as my unprivileged user, including one that would open a port, allow some remote user to connect to it and just forward any commands to bash, returning the result. I just don't know any good program to do that.
So, does any one know? I looked at ways to launch ssh_server as an unprivileged user but some users reported that recent versions of ssh_server do not allow that anymore. Actually I don't even need ssh specifically, any way to get a working CLI would do the trick. Even a crappy node.js program launching an http server would work, as long as I have a CLI (... and it's not excessively crappy, the goal is to have a clean CLI, not something that bugs every two characters).
In case you would ask why I would like to do that, it's not related to anything illegal ^^. I just have to work with a very crappy Jenkins server for which I'm not allowed to have direct access to its agents. Whoever is responsible for that server doesn't give a sh** about its users' needs so we have to use hacky solutions just to have some diagnostic data about that server (like ram, cpu and disk usage, installed programs, etc...). Having a CLI that I can launch some time instead of altering a build configuration and waiting 20 minutes to have an answer about what's going on would really help.
Thanks in advance for any answer.
So do you have shell access to the server at least once? E.g., during the single day of the month when you are physically present at the site of your client or the outsourcing contractor?
And if you have shell access then, can you or your sysmin install Cockpit?
It listens on port 9090.
You can then use the credentials of your local user and open a terminal window in your browser. See sidebar item "Terminal" on the screenshots of the cockpit homepage.
According to the documentation
Cockpit has no special privileges and doesn’t run as root. It creates a session as the logged in user and has the same permissions as that user.
I need to get a hold of web-server logs by regular users who have /bin/bash as their shell enabled. Logs are stored in a directory which has drwx------ permissions and is owned by root:root so obviously they can't access any files in it (and yes, I can't really change this permissions setup).
The system(s) is Debian Linux. So I'm looking for some wrapper script, it might not be bash exactly, which, in my vision, will do the following:
you pass one argument to it - a sitename - i.e. site.com;
it greps all the lines containing this site.com;
stores the result to user home dir.
This part is easy, the real problem arises when you want to bypass restrictions yet to stay (at least somewhat) safe. So:
script must only be started after password is provided for it to be run;
in case of bash scripts they are run with permissions of the user account who ran it - so my guess is it should have su -m root -c 'grep ...' in it, but I found no way how to pass password to the prompt inside the script so far (sudo is not exactly suitable unfortunately);
if there is a way to pass password to su from inside the script then of course script itself must have permissions 751 and owner of root:root - so that the end user who runs the script (or anyone else) won't be able to see the script's content.
I'm open to suggestions how this should be done or if it's should be done at all (at least this way) :) Thank you.
Given what I understand of your needs, I summarize here the various options that come to my mind. In no particular order:
Use sudo together with a policy file (/etc/sudoers -- edit with
visudo) to restrict the commands available to the user
Use a cron job (more or less smart) to collect data on the server at regular
intervals and store them at a location accessible to you (or mail them to you...)
If you have administrative access to the server, you might create a special user with
the "log-grepping" tool as connection shell (/etc/passwd)
If you have ssh access to your server, you may also use the
authorized_keys file on the server to restrict remote command over ssh
Those are only general directions. Read about them. Try them. And if you're struggled, don't hesitate to post an other question!
As a last word, as it has already been stated in a comment, please refrain yourself to develop your own "security restriction system". sudo, ssh, pam (and probably others ... selinux?) have been specifically crafted for that purpose...
I've this need, I have to install ubuntu on a machine for a specific purpose, and I have to create a particular locked user account.
On startup i need to display the login box (so I have to admin the machine, only reboot and login as root) in the format with username and password fields.
After the login of this user, I have to auto open Google Chrome on a specific page.
Stop, this specific user doesn't have to do more. This machine is connected to a display with show ads in the expo of my client.
How to do this? I don't have any idea. Can anyone tell me ALL the correct step to achieve this?
Thanks in advance, Francesco
You have to setup a kiosk mode. You can find a good tutorial and all needed steps at http://www.alandmoore.com/blog/2011/11/05/creating-a-kiosk-with-linux-and-x11-2011-edition/
This may be an "old hat" answer...but yes, it's pretty common in practice to simply create a login shell that does a specific task (kind of similar to FTP or backup user accounts).
This means - simply put - in the /etc/passwd where you normally put the shell for the user (/bin/bash or whatever) you actually put a script that does whatever you want it to. When the script ends, the user is booted off.
If this is combined with a properly configured selinux, its pretty safe as long as the script is not hackable (I.e. does not request input which can have appended commands (I.e. "input name:" Mike; rm -rf /) or that can lead to a buffer overrun.
For this reason, its good practice to put the script in an isolated directory, chroot the user, put the user in its own group, and have the user/group only have permissions to that dir.
I want to build a web based admin tools that allow the system admin to run pre-configured commands and scripts through a web page (simple and limited webmin), what is the best approach?
I already started with Ubuntu installing LAMP and give the user www-data root's privileges !!!
as I learned (please check the link) this is a really bad move !!!, so how to build such web-based system without the security risk?
cheers
I did something like this a couple of years ago. It was (I like think) fairly secure and only accessible to a limited number of pre-vetted, authenticated users, but it still left me with an uneasy feeling! If you can avoid doing it, I'd recommend you do :)
I had a database sitting between the frontend web-tier and the script which was actually executing actions. The relevant table contained a symbolic command name and an optional numeric argument, which was sufficient for my needs. This allows you to audit what's been executed, provides a quick and dirty way to have a non-www user do things, and means if the website is compromised they're constrained by the DB structure (somewhat) and the script which pulls data from it.
The data from the DB can be read by a daemon running in a separate, unprivileged account. The daemon pulls and sanitises data from the DB and maps the 'command' to an actual executable (with a hard-coded map, so commandA executes A, commandB executes foo, and anything else would get flagged as an error). The account can be locked down using AppArmor (or SELinux, I imagine) to prevent it from executing, reading or writing anything you don't expect it to. Have a system in place to alert you of any errors from either the daemon or AppArmor/SELinux.
The executables which the daemon runs can be setuid'd if appropriate, or you can use the sudoers mechanism to allow the unprivileged account to execute them without a password.
I already started with Ubuntu installing LAMP and give the user www-data root's privileges
Don't do this.
If you really want to execute some very specific scripts under root privileged. Create such predefined very limited scripts, allow their password-less execution with sudo for specific user and then run them via script and don't forget authentication.
Generally this is bad idea.
SSH is your best friend.
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
The systems I run have a sudo-only policy. i.e., the root password is * (disabled), and people have to use sudo to get root access. You can then edit your sudoers file to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.
I would normally suggest the following:
Use a blank root password.
Disable telnet
Set ssh for no-root-login (or root login by public key only)
Disable su to root by adding this to the top of /etc/suauth: 'root:ALL:DENY'
Enable secure tty for root login on console only (tty1-tty8)
Use sudo for normal root access
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
If you have ssh access via your certificates, can't you log in via ssh and change the root password via passwd or sudo passwd when you need to do something else that requires the password?
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH keys have no real alternative.
For management of many authorized_keys files on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.
Else a for loop in bash or some clush action will suffice.
Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.