This means that if you've left your console unattended and a passer-by gets to run command as bruno, they won't be able to use Sudo: they might be able to damage your account, but not the rest of the system.Īnother advantage of requesting a password is that it alerts you that something unusual is taking place. However, since using Sudo can have major consequences, Sudo requires some extra authentication: you need to type your password again, sometimes. In principle, it can rely on the system's authentication mechanism: if you can run commands as bruno, it means you've already authenticated as bruno. In order to apply this rule, Sudo needs to know that the user invoking it is indeed bruno. In the sudoers file allows the user bruno to execute any command with any privilege. Its job is to determine whether you are allowed to execute a command with elevated privileges, and if you are, to execute that command. Sudo is primarily a tool for authorization.

If you have a dynamic IP then use something like Port Knocking or Single Packet Authorization to open important ports for your IP address when you need them, that way they don't need to be open globally.This is an illustration of the difference between authentication and authorization. If you want to stop a brute force attack, then don't allow access to the SSH port. As soon as someone discovers you've done it, they simply alter their attack to make it effective again. It's about as useless as changing port numbers from the default. This is especially unfortunate because they appear to be using the same name for this account on every server, and as soon as someone figures this out they'll have the same problem they're trying to avoid by making this change. My server host is sadly setting up new servers with the root account disabled (presumably to combat brute force attacks) and using an alternate account configured as an admin (I would believe via SUDO). Granted I've always used RedHat/CentOS/Fedora Linux, so there's never really been a requirement to use it. This is why I refuse to configure SUDO, since there are occasional vulnerabilities like this that make it dangerous.

As seen below, the user `test` has a UID of 1001 and `bleeping-test` has a UID of 1002. When creating users in Linux, each user is given a UID. For example, the following command would launch vim as the user `bleeping-test`. test ALL = (ALL, !root) /usr/bin/vimįor the `test` user to execute one of the above commands, they would use a sudo command with the -u argument to specify the user to run as. The sudo command can also be configured to allow a user to run commands as another user by adding special directives to the /etc/sudoers configuration file.įor example, the below commands allow the user `test` to run the /usr/bin/vim and /usr/bin/id commands as any user but root. When executing commands on a Linux operating system, unprivileged users can use the sudo (super user do) command to execute commands as root as long as they have been given permission or know the root user's password. Thankfully, this vulnerability only works in non-standard configurations and most Linux servers are unaffected.īefore we get to the vulnerability it is important to have some background information on how the sudo command works and how it can be configured. A vulnerability in the Linux sudo command has been discovered that could allow unprivileged users to execute commands as root.

Rootgiving sudo bug impacts