Chapter 12. Strategies for Keeping a Secure Server
Linux can certainly be considered to be as secure -- or more secure -- than operating systems from other vendors. Admittedly, with Linux becoming more and more popular, it is becoming a very attractive target for crackers to concentrate their break-in efforts on. There are exploits that are discovered from time to time, however the open nature of Linux usually means that such exploits are patched quickly, and security announcements are disseminated widely, containing either temporary workarounds or pointers to updated software.
I won't pretend to be an expert on security issues, however I am at least aware of these issues, which I believe to be a large part of the battle towards making one's systems as secure as possible. Although being aware and diligent in keeping up with security updates will in no way guarantee that a system's security measures won't be circumvented, the likelihood of a break-in is greatly reduced.
Although there have been security exploits found in external services which could have been used by crackers to break into a system (for example, the IMAP daemon exploit), I believe that it is far more likely that a determined cracker will penetrate the system from within. Compared to the handful of services communicating with the outside world, there are thousands of commands and utilities available from the shell, one or more of which may contain bugs which can be exploited to penetrate security (that being said, I must admit to recently discovering one of the servers I maintain had been compromised through an external service).
For this reason, I recommend avoiding giving out shell accounts to users unless they are absolutely necessary. Even if you consider your users completely trustworthy and have no qualms in providing them with access to the shell, all it takes is just one of these users to have a weak password. An outside cracker, finding its way into your system by exploiting this weak password, will then be able to work at his or her leisure internally, looking for further weaknesses.
There are, fortunately, things you can do to greatly increase the security of your Linux system. While a detailed discussion of security issues is beyond the scope of this document, the following checklist provides some of the most important things you should do to enhance security:
Upgrade system tools, applications, and kernel: By far the most common cause of system break-ins is by not exercising diligence in keeping an up-to-date server. Performing regular upgrades of the system kernel, tools and utilities will ensure that your system is not filled with older items for which known exploits are available. For details on keeping an up-to-date server, see the section called Downloading and Installing Red Hat Updates in Chapter 4, as well as the section called Strategies for Keeping an Up-to-date System in Chapter 10.
Shadow passwords: You should definitely be using Shadow passwords; switching to this password format is easy! For details, see the section called Linux Password & Shadow File Formats in Chapter 6.
Smart password management: Make sure passwords, especially for users you are providing with shell access, are strong and changed often. Also, if you use multiple servers, resist the temptation to use the same password for all of them (otherwise, if a cracker breaks into one server using a discovered password, he or she can break into them all).
Use secure shell (ssh): Switch to using ``ssh'' instead of ``telnet''. Telnet is insecure for two reasons: One, sessions are unencrypted, which means everything, including username and passwords, are transmitted as clear text. Second, an open telnet port is one of the first places a cracker will try to connect to.
Ssh provides encrypted and compressed connections and provide substantially more security than telnet connections. You can run a ssh server (which allows incoming secure connections) as well as a client (for outgoing secure connections) under Linux. You can find binary RPM packages at ftp://ftp.replay.com/pub/replay/redhat/i386/. You will need the following files (newer versions may be available by the time you read this):
ssh-1.2.27-5i.i386.rpm The base package.
ssh-clients-1.2.27-5i.i386.rpm Clients for outgoing connections.
ssh-extras-1.2.27-5i.i386.rpm Some handy perl-based scripts.
ssh-server-1.2.27-5i.i386.rpm Server for incoming connections.
Note: The SSH RPM files listed above are the international versions. If you reside in the U.S. or Canada, you can choose to download the U.S. packages (which may have stronger encryption algorithms); these packages have a ``us'' instead of an ``i'' suffix after their version numbers. Under U.S. law, it is illegal to export strong crypto products outside of the U.S. or Canada. Hopefully one day the morons in the U.S. Department of Justice will finally see the light, and remove this silly restriction (Red Hat doesn't include SSH with their distribution because of this very reason, and we all suffer).
Should your Windows users be up-in-arms about no longer being able to connect to your system, they will be happy to know that several free ssh clients for Windows are available:
- “TeraTerm Pro” client software
- “TTSSH” client software
- “Cryptlib” client software
- “Putty” client software
Note: If you do decide to switch to using ssh, make sure you install and use it on all your servers. Having five secure servers and one insecure one is a waste of time, especially if you are foolish enough to use the same password for more than one server.
Restrict access to external services: Next, you should edit the ``/etc/hosts.allow'' as well as the ``/etc/hosts.deny'' file to restrict access to services to external hosts. Here is an example of how to restrict telnet and ftp access. First, the ``/etc/hosts.allow'' file:
# hosts.allow in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name
The above would allow any hosts in the IP class C's 123.12.41.* and 126.27.18.*, as well as any host within the mydomain.name and another.name domains to make telnet and ftp connections.
Next, the ``/etc/hosts.deny'' file:
# hosts.deny in.telnetd: ALL in.ftpd: ALL
Turn off and uninstall unneeded services: Edit your ``/etc/inetd.conf'' file, and disable (ie. comment out using a ``#'' character) any services that are not needed (if you're using ssh as recommended above, you might wish to disable the ``telnet'' service). After you have done so, as root type ``/etc/rc.d/init.d/inet restart'' to restart the inetd daemon with the changes.
Install a security detection system: Consider installing security programs such as ``Tripwire'' (see http://www.tripwiresecurity.com/) which can detect intrusions, and ``Abacus Sentry'' (see http://www.psionic.com/abacus/) which can help prevent them.
Due diligence: Keeping your eye on your system, performing random security audits (which can be as simple as checking for suspicious entries in the password files, examining your process list, and checking your log files for suspicious entries) can go a long way towards keeping a secure system. In addition, report any break-in attempts to the appropriate authorities -- it may be a hassle to do this, particularly if your system sees several of these attacks in a given week, but such reports ensures that would-be crackers are deterred by threat of punishment, as well as ensuring that others' systems (which may themselves have been compromised) are kept secure.
Assuming you install and upgrade system tools and applications using the ``RPM'' utility, you may wish to verify the integrity of your installed packages by auditing them with the following command:
rpm --verify -a > /tmp/rpm-audit.txt
The above command will check your system's RPM database with all relevant files, and indicate any files which have been modified, by displaying a '5'. Here is some example output of such an audit:
S.5....T /bin/ls S.5....T /usr/bin/du ......G. /dev/tty5 .....U.. /dev/vcs5 .....U.. /dev/vcsa5 S.5....T c /etc/lynx.cfg S.5....T c /etc/sendmail.cf
In the sample output above, you can see a list of seven files, four of which have been modified. Now, obviously there are going to be several, perhaps many, files which have been modified if you have customized your system at all. A brief check of the /etc/lynx.cfg and /etc/sendmail.cf files, perhaps visually or perhaps from backup, might reveal legitimate configuration changes that you have made to your system.
However, notice in the sample above, two of the modified files are binary executable files? It is likely that these two binaries, the ``ls'' command as well as the ``du'' command, are actually trojan binaries which a system cracker has installed to perform some nefarious purposes (a ``diff'' command performed on any modified binaries with those restored from backup or RPM might reveal significant size or other differences; further evidence of trojans.)
(For more information on ``RPM'', see the section called Using the Red Hat Package Manager (RPM) in Chapter 10.)
For more information on security-related issues, an excellent resource entitled, “Securing RedHat 5.x” document is available at http://redhat-security.ens.utulsa.edu/. An excellent resource for Linux crypto and related software is at http://replay.com/redhat/.