Best practices for hardening sudo?

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.

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.