- Obscurity through Security
- Inventor of sudo
- Everyone Loves sudo!
- Where it all began!
- Stop allowing password based root logins via SSH!
- Say no to root logins via SSH
- Linux flavours don't do sudo correctly
- Cloud Providers are doing it wrong, kinda.
- Bastion Hosts FTW!
- Auditing is easily turned on for sudo
- Automated deployments + Restricting Access
- What do I think?
Obscurity through Security
I would group this in with changing your SSH port. It's really an inconvenience more than anything. However it can be used to mitigate attacks. Especially when there are multiple users managing the system
Inventor of sudo
Here's a quick interview with the person who invented sudo https://www.youtube.com/watch?v=LaAwl3HN5ds
Everyone Loves sudo!
You'll find that a majority of guides will provide most commands with sudo prefixed to them. Why?
The idea is that it's more secure, but in reality, the original reasoning for sudo was simply to allow more than one person to have root access to a machine that was used by multiple staff to run jobs.
Where it all began!
But let's talk about why this trend started happening. There was a time where you would install a flavor of Linux, and set a root password. You'd then log in to the server with the root password and do what you needed to do. This was insecure, by default this allows root logins via SSH with a password. If that password was compromised, or it's extremely weak (See the movie Hackers) you're going to get owned pretty quickly with a brute force attack.
Stop allowing password based root logins via SSH!
So how do you avoid this? Set a root password, store it safely, and enable SSH key-based logins to root only. Make sure that your SSH key was protected with a password!
It's now harder for an attacker to gain access to the system as they need to own your SSH key, which is also password protected. You still have a password for root, which you can use at the console (local keyboard and mouse) or when you need to login via single-user mode to fix a failed raid or fsck a hard drive. It took a while to adopt ssh-key only root logins. But it's pretty much gold standard now.
Say no to root logins via SSH
The next step was to eliminate root logins directly over SSH altogether. Instead during the installation of a majority of Linux flavors and cloud provider installs. You'll be asked to create a local user and a root password. To login as root you need to login as the local user use an SSH preferably and then use one of the following methods to login as root.
su - and use the root password, run a single command using
sudo ps -auxwwf or login to a root shell by running
sudo su -
Linux flavours don't do sudo correctly
The only issue now is that most Linux flavors will not require a password to sudo as the local user set up during the initial install.
So you can log in as the local user with your ssh-key and sudo su - to a root shell. So if your key is compromised, you pretty much have root access.
Unless you require a password for sudo and you limit SSH logins to only key-based logins. So now a user has to log in via SSH with their SSH key, and then to sudo they need their password. But they can't log in via SSH with this password. It's almost like two factors, but not OTP based. Two factor isn't always OTP.
Cloud Providers are doing it wrong, kinda.
Cloud providers allow a user to provide an SSH key to be automatically added to the default local user (ubuntu or ec2-user are common users). You can then login via SSH using this key and
sudo su - to root or just run
sudo commands at will.
If you're not 100% familiar AWS as a business owner, and you have a contractor working on your servers. They'll most likely ask for the original AWS key that you created on the initial deployment. This is pure laziness. It's not a password protected key, and chances are you've given it out to multiple contractors.
Bastion Hosts FTW!
I had to help a client with this recently and will be setting up a bastion host for them. Using https://goteleport.com/
When a contractor or coder needs access. He can deploy their keys as necessary and remove them. I really wish Amazon had this built out already. If you don't want another system to manage, setup a WSL for Windows 10 or use the Terminal (iTerm is awesome) for macOS.
Auditing is easily turned on for sudo
The only other reason I see a good reason to use sudo is for audit logging. However, you can turn on full system audit logging for all users and see what commands are being run. So it's moot, the sudo audting is cleaner however.
Automated deployments + Restricting Access
The other reasons for using sudo would be for automated deployments and restricting access. Pulling down code, and then restarting services using automation. Or providing a user access to restart a service or edit configuration and more.
What do I think?
Like it really matters what my take on this is? 😂
I don't believe sudo provides enough protection simply by using it. You still need to lock down SSH to SSH key only authentication for all accounts. Once a user logs in, a password is required to utilize sudo and it should be different than the SSH key password you're using.
I'd also set up SSH logins and sudo to use 2FA which is amazing.