Computer Protection Program Berkeley Lab
Computer Protection Program at Berkeley Lab Security
Ernest Orlando Lawrence Berkeley National Laboratory
Emergencies | Site Index | Contact Us
CPP Home
Contacts
Policy Guidelines
Scan Information
System Procedures
Tools & Services
ALERTS
Recent CPP Actions
News & Articles
CPP Intranet
 
 
  PROCEDURES FOR SECURING SYSTEMS  
Checklist for Securing RedHat Linux Systems [fn1]  

<< Back to Unix Security

________

Introduction

RedHat Linux is currently one of the most widely used operating systems. Although default security-related settings have generally improved over subsequent releases of this operating system, you'll need to tighten many default settings and regularly inspect your system's settings and log file output if you want your system to be able to resist the major types of attacks that occur today. This checklist, which has been written specifically for RedHat 7.x systems (but will also apply in large part to other versions of RedHat), presents the measures you'll need to take to achieve baseline security in this operating system.

Baseline Security Measures

A. Protecting the Boot Process

  1. Require the root password to protect against unauthorized single user mode boots.
    1. Go to /etc/inittab

    2. Then add
    3. ~~;S:wait:/sbin/sulogin

      below the one that begins with si::sysinit

    4. To make this change go into effect right away, enter
    5. # init q

  2. If your system uses LILO to boot, password protect the LILO prompt.
    1. After the prompt line in /etc/lilo.conf, enter
    2. password = <password>
      Restricted

    3. Then change the permissions on /etc/lilo.conf by entering:
    4. # chmod 600 /etc/lilo.conf

    5. To put the changes into effect, enter:


    6. # /sbin/lilo

  3. If your system uses GRUB to boot, password protect the GRUB boot.



    1. To do this enter

    2. # grub


    3. When the grub prompt appears, enter
    4. grub> md5crypt

    5. When you are prompted, enter a difficult-to-guess password.

    6. Now exit grub mode and create a new line below the timeout line [fn2] in /etc/grub.conf
    7. The line should look like this:

      password --md5

    8. Now add a space after --md5 and then paste in the md5crypt output, so that the new line now looks something like this:
    9. password –md5 wYi2R#xaVwP9d

    10. To protect the password, enter
    11. # chmod 600 /etc/grub.conf

    12. To put the changes into effect, enter
    13. # /sbin/grub

  4. If your system uses LILO to boot, password-protect the LILO boot.
  5. Edit /etc/lilo.conf by adding a line beneath the line that contains the word "prompt." The new line should read:

    password = <password>

    where <password> is a strong (difficult-to-guess) password. (Note—you do not need to type the angle brackets if you do not want to.)

    Add a line beneath the line that contains the word "image." This new line should read:

    restricted

    Now save /etc/lilo.conf.

    To protect the password, enter:

    chmod 600 /etc/lilo.conf

    To put the changes into effect, enter:

    /sbin/lilo

  6. Require a password to be entered if anyone is to gain interactive access during any OS boot.
  7. Enter lock below the timeout line for each entry that starts with title in /etc/grub.conf

  8. For example,

    title <OS name>
    timeout……
    lock

    To protect any interactive access at boot, however, you do not need the timeout line.

B. Securing Your System’s Accounts and Groups

  1. Assign a strong root password.
  2. %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

  3. 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 –

  4. 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

  5. Prevent nonadministrative accounts from logging in.
  6. 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

  7. Disable unneeded default accounts.

    Unneeded default accounts provide a potential avenue of attack. Default accounts you should strongly consider disabling include:

    bin
    daemon
    adm
    lp
    sync
    mail
    news
    uucp

    Caution: Disable each unnecessary account by replacing the shell for the account with "/sbin/nologin."

  8. 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
  9. # cd <path_to_directory_that_contains_su>
    # chgrp root su
    # chmod o-x su

  10. 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.
  6. 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.

    1. To check whether the sticky bit is set on, enter
    2. # 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.)

    3. To set the sticky bit on /tmp, enter:
    4. # chmod 1XXX /tmp

      OR

      # chmod o+t /tmp

  7. Set a umask value.
  8. 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.
  2. This tool acts as host-based firewall by screening out certain undesirable traffic from certain hosts. /etc/hosts.deny must have only the following entry:

    ALL: ALL

    /etc/hosts.allow should have one entry per service:

    sshd: <hostname OR domain>

    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.

  3. Disable [fn3] 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:
    4. 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

    5. 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

    6. If you need to run FTP, but do not need anonymous FTP, disable anonymous FTP:
    7. 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

    8. 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) 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

    9. 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):
    10. 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.)

    11. 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

    12. 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

    13. 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:
    14. # /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.

  4. 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

    2. –/etc/hosts.equiv

    3. Find (and later remove) unnecessary user ~.rhosts files by running the following commands:

      # find / -name .rhosts -print
    4. # find / -name hosts.equiv -print

  5. Set up remote access to your host via ssh.
    1. Ensure that sshd is running by entering ps. If sshd is not running, enter:

      chkconfig ssh on
      #/etc/rc.d/init.d/sshd start

    2. Add entries in /etc/hosts.allow to allow inbound SSH:

      #Permit SSH access to users in same domain
      sshd : LOCAL : ALLOW

    3. Each user must create an SSH key pair* by entering

      ssh-keygen -t dsa [fn4]

      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.

    1. Now copy id-dsa.pub to the path, as follows:
    2. <home_directory>/.ssh/authorized_keys2 [fn5]

    3. 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.

  6. 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

  7. Installing updates.
  8. To update your host, enter:

    # rpm -Uvh <package-name OR URL>

    Install the rpms by entering:

    rpm -ivh <package-name OR URL>

    To update a package, enter:

    # up2date <option> <package>

    OR

    Obtain yum (yellow updated modified) from here.

    Turn yum on by going to Setup -> yum and pressing <space>

    To update your host, enter:

    yum update

    Note that you will be prompted, "Is this ok [y/n]." If you type "y," rpms will be downloaded to /var/cache/ym and then installed. To clear the cache afterwards, enter:

    yum clean

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:

F. Configuring Logging

  1. Increase the amount of syslog logging.
    • Add [fn6] the following lines to /etc/syslog.conf:
    • kern.* /var/log/kernel
      kern.* /dev/console
      *.warn /var/log/syslog

  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:
  4. # /etc/rc.d/init.d/syslog restart

G. Installing Bondo

Bondo is an LBL-developed script that checks for rootkits based on file anomalies that rootkits create. This script sends the results of these checks to a central host for analysis by the Computer Protection Program (CPP). The CPP requires that all Linux hosts run Bondo continuously.

Bondo installation must be done as root and cron must be running for the script to be executed.

RPM-based installation (preferred)

rpm -ivh http://hosed.lbl.gov/bondo.rpm

OR

copy http://hosed.lbl.gov/bondo.rpm to the file system
rpm -ivh /path/to/bondo.rpm

Non-RPM installation

copy http://hosed.lbl.gov/bondo.cron to local file system
copy /path/to/bondo.cron /etc/cron.hourly/bondo.cron
chown root /etc/cron.hourly/bondo.cron
chmod 700 /etc/cron.hourly/bondo.cron

________

Footnotes

1. This 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.

2. It is very important that this new line appear below the timeout line, although anywhere below the timeout line will do. If the password line is not below the timeout line, you will not be able to boot your system.

3. # chkconfig --list will show the status of all services.

4. In most Linux systems you will have a choice of the type of key that will be created. DSA, a widely used type of encryption, is a good choice. RSA is also a good choice. If you choose RSA instead, the key files will be named id_rsa and id_rsa.pub.

5. Copying the key to <home_directory>/.ssh/authorized_keys will also work.

6. Be sure to use <TAB> to separate the fields in each line from each other.

References

Anonymous. Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Server and Workstation. Indianapolis: SAMS, 2000.

Hatch, B., Lee, James, and Kurtz, George. Hacking Linux Exposed: Linux Security Secrets and Solutions. New York: Osborne, 2001.

Ziegler, Robert L. Linux Firewalls (2nd Edition). Indianapolis: New Riders, 2002.

Valuable sercurity-related documention is available at http://lug.lbl.gov/docs/Redhat-8.0/Security/

 

Home | Contacts | Policy Guidelines | System Procedures | Tools & Services | ALERTS | News & Articles