How to Secure your RedHat box.

There are many considerations that must be taken when securing your machine:
  • Is it networked?
  • Is it a multiuser system?
  • Is it a server or a workstation?
  • Are there people using the machine named Michael Cosby?

    This document will cover what you need to know about securing a virgin Linux installation. There are other documents available that will discuss more in-depth security on both the user and network ends.

    Keep in mind that no system is totally secure. People who are ignorant to the threat of attacks are the first ones to be hit. Paranoia is the only line of defense.

    Kernels and OS:
    The first thing you should do is install the latest stable release of the OS. Upgrades are not advised since many old packages/libraries with bugs won't be upgraded, leaving possible holes. Install only the packages you think you will be using. Don't install every last item because your OC-12 can support it.
    A quick note about partitioning. Partitions should be set up as follows: /, /var, /home, /tmp should all be on separate partitions, or even disks. Reasoning: /var can fill up with logs hence filling your disk. /home can also become full even with quotas turned on. /tmp should be separate since all users can write to it, hence they might fill it. Note: Under some BSD variants, the kernel will panic when /var is full.

    Next, get the latest stable, non-developmental kernel.
  • Don't use a developmental kernel. Many times new security holes are introduced as the kernel is being built. The 2.2.x kernels provided a bunch of security fixes from 2.0.x involved with network attacks and DoS. As of the last revision, 2.2.x through 2.2.8 had several tcp vulnerabilities.
  • You will also need to upgrade a bunch of libraries and modules. A current list is available at LinuxHQ.
  • Don't blow away your old kernel in case you screw something up. It's much easier to have a working kernel on hand than to have to putz with a new non-working one.
  • If you are comfortable with using modules, use them! This makes upgrading individual kernel components a cinch without having to reboot.

    Patches:
    Find out if there are any general patches for your system. The best way to do this is check the ../updates directory on the redhat mirror. Install the patches using 'rpm -Fvh *.rpm'. Take care to only install the patches your system needs.

    The BIOS:
    You should set a BIOS password so system settings cannot be changed. Make sure to set the boot sequence to only boot from the primary drive, so a floppy cannot be used to boot the system.

    LILO:
    Some things to think about:
    dual booting: - having more than one OS on a machine causes a bunch of headaches. There is more than likely a way to mount your linux partitions in the other OS. This means your files can be read and modified. If you don't have more than one OS on your system you can set the delay option to 0. However by setting the prompt option, lilo will wait until the timeout is reached before booting the default kernel.
    restricted - requries a password if any options are passed at boot time.
    password=xxxxxx - This is the password lilo will ask for. Use this with the restricted option. Note the password is stored in plain-text so chmod 600 /etc/lilo.conf so it is not world readable anymore. It is a good idea not to use the real root password here either.
    This is an enhanced /etc/lilo.conf
            boot=/dev/sda
            map=/boot/map
            install=/boot/boot.b
            prompt
            timeout=100
            default=linux
            image=/boot/vmlinuz-2.2.9
                    label=linux
                    root=/dev/sda1
                    read-only
                    restricted
                    password=some_password
    

    Services:

    Most systems start with a default array of services. It is these services that provide the entry point for unwanted users. Services and daemons are started using /etc/rc.d/rc3.d/ and /etc/inetd.conf

    /etc/inetd.conf
    We will briefly visit this file to shut services off. Later we will learn how to add TCP/IP wrappers to those services you want to run. This file controls services that you do not want to run constantly. You want to shut off just about every service in this file. I'm not going to go into detail about the exploits now. Take a careful look at what this file does, and read the man page on each service listed. The only ones you want running are ftpd and maybe telnetd. Telnet should be replaced by a secure telnet client, so you can probably turn telnet off too.
    /etc/rc.d/rc3.d/

    The files in this directory start certain services at init changes. Since you will be in 'runlevel 3' most of the time, you really only need to worry about what's in this directory. Here is a list of stuff you might want running:
  • S10network- duh?
  • S20random - keep this!
  • S30syslog - do you like to know what's happening on your machine?
  • S40atd - makes stuff run at certain times
  • S40crond - makes crons go
  • S50inet - starts network services /etc/inetd.conf
  • S60lpd - starts printer servies
  • S75keytable - maps out the keyboard
  • S85gpm - starts the mouse
  • S90xfs - starts the x-font server
  • S99linuxconf - the linux configurator tool - This can be turned off!
  • S99local - starts other local services as stated in /etc/rc.d/rc.local
    Portmap might be required depending on your needs, be careful because this can bite you! You can delete the symbolic links to all other stuff, unless you want something to run. Note that PCMCIA is used on laptops.

    Telnet:
    Telnet poses an interesting problem. A very flexible tool allowing remote administration, but allowing other to snoop on your activities. What you want to do is get a secure telnet client that uses some form of encryption. SSH is the most popular client although several others are available. Once your secure telnet client is installed and tested, turn off 'telnetd' in /etc/inetd.conf
  • SSH - SSH is now somewhat commercial, but is available for educational use at: ftp.replay.com. I have noticed that there have been installation problems with the version 2 line of SSH.
  • LSH is another free alternative to SSH. www.net.lut.ac.uk/psst
  • Others include: NSH, Fsh Shells:
  • secsh - Secure Shell - prompts the user for a password after login. www.leenux.com/scripts

    System Files:

    /etc/passwd
    This file provides login and file information to users. It must be world readable, which means the encrypted passwords in it are world readable. This is bad! Don't think that changing permissions on the file will work, this will cause problems throughout the system. Use /usr/sbin/pwconv at the command line to create a /etc/shadow file. The /etc/shadow file is now only readable by root and contains the passwords which have been stripped from /etc/passwd along with other private information.

    /etc/group and /etc/gshadow
    A similar situation to the /etc/passwd file combo. Create this file using /usr/sbin/grpconv. Run both these commands at regular intervals to ensure all passwords are shadowed.

    /etc/shells
    Contains valid shells for your system. Delete shells that are not installed on your system.

    /etc/login.defs
    This file contains some default values for account creation. Review it's contents as it is commented well.

    /etc/securetty
    These are consoles where root can log into the machine directly. It might be favorable to provide at least one console for this, '/dev/tty1', although you can disable this altogether. You can also allow root to log in on a serial port for network/modem usage. This is a very bad idea. In the more advanced documentation, I will discuss some 'neat' options for root logins.

    System Logging:

    There are two programs which handle logging under Linux: sysklogd and klogd. klogd provides logging for the kernel, and sysklogd does almost everything else. Try to configure most programs, i.e. apache, to log to a central place, /var/log/. As noted above, keep /var on a separate disk to keep / from becoming full. Compression utilities should be used in conjunction with a log rotator. I think one of the neatest features of syslog is the ability to log to a remote host. This is great for centralizing log files for many servers. A major problem with logging facilities is that once a hacker has gained root access, they are free to modify and delete log files. A free secure-syslog program from www.core-sdi.com/ssyslog/ is available for logging with encryption, however logs can still be deleted. One way to help prevent deletion is to set imutable bits on log files. This is discussed in the advanced docs.
    Add the following line to /etc/syslog.conf:
        *.*;auth,authpriv.none                             /dev/tty12	
    
    This will log most of the important stuff to /tty12. You can also log to another host by using:
        *.*;auth,authpriv.none                                 @129.21.60.9
    
    A sample /etc/syslog.conf
    This logs to the host at 129.21.60.9. Use IPs instead of DNS lookups as server failures and spoofing cause headaches. Don't forget to check logs for suspicious activity and messages from programs. Many programs for this purpose are available along with statistical genereators.

    TCP Wrappers:

    TCP Wrappers are used to allow and deny certain hosts from making connections to your machine. Let's start with the two configuration files: /etc/hosts.allow and /etc/hosts.deny
    These files work in a top-down reading where explicit entries in hosts.allow will automatically be allowed in. If an entry in hosts.allow is not found, hosts.deny is checked. If a match is found, the host is disallowed, however if no match is found in either table, the host is allowed. You should avoid using DNS lookups because they are fairly easy to spoof, and a DNS failure would put you SOL. Here is a sample, consult the man page 'hosts.allow' for more info.
    hosts.allow
    #allow everything inside of the CSH network
    ALL: 129.21.60.0/255.255.255.0
    
    #Give myself some access points in case DNS gets fsucked
    in.telnetd: wrench.cs.rit.edu
    in.telnetd: sprocket.cs.rit.edu
    in.telnetd: grace.isc.rit.edu
    
    #Allow the world to get ftp access
    in.ftpd: 0.0.0.0/0.0.0.0
    ------------------------------------------------------------
    hosts.deny
    #The following line kills everyone else off including NFS
    ALL: 0.0.0.0/0.0.0.0
    
    Run /usr/sbin/tcpdchk to find possible errors with your configuration.
    A note about paths:
    Paths should be set up like this....
    	$ echo $PATH
    	/usr/bin:/bin:/usr/sbin::$HOME/bin:.
    
    The deal is that if the user's home 'bin' directory was searched before the system /bin, the user might be able to sneak a program into $HOME/bin which preforms a malicious act on the system.
    Topics to be included later:
    something about pwck

    X Windows:

    Never run as root. Period!