Printed 12/23/2003 - 12:44 PM

Nortel Networks

Linux Operating System Hardening

Guideline Document

Issue 1.0

Issue Date November, 2003

Author Nortel Networks

Please Note
THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND DOES NOT CONSTITUTE
ADVICE. ANY RELIANCE UPON THIS DOCUMENT SHALL BE AT YOUR OWN RISK. THE
INFORMATION CONTAINED HEREIN IS PROVIDED “AS IS” WITHOUT ANY WARRANTIES OF
ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-
INFRINGEMENT. IN NO EVENT SHALL NORTEL NETWORKS, ITS AGENTS OR SUPPLIERS BE
LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), WHETHER IN CONTRACT, TORT OR
OTHERWISE (INCLUDING NEGLIGENCE) FROM USE OF OR RELIANCE UPON THE INFORMATION
CONTAINED HEREIN, EVEN IF NORTEL NETWORKS, ITS AGENTS OR SUPPLIERS HAVE BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

© Copyright Nortel Networks 2003. This document is the property of Nortel Networks who
own the copyright therein. The information in this document is given in confidence and
without the written consent of Nortel Networks given by contract or otherwise the document
must not be copied reprinted or reproduced in any material form either wholly or in part nor
must the contents of the document or any method or technique available there from be
disclosed to any third party.

Page 2 0f 30
Summary
This document provides background information and detailed steps that should be taken in
order to harden the Linux operating system against common network security attacks. Please
note however that operating system hardening procedures cannot be followed blindly.
Operating system hardening involves, among other things, turning off all services that are not
required for particular application. For this reason, each operating system hardening instance
must be customized and this document should only be considered as a general guideline to
follow during this customization.

Page 3 0f 30
Table of Contents
1. Purpose of OS Hardening...................................................................................... 5
2. Linux Hardening Procedure .................................................................................. 6
Step 0: Installing Linux .......................................................................................................... 6
Step 1: Removing Unnecessary Software Packages and Processes ........................... 7
Step 2: Setting up Time Synchronization Using NTP..................................................... 11
Step 3: Configuring Syslog and Installing Log Analyzer ................................................ 12
Step 4: Disabling sendmail Service................................................................................... 14
Step 5: Tightening up the System ..................................................................................... 15
Step 6: File System Lockdown........................................................................................... 22
Step 7: Vulnerability Testing and Patching ...................................................................... 23
Appendix A : Recommended Software for Servers.................................................. 24
Appendix B : Log Analyzers ........................................................................................... 26
Appendix C: Minimal sendmail configuration file..................................................... 29
Appendix D: Sample /etc/lilo.conf file .......................................................................... 30
Appendix E: References .................................................................................................. 30

Page 4 0f 30
 1. Purpose of OS Hardening
Computers and network elements connected to networks are vulnerable to attacks. The following is a
list of commonly known types of attacks:

1. Viruses, worms, backdoors and Trojan programs.

2. Wire tapping and sniffing
3. Password cracking
4. Exploits of known vulnerabilities such as software buffer overflow
5. Denial of services (DOS)

Some of these attacks are based on well-publicized techniques, with scripts and other tools available
to make it possible for less knowledgeable crackers to apply exploits against systems. Once a system
has been compromised, an intruder can do a number of things, including the following:

1. Modify or destroy information

2. Disclose sensitive information
3. Install malicious code to gather information
4. Use the compromised server to attack other systems

Our goal is to provide some reference guidelines so that you can use to improve the resistance of
your Linux-based systems to attacks. We present what we believe to be sound practices. But we
must point out that no system is absolutely secure and that continued vigilance is still required even
after your system has been hardened. It is highly recommended that you monitor early warning
forums such as http://www.cert.org to obtain the newest vulnerability reports and stay on your
vendor’s bug-fix mailing list to get the latest security patches and bug fixes for the Linux operating
system you use.

The hardening procedure is verified on RedHat Linux 7 and 9 and may be adapted for other Linux
based systems.

We assume that you have working knowledge of Linux or general UNIX system administration and
that the system installation and hardening will be performed in an isolated or safe network
environment.

Page 5 0f 30
 2. Linux Hardening Procedure
Step 0: Installing Linux

Before installing a Linux distribution, we need to decide what the server or workstation is going to be
used for. The rule of thumb is to install only what you need because the general principle of OS
hardening is to strip down the system to the minimum necessary to perform the function it is set up
for.

A modem Linux distribution allows a user to choose the installation type best for the intended
purpose. Red Hat, for example, provides the following five installation types:

1. Workstation -- A workstation installation will create a system for general desktop use. A
graphical environment will be installed. This can be GNOME or KDE or both. Workstation
installation will not install the network daemon xinetd (inet services), as a result, in-bound
network-related services such as finger, telnet, talk and FTP will not work.
2. Server -- A server installation will allow your system to function as a Linux-based server.
There are three subcategories: server minimum without graphical interface, full server without
graphical interface and full server with graphical interface.
3. Laptop -- Much like a workstation installation.
4. Custom -- A custom installation allows you the greatest flexibility during your installation.
However, with flexibility also comes complexity. An improperly customized system may not
even be functional. In that sense, we recommend that you either select Workstation or Server
depending on the intended purpose of the system and use OS hardening procedures later on
to secure the new system.
5. Upgrade -- If you already have a version of Red Hat Linux (3.0.3 or greater – please note that
Red Hat has announced that there will be no more Red Hat Linux after version 9) running on
your system and you want to quickly update to the latest packages and kernel version, then
an upgrade is most appropriate for you.

This document focuses on hardening the server. But the techniques can be used to help secure a
Linux-based workstation as well. Appendix A contains a list of recommended software to be included
into the server installation.

Page 6 0f 30
Step 1: Removing Unnecessary Software Packages and Processes

Unneeded software packages and files

Many unnecessary programs are installed by default even though you may have chosen to install a
base system. For example, the Red Hat server installation option will install the following software you
don’t need without allowing you to deselect them at the time of installation:

anacron – cron-like program for systems that don’t run 24 hours a day
apmd – advanced power management daemon for notebook batteries
at – job scheduler
dhcpcd – dhcp client daemon
dosfstools – DOS file system tools
eject – eject removable media
hotplug – hot plug and play
ipchains – obsolete firewall
ksymoops – kernel oops decoder (removed in Red Hat 9 by default)
kudzu – auto config of new hardware
lokkit – utility to set up ipchains firewall
mailcap – metamail capabilities file
pciutils – utilities to inspect and set up devices connected to PCI bus
pump – dhcp or bootp client
raidtools – raid tools
redhat-logos – contains the Red Hat “shadow man” logo and the RPM logo
redhat-release - contains Red Hat Linux release files
setserial – set serial port utility

So the first thing to do after the server installation is to uninstall the unnecessary software. Use the
following RPM command to uninstall them:
[root@wen /]# rpm -e <softwarenames>
where <softwarenames> is the name of the software you want to uninstall, e.g., anacron.

Programs like anacron, apmd and at are daemons that run as processes in the background. It’s better
to stop them before uninstalling from the system. To stop a process, use the following command:
[root@wen /]# /etc/rc.d/init.d/proccessname stop

Example:
# /etc/rc.d/init.d/apmd stop
Shutting down APM daemon: [OK]

Once the processes have been stopped, you can uninstall the software by using the following
command:
[root@wen /]# rpm –e –-nodeps software-name

Example:
[root@wen /]# rpm –e –nodeps anacron apmd at dhcpcd dosfstools eject

This will uninstall anacron, apmd, at, dhcpcd, dosfstools and eject software packages. You may add
more to the list to get all of them removed. Or you may do it in smaller groups or individually. The

Page 7 0f 30
anacron daemon has a spool directory at /var/spool/anacron which should be removed after the
daemon is uninstalled. The command to remove that directory is “rm –rf /var/spool/anacron”

The following programs are used for specific types of harddisks. You need to keep only the one that’s
designed for your type of harddisk(s). Use the rpm command to remove one of the two – unless the
server has both IDE and SCSI disks:

hdparm – is needed by IDE harddisks only; not by SCSI disks.

mkinitrd – is needed by SCSI or RAID disks; not by IDE disks.

The following programs are used to set up your keyboard language and type, your mouse type, your
default time zone, your NIS and shadow passwords, your numerous symbolic links in /etc/rc.d
directory, and text mode menu utility which allow you to access all of these features. It’s
recommended that they be removed using the command rpm after the server has been properly
configured for deployment.

kbdconfig authconfig
mouseconfig ntsysv
timeconfig setuptool

The following programs may be removed if they are not needed for the intended purpose of the
server.

ash – smaller version of Bourne shell

ash.static – smaller version of Bourne shell statically linked
cyrus-sasl – simple authentication and security layer for cyrus electronic messaging program
krb5-libs – shared libraries needed by Kerberos 5. After krb5-libs is removed using rpm command,
the /usr/kerberos directory can be removed using “rm –rf” command
openldap – directory accessing protocols and application package
procmail – mail processing program which can be used by sendmail for local delivery
quota – used to monitor/limit user/group disk usage
sendmail – mail transport agent (MTA)
tcsh – another commonly used shell
time – used by developers to optimize their programs

The last checkpoint for installation of software packages is to make sure that the compilers and
development packages are not installed or have been removed after the server has been properly set
up and configured for deployment. You may simply delete it from the directory where it resides. If the
installation is done via RPM, you may use the following command to remove it:

[root@wen /]# rpm –e [compiler package name]

You may also want to remove the documentation files. By default the majority of each RPM’s
packages installed under Linux comes with documentation files related to the software. This
documentation contains original files from the program tar archive like README, FAQ, BUG,
INSTALL, NEWS, Many of them can be easily retrieved from the website where the program has
been downloaded and it makes no sense for them to be kept on your system. To remove the
documentation files, execute the following commands:

[root@wen /]# cd /usr/share/doc/

[root@wen /]# rm –rf *

Unneeded services
A lot of unneeded services are installed and started up automatically by default after installing a Linux
system. The next step to harden the operating system is to remove them from the startup files in

Page 8 0f 30
/etc/rc3.d directory, assuming the server boots into Runlevel 3 multi-user mode. The following is a list
of auto-configuration soft links pointing to the actual scripts in /etc/rc.d/init.d directory (your listing may
vary slightly depending on your distribution, version and installation):

1. S05apmd -> ../init.d/apmd

2. S10network -> ../init.d/network
3. S11portmap -> ../init.d/portmap
4. S15netfs -> ../init.d/netfs
5. S20random -> ../init.d/random
6. S30syslog -> ../init.d/syslog
7. S32gated -> ../init.d/gated
8. S40atd -> ../init.d/atd
9. S40crond -> ../init.d/crond
10. S45pcmcia -> ../init.d/pcmcia
11. S50inet -> ../init.d/inet
12. S55named -> ../init.d/named
13. S60lpd -> ../init.d/lpd
14. S60mars-nwe -> ../init.d/mars-nwe
15. S60nfs -> ../init.d/nfs
16. S65dhcpd -> ../init.d/dhcpd
17. S72amd -> ../init.d/autofs
18. S75keytable -> ../init.d/keytable
19. S80sendmail -> ../init.d/sendmail
20. S85gpm -> ../init.d/gpm
21. S85httpd -> ../init.d/httpd
22. S90xfs -> ../init.d/xfs
23. S91smb -> ../init.d/smb
24. S95innd -> ../init.d/innd
25. S99linuxconf -> ../init.d/linuxconf
26. S99local -> ../rc.local

You can rename or remove the links and files that you don’t need so the unnecessary services
associated with them will not be automatically brought up upon system reboot. A more radical
approach would be to delete them completely. It is recommended that the files be renamed first and
be removed after thorough tests have been done to make sure the system works as expected. You
may also want to rename or remove files in other runlevel directories such as the graphic multi-use
mode if it is not used by your system.

If you are hardening a pre-installed Linux system, you may see more services depending on the
install option selected at the time of installation. The rule of thumb is that you should disable all the
services that you are not using. You can also manually move the file to a new name. As long as the
file does not start with a capital letter S, it will not be automatically started upon system reboot. The
scripts provided below rename the files of unnecessary services as .Nofilename, for example,
S05apmd becomes .NoS05apmd.

#This script renames the first five unneeded services

#in /etc/rc.d/rc3.d. You can repeat it to disable all
#the services you are not using
cd /etc/rc.d/rc3.d
for file in S05apmd S15netfs S32gated S40atd S45pcmcia
do
mv $file .NO$file
done

Page 9 0f 30
The next step is to disable unnecessary network services managed by the inetd or xinetd process. In
principle, the following default services should all be disabled:

echo stream tcp nowait root internal

echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
comsat dgram udp wait root /usr/sbin/tcpd in.comsat
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
bootps dgram udp wait root /usr/sbin/tcpd bootpd
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o

To disable a service, open the file /etc/inetd.conf with a text editor such as vi and place a # sign in
front of the line. If your Linux uses xinetd instead of inetd, edit the /etc/xinetd.conf and /etc/xinetd.d
directory to disable unneeded services. The following is a sample xinetd.conf file:

#
# Simple configuration file for xinetd
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
}
includedir /etc/xinetd.d

To disable a service, edit the file in the /etc/xinetd.d and make sure “disable = yes” as illustrated in
this ftp example:

# Converted by inetdconvert
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root

Page 10 0f 30
 server = in.ftpd
server_args = -l -a
disable = yes
}

The super internet server inetd or xinetd should be restarted in order for the changes to take effect.
Or you can reboot the system.

Please note that for a production system, it is highly recommended that the files be removed if the
services have been disabled as per security policy. If no services are enabled, inetd or xinetd should
be disabled and removed from the system as well.

If you need remote terminal access and file transfer capabilities, you can install OpenSSH which is a
safer replacement for remote login, telnet and ftp. You can get OpenSSH at the following URL:
http://www.openssh.org

Next you can empty crontabs and clean out the password file. You should leave only the cron jobs
and user names you know that are necessary for the intended purpose of the server and remove the
rest. The following is just an example:

cd /var/spool/cron/crontabs
rm adm lp sys
for user in adm lp news uucp operator games gopher ftp
do
/usr/sbin/userdel –r $user
done

You may want to edit the password file and make /dev/null the shell for all but root and authorized
users. Shadow password shall be used by default.

Step 2: Setting up Time Synchronization Using NTP

System timekeeping can be done via both xntpd/ntpd (daemon) and ntpdate/rdate (client). While the
daemon may provide more network functionalities, it also presents volunerabilities, one of which is
xntpd buffer-overflow. Unlike xntpd which listens on UDP port 123, ntpdate/rdate is a client to be
executed only when needed to get the time of day from a pre-defined NTP server.

Accurate system time is essential for the validity of the system logs. It is recommended that
ntpdate/rdate be used to set system clock. If daemons must be used, it is highly recommended that
its access be restricted to the IP you know and, if applicable, be protected by authorization keys.
Please refere to Appendix X for information on Nortel Networks Security Advisory Task Force (SATF)
Triage Process of handling vulnerabilities and vendor patches.

Add the following to /etc/rc.local startup script to set the time of day at boot time if you decide to use
rdate:

/usr/sbin/rdate –s NTP_server_addr

The –s switch will set system time to the returned time. For precise timekeeping this command can
also be run from a cron job every hour on the hour:

0 * * * * /usr/sbin/rdate –s NTP_server_addr

Page 11 0f 30
Step 3: Configuring Syslog and Installing Log Analyzer

Syslog configuration for local and remote logging

Syslogd provides both local and remote logging. It is able to send messages to a remote host running
syslogd. To forward messages to another host, prepend the hostname with the at sign (``@''). For
security reasons, it is recommended that logs be sent to both the local files and a dedicated syslog
server.

The host that functions as a syslog server should have syslogd started with the –r switch in order to
receive messages from other hosts.

A main purpose of logging is for the system administrators to review and discover abnormality
including attempts of unauthorized access. For this reason it is recommended that separate log files
be used to make the task of log analysis more manageable.

The following table lists five major categories:

/var/log/messages User level information and the programs they run

/var/log/maillog Mail log if the server runs a MTA such as sendmail
/var/log/secure User authentication information
/var/log/daemon-log Daemon log
/var/log/cron-log Cron log

The following is a sample syslog configuration for a Linux system to log messages for the above
listed categories in local files and sending them over to a log server:

info;cron.none;mail.none;authpriv.none;daemon.none /var/log/messages
info;cron.none;mail.none;authpriv.none;daemon.none @log_server

authpriv.*;auth.* /var/log/maillog
authpriv.*;auth.* @log_server

mail.* /var/log/maillog
mail.* @log_server

daemon.* /var/log/daemon-log
daemon.* @log_server

cron.* /var/log/cron-log
cron.* @log_server

You can comment out or remove the second line of each pair from the above sample configuration
file if you only intend to log to local files only.

Log rotation
Logrotate is a Linux utility that renames and re-uses syslog files on a periodic basis so that they don’t
occupy excessive disk space. The /etc/logrotate.conf file is a general configuration file in which you
can specify the frequency with which the files are re-used. You can specify “monthly”, “weekly” or
“daily” rotation keywords depending on how much information syslog collects on the server. You can
also specify how many weeks worth of backlogs to keep on the server as per your security policy on
log retention.

Log analyzer
Log information is useless unless it is reviewed and analyzed in a timely manner. Appendix B
provides a list of commonly used log analyzers for the Linux platform. While they all have their own

Page 12 0f 30
unique features and strengths, logcheck is among the most widely used and highly recommended
syslog analyzers. The whole process follows the following structure:

logcheck.sh executes hourly ---->

logcheck.sh executes logtail on log files ---->
logtail parses off any text from the last time it was run --->
logcheck greps text for system attack messages --->
logcheck greps text for security violations --->
logcheck greps text for security violations to ignore --->
logcheck greps text for all messages to ignore. --->
any messages found are mailed to system admin.

To install logcheck, download the rpm package using the URL supplied from Appendix B and execute
the following command:

[root@wen /]# rpm -Uhv logcheck-1.1.1-8mdk.i586.rpm

Preparing... ########################################### [100%]
1:logcheck ########################################### [100%]

The following files will be installed:

/etc/cron.daily/logcheck
/etc/logcheck/hacking
/etc/logcheck/ignore
/etc/logcheck/violations
/etc/logcheck/violations.ignore
/usr/bin/logcheck.sh
/usr/bin/logtail
/usr/share/doc/logcheck-1.1.1
/usr/share/doc/logcheck-1.1.1/CHANGES
/usr/share/doc/logcheck-1.1.1/CREDITS
/usr/share/doc/logcheck-1.1.1/INSTALL
/usr/share/doc/logcheck-1.1.1/LICENSE
/usr/share/doc/logcheck-1.1.1/README
/usr/share/doc/logcheck-1.1.1/README.how.to.interpret
/usr/share/doc/logcheck-1.1.1/README.keywords
/usr/share/doc/logcheck-1.1.1/README.linux
/usr/share/doc/logcheck-1.1.1/README.linux.IMPORTANT
/var/lib/logcheck

Read the INTALL and README files at /usr/share/doc/logcheck-1.1.1 subdirectory for more
information on how to use logcheck. You may want to remove the entire logcheck documentation
subdirectory once logcheck is properly configured and is working as expected.

Logcheck has been freely distributed since its first release by Psionic under the GPL license.
However, Psionic has recently been bought by CISCO, which may or may not have an impact on
commercial use of logcheck. You may want to consult your legal department first.

Page 13 0f 30
Step 4: Disabling sendmail Service

MTA such as sendmail may be disabled as a service if the system is not used as a mail server. But if
you have programs and processes that generate messages in the form of mail, you should consider
starting sendmail as a client periodically from crontab to process these messages. Unprocessed
system messages generated in mail form may fill up diskspace, resulting in a self-inflicted denial-of-
services attack.

Sendmail may be disabled in Step 1 “Removing Unneccessary Software Packages and Processes.”
In case it was not, here are the commands to manually disable it:

[root@wen /]# /etc/rc3.d/S80sendmail stop

[root@wen /]# mv /etc/rc3.d/S80sendmail /etc/rc3.d/.NOS80sendmail

Replace the installed sendmail.cf file with the minimal sendmail.cf in Appendix C. Please note that if
sendmail is not used and is not installed, there is no need to keep the sendmail.cf file on the system.

Add the following entry to root’s contab to flush the mail queue once per hour:

0 * * * * /usr/sbin/sendmail -q

Page 14 0f 30
Step 5: Tightening up the System

It is recommended that you take the following actions in order to lock your Linux system down.
However, a system with users is a dynamic environment and requires monitoring and auditing to
make sure your security policy is implemented and best security practices are followed.

BIOS password
Disabling the ability to boot from floppy drives and being able to set a password to access the BIOS
features will improve the security of your system. You can check your BIOS manual or look at CMOS
Menu the next time you boot up your system to find out how to do this.

BIOS password will block unauthorized people from trying to boot your Linux system with a special
boot disk and will protect you from people trying to change BIOS features like allowing boot from
floppy drive or booting the server without prompt password. It is important to note that there is a
possibility to bypass this security measure if someone has a physical access to your server since
they can open the computer and unplug the BIOS battery. This will reset all features to their initial
values, which means there will be no password protection.

Set login time out for root account

Make the bash shell automatically logout root after a period of idling time. To do that, set the
TMOUT variable to the time in seconds by editing /etc/profile file and adding the following line
somewhere after the line that read “HISTSIZE=”:

TMOUT=7200

where the time-out value is 7200 seconds or 2 hours. You may shorten the time as per your security
policy. This autologout will apply to all users on the system. To selectively change timeout values for
users, edit their .bashrc files in their home directories.

The /etc/exports file

If you have a need to export file systems using the NFS service, be sure to configure the /etc/exports
file with the most restrictive access possible. This means not using wildcards, not allowing root write
access, and mounting read-only wherever possible. Edit the /etc/exports file and add the following:

/dir/to/export host1.mydomain.com(ro, root_squash)

/dir/to/export host2.mydomain.com(ro, root_squash)

where /dir/to/export is the directory you want to export, host1.mydomain.com is the machine allowed
to log in to this directory, the “ro” option means mounting read-only and the “root_squash” option
means not allowing root write access in this directory.

For this change to take effect you will need to run this command as root on the terminal command
line:
[root@wen /]# /usr/sbin/exportfs -a

Note that running NFS on your system can be a security risk. NFS is not installed if you have
followed the instructions in this guide prior to this section.

The single-user login mode of Linux

Linux has a single-user mode. It is generally used for system maintenance. You can boot Linux into
single-user mode by typing at the LILO boot prompt the following command:
LILO: linux single

Page 15 0f 30
This will place the system in Run level 1 where you will be logged in as root without having to type in
a password. You can change this default behaviour by modifying the /etc/inittab file. Change the
following line from
id:3:initdefault:
to
id:3:initdefault:
~~:S:wait:/sbin/sulogin

This will require the root password before continuing to boot into single-user mode by making init run
the program sulogin before dropping the machine into a root shell for maintenance. To make the
change take effect without a reboot, type the following command as root at the terminal command
line:
[root@wen /]# /sbin/init q

The LILO and /etc/lilo.conf file

LILO is a commonly used boot loader for Linux. It manages the boot process and can boot Linux
kernel images from floppy disks, hard disks or can even act as a boot manager for other operating
systems. (Please note that Redhat is starting to use another boot loader configuration tool called
Grub).

There are three options to secure LILO:

Adding: timeout=00
The option controls how long in seconds LILO waits for users input before booting to the default
selection. One of the requirements of C2 security is that this interval be set to 0 unless the system
dual boots something else.

Adding: restricted
This option asks for a password only if parameters are specified on the command line (e.g., linux
single). The option “restricted” can only be used together with the “password” option. Make sure you
use this one on each additional image you may have.

Adding: password=<password>
This option asks you for a password when you are trying to load the image. It doesn’t matter if you
boot Linux in single mode or if you just do a normal boot. It will always ask you for the password,
which may present a problem if you want to reboot the systrem remotely. It is for this reason that
adding “restricted” relaxes the password protection and a password is required only if parameters
are specified at the LILO prompt (e.g., linux single).

Passwords are always case-sensitive and also make sure the /etc/lilo.conf file is no longer world
readable (chmod 600 /etc/lilo.conf), or any user will be able to read the password. Appendix D
provides a sample lilo.conf file. Execute the following command to make the updates take effect :
[root@wen /]# /sbin/lilo –v

In addition to make /etc/lilo.conf unreadable to the world, you may also want to make the file
immutable:
[root@wen /]# chattr +i /etc/lilo.conf

To unset the immutable flag, use the following command:

[root@wen /]# chattr -i /etc/lilo.conf

Disabling Ctrl+Atl+Del keyboard shutdown command

Edit the /etc/inittab file and remove or comment out the following line:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

And then execute the following command as root in the terminal command line:

Page 16 0f 30
 [root@wen /]# /sbin/init q

The /etc/services file

The /etc/services file enables server and client programs to convert service names to the numbers
(ports) defined in RFC 1700. Only root is allowed to make modifications to this file. It is rare to edit the
/etc/services file, since it already contains the most common service names and port numbers. To
improve security, you can set the immutable flag on this file to prevent unauthorized deletion or
modification by executing the following command:
[root@wen /]# chattr +i /etc/services

The /etc/securetty file

The /etc/securetty file allows you to specify which tty and vc (virtual console) devices root is allowed
to login on. The /etc/securetty file is read by the login program (usually /bin/login). Its format is a list of
the tty and vc devices names allowed, and for all others that are commented out or do not appear in
this file, root login is disallowed. Disable any tty and vc devices that you do not need by commenting
them out (# at the beginning of the line) or by removing them. Example:
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

This will restrict root login on only tty1 and vc/1. It is recommended that root be allowed to log in on
only one tty or vc device and use the su command to switch to root if you need more devices to log in
as root.

Special accounts
It is important to disable all default vendor accounts that you don’t use on your system. Some
accounts exist by default even if you have not installed the related services on your server. This
should be checked after each upgrade or new software installation.

To delete user on your system, use the following command:

[root@wen /]# userdel username

To delete group on your system, use the following command:

[root@wen /]# groupdel username

Type the following commands to delete all default users accounts listed below:
[root@wen /]# userdel adm

Page 17 0f 30
 [root@wen /]# userdel lp Å if you don’t provide print service
[root@wen /]# userdel shutdown
[root@wen /]# userdel halt
[root@wen /]# userdel news
[root@wen /]# userdel mail Å if you don’t use sendmail
[root@wen /]# userdel uucp
[root@wen /]# userdel operator
[root@wen /]# userdel games
[root@wen /]# userdel gopher
[root@wen /]# userdel ftp Å if you don’t provide anonymous FTP

Alternatively, you may want to use a simple script to save some typing:
# a script to delete a group of users
for user in adm lp shutdown halt news mail uucp operator games gopher ftp
do
userdel $user
done

The next task is to remove default vendor account groups from the /etc/group file. Type the following
commands to delete all default usersgroups accounts listed below:
[root@wen /]# groupdel adm
[root@wen /]# groupdel lp
[root@wen /]# groupdel news
[root@wen /]# groupdel mail
[root@wen /]# groupdel uucp
[root@wen /]# groupdel games
[root@wen /]# groupdel dip

Alternatively, you may want to use a simple script to save some typing:
# a script to delete groups in batch mode
for group in adm lp news mail uucp games dip
do
userdel $group
done

At this point, you may want to add necessary users and groups into the server. Once you are done, it
is highly recommended that you use the immutable bit to protect /etc/passwd, /etc/shadow and
/etc/group files so that it would be a little bit more difficult to alter or delete them. To set the immutable
bit on the password and group files, use the following commands:
[root@wen /]# chattr +i /etc/passwd
[root@wen /]# chattr +i /etc/shadow
[root@wen /]# chattr +i /etc/group
[root@wen /]# chattr +i /etc/gshadow

If you intend to add or delete users, passwords, user groups, or group files, you must unset the
immutable bit on all those files or you will not be able to make and update your changes. Also if you
intend to install an RPM program that will automatically add a new user to the system, then you will
receive an error message during the install if you have not unset the immutable bit from those files.
To unset the immutable bit, use the following commands:
[root@wen /]# chattr -i /etc/passwd
[root@wen /]# chattr -i /etc/shadow
[root@wen /]# chattr -i /etc/group
[root@wen /]# chattr -i /etc/gshadow

Page 18 0f 30
Control mounting file systems
You can edit /etc/fstab file and add security options so that you have more control on mounting file
systems. Information related to security options in the fstab file are:
defaults - allow everything (quota, read-write, and suid) on this partition.
noquota - do not set users quotas on this partition.
nosuid - do not set SUID/SGID access on this partition.
nodev - do not set character or special devices access on this partition.
noexec - do not set execution of any binaries on this partition.
quota - allow users quotas on this partition.
ro - allow read-only on this partition.
rw - allow read-write on this partition.
suid - allow SUID/SGID access on this partition.

You should choose the most restrictive level your application will allow. The following example shows
how to tighten three commonly mounted partitions:

LABEL=/cache /cache ext2 defaults,nodev 1 2

LABEL=/home /home ext2 defaults,nosuid 1 2
LABEL=/tmp /tmp ext2 defaults,nosuid,noexec 1 2

What it means is that in /cache partition, do not interpret character or block special devices; in /home
partition, do not allow set-user-identifier or set-group-identifier bits to take effect; and in /tmp partition,
do not allow execution of any binaries, in addtion to not allowing set-user-identifier or set-group-
identifier bits to take effect. For more information on options that you can set, see the man pages
about mount (8). The file systems need to be remounted after changes have been made to the
/etc/fstab file.

Mounting /boot as read-only

The Linux kernel and its related files reside in the /boot directory which can be a regular directory or a
separate partition mounted as /boot depending how the system is installed. If it is a partition, it is by
default mounted as read-write. Changing it to read-only reduces the risk of unauthorized modification
of vital files there. The following example shows how to mount /boot read-only:
LABEL=/boot /boot ext2 defaults,ro 1 2

Please note that you need to reset the change to read-write if you need to upgrade the kernel.

Safeguard program installer RPM

For a fully configured system that’s ready to be deployed, there is no reason to expect installation of
new binaries or software packages. It is recommended that the rpm command be moved to a safe
place of your choice such as a floppy or a hidden directory on the system. At very least, its default
permission should be changed to root use only by executing the following command as root:
[root@wen /]# chmod 700 /bin/rpm

Tighten scripts under /etc/rc.d/init.d/

Change the file permission to allow only root to read, write and execute those scripts by executing
the following command:
[root@wen /]# chmod –R 700 /etc/rc.d/init.d/*
or
[root@wen /]# chmod –R 700 /etc/init.d/*

Then use the # sign to comment out the following lines from /etc/rc.local file as illustrated below:
# This will overwrite /etc/issue at every boot. So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
#echo "" > /etc/issue
#echo "$R" >> /etc/issue
#echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue

Page 19 0f 30
 #
#cp -f /etc/issue /etc/issue.net
#echo >> /etc/issue

And then remove /etc/issue and /etc/issue.net files so that the login prompt will not reveal the Linux
distribution name, version, kernel version, and the name of the server.

Bits from root-owned programs

A regular user will be able to run a program as root if it is set to SUID root. All programs and files on
the system with the “s” bits appearing on its mode, have the SUID or SGID bit enabled. Because
these programs grant special priviledges to the user who executes them, it is important to remove
the “s” bits from root-owned programs that won’t absolutely require such privilege. The following
command may help you find all files with the “s” bits from root-owned programs:
[root@wen /]# find / -type f \( -perm -04000 –o –perm -02000 \) –exec ls –l {} \;

As a minimum, it is recommended that the following SUID/SGID programs be disabled:

-rwsr-xr-x 1 root root 34220 Jul 18 14:13 /usr/bin/chage

-rwsr-xr-x 1 root root 36344 Jul 18 14:13 /usr/bin/gpasswd
-r-xr-sr-x 1 root tty 6524 Jul 12 03:19 /usr/bin/wall
-rws--x-x 1 root root 13184 Jul 21 19:15 /usr/bin/chfn
-rws--x-x 1 root root 12640 Jul 21 19:15 /usr/bin/chsh
-rws--x-x 1 root root 5464 Jul 21 19:15 /usr/bin/newgrp
-rwxr-sr-x 1 root tty 8500 Jul 21 19:15 /usr/bin/write
-rwsr-xr-x 1 root root 6288 Jul 26 10:22 /usr/sbin/usernetctl
-rwsr-xr-x 1 root root 20540 Jul 25 07:33 /bin/ping
-rwsr-xr-x 1 root root 55356 Jul 12 05:01 /bin/mount
-rwsr-xr-x 1 root root 25404 Jul 12 05:01 /bin/umount
-rwxr-sr-x 1 root root 4116 Jul 26 10:22 /sbin/netreport

To disable the suid bits on selected programs above, type the following commands:
[root@wen /]# chmod a-s /usr/bin/chage
[root@wen /]# chmod a-s /usr/bin/gpasswd
[root@wen /]# chmod a-s /usr/bin/wall
[root@wen /]# chmod a-s /usr/bin/chfn
[root@wen /]# chmod a-s /usr/bin/chsh
[root@wen /]# chmod a-s /usr/bin/newgrp
[root@wen /]# chmod a-s /usr/bin/write
[root@wen /]# chmod a-s /usr/sbin/usernetctl
[root@wen /]# chmod a-s /bin/ping
[root@wen /]# chmod a-s /bin/mount
[root@wen /]# chmod a-s /bin/umount
[root@wen /]# chmod a-s /sbin/netreport

Unusual or hidden files

If you are hardening an existing Linux system, it is imperative that a search be performed as part of
the OS hardening process to determine if there is any unusual or hidden files on the system. The
following commands can be used:
[root@wen /]# find / -name ".. " -print -xdev
[root@wen /]# find / -name ".*" -print -xdev | cat -v

Finding group and world writable files and directories

Groups and world writable files and directories, particularly system files (partitions), can be a security
hole if a cracker gains access to your system and modifies them. Additionally, world-writable
directories are dangerous, since they allow a cracker to add or delete files as he or she wishes in

Page 20 0f 30
these directories. In the normal course of operation, several files will be writable, including some
from the /dev, /var/catman directories, and all symbolic links on your system.

To locate all group & world-writable files on your system, use the command:
[root@wen /]# find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;
To locate all group & world-writable directories on your system, use the command:
[root@wen /]# find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;

Unowned files
Unowned files may also be an indication that an intruder has accessed your system. If you find
unowned file or directory on your system, verify its integrity, and if all looks fine, give it an owner
name. Some time you may uninstall a program and get an unowned file or directory related to this
software; in this case you can remove the file or directory safely.

To locate files on your system that do not have an owner, use the following command:
[root@deep /]# find / -nouser -o -nogroup

Minimum acceptable password length

Follow these steps to define minimum password length using PAM:

Edit /etc/pam.d/passwd file and remove the following line:

password required /lib/security/pam_stack.so service=system-auth

Add these three lines:

password required /lib/security/pam_cracklib.so retry=3 minlen=12
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/pam_deny.so

Then edit /etc/pam.d/system-auth file and remove the following three lines:
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/pam_deny.so

This imposes a minimum password length of 12 characters and a maximum of 3 login retries. Please
note that the minimum password length requirement does not apply to root user.

Disabling console program access

Default Linux installation allows regular users who have console access the privilege of root to run
certain programs such as shutdown, reboot and halt . Follow these steps to disable all console-
equivalent access to these programs for regular users:
[root@wen /]# rm -f /etc/security/console.apps/<servicename>
where <servicename> is the name of the program to which you wish to disable consoleequivalent
access. Please note that unless you use xdm, removing the xserver file will result in the inability to
start the X Server to everyone except root. It is recommended that the following programs be
removed for regular users:
halt
poweroff
reboot
shutdown
xserver (if removed, root will be the only user able to start X).

Disabling all console access

Following these steps to disable all console access to regular users:
cd /etc/pam.d

Page 21 0f 30
 for in in * ; do
sed ‘[^#].*pam_console.so/s/^/#/’ < $i > foo && mv foo $i
done

Step 6: File System Lockdown

After you have installed and configured all the necessary software on your system, you may want to
make sure that no one can modify them and the system binaries. You may also want to prevent rogue
setuid programs from showing up. In order to do that, you can modify the /etc/fstab file and set the
appropriate flags.

Edit the /etc/fstab file with a text editor such as vi:

vi /etc/fstab

If you have separate partitions for binaries, variable data and user space, we recommend that you
mount the binaries partition as read-only and mount other non-root filesystems with nosuid.

Please make sure you have double checked everything at this point. Once you finish here, you will
reboot to verify everything. If you have not added all your components properly, you will not easily be
able to make changes, in which case you will have to remount your binaries partition to make it
writable.

There are third party applications that can be used to monitor your file system. Tripwire is a
recognized leader in the industry. Tripwire is originally known as an intrusion detection tool, but can
be used for many other purposes such as integrity assurance, change management, policy
compliance and more. In October of 2000, Tripwire, Inc. released the source code for the Linux
version of Tripwire 2.2.1 under the General Public License (GPL). This version can be found in the
download section of http://www.tripwire.org site. Please consult your legal department about use of
open source software.

Page 22 0f 30
Step 7: Vulnerability Testing and Patching

A comprehensive Threat and Risk Assessment (TRA) test procedure should be applied to the
hardened operating system. Nortel Networks Network Security Group provided a complete TRA
process to Nortel Networks product groups.

Page 23 0f 30
Appendix A : Software for Servers

Page 24 0f 30
Page 25 0f 30
Appendix B : Log Analyzers
Autobuse is Perl daemon which identifies probes and the like in logfiles and automatically reports
them via email. This is, in a way, the opposite of logcheck in that autobuse identifies known badness
and deals with it automatically, while logcheck identifies known goodness and leaves you with the
rest.

Homepage http://www.picante.com/~gtaylor/autobuse/
Download http://www.picante.com/~gtaylor/download/autobuse/

Author Grant Taylor <gtaylor+autobuse@picante.com>

Version snap918416038
Licence GPL
Source Yes
Environment Console
Status Stable

loco is a Perl script which gives the messages file (usually /var/log/messages) some color, so the
output is easier to read. It uses a Perl module called Term::ANSIColor to produce the colors. The Perl
script is very readable and customizable. It can be tailored for other log files.

Homepage http://zjuul.net/~jules/loco/
Download http://zjuul.net/~jules/loco/

Author Jules Stuifbergen <zjuul@zjuul.net>

Version 0.32
Licence GPL
Source Yes
Environment Console
Status Stable

Logcheck is designed to automatically run and check system log files for security violations and
unusual activity. It utilizes a program called logtail that remembers the last position it read from in a
log file and uses this position on subsequent runs to process new information. All source code is
available for review and the implementation was kept simple to avoid problems. This package is a
clone of the frequentcheck.sh script from the Trusted Information Systems Gauntlet(tm) firewall
package. TIS has granted permission for the author to clone this package.

Homepage http://www.psionic.com/
Download http://rpmfind.net//linux/RPM/cooker/cooker/i586/Mandrake/RPMS/logcheck-1.1.1-
8mdk.i586.html

Author Originally Psionic. This package: Warly <warly@mandrakesoft.com>

Version 1.1.1
Licence It has been freely distributed since its first release. But Psionic has recently been
bought by CISCO.
Source Yes
Environment Console
Status Stable

Page 26 0f 30
LogDog is a very easy-to-configure and install system log monitor for watching system log files and
emailing administrators when problems are found. LogDog has a single configuration file which allows
you to easily specify a list of key words to watch for, a list of words to ignore, and a list of
administrators to email when problems are found.

Homepage http://marvin.criadvantage.com/caspian/
Download http://marvin.criadvantage.com/caspian/Software/LogDog/

Author Brandon Zehm <caspian@linuxfreak.com>

Version 0.94.4
Licence Freely distributable
Source Yes
Environment Console
Status Development

logsurfer is a log checking/auditing tool similar to swatch and logcheck but with the capability of
handling multi-line messages and dynamically adapting the ruleset. It is written in portable C, well
documented, fast, and flexible. It works on any textfile or stdin, can be run at intervals or continuously,
and has timeouts and resource limits.

Homepage http://www.cert.dfn.de/eng/logsurf/
Download ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer/logsurfer-1.41.tar.gz

Author Wolfgang Ley <info@cert.dfn.de>

Version 1.41
Licence Freeware
Source Yes
Environment Console
Status Stable

Swatch was originally written to actively monitor messages as they were written to a log file via the
UNIX syslog utility. It has multiple methods of alarming, both visually and by triggering events. The
perfect tools for a master loghost. This is a beta release of version 3.0, so please use it with caution.
The code is still slightly ahead of the documentation, but examples exist. NOTE: Works flawlessly on
Linux (RH5), BSDI and Solaris 2.6 (patched).

Homepage http://www.stanford.edu/~atkins/swatch/
Download http://www.stanford.edu/~atkins/swatch/latest.tar

Author Todd Atkins <Todd.Atkins@Alumni.Stanford.ORG>

Version 3.0b1
Licence GPL
Source Yes
Environment Console
Status Stable

Page 27 0f 30
For a system administrator it is a bothersome job to sort out the interesting (and sometimes alarming)
log entries from the pile of standard entries. Tidy distinguishes different services (telnet, finger, etc.)
and removes standard entries. Furthermore tidy tries to extract a remote host from the messages.
These remote hosts are added to a statistics database. The number of contacts of each service is
saved together with the time/date stamp of the last contact. The statistics can be printed out as
simple ASCII or HTML.

Homepage
Download ftp://metalab.unc.edu/pub/Linux/system/admin/log/
Alt Download ftp://tsx-11.mit.edu/pub/linux/sources/sbin/

Author Marek Rouchal <marek@saftsack.fs.uni-bayreuth.de>

Version 1.0
Licence GPL
Source Yes
Environment Console
Status Stable

WOTS is a logfile monitoring utility written in perl5. It's based on swatch but is brand new. WOTS can
be configured to watch multiple logfiles and to generate actions based on patterns matched in those
files. The actions can be printing the message, executing an external command, and others.

Homepage http://www.tony-curtis.cwc.net/tools/
Download http://www.tony-curtis.cwc.net/tools/wots-1.22.tar.gz

Author Tony Curtis <Tony.Curtis@vcpc.univie.ac.at>

Version 1.21
Licence freely distributable
Source Yes
Environment Console
Status Stable

Page 28 0f 30
Appendix C: Minimal sendmail configuration file
# Minimal client sendmail.cf

### Defined macros

# The name of the mail hub - PUT APPROPRIATE HOSTNAME FOR YOUR SITE
HERE!!!
DRmailhost

# Define version
V8

# Whom errors should appear to be from

DnMailer-Daemon

# Formatting of the UNIX from line

DlFrom $g $d

# Separators
Do.:%@!^=/[]

# From of the sender’s address

Dq<$g>

# Spool directory
OQ/usr/spool/mqueue

### Mailer Delivery Agents

# Mailer to forward mail to the hub machine
Mhub, P=[IPC], F=mDFMuCX, S=0, R=0, A=IPC $h
# Sendmail requires these, but are not used
Mlocal, P=/dev/null, F=rlsDFMmnuP, S=0, R=0, A=/dev/null
Mprog, P=/dev/null, F=lsDFMeuP, S=0, R=0, A=/dev/null

### Rule sets -- WHITESPACE BETWEEN COLUMNS MUST BE TABS!!!

S0
R@$+ $#error $: Missing user name
R$+ $#hub $@$R $:$1 forward to hub
S3
R$*<>$* $n handle <> error address
R$*<$*>$* $2 basic RFC822 parsing

Page 29 0f 30
Appendix D: Sample /etc/lilo.conf file
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt (remove this line if you don’t want to pass options at the LILO prompt)
timeout=00 (change this line to 00 to disable the LILO prompt)
linear
message=/boot/message (remove this line if you don’t want the welcome screen)
default=linux
restricted (add this line to relax the password protection)
password=<password> (put your password here)
image=/boot/vmlinuz-2.4.2-2
label=linux
initrd=/boot/initrd-2.4.2-2.img
read-only
root=/dev/sda6

Appendix E: References

1. Linux Security Handbook by O'Reilly

2. Secure Linux Server by O'Reilly
3. Linux Security, Prentice Hall

Page 30 0f 30