Lab 7 – Securing Linux Systems

Materials Needed:

• Computer
• Internet connection
• Root access to Linux account

Assignment:

The original checklist was written by Gene Schultz of Berkeley Lab and has been copyrighted in 2003 by the Regents of the University of California. All rights are reserved. (http://www.lbl.gov/ICSD/Security/systems/redhat-linux-checklist_v7.html)

Baseline Security Measures

A. Securing Your System’s Accounts and Groups

1. Assign a strong root password.

%syZ12Ghy#! would be a very strong password, but do not use this particular example as your password! The root account is the most important to protect, and the danger of it being compromised is high, given that powerful password crackers such as John the Ripper are freely available.

• To change the root password, obtain a root shell, and then enter passwd

2. Ensure direct remote root logins are disabled. /etc/securetty should list only the console tty (tty<#>).
• To find the console number, login locally and enter # tty
• Local root users will be able to logon directly, but to gain root access remote root users will have to enter
  su –

3. Disable remote root logins for FTP users.The best thing for security is to not run FTP server at all. If you must run an FTP server, limit opportunities for attackers by locking out certain accounts frequently used by attackers. /etc/ftpusers specifies users who are not permitted to do an FTP login. At a minimum, all default accounts (including root) should be listed in /etc/ftpusers, such as in the following example:

#cat /etc/ftpusers
root
adm
sysop
daemon
lp

4. Prevent nonadministrative accounts from logging in.

If the console is not physically secure, you should limit who can login and what service they can use. /etc/security/access.conf defines the users who can login using particular services. For example, to keep everyone but root from logging in and using the console, add the following entry to this file:

-:ALL EXCEPT root :console

5. Delete unneeded default accounts.
   
   Unneeded default accounts provide a potential avenue of attack. Default accounts you should strongly consider deleting include:

bin
daemon
adm
lp
sync
mail
news
uucp

Caution: always test deletion of default accounts on nonproduction hosts before deleting them on production systems.

6. Limit who can use the su command. Include everyone allowed to use the su command in the root group in /etc/group and then enter

# cd <path_to_directory_that_contains_su>
# chgrp root su
# chmod o-x su

7. Use chage to set password aging for each account.
   
   chage changes number of days between password changes and the date of last password change. -m means minimum number of days between password changes. -M means maximum number of days between password changes.

• To set password expiration (with an advance warning to users), enter

# chage -M90 -W5 <username>

• To check the last time a user password was changed, enter

$ chage -l <username>

C. Securing Your System’s File System

1. Check ownerships on system directories and files.
   a. Root should own all files in every system directory (/bin, /sbin, /dev, /etc, /var, and so on).
• To change ownership, enter:

# chown user <file>

2. Root (or possibly some other system group) should be the group owner of all files in every system directory.
• To change group ownership, enter:

# chgrp group <file>

3. Check permissions on system directories and files.
   World-writeable system files and directories are a worst-case scenario for security.
• To discover world-writeable system files and directories, enter

# find / -perm -002 -type f -print

• To remove the world-writeable permission from a file, enter

# chmod o-w <file>

For example, if the permission is 666 and you want to allow world only read access to /etc/hosts, enter:

# chmod 664 /etc/hosts

4. Check for unnecessary SUID/SGID root files.
• To check for SUID root programs, enter

# find / -user root -perm -4000 –print

• To check for SGID root programs, enter

# find / -user root -perm -2000 –print

• To change programs to no longer be SUID/SGID, enter

# chmod 0XXX <file>

5. Check to ensure that the sticky bit is set; set it if it is not set.

Setting the sticky bit prevents users other than the owner of files in a temporary directory for which the sticky bit is set from removing or renaming the files in that directory.

a. To check whether the sticky bit is set on, enter

# ls -ldg /tmp
drwxrwxrwt 1 root root 256 April 9 2002 /tmp

(Note that a “t” is listed in the output to show that the sticky bit is set.)

b. To set the sticky bit on /tmp, enter:

# chmod 1XXX /tmp

OR

# chmod o+t /tmp

6. Set a umask value.

umask puts a mask on permissions for newly created files and directories you create to help prevent accidental assignment of inappropriate permissions. It defines nonallowed default permission values in octal.

• To set a umask of 022, enter

# umask 022

D. Securing Services that Run on Your System

1. Configure the built-in TCP wrapper tool.

This tool acts as host-based firewall by screening out certain undesirable traffic from certain hosts. Visit http://www.lbl.gov/ITSD/Security/services/install-banner.html#tcp for procedures for installing the built-in TCP wrapper tool.

If you configure the TCP wrapper, be sure to regularly check its output. /var/log/secure keeps records of connections. Transferred files are recorded in /var/log/xferlog.

xinetd messages are saved in var/log/messages.

2. Disable as many of the following (or, ideally, all) of the following services as possible:

All the r-utilities (rlogin, rsh, rdist, rcp, rexec, etc.)

tftp ftp
finger uucp
systat chargen
echo nfs
http dns
sendmail

1. To turn a service off or on, enter

# chkconfig <service> on|off

# /etc/rc.d/init.d/xinetd restart (only if the service is an xinetd-based service)

2. If your system is not a mail server, there is a good chance that it does not need to run sendmail at all:
• If so, turn off sendmail using the syntax shown above.
3. Some mail clients such as elm, however, may need sendmail:

1) If so, stop sendmail from running in daemon mode by editing etc/sysconfig/sendmail to have the following entry:

DAEMON=no

2) Next, restart the sendmail daemon by entering

# /etc/rc.d/init.d/sendmail restart

4. If your system is not a DNS server, it should not run the DNS service.
• To do this, stop named and remove the DNS software:

# /etc/rc.d/init.d/named stop
# rpm -e caching-nameserver
# rpm -e bind

5. If you need to run FTP, but do not need anonymous FTP, disable anonymous FTP:

1) Edit /etc/ftpaccess such that the following line:

class all real,guest,anonymous *

is changed to:

class all real *

2) You need to also remove the FTP anonymous home directory by entering:

# rpm -e anonftp

6. If you need to run anonymous FTP:
   1) Enter anonftp in /var/ftp/pub/

The /bin and /etc directories need to be root-owned and to have permissions of 111. /pub should also be owned by root and should have permissions of 2555.

2) Set up access through /etc/hosts.deny|allow by including the following entry:

in.ftpd : ALL

3) Additionally, to run anonymous FTP more securely, use /etc/ftpaccess to restrict operations (e.g., to prevent anonymous users from modifying file contents):

chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous

7. If you need an incoming directory (something that is not good for security, since it allows anyone to deposit just about any type of file):

1) allow only write and execute access to it:

# mkdir -m 333 /home/ftp/incoming

2) Additionally, add the following entries in /etc/ftpaccess:

upload /home/ftp /incoming yes root ftp 0600 nodirs
noretrieve /home/ftp /incoming/

(Note: The first entry allows files to be uploaded to the /incoming directory, but they will be UID root and GID FTP, mode 0600, and subdirectories cannot be created below this directory. The second prevents anonymous users from downloading any files from /incoming.)

h. If you need to run the NFS service, make NFS access as secure as possible.

1) First, specify allowed addresses and/or address ranges in /etc/hosts.allow

For example, to allow NFS mounts only by LBLnet hosts, include the following entry:

portmap : 131.243.0.0/255.255.0.0 128.3.0.0/255.255.0.0

2) Do not allow the root volume to be NFS-mounted. Additionally, create entries in /etc/exports that allow read-only, not read/write access, per the following:

<directory1> <hostname> ro
<directory2> <hostname> ro

9. If you have a workstation that does not need to run any services (http, ftp, and so forth) that need to be accessed by other remote users, the best thing to do is disable xinetd altogether by entering:

# /etc/rc.d/init.d/xinetd stop
# /sbin/chkconfig xinetd off

IMPORTANT NOTE: If you need to run a Web server, you’ll need to ensure that it runs securely. An insecure Web server can be one of the easiest ways an attacker can gain unauthorized access to the host on which the Web server runs. See the Apache Web Guideline.

3. Pare down trusted access to the minimum needed, but none at all if possible.
1. To remove all trusted access, remove all entries in:

–~.rhosts –/etc/hosts.equiv

2. Find (and later remove) unnecessary user ~.rhosts files by running the following commands:
   # find / -name .rhosts -print

# find / -name hosts.equiv -print

4. Set up remote access to your host via ssh.
1. Add sshd : LOCAL in /etc/hosts.allow to allow SSH access
2. Each user must create an SSH key pair* by entering

ssh-keygen -t dsa

and then entering a passphrase (the first letters of each word from a fairly long phrase) for SSH access.

A public-private key pair will be generated; by default, both will be saved in the path $HOME/.ssh.

id_dsa.pub will hold the public key and /id_dsa will hold the private key.

3. Now copy id_dsa.pub to the path, as follows:

<home_directory>/.ssh/authorized_keys2 [fn5]

4. Be sure to chmod <home_directory>/.ssh/id_dsa to 400, since it holds the private key. Chmoding <home_directory>/.ssh/id_dsa.pub to 444 is also a good idea.

5. Substitute ssh for r-utility programs.

• Enter:

# ln -s /usr/bin/scp /usr/bin/rcp
# ln -s /usr/bin/ssh /usr/bin/rsh
# ln -s /usr/bin/slogin /usr/bin/rlogin

E. Setting Up Host-based Firewall Protection

1. Set up a quick and easy host-based firewall.

To do so:

1. Enter setup*
2. Choose Firewall Configuration
3. Set the firewall to the level of security you want (high, medium, or low)

2. Or if you need a more sophisticated and precise host-based firewall:

• Configure IPTables.

IPTables configuration is not within the scope of this checklist, however. For more information, see Ziegler’s excellent book (referenced below) on this topic.

F. Configuring Logging

1. Increase the amount of syslog logging.
• Add the following lines to /etc/syslog.conf:

kern.* /var/log/kernel
*.warn;*.err /var/log/syslog
*.err @<loghost_address>
authpriv.*;auth.* @<loghost_address>

2. Create /var/log/syslog and /var/log/kernel if they do not already exist, and set the permissions for both to 600.
• Do this by entering:

touch /var/log/syslog /var/log/kernel
chmod 600 /var/log/syslog /var/log/kernel

3. Make syslog read the new configuration file by entering:

# /etc/rc.d/init.d/syslog restart

4. Set up an initial log rotation configuration.

In the example below, to rotate every four weeks, send errors to root, create new empty logs after the log files are rotated, and to compress log files, enter

weekly
rotate 4
errors root
create
compress

in /etc/logrotate.d/syslog

(You may also want to check the default log rotation in /etc/logrotate.conf.)