Just another Scott Alan Miller Sites site

Using sudo as an alternative to regularly logging in as root to a system which you need to administer is a well known and quite popular security option.  Not everyone believes that the security benefits are worth the additional effort that this entails but it continues to gain traction as a best practice and is very simple to implement.  Using sudo in the RHEL world is far less popular but is standard practice in the Debian and Ubuntu camps and so its use has become very well known recently.

The dangers of going directly to root are generally pretty obvious.  Logging in remotely to a root account means that root itself has to be exposed – obviously not an optimal situation.  We can also assume that the root password is probably being shared between multiple admins – also very bad.  Shared passwords mean that we can’t audit to know who is performing root level actions.  Being logged in as root also means that we can forget ourselves and issue commands as root that we meant to issue as a non-root user.  Accidents can happen and being proactive can mean the difference between a good day and a horrible weekend.

There are two steps necessary to get our admin users set up to work with sudo.  The first step is adding the admin users to the wheel group.  Wheel is an old concept in UNIX and has a lot of legacy behind it.  Traditionally it was used with the su command and a shared root password.  But that is not the way in which we want to use wheel as that is not secure.

In /etc/group, edit the wheel group to include all of your system admins.  Everyone in this group will have access to root when we are done.

Now that our group is set up we can alter the behavior of sudo to use the wheel group in the manner which we expect.  In case you don’t have sudo on your system, install it with:

yum install sudo

Sudo is configured by the /etc/sudoers file.  By default, sudo is effectively disabled.  The easiest way to our wheel options is to search for the word “wheel”.  There are two lines about wheel, both of which are currently commented out.  The first line, if uncommented, allows anyone in the wheel group to sudo to root but requires the user to re-enter their password for security.  Great idea but this can be problematic for many management tasks.  The second line, if uncommented, does the same but will not require the users to re-enter their password before performing an action as root.  This second option is my preferred method – striking the right balance between security and ease of use to make the sudo system work for most users.

When you are done, the line will look like this:

%wheel  ALL=(ALL)       NOPASSWD: ALL

Now sudo should be working.  As a user in the wheel group (the system administrator group) we can easily issue commands at root with only minimal additional effort.

sudo rpm -q sudo

Ta da!  It’s really that easy.  Now, there are times when working as root is just practical and always having to sudo before each and every command can be too cumbersome for the real world.  Not a problem.  When it is necessary to still become root like back in the “good old days” you can sneakily do so using this command:

sudo -i su

And again, ta da!  Now you are root without needing a shared password.  Now you can secure the root user to keep anyone from using it directly.

The base Red Hat and CentOS repositories are highly conservative, well tested packages recommended for the bulk of enterprise environments.  However, the conservative approach to package management within RHEL often leaves administrators wishing for a greater selection of available packages.  To this end, the Fedora community has created the EPEL (Extra Packages for Enterprise Linux) repository which is, in effect, a repository of Fedora packages for the RHEL family of operating systems (RHEL, CentOS, Unbreakable, Scientific, etc.)

By enabling the EPEL repository you get much of the added functionality of Fedora without going to the extreme level of rapid versioning and cutting edge technology for which that distro is known.  EPEL is often a very good compromise for enterprise Linux administrators needing extensive package selection but wanting to keep the conservative, well tested, slow change approach normally applied in a managed, enterprise environment.

Since the EPEL is a repo, the EPEL folks figured that the best way to handle adding the EPEL to your system is through an RPM package.  Check the website for the latest version but at the time of this writing you can install with just this command on CentOS 5:

rpm -ivh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

To install on CentOS 6 use this command instead:

rpm -ivh http://mirrors.servercentral.net/fedora/epel/6/i386/epel-release-6-8.noarch.rpm

It is really that easy.  Now your yum commands will be able to make use of the additional packages in the EPEL repo.  This repository is very extensive and offers greatly expanded functionality over the base RHEL packages.

One of the inherent vulnerabilities of an SSH server is a brute force attack against it.  The accepted method of protecting against this on Linux is to use the Fail2Ban script which detects successive, failed login attempts against SSH and uses IPTables to block sessions originating from IP addresses making those failed attempts.  This is a very effective technique and eliminates the majority of threats against your SSH server.  It is a rare enterprise Linux server on which you will not want to install and configure Fail2Ban.

Once you have enabled the EPEL repositories installation is as simple as:

yum install fail2ban

Once installed, Fail2Ban is configured to a level of basic functionality and can be started immediately using:

/etc/init.d/fail2ban start