Linux Hardening

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Linux Hardening as PDF for free.

More details

  • Words: 8,157
  • Pages: 30
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 NONINFRINGEMENT. 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 mouseconfig timeconfig

authconfig ntsysv 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.

S05apmd -> ../init.d/apmd S10network -> ../init.d/network S11portmap -> ../init.d/portmap S15netfs -> ../init.d/netfs S20random -> ../init.d/random S30syslog -> ../init.d/syslog S32gated -> ../init.d/gated S40atd -> ../init.d/atd S40crond -> ../init.d/crond S45pcmcia -> ../init.d/pcmcia S50inet -> ../init.d/inet S55named -> ../init.d/named S60lpd -> ../init.d/lpd S60mars-nwe -> ../init.d/mars-nwe S60nfs -> ../init.d/nfs S65dhcpd -> ../init.d/dhcpd S72amd -> ../init.d/autofs S75keytable -> ../init.d/keytable S80sendmail -> ../init.d/sendmail S85gpm -> ../init.d/gpm S85httpd -> ../init.d/httpd S90xfs -> ../init.d/xfs S91smb -> ../init.d/smb S95innd -> ../init.d/innd S99linuxconf -> ../init.d/linuxconf 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 echo dgram discard stream discard dgram daytime stream daytime dgram chargen stream chargen dgram time stream time dgram ftp stream telnet stream shell stream login stream exec stream comsat dgram talk dgram ntalk dgram dtalk stream pop-2 stream pop-3 stream imap stream uucp stream tftp dgram bootps dgram finger stream cfinger stream systat stream netstat stream auth stream

tcp udp tcp udp tcp udp tcp udp tcp udp tcp tcp tcp tcp tcp udp udp udp tcp tcp tcp tcp tcp udp udp tcp tcp tcp tcp tcp

nowait wait nowait wait nowait wait nowait wait nowait wait nowait nowait nowait nowait nowait wait wait wait waut nowait nowait nowait nowait wait wait nowait nowait nowait nowait nowait

root internal root internal root internal root internal root internal root internal root internal root internal root internal root internal root /usr/sbin/tcpd in.ftpd -l -a root /usr/sbin/tcpd in.telnetd root /usr/sbin/tcpd in.rshd root /usr/sbin/tcpd in.rlogind root /usr/sbin/tcpd in.rexecd root /usr/sbin/tcpd in.comsat root /usr/sbin/tcpd in.talkd root /usr/sbin/tcpd in.ntalkd nobody /usr/sbin/tcpd in.dtalkd root /usr/sbin/tcpd ipop2d root /usr/sbin/tcpd ipop3d root /usr/sbin/tcpd imapd uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l root /usr/sbin/tcpd in.tftpd root /usr/sbin/tcpd bootpd root /usr/sbin/tcpd in.fingerd root /usr/sbin/tcpd in.cfingerd guest /usr/sbin/tcpd /bin/ps -auwwx guest /usr/sbin/tcpd /bin/netstat -f inet 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 protocol wait user

= = = =

stream tcp no root Page 10 0f 30

}

server server_args disable

= in.ftpd = -l -a = 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 /var/log/maillog /var/log/secure /var/log/daemon-log /var/log/cron-log

User level information and the programs they run Mail log if the server runs a MTA such as sendmail User authentication information Daemon 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 info;cron.none;mail.none;authpriv.none;daemon.none

/var/log/messages @log_server

authpriv.*;auth.* authpriv.*;auth.*

/var/log/maillog @log_server

mail.* mail.*

/var/log/maillog @log_server

daemon.* daemon.*

/var/log/daemon-log @log_server

cron.* cron.*

/var/log/cron-log @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... 1:logcheck

########################################### [100%] ########################################### [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-ofservices 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-groupidentifier 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 consoleequivalent 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 Download

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

Author Version Licence Source Environment Status

Grant Taylor snap918416038 GPL Yes Console 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 Download

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

Author Version Licence Source Environment Status

Jules Stuifbergen 0.32 GPL Yes Console 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 Download

http://www.psionic.com/ http://rpmfind.net//linux/RPM/cooker/cooker/i586/Mandrake/RPMS/logcheck-1.1.18mdk.i586.html

Originally Psionic. This package: Warly <[email protected]> 1.1.1 It has been freely distributed since its first release. But Psionic has recently been bought by CISCO. Yes Source Environment Console Stable Status

Author Version Licence

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 Download

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

Author Version Licence Source Environment Status

Brandon Zehm 0.94.4 Freely distributable Yes Console 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 Download

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

Author Version Licence Source Environment Status

Wolfgang Ley 1.41 Freeware Yes Console 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 Download

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

Author Version Licence Source Environment Status

Todd Atkins 3.0b1 GPL Yes Console 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 Alt Download

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

Author Version Licence Source Environment Status

Marek Rouchal <[email protected]> 1.0 GPL Yes Console 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 Download

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

Author Version Licence Source Environment Status

Tony Curtis 1.21 freely distributable Yes Console 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

Related Documents

Linux Hardening
November 2019 13
Linux Hardening
June 2020 3
Hardening Debian
November 2019 24
Precipitation Hardening
November 2019 16
Surface Hardening
May 2020 20
Hardening Terminologies
October 2019 43