Printed 12/23/2003 - 12:44 PM

Nortel Networks

Issue Date November, 2003 Author Nortel Networks

Linux Operating System Hardening Guideline Document Issue 1.0

Page 2 0f 30

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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 0f 30

Appendix A : Software for Servers

Page 25 0f 30

Page 26 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 27 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 28 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 29 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 30 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