Hardening Fedora Core 5

I revised a year-old hardening document designed for Red Hat Enterprise, forking it to create a hardening document for Fedora Core 5.


I followed the CIS recommendations in general. These consist of:

Patch to OS

• Remove (or don’t install) unnecessary services
  
• Further harden with Bastille Linux
  
• Apply a few more scripts to provide additional hardening.
  

The first two points are no-brainers. The difference is that yum is used to patch Fedora, while up2date is used for RH Enterprise. Do the following:

yum update

Fedora Core 5 supports SELinux to the extent of asking for configuration as part of the install process. I decided the hardening process should set SELinux to “warn” (permissive) mode initially, then set it to ‘enforce” mode once it is clear that applications would not be affected. There is an obvious analogy to installing RACF in this process. The trick is to eventually graduate from permissive to enforce mode.

Here’s how to do this:

1. Review SELinux policy violation messages
   After applications have been installed and are running, search the messages log file for any SELinux error or warning messages:
   

   grep avc /var/log/messages

   
   If SELinux were to be installed in enforce mode, the listed errors would cause the application to fail. SELinux policy violations resulting from normal application use should be corrected by modifying the policy before setting SELinux to enforce mode.
   
2. Revise SELinux policy to permit normal application functions
   A procedure is described in http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizing.html to modify the local SELinux policy to prevent authorization failures from normal application use. This procedure is summarized as:
   
   2.a. Install the yum module checkpolicy:
   

   yum install checkpolicy

   
   2.b. Create a file containing the SELinux error log messages
   

   grep avc /var/log/messages > avc

   
   2.c. Create a local SELinux policy file:
   

   /usr/bin/audit2allow –M local 

   
   2.d. Load the policy file into the kernel:
   

   /usr/sbin/semodule –i local.pp

   
   SELinux error messages should be tracked to ensure no other authorization failures occur.
   
   
3. Set SELinux to enforce mode
   Observe the messages log file for any further SELinux error or warning messages. If no authorization failures occur due to normal application operations, SELinux should be set to enforce mode:
   

   /usr/sbin/setenforce 1

   
   

Bastille has turned out to be a real pain. Bastille allows use of batch files to automate the hardening process. The batch files are replicas of the questions and answers used in the interactive hardening. Unfortunately, the batch files must follow a specific format exactly, or the entire process aborts. If a question/response is missing or out of order, the hardening never happens. You then have the option of running Bastille interactively, in either graphical or curses-text mode.

Running in a graphical environment requires X. Hardened servers should not run X or even have the applications installed. First, I’ll be damned if I install X just to run a one time configurator. Second, if I’m going through the trouble to harden a server using Bastille, why would I introduce an unsafe application?

Text mode requires the perl curses modules. If you don’t have the modules, you would have to install them. Installing curses requires a ‘c’ compiler. Again, what hardened server keeps compilers around “just in case”? The same issues as with X – why go through the trouble, and why weaken security to run a hardening script?

Instead, I reviewed Bastille’s functions and specified shell commands to perform the same functions:

1. Remove non-root access to the following commands: linuxconf, fsck, ifconfig, runlevel and portmap:

   chmod 700 command

2. Disable suid for mount/unmount commands:

   chmod ug-s command
   

3. Remove suid status for dump and restore, cardctl, at, news server stuff (inndstart and startinnfeed), printing utilities (if not using anyway), usernetctl:

   chmod ug-s /usr/bin/command

   
   
4. Remove all permissions for r-utilities ( rcp, rlogin, rdist, RSH, REXEC, RCP) so not even root can run these utilities without changing permissions explicitly:

   chmod 000 command

   
   
5. Enable password aging in /etc/login.defs. The password change interval should be set as required by ITD policy. The minimum password length should be set to eight characters using the parameter PASS_MIN_LEN 8
   
   
6. Require use of strong passwords for user accounts. To set up password restrictions, edit the /etc/pam.d/system-auth file and add/change the following:
   

   password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3    minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1

   Note that running authconfig will destroy these changes, so permissions to authconfig should be set to avoid this:

   chmod 000 /usr/bin/authconfig

   chmod 000 /usr/sbin/authconfig

   
   
7. Set default umask - always edit the /etc/login.defs file to change the default umask to 077. Add the line UMASK 077 to the end of the file.
   
   
8. Remove unnecessary accounts: news, uucp, games, gopher. Also remove ftp, apache, and named if not using these service. Remove all associated groups having the same name as the removed accounts. userdel account groupdel group
   
   
9. Create authorized use banner in /etc/motd .
   
   
10. Disable these services unless specifically required: nfs, nfslock, ypbind, portmap, rpcidmapd, rpcgssd, netfs, cups, cups-config-daemons, hplib, and kudzu. Note that many servers may require printer access. Printer services may remain enabled if documented in the SIS and approved by ITD Security.
    
    These services are specifically described in the CIS hardening document. Other unnecessary services should be disabled as well, including isdn and bluetooth-related services.
    
    To disable services, from the System menu select the option Services. Select the background tab to remove services started at boot time.
    
    
11. Remove these applications unless specifically required: apmd, PCMIA services, GPM, and news. To remove applications, from the Applications menu select the option Add/Remove Software.
    

These don’t cover everything Bastille could cover, but they reflect the needs of the environment. I specifically excluded hardening steps designed to protect against inappropriate physical access (e.g., USB boot devices, boot passwords, etc.). The servers are in a secured data center, so physical security should be adequate. An intruder with physical access can always work around logical security measures. Conversely, these measures will make needed emergency maintenance more difficult.