Five security reasons to switch to the Linux sudo command

time:2022-11-27 02:52:26 source:scripttoolbox.com author:Power Supply
Five security reasons to switch to the Linux sudo command

On traditional Unix and Unix-like systems, the first and only user that exists on a new system is root. Log in with the root account and create a "normal" user. After initialization, you should be logged in as a normal user. Using the system as a regular user is a self-imposed restriction that prevents stupid mistakes. For example, as a regular user, you cannot delete profiles that define network interfaces or accidentally overwrite user and group lists. As a normal user, you don't have access to these important files, so you can't make these mistakes. As the actual owner of the system, you can always switch to superuser (root) via the su command and do whatever you want, but for day-to-day work you should use a normal account. For decades, su worked fine, but then came the sudo command. To someone who uses superuser on a daily basis, the sudo command may seem redundant at first glance. In some ways it feels a lot like the su command. For example: $ su root # dnf install -y cowsaysudo Do the same thing: $ sudo dnf install -y cowsay They do almost exactly the same thing. But most distributions recommend using sudo instead of su, and even most distributions have completely canceled the root account user, still owns most system files and runs most services in the background). Is it a conspiracy to make Linux stupid? But in fact, it's not. sudo makes Linux more flexible and configurable without loss of functionality, in addition to several notable advantages. Why is sudo better than root on Linux? Here are five reasons why you should replace su with sudo. 1. Root is the confirmed target of the attack I use a common combination of firewall, fail2ban and SSH keys to prevent some unwanted access to the server. I was terrified of brute force in logs until I understood the value of sudo . Automatic attempts to log in as root are the most common case, and for good reason, of course. Attackers with some common sense of hacking should know that before sudo was widely used, basically every Unix and Linux had a root account. This leaves the attacker with one less guesswork. Because the login is always correct as long as it is root, the attacker only needs a valid password. Removing the root account provides a lot of protection. Without root, the server has no confirmed login. The attacker must guess the login name as well as the password. It's not two guesses, but two guesses that must be correct at the same time. (LCTT Annotation: This is misleading, the root user cannot be deleted, otherwise the system will have problems. In addition, although root can be renamed, it is best not to do so, because many programs have a hard-coded root user name. You can disable root user, give it a password that cannot log in.) 2. root is the ultimate attack vector The root user is often seen in the access failure logs because it is the most powerful user. If you're going to set up a script to force your way into someone else's server, why waste time trying to get in as a limited regular user? Only the most powerful users make sense. root is both the only known username and the most powerful user account. So root basically makes it pointless to try to brute force anything else. 3. Optional privileges for the su command are either all or nothing. If you have the su root password, you can become superuser. If you don't have the password for su then you don't have any admin rights. The problem with this model is that the system administrator must choose between handing over the root key or keeping it and taking ownership of the system. It's not always what you want, sometimes you just want to empower. For example, let's say you want to give a user permission to run a specific application as root, but you don't want to give the user the root password. By editing the sudo configuration, you can allow specified users, or any user belonging to a specified Unix group, to run certain commands. The sudo command requires the user's existing password, not your password, and certainly not the root password. 4. Authenticated users are elevated for 5 minutes after running a command with sudo after a timeout. During this time, they can run any administrator-authorized command. After 5 minutes, the authentication cache is cleared, and the next time you use sudo, you will be prompted for the password again. The timeout prevents the user from accidentally doing something (for example, accidentally searching the shell history or pressing too many up arrows). It also ensures that another user cannot run those commands if one user leaves the desk without locking the computer screen. 5. Logging Shell history function can be used as a log of what a user does. If you need to know what's going on with the system, you can (in theory, depending on how shell history is configured) switch to someone else's account using su, see their shell history, and also see what commands the user has executed. However, if you need to audit the behavior of 10 or 100 users, you may notice that this approach doesn't scale. Shell history rotation is fast, 1000 by default, and they can be easily bypassed by preceding any command with a space. When you need to manage the logs of your tasks, sudo provides a complete logging and alerting subsystem, so you can view activity in one specific location and even get alerted when something major happens. Learn other sudo features In addition to some of the features listed in this article, the sudo command has many new features that already exist or are under development. Because sudo is often something you configure once and forget, or only configure when a new admin joins the team, it's hard to remember its nuances.

(Responsible editor:Hard disk)

Related content