Securing a fresh Linux install, part 1

Most Linux distros provide a wide variety of server applications, and many network-aware apps are enabled by default when you install the operating system. Before you put your new Linux machine online, there are a number of steps you should take to make your network secure. Use these tips every time you perform a fresh install; none of these steps will help to secure a machine that has already been compromised.

Before you install anything on your machine, check the Web site of the distro you plan to use and download any security patches or updates that have been released since the version you are going to install. As soon as the install process is finished apply the patches and updates you found.

Choose sensible passwords

Many users, if left to their own devices, choose passwords that are easy to remember — and just as easy for a cracker to guess. Any password can be cracked given enough time and resources, but a safe password is one which would take an unreasonably long time to crack, while not being impossible for the user to remember.

One of the first steps in securing any system is to ensure that all users have safe passwords. Passwords should be at least eight characters in length and contain a mixture of
upper- and lower-case letters, numbers, and special characters. A common way of choosing a safe password is to think of a phrase of eight or more words — for example ‘There was an old woman who lived in a shoe.’ Take the first letter of each word in the phrase — ‘twaowwlias.’ Now replace some of the letters with numbers, mix the case, and add some special characters to get your password — ‘tW40ww!iAS.’ This password is much more difficult to crack than your dog’s name, but not too much more difficult to remember.

su and sudo

You’ve probably been told a hundred times since you started using Linux that you shouldn’t log on as root; instead, you should log on as a normal user and use su to gain root privileges for specific tasks. You can take this a step further and restrict which users can actually use the su command to gain root privileges. In the file /etc/suauth add the line:

root:ALL EXCEPT GROUP wheel:DENY

This line require that a user be a member of the wheel group before he can su to root. Check man /etc/suauth for more options. You can achieve the same effect using PAM, as we’ll discuss later.

It is a good idea to make sure that all su activity is logged. Normally
logging to syslog is enabled by default. Make sure the line:

SYSLOG_SU_ENAB          yes

is uncommented in /etc/login.defs to be sure. You can also enable logging of
su activity to its own file by uncommenting the line:

#SULOG_FILE     /var/log/sulog

You should never need to give out the root password of your servers to users. If
you really need to give a user or users access to something that requires root privileges,
you should use sudo instead. Sudo allows certain users to perform certain tasks
with root privileges without needing to know the root password.

You can configure sudo using the visudo command, which opens the /etc/sudoers configuration
file in a special vi session. sudo’s man page contains plenty of details on configuring sudo, with examples.

Restrict the number of running services

One of the most common errors made by Linux admins is having unnecessary services running. The more services you have running, the greater the risk of your box being broken into. If you’re not running a service, it can’t be exploited, so you should run only services you really need.

To see a list of the services currently running, issue the command # ps -aux | less to show all running processes, and # netstat -atu to see a list of services and the ports that they are listening to. Examine the output of these commands and decide which services you really need. If you don’t know whether you need a service or not, the simple answer is, you don’t. It is better to be aggressive when deciding what to disable; if you later find something you need is missing, you can always re-enable it.

Many network services are initiated by the Internet superserver daemon — inetd for short. inetd reads its configuration from /etc/inetd.conf. You can prevent services from being started by commenting out (placing a # at the beginning of) the lines in inetd.conf:

# echo          stream  tcp     nowait  root    internal

To begin with, you should comment out all of the services in this file. If you later find you need something, you can enable it.

You may also consider replacing inetd with xinetd, which is a more recent and secure alternative.

Your distro’s boot scripts are also responsible for initiating services at system startup. Exactly where these scripts are depends upon the distro you use, but you should check them thoroughly to see what services are being started and disable the ones you don’t need. In Red Hat you can use the chkconfig utility. Running chkconfig --list shows you what daemons are started at which run level. You can use the --del option to turn off services. So, for example, to disable routed, you would type # chkconfig --del routed.

Not all services are chkconfig-friendly. You must disable such services by removing the symlinks in the directories corresponding to the different run levels — e.g. /etc/rc.d/rc3.d/S50inet. It’s enough to remove just the links; keep the actual files in case you need to enable something later.

In the case of Slackware you should check the scripts under /etc/rc.d, and either comment out the startup commands of services you don’t need, or alternatively, remove the executable bit from the appropriate script with a command such as # chmod a-x /etc/rc.d/rc.sendmail.

Once you are sure you have disabled everything you don’t need, reboot — it’s the best way to make sure that you really have disabled everything you think you have. It’s no good if all the good work you’ve put in so far will be undone next time your machine reboots.

Once you’ve restarted, run the ps and netstat commands I gave earlier again to check what’s running. Repeat as necessary until you have the bare minimum of services running.

TCP Wrappers

TCP Wrappers is a daemon that uses two files, /etc/hosts.allow and /etc/hosts.deny, to decide which users and domains can connect to the services run by inetd. Most default installations leave these files blank. The first thing to do with TCP Wrappers is set your default policy to “deny.” The best policy in security is to lock all the doors to begin with, and then and only then to open the ones you need. Edit /etc/hosts.deny and add the line:

ALL:ALL

This denies access to all services from all hosts. If you want to be notified by mail of any failed connection attempts, you can modify the above to read:

ALL:ALL:/bin/mail -s "%s connection attempt from %c" mike@localhost

Having set the default policy to deny all access, you can enable access for individual hosts to certain services by editing /etc/hosts.allow. For example, the line ALL:127.0.0.1 allows access for 127.0.0.1 to all services. Similarly, ipop3d:192.168.1.1 allows 192.168.1.1 access to pop3. You can specify a range of addresses with a line like ipop3d:192.168.1., or use multiple addresses separated by a comma: ipop3d:192.168.1.1, 192.168.1.4 You can use domain names rather than IP addresses, but this could really slow things down if you experience a DNS failure. Where possible stick to using IP addresses.

Now that you’ve secured your services, it’s time to look at files. That’s what we’ll tackle next time.

Mike Peters is a freelance consultant and programmer and long-time Linux user.