19

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.

  • 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
23

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.

  • 2
    +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.

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.

  • "additional users with uid 0" I didn't know that was possible... Is it recommended? – Bryan Field 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. – Bryan Field Aug 31 '16 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.