The Linux Operating System is one of the most stable and diverse OS’s 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’re planning 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 RedHat. Other open source varieties include Mandrake, Debian, or SuSE. We’ll be referring to the RedHat 9 distro throughout this tutorial.
Do Not Turn Your Brain Off At The Door!
Warning! If you think that reading this article will give you all the information you need to be a systems administrator, think again. This article will cover the basics of security, but it is not intended to be a substitute for common sense, nor the necessary interactive thinking of a competent systems administrator.
This is not a fix-all! Hackers and attackers constantly reinvent themselves and a good systems administrator will be versatile and adept, reinventing himself as necessary. I recommend these sources to help you stay on top of systems administration and security issues pertaining to your Linux server:
Installation
Before you can really get going, you have to install your Linux distro. Because we’re setting up a server, we are going to run without X-Windows (the graphical user interface that ships with Redhat). You may choose to install X if you wish, but we won’t use it in this tutorial.
The rule of thumb we’re operating under here, is that, if something is not needed, we’re not going to enable it. The reason for this approach is that the more services and modules that you have installed, the greater is 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. You can use the following command to locate a file: find / -name filename. You can also use tools such as pico or vi to edit a file, by executing the following command:
# pico fileor
# vi fileLockdown
This is the first thing you want to do to secure your new Linux box. There are a number of actions that can be taken to prevent dangerous activity.
Changing the root PasswordThe 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 this once every 30 days, and it’s also wise to come up with a password that will not be easily cracked. There are apps out there that can run a password list against a dictionary and try to crack passwords that way. There are also apps that will run a password list against a dictionary, and against “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 is 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. With suid, an underprivileged user can run an application as if they were a privileged user. For instance, 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.
You can find out which files are using suid by executing the following command. Anything with an ‘s’ in the permission column (on the left) is enabled to run with suid.
# ls -alF `find / -perm -4000` > /root/suid.txtOn 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 systems administrators will recommend the deactivation of services like ping and traceroute, which are not required. In this particular output, I’m going to disable /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 and /usr/sbin/ping6, /bin/ping.
To disable suid on a file, use the following command. This makes the file executable only by the owner, and also makes it immutable (unable to be modified or deleted, or even linked to):
# chmod 111 /path/to/file
# chattr +I /path/to/fileRemember, the rule of thumb is if something isn’t needed, disable it!
/etc/securetty — Next, you’ll want to 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, and 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 (i.e. comment out, 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. Our box has the following /etc/securetty file before we get to it.
# 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
#tty11We are going to 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 telnet is disabled for the method of transmission, FTP should also not be used 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 Access (SSH) to its users. But, back to the topic at hand.
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, 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 needed.
On our system, we’ll descend further, to the /etc/xinet.d/ directory, where a file is listed for each of the default internetworking services. On our 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 look similar to this:
# 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. Make sure that, whenever you make any changes to these files, you restart the inet daemon using:
# /etc/rc.d/init.s/inet restartipchains
ipchainsis Linux's answer to a firewall. There are a lot of neat tricks that can be performed withipchains, and you can search for those tricks on Google. But 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 over-technical. PLEASE BE CAREFUL, AS YOU CAN EASILY LOCK YOURSELF OUT OF YOUR OWN BOX.It is important to recognize that
ipchainsactually refers to three separate chains. A typicalipchaincommand consists of several parts.Firstly, it carries one of 3 commands.
-F flushes a chain-P sets the handling for a chain-A adds a new rule to the chainTo set up a chain, you might use:
# ipchains --F input
# ipchains --A input REJECTThis 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 Linux box in the world is connected to a network or the Internet, so it’s not realistic to use such a blanket command.
Let’s look at some more options available to us, to setup a more intelligent filtering system. Let’s say your Linux box is a development server accessible only on the local LAN. The IP of its network device is 192.168.25.4 and has 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 the ipconfig command 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 this:
# ipchains --A input --I eth0 -s 192.168.1.0/255.255.255.0 --d 192.168.25.4 --j ACCEPTWhat the heck does that mean? Let’s analyse.
ipchains --A input — As mentioned above, this adds a rule to the input chain.-I eth0 – This tells the firewall that the packet traffic on which we want to run this rule is attached to Ethernet Network Device 0 (Eth0).-s 192.168.1.0/255.255.255.0 — the source, or sending IP is at 192.168.1.0. The number after the slash denotes the mask, which in our case is 255.255.255.0ACCEPT designates that all traffic from this source should be allowed. You could also use REJECT to keep traffic out.The best bet for ipchains firewalling lies within its documentation, which can be found here.
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 deal with items called tcp wrappers, which simply “wrap” a service in a particular rule. Your hosts.allow file might look similar to this:
// 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 : ALLOWYour /etc/hosts.deny file might look similar:
// No one can connect via anything except loopback localhost
ALL : ALL EXCEPT 127.0.0.1:DENYIntrusion Detection
You may want to consider using a package like Tripwire to detect intrusions. It doesn’t come with Redhat, but you can get the source and compile it yourself. The way it works is that 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 backdoor for himself so that he can gain access at other times. Most of the time, these backdoors 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 systems 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 do not read this article and think that this is the be-all and end-all of system security. These tips merely scratch the surface. Happy guarding!l
abrazellAaron Brazell is the senior technology manager for b5media, a new media network. He is a well known and respected voice in the world of blogging and social media and has a passion for written communication. He has been developing in PHP for six years and has been actively involved with WordPress for nearly three years. He writes on his blog, Technosailor and is available for WordPress consulting
