22

Every hardening guide I read recommends forbidding to login to root account and instead using sudo. I can understand this if you set a strict sudoers file which only enables the necessary commands for each group and user. But on every server I put my foot on, I have only witnessed a non restrictive sudo configuration. I would like to understand if it is a good practice or not and why (still, I understand the traceability reason)?

So here are my questions :

  • Is it enough to forbid su and allow sudo in order to keep the traceability of the administrator actions ? (I can imagine a scenario where a user does a lot of sudo actions before deleting his bash_history)
  • Is there another source beside .bash_history useful to keep traceability ? can such a file be updated by an administrator (with sudo) ?
  • Is it possible to restrict sudo -i and sudo -s in the configuration ?
  • Can sudo command have utility without a strong sudoers configuration ? If yes, which ones?

Moreover, for a single user, I see only advantages to forbid sudo and enable su. Indeed, Log on with root and normal user using the same password seems to be a bad practice.

techraf
  • 9,141
  • 11
  • 44
  • 62
MarcelBrouette
  • 323
  • 1
  • 2
  • 5
  • 1
    Ultimately speaking, it is impossible to *fully* harden `sudo` using a blacklist. You would need a whitelist. (But there are good reasons to use `sudo` even if unrestricted.) – Wildcard Aug 30 '16 at 23:21
  • One can use third party external PAM (Privileged Access Management) solutions to manage and audit admin or sudo access across the organization. – LLub Nov 29 '19 at 15:12

3 Answers3

26

Your question is rather broad, touching on several different subjects. It may be better to take some of the details and put them in a separate question.

Is it enough to forbid su and allow sudo in order to keep the traceability of the administrator actions?

... can sudo command have utility without a strong sudoer configuration ? which ones ?

Unrestricted sudo has a couple benefits over su.

  • Each sudoer can use his personal password. This way you do not have to re-distribute the root password if it is changed.

  • sudo can be configured to log activity. If your syslog configuration writes to a remote location, then it becomes difficult for someone to cover their tracks.

However, unrestricted root access is still 'unrestricted'.

  • If you do not use a remote syslog server then tracks can easily be covered.

  • For convenience, folks often will use sudo -s to get an interactive shell. This allows you to get bash autocomplete on restricted directories. Unfortunately, the syslog benefits are void if a person is allowed to run sudo -s. Also there are many alternatives to sudo -s that can allow commands to be run without specific logging.

(I can imagine a scenario where a user does a lot of sudo actions before deleting his bash_history)

bash_history is not to be used as a history trace tool. It is only for user convenience.

Is there another source beside .bash_history useful to keep traceability? can such a file be updated by an administrator (with sudo)?

Any files on the server can be updated by a person with unrestricted root access. (whether via sudo or su)

How to trace the activity of a root user may be the subject of a different question. I believe advanced configurations of SELinux can do this, but it is probably not practical. I don't know of any other way to trace activity of a root user.

As I said if you have any logging that will have to be written to a remote log server to keep those from being erased by the attacker.

is it possible to restrict sudo -i and sudo -s in the configuration ?

To answer you verbatim, this may be possible, but is beyond the scope of this post. Consider creating a new question.

However, this will not solve your problem. For example, one could use sudo su instead of sudo -s. One could use sudo sudoers, or update the crontab, etc.

The only way to solve this is to 'restrict' the sudo abilities using a whitelist. As you said, this is not nearly as common, but is certainly the only way to accomplish the goal of reliable traceability with any level of detail.

Hope this helps. Feel free to ask for clarification on my answer, or post a more specific question if you have new questions based on what you learned so far.

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • 4
    +1 for: "bash_history is not to be used as a history trace tool" – TuringTux Aug 30 '16 at 18:10
  • 1
    You should enable audit logging on this server and ship the logs to a remote server for storage/analysis. That will help in traceability. As George mentioned above, use of "sudo" with any possible combinations of "su" should be restricted as much as possible. For every thing that you want to allow via sudo, you should whitelist that specific command(s). The reason why you see unrestricted sudo is due to lopsided security measures, not because of best practices. It mostly boils down to "Let me spin this quickly, and then we will revisit the policy doc". The policy doc is normally not visited. – yetdot Aug 30 '16 at 20:25
3

Addressing your last sentence, I actually do something in that spirit on my SSH server. I have two users there: ssh_user and sudo_user. Only ssh_user is allowed to login, but he's not in sudoers and has to issue a su sudo_user command to get things done. This provides an extra line of defense: even if the attacker obtains credentials of ssh_user (e.g. by stealing my putty configuration files), he won't immediately get access to sudo or /etc/shadow on the server and will have to brute-force the password of sudo_user or run an exploit on the system to get root access.

Of course, once the attacker has access to ssh_user account the server is compromised, but I expect this trick to give me a little extra time to react before actual damage is done.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
1

As for this:

Log on with root and normal user using the same password seems to be a bad practice.

sudo can be configured to ask for the password of the "target" user, or for a root password, instead of the running user's password. So for a single user you can have distinct unprivileged and admin passwords. For multiple admins, who should all have distinct passwords for unprivileged and admin access, it's harder and is probably easiest by creating additional users with uid 0.

From sudoers(5):

[sudo] validates the invoking user's credentials, not the target user's (or root's) credentials. This can be changed via the rootpw, targetpw and runaspw flags, described later.

ilkkachu
  • 2,086
  • 1
  • 11
  • 15
  • *"additional users with uid 0"* I didn't know that was possible... Is it recommended? – 700 Software Aug 31 '16 at 12:08
  • @GeorgeBailey, Possible? yes, it even works pretty well, in that you get distinct home directories and shells if you want. (I think some *BSD made two separate root accounts with different shells by default at some point in time.) The only problem I remember seeing with that is that `nscd` (which caches usernames lookups with LDAP) didn't always return the same name with a uid->username lookup, but changed among the different names of the same uid. But that only mattered for display. – ilkkachu Aug 31 '16 at 12:19
  • @GeorgeBailey, But recommended? Depends on who you ask, of course. :) I've grown used to it, but someone else might prefer always using sudo, and would find it abhorrent to run an interactive shell with any uid 0 account. – ilkkachu Aug 31 '16 at 12:20
  • Well I certainly understand the convenience of an interactive root shell; just commenting on having multiple usernames assigned to that singe id, and how it seems confusing at first glance. – 700 Software Aug 31 '16 at 13:06
  • I would argue that a second (or third or fourth) user with user ID 0 is still root. So all you are doing is create a multiple root passwords. So so instead of having to guess one password, an attacker now has two or three or four he can guess, any of which is sufficient for root access. Or am I overlooking something? – Kevin Keane Apr 23 '20 at 21:19
  • @KevinKeane, yes, they're root accounts in all but the username, that's what they're actually for. As for passwords, that shouldn't be a serious problem, since you'd still need to match the username and password (i.e. the password for my admin account with your admin username won't match), and even ignoring that it's only a few bits worth of password entropy, which is easy to fix with better passwords. (say, you have 8 passwords, that's 3 bits of entropy which is about the same as one random character.) – ilkkachu Apr 30 '20 at 12:47
  • @KevinKeane, of course it would be optimal if you could tie the regular accounts to the admin accounts so that it's not possible to access my admin account through your regular account, let alone some random users'. Though getting arbitrary code execution to just a regular account used to run `sudo` would probably be a problem in itself, or if they get a keylogger on your workstation. – ilkkachu Apr 30 '20 at 12:49
  • @ilkkachu Thanks for your response. I would argue that the real problem is with the better passwords bit. These would be ordinary, albeit trusted, users. If the user's passwords were random 20-character strings, that's one thing. But even sysadmins aren't immune to poor password hygiene and phishing. – Kevin Keane May 01 '20 at 16:39
  • @KevinKeane, yes, passwords suck in general :) I don't think it matters much for phishing/keyloggers if the admins have distinct passwords or just one: you still only need to successfully get one of them to type a working password somewhere the attacker can get it. Trying to brute force the passwords should be deal with by rate-limiting etc., and if your admins use the name of their first pet as a password, you should re-educate them... in Siberia. – ilkkachu May 02 '20 at 08:41