Adding Security to Common Linux Distributions

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

System Administration

AuthorImage:[Here we need a little image from you]

[Photo of the Author]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in en Michael Jastremski

AboutTheAuthor:[A small biography about the author]

Michael Jastremski has been hacking Unix for about the past four years. His website can usually be found at . He thanks Andrew <andy(at)> for help with his English.

Abstract:[Here you write a little summary]

This article discusses ways in which system administrators can help secure there system from intruders. It discusses several ways to improve the security of Linux systems.

ArticleIllustration:[One image that will end up at the top of the article]


ArticleBody:[The main part of the article]


Large scale attempts at compromising internet computers are becoming commonplace. Linux and FreeBSD servers have increasingly become the target of recent attacks, involving buffer overflows in the imapd and BIND sources. Every day, vulnerabilities of all shapes and sizes are unleashed upon the nearly 20,000 subscribers of BUGTRAQ mailing list (If you only subscribe to one security mailing list, this is the one ).

It would be judicious to assume that at least one of those 19,305 subscribers is going to write a for() loop and a little bit of logic around a cut+paste exploit in the hope of efficiently gaining access to as many computers as possible..

Sooner or later, the loop will construct the address of your computer. There is no time like the present to prepare.

Despite what some 'experts' may have you believe, installing and maintaining a secure computer isn't rocket science.. Sound system administration practices serve as protection from the menaces of the global network. This article describes some of the precautions i generally take when configuring a networked RedHat Linux system. While this article provides guidelines for protecting your computer from the malicious intent of others, it is not intended to be a complete reference.

The following are some steps which will hopefully prevent your installation from falling victim the next publicized hole in your network software. WARNING: If you're not exactly sure of what you're doing, don't do it. Some of these steps assume a moderate degree of cluefulness on your part. Warranty void in Alaska,Hawaii & Puerto Rico. Some suggested reading is mentioned at the end..

Steps to safety

1. Remove all unnecessary network services from your system. Fewer ways to connect to your computer equal fewer ways for an intruder to break in to your computer. Comment out everything you don't need from /etc/inetd.conf. Don't need telnet on this system? Disable it. Same goes for ftpd,rshd,rexecd,gopher,chargen, echo,pop3d and friends. Dont forget to do a 'killall -HUP inetd' after editing inetd.conf. Also don't neglect the /etc/rc.d/init.d directory. Some network services (BIND,printer daemons) are standalone programs started from these scripts.

2. Install SSH. SSH is a drop-in replacement for most of those antiquated Berkeley 'r' commands. From the homepage at

Ssh (Secure Shell) is a program to log into another 
computer over a network, to execute commands in a
remote machine, and to move files from one machine 
to another. It provides strong authentication 
and secure communications over insecure channels.

It also does lots of other stuff any aspiring hacker should find interesting. Download SSH from .

3. Use vipw(1) to lock any non-login accounts. Note that under RedHat Linux, accounts with a null login shell names are default to /bin/sh, which is probably not what you want. Also make sure that none of your accounts have null password fields. The following is an example of what the system part of a healthy password file might look like.

  ftp:*:14:50:FTP User:/home/ftp:/bin/sync

4. Remove the 's' bits from root-owned programs that won't require such privelege. This can be accomplished by executing the command 'chmod a-s' with the name(s) of the offending files as it's arguments.

Such programs include, but aren't limited to:

  1. programs you never use
  2. programs that you don't want any non-root users to run
  3. programs you use occasionallly, and don't mind having to su(1) to root to run.

I've placed an asterisk (*) next to each program i personally might disable. Remember that your system needs some suid root programs to work properly, so be careful.

Alternately, you could create a special group called 'suidexec', place trusted user accounts into this group. chgrp(1) the iffy suid program(s) to the suidexec group, and remove the world execute permissions.

# find / -user root -perm "-u+s"    
*/bin/mount              -- only root should be mounting
*/bin/umount             -- same here    
/bin/su                  -- don't touch this!
*/sbin/cardctl           -- PCMCIA card control utility
*/usr/bin/rcp            -- Use ssh
*/usr/bin/rlogin         -- ditto
*/usr/bin/rsh            --  "
*/usr/bin/at             -- use cron, or disable altogether
*/usr/bin/lpq            -- install LPRNG
*/usr/bin/lpr            -- "
*/usr/bin/lprm           -- "
/usr/bin/passwd          -- don't touch! 
*/usr/bin/suidperl       -- each new version of suidperl 
                         seems to have a buffer overflow
*/usr/bin/sperl5.003     -- use it only if necessary
/usr/bin/procmail        -- 
*/usr/X11R6/bin/dga      -- lots of buffer overflows 
                            in X11 as well
*/usr/X11R6/bin/xterm    -- "
*/usr/X11R6/bin/XF86_SVGA   -- "    
*/usr/sbin/traceroute    -- you can  stand to type the 
                         root password once in a while.

5. Upgrade sendmail. Download the source from il. Unpack it and read the instructions. Install smrsh (packaged with sendmail) if you have a couple extra minutes. this program addresses many of the concerns people have with sendmail, such as sending email to arbitrary programs. Edit and set the 'PrivacyOptions' option to 'goaway':

        O PrivacyOptions=goaway

If you don't plan to receive internet email, DON'T RUN SENDMAIL IN RECEIVE MODE (sendmail -bd)!. In this case, disable /etc/rc.d/init.d/sendmail.init and do a 'killall -TERM sendmail'. You'll still be able to send outbound email.

6. Upgrade BIND if you use it. The latest BIND can be found at . Otherwise disable it altogether.

7. Recompile the kernel. I usually do this if just to reduce the bloat of the default kernel. HINT: turn on all of the firewalling options even if the computer isn't a firewall.

        # CONFIG_IP_FORWARD is not set
        # CONFIG_IP_MULTICAST is not set
        # CONFIG_IP_MASQUERADE is not set
        # CONFIG_IP_TRANSPARENT_PROXY is not set
        # CONFIG_IP_ROUTER is not set
        # CONFIG_NET_IPIP is not set

8. Apply patches: Any known problems with their software can be found at RedHat on their Errata pages. (see to see which patches apply to your release. RedHat does a very good job of keeping those pages up to date. They also includes links to the RPM files you'll need with installation instructions.

9. Configure tcp_wrappers: Tcp_wrappers are a method for controlling which computers on the 'net(c) are permitted to 'talk' to your computer. This package, written by security guru Wieste Venema, sits in front of programs run from inetd (or those linked with it's library) consulting it's configuration files to determine whether to deny or permit a network transaction. For example, to allow telnet & ftp from home via your isp, while denying everything else, put the following in /etc/hosts.allow:

        in.ftpd : : allow
        all : all : deny 

SSH, sendmail and other packages can be built with tcp_wrappers support. Read the tcpd(1) manual page for further information.