Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Secure Your Linux Server

by Aaron Brazell
03/23/2006

The Linux operating system is one of the most stable and diverse OSes around. It's also one of the most popular servers in the world, thanks to its stability, process handling, and developer dedication. No matter what you plan to do with Linux, you can bet there's a flavor that will match your particular needs.

In the development world, the most popular and often used Linux distribution (known to Linux geeks as a "distro") is Red Hat. Others include Mandriva, Debian, and SuSE. This tutorial refers to Red Hat 9.

Do Not Turn Your Brain Off at the Door

Warning! If you think reading this article will give you all the information you need to be a system administrator, think again. This article covers the basics of security, but it is not a substitute for common sense, nor for the necessary interactive thinking of a competent system administrator.

This is not a fix-all. Hackers and attackers constantly reinvent themselves, and a good system administrator will be versatile and adept, reinventing himself as necessary. I recommend following Linuxdocs.org and CERT to help stay on top of system administration and security issues pertaining to your Linux server.

Installation

Related Reading

Run Your Own Web Server Using Linux & Apache
By Tony Steidler-Dennison

Before you can really get going, you have to install your Linux distro. I assume that you are setting up a server and will run without X11 (the GUI that ships with Red Hat). You may choose to install X if you wish, but this tutorial will not assume that you have it.

The rule of thumb to operate under is that if you don't need something, don't enable it. The reason for this approach is that the more services and modules you have installed, the greater the risk that an exploited and overlooked service could provide a gateway to your box.

Depending on your server or distro, the file locations I provide here may not correspond with those on your own system. To locate a file, use the command find / -name filename. You can also use tools such as pico or vi to edit a file.

Lockdown

This is the first thing to do to secure your new Linux box. There are several actions to take to prevent dangerous activity.

Changing the root password

The most obvious and simplest lockdown method is to change (or even initially setup) your root password, right from the start.

It's a good idea to change it once every 30 days, and it's also wise to come up with a password that won't be easy to crack. There are apps out there that can run a password list against a dictionary and try to crack passwords that way. Other apps will run a password list against a dictionary and hacker spellings. Therefore, using the term d0gf00d as your password is highly insecure.

You can change your password using the passwd command while logged in as root.

Disable suid

It's very valuable at times, and also very dangerous, to be able to run an application as a different user. The most common application of this is with suid (think "set user ID"). With suid, an underprivileged user can run an application as if he were a privileged user. For instance, the Apache web server, which by design runs as its own user, could execute commands as root. In this way, it would be possible for a regular user to gain access to and edit the /etc/passwd file, among others.

To find which files use suid, execute the following command. Anything with an s in the permission column (on the left) runs with suid.

# ls -alF `find / -perm -4000` > /root/suid.txt

On your server, you may get something like this in /root/suid.txt:

-rwsr-xr-x    1 root     root  60104 Apr  1  2002 /bin/mount*
-rwsr-xr-x    1 root     root    35192 Apr 18  2002 /bin/ping*
-rwsr-xr-x    1 root     root    19116 Apr  8  2002 /bin/su*
-rwsr-xr-x    1 root     root    30664 Apr  1  2002 /bin/umount*
-r-sr-xr-x    1 root     root    120264 Apr  9  2002 /sbin/pwdb_chkpwd*
-r-sr-xr-x    1 root     root    16992 Apr  9  2002 /sbin/unix_chkpwd*
-rwsr-xr-x    1 root     root    37528 Jan 17  2002 /usr/bin/at*
-rwsr-xr-x    1 root     root    34296 Mar 27  2002 /usr/bin/chage*
-rws--x--x    1 root     root    12072 Apr  1  2002 /usr/bin/chfn*
-rws--x--x    1 root     root    11496 Apr  1  2002 /usr/bin/chsh*
-rwsr-xr-x    1 root     root    21080 Apr 15  2002 /usr/bin/crontab*
-rwsr-xr-x    1 root     root    36100 Mar 27  2002 /usr/bin/gpasswd*
-rwsr-xr-x    1 root     root    19927 Apr 17  2002 /usr/bin/lppasswd*
-rws--x--x    1 root     root    4764 Apr  1  2002 /usr/bin/newgrp*
-r-s--x--x    1 root     root    15104 Mar 13  2002 /usr/bin/passwd*
-rwsr-xr-x    1 root     root    14588 Jul 24  2001 /usr/bin/rcp*
-rwsr-xr-x    1 root     root    10940 Jul 24  2001 /usr/bin/rlogin*
-rwsr-xr-x    1 root     root    7932 Jul 24  2001 /usr/bin/rsh*
-rwsr-xr-x    1 root     root    219932 Apr  4  2002 /usr/bin/ssh*
---s--x--x    1 root     root    84680 Apr 18  2002 /usr/bin/sudo*
-rwsr-xr-x    1 root     root    32673 Apr 18  2002 /usr/sbin/ping6*
-r-sr-xr-x    1 root     root    451280 Apr  8  2002 /usr/sbin/sendmail.sendmail*
-rwsr-xr-x    1 root     root    20140 Mar 14  2002 /usr/sbin/traceroute*
-rwsr-xr-x    1 root     root    13994 Apr 18  2002 /usr/sbin/traceroute6*
-rws--x--x    1 root     root    22388 Apr 15  2002 /usr/sbin/userhelper*
-rwsr-xr-x    1 root     root    17461 Apr 19  2002 /usr/sbin/usernetctl*

Many system administrators will recommend the deactivation of services like ping and traceroute, which systems don't often require. In this particular output, I recommend disabling /usr/bin/chage, /usr/bin/chfn, /usr/bins/chsh, /bin/mount,
/bin/umount, /usr/bin/gpasswd, /usr/sbin/usernetctl, /usr/sbin/traceroute, /usr/sbin/traceroute6, /usr/bin/newgrp, /usr/sbin/ping6, and /bin/ping.

Disabling suid on a file makes the file executable only by the owner and also makes it immutable (unable to be modified or deleted, or even linked to). To do this, use the command:

# chmod 111 /path/to/file
# chattr +I /path/to/file

Remember the rule of thumb: if you don't need it, disable it!

/etc/securetty

Next, edit your /etc/securetty file. This script allows you to define what services have access to your TTY device. A TTY device is a fancy designation for any basic input/output device. In this case, the device is your Linux console.

The file contains a list of services by which root can access your console. The most important items here will be to disable (comment out by using a # in front of the line) telnet. The reason for this is that telnet broadcasts unencrypted packets. In layman's terms, it shouts your vital user password through a bullhorn for the world to hear. Obviously, you don't need your root password broadcast this way. A Red Hat 9 box starts with a /etc/securetty file containing:

# pico /etc/securetty
vc/1
#vc/2
#vc/3
#vc/4
#vc/5
#vc/6
#vc/7
#vc/8
#vc/9
#vc/10
#vc/11
tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
#tty9
#tty10
#tty11

Comment out (place a # in front of the appropriate line) all devices except vc/1 and tty1, effectively preventing root access except from these single consoles. The only way to access root, then, is to use su -.

/etc/ftpusers

In the same way that disabling telnet is important for root, so should you disable FTP for root transactions. As a side note, it is also a good idea for a normal FTP user to find an SFTP client. This will allow secure FTP transactions to occur, as long as the hosting provider gives Secure Shell (SSH) access to its users.

When you edit /etc/ftpusers, make sure that root is not among the listed users. If it is, comment it out by putting a # at the start of the line.

/etc/xinetd.conf

Older versions of Linux use /etc/inetd.conf instead of this file, and it has a slightly different syntax and use. The xinetd.conf file is crucial to your networking. It starts services that pertain to your network connections. From it, you can (and should!) disable services that are not running or necessary.

Descend further, to the /etc/xinet.d/ directory, which contains a file for each of the default internetworking services. On a standard Red Hat 9 system, this directory includes chargen, chargen-udp, daytime, daytime-udp, echo, echo-udp, finger, finger-udp, ntalk, rexec, rlogin, rsh, rsync, servers, services, talk, telnet, time, and time-udp.

The contents of these files resemble:

# default: off
# description: A daytime server. This is the tcp \
# version.

service daytime
{
       type          = INTERNAL
       id            = daytime-stream
       socket_type   = stream
       protocol      = tcp
       user          = root
       wait          = no
       disable       = yes
}

If you do not need, or are not familiar with, any of the services listed, go into the file and set the disable attribute to yes until you can familiarize yourself with that service's use. Whenever you make any changes to these files, make sure to restart the inet daemon using:

# /etc/rc.d/init.s/inet restart

ipchains

ipchains is Linux's answer to a firewall. There are a lot of neat tricks you can perform with ipchains, and you can search for those tricks on Google. The module itself is fairly easy to use once you get the hang of it. I hope you can stay with me on this, as it can sound a bit overtechnical. Please be careful, as you can easily lock yourself out of your own box!

ipchains actually refers to three separate chains. A typical ipchain command consists of several parts. First, it carries one of three commands:

To set up a chain, you might use:

# ipchains --F input
# ipchains --A input REJECT

This is a blanket command that essentially halts all incoming traffic. The first command flushes the input chain, and the second command adds a new rule to the input chain that rejects all traffic.

You could do this if you were completely disconnected from a network, but most of the world is not. Almost every desktop or server Linux box in the world connects to a network or the internet, so it's not realistic to use such a blanket command.

There are plenty of other options to set up a more intelligent filtering system. Suppose that your Linux box is a development server accessible only on the local LAN. The IP of its network device is 192.168.25.4, with a netmask of 255.255.255.0.

Note that on Linux you can determine the source machine's network IP through ifconfig, or on Windows using ipconfig at the command prompt. The rest of the network is on the 192.168.x.x private block as well.

You might write a rule that looks like:

# ipchains --A input --I eth0  -s 192.168.1.0/255.255.255.0 \
    --d 192.168.25.4 --j ACCEPT

What the heck does that mean?

ipchains --A input adds a rule to the input chain.

-I eth0 tells the firewall that the packet traffic on which to run this rule is attached to Ethernet network device 0 (Eth0).

-s 192.168.1.0/255.255.255.0 identifies the source, or sending IP address, as 192.168.1.0. The number after the slash denotes the netmask, which in this case is 255.255.255.0

The ACCEPT designates that ipchains should allow all traffic from this source. You can also use REJECT to keep traffic out.

The best bet for ipchains firewalling lies within the ipchains how-to.

Other Tricks

Some other tricks you can perform to further secure your server have to do with your servers' hosts* files.

In /etc/hosts.deny and /etc/hosts.allow, you can enable tcp wrappers, which simply wrap a service in a particular rule. Your hosts.allow file might look similar to:

// Allow localhost ALL : 127.0.0.1
// Allow SSH Access to anyone except from 192.168.1.101
sshd : ALL EXCEPT 192.168.1.101 : ALLOW

Your /etc/hosts.deny file might resemble:

// No one can connect via anything except loopback localhost
ALL : ALL EXCEPT 127.0.0.1:DENY

Intrusion Detection

You may want to consider using a package like Tripwire to detect intrusions. It doesn't come with Red Hat 9, but you can get the source and compile it yourself. It creates and compares the hashes of critical files to determine whether any changes have been made.

An effective hacker won't just break into your system. He will also create a back door for himself so that he can gain access at other times. Most of the time, these back doors are in exploited files, and this is one way you can protect against this occurrence.

Summary

There are many other tricks and tips available to the security-conscious system administrator. The key to being effective is to always be on your toes and ready to think outside the box. There's generally more than one way to skin a cat, and hackers are consistently inventing or discovering new means.

Please don't read this article and think this is the last word in system security. These tips merely scratch the surface. Happy guarding!

Aaron Brazell is an author and blogger from Baltimore, Maryland, and is the primary system administrator for b5media, a network of more than 100 blogs.


Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.