Sometimes you want to delegate.įor example, say you want to grant a user permission to run a specific application that usually requires root permissions, but you don't want to give this user the root password. The problem with this model is that a sysadmin has to choose between handing over the master key to their system or withholding the key and all control of the system. If you don't have the password for su, you have no administrative privileges whatsoever. If you have the password for su root, you can become the superuser. If you're going to set up a script to brute force its way into somebody else's server, why waste time trying to get in as a regular user with limited access to the machine? It only makes sense to go for the most powerful user available.īy being both the singularly known user name and the most powerful user account, root essentially makes it pointless to try to brute force anything else. Our latest Linux articles 2. Root is the ultimate attack vectorĪnother reason root is a popular name in failed access logs is that it's the most powerful user possible. That's not just one guess and then another guess it's two guesses that must be correct concurrently. In addition, the attacker must guess a password to associate with a login name. An attacker must guess at possible login names. Without root, a server has no confirmed login accounts. Removing the root account offers a good amount of protection. The login name is always right, as long as it's root, so all an attacker needs is a valid passphrase. That's one less guess about how to get into your server an attacker has to make. Automated attempts to log in as root are easily the most common, and with good reason.Īn attacker with enough knowledge to attempt a break-in also would also know that, before the widespread use of sudo, essentially every Unix and Linux system had a root account. Before I understood the value of sudo, I used to look through logs with horror at all the failed brute force attacks directed at my server. I use the usual mix of firewalls, fail2ban, and SSH keys to prevent unwanted entry to the servers I run. Here are five reasons you should be using sudo instead of su. In fact, sudo makes Linux more flexible and configurable than ever, with no loss of features and several significant benefits. Is it a conspiracy to dumb down Linux?įar from it, actually. Yet most distributions recommend using sudo instead of su, and most major distributions have eliminated the root account altogether. The two interactions are nearly identical. For instance, here's the su command in action: $ su rootĪnd here's sudo doing the same thing: $ sudo dnf install -y cowsay In some ways, it feels very much like the su command. To a longtime superuser, the sudo command might seem superfluous at first. Using su worked well enough for a few decades, but then the sudo command came along. Of course, as the literal owner of a system, you could always use the su command to become the superuser (root) and do whatever you want, but for everyday tasks you're meant to use your normal account. You can't make those mistakes because, as a normal user, you don't have permission to access those important files. As a normal user, you can't, for instance, delete the configuration file that defines your network interfaces or accidentally overwrite your list of users and groups. Running your system as a normal user is a self-imposed limitation that protects you from silly mistakes. After that initial interaction, you're expected to log in as a normal user. Using the root account, you log in and create secondary "normal" users. On traditional Unix and Unix-like systems, the first and only user that exists on a fresh install is named root.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |