Host Security

1.1 BIOS

It is recommended that you set a Boot password to disallow booting from floppy/cdrom/usb drives and set passwords on BIOS features. Disallowing the possibility to boot from floppy/cdrom/usb drives and being able to set a password to access the BIOS features will improve the security of your system. This will block undesired people from trying to boot your Linux system with a special boot disk and will protect you from people trying to change BIOS feature like allowing boot from floppy/cdrom/usb drive or booting the server without prompt password.

1.2. Security as a Policy

It is important to point out that you cannot implement security if you have not decided what needs to be protected, and from whom. You need a security policy; a kind of list of what you consider allowable and not allowable, upon which to base any decisions regarding security. The policy should also determine your response to security violations. What you should consider while compiling a security policy will depend entirely on your definition of security. The answers to the following questions should provide some general guidelines:

• How do you classify confidential or sensitive information?

• Does the system contain confidential or sensitive information?

• Exactly whom do you want to guard against?

• Do remote users really need access to your system?

• Do passwords or encryption provide enough protection?

• Do you need access to the Internet?

• How much access do you want to allow to your system from the Internet?

• What action will you take if you discover a breach in your security?

This list is not very comprehensive, and your policy will probably encompass a lot more before it is completed. Any security policy must be based on some degree of paranoia; deciding how much you trust people, both inside and outside your organization. The policy must, however, provide a balance between allowing your users reasonable access to the information they require to do their work and totally disallowing access to your information. The point where this line is drawn will determine your policy.

NOTE: For Policy templates visit http://www.sans.org/resources/policies/#template

1.3. Choose the right Password

The starting point of our Linux General Security tour is the password. Many people keep their valuable information and files on a computer, and the only thing preventing others from seeing it is the eight-character string called a password. An unbreakable password, contrary to popular belief, does not exist. Given time and resources all passwords can be guessed either by social engineering or by brute force.

Social engineering of server passwords and other access methods are still the easiest and most popular way to gain access to accounts and servers. Often, something as simple as acting as a superior or executive in a company and yelling at the right person at the right time of the day yields terrific results.

Running a password cracker on a weekly basis on your system is a good idea. This helps to find and replace passwords that are easily guessed or weak. Also, a password checking mechanism should be present to reject a weak password when first choosing a password or changing an old one. Character strings that are plain dictionary words, or are all in the same case, or do not contain numbers or special characters should not be accepted as a new password. We recommend the following rules to make passwords effective:

• They should be at least six characters in length, preferably eight characters including at least one numeral or special character.

• They must not be trivial; a trivial password is one that is easy to guess and is usually based on the user's name, family, occupation or some other personal characteristic.

• They should have an aging period, requiring a new password to be chosen within a specific time frame.

• They should be revoked and reset after a limited number of concurrent incorrect retries.

The minimum acceptable password length by default when you install your Linux system is 5. This mean that when a new user is allowed to have a access on the server, his/her password length will be at minimum 5 mixes of character strings, letter, number, special character etc. This is not enough and must be 8.

To prevent non-security-minded people or administrators from being able to enter just 5 characters for the valuable password, edit the rather important /etc/login.defs file and change the value of 5 to 8. Edit the login.defs file vi /etc/login.defs and change the line that read:

            PASS_MIN_LEN    5
            

To read:

            PASS_MIN_LEN    8
            

The login.defs is the configuration file for the login program. You should review or make changes to this file for your particular system. This is where you set other security policy settings like password expiration defaults or minimum acceptable password length.

1.4. The root account

The root account is the most privileged account on a Unix system. The root account has no security restrictions imposed upon it. This means the system assumes you know what you are doing, and will do exactly what you request -- no questions asked. Therefore it is easy, with a mistyped command, to wipe out crucial system files. When using this account it is important to be as careful as possible. For security reasons, never log in on your server as root unless it is absolutely an instance that necessitates root access. Also, if you are not on your server, never sign in and leave yourself on as root --this is Very, Very, Very BAD practice.

Set login time out for the root account. Despite the notice to never, if they are not on the server sign in as root and leave it unattended, administrators still stay on as root or forget to logout after finishing their work and leave their terminals unattended. The answer to solve this problem is to make the bash shell automatically logout after not being used for a period of time. To do that, you must set the special variable of Linux named TMOUT to the time in seconds of no input before logout. Edit your profile file /etc/profile and add the following line somewhere after the line that read HISTFILESIZE= on this file:

            TMOUT=7200
            

The value we enter for the variable TMOUT= is in second and represent 2 hours (60 * 60 = 3600 * 2 = 7200 seconds). It is important to note that if you decide to put the above line in your /etc/profile file, then the automatic logout after two hours of inactivity will apply for all users on the system. So, instead, if your prefer to control which users will be automatically logged out and which ones not, you can set this variable in their individual .bashrc file. After this parameter has been set on your system, you must logout and login again as root for the change to take effect.

1.5. Disable console program access

In a safe environment where we are sure that console is secured because passwords for BIOS and LILO are set and all physical power and reset switches on the system are disabled it may be advantageous to entirely disable all console-equivalent access to programs like shutdown, reboot, and halt for regular users on your server. To do this, run the following command:

#rm -f /etc/security/console.apps/<servicename>
             

Where <servicename> is the name of the program to which you wish to disable console-equivalent access. Unless you use xdm, however, be careful not to remove the xserver file or no one but root will be able to start the X server. If you always use xdm to start the X server, root is the only user that needs to start X, in which case you might actually want to remove the xserver file.

             
# rm -f  /etc/security/console.apps/halt
# rm -f  /etc/security/console.apps/poweroff
# rm -f  /etc/security/console.apps/reboot
# rm -f  /etc/security/console.apps/shutdown  
             

This will disable console-equivalent access to programs halt, poweroff, reboot, and shutdown.

1.6. Disable all console access

The Linux-PAM library installed by default on your system allows the system administrator to choose how applications authenticate users, such as for console access, program and file access. In order to disable all these accesses for the users, you must comment out all lines that refer to pam_console.so in the /etc/pam.d/ directory. This step is a continuation of the above hack Disable console program access. The following script will do the trick automatically for you. As root creates the disabling.sh script file, touch disabling.sh and add the following lines inside:

# !/bin/sh
cd /etc/pam.d
for i in * ; do
sed '/[^#].*pam_console.so/s/^/#/' < $i > foo && mv foo $i
done
               

Make this script executable with the following command and execute it:

# chmod  700  disabling.sh
# ./disabling.sh
               

This will comment out all lines that refer to pam_console.so for all files located under /etc/pam.d directory. Once the script has been executed, you can remove it from your system.

1.7. xinetd

xinetd, called also the super server, will load a network program based upon a request from the network. The xinetd.conf file tells xinetd which ports to listen to and what server to start for each port.

The first thing to look at as soon as you put your Linux system on ANY network is what services you need to offer. Services that you do not need to offer should be disabled and uninstalled so that you have one less thing to worry about, and attackers have one less place to look for a hole. Look at your /etc/xinetd.d/* files to see what services are being offered by your xinetd program. Disable what you do not need by editing each file and changing disable = false to disable = true, and then sending your xinetd process a SIGHUP command to update it to the current xinetd.conf file.

1. Change the permissions on this file to 600.

   #chmod 600 /etc/xinetd.conf

2. Ensure that the owner is root.

# stat /etc/xinetd.conf
             

  File: `/etc/xinetd.conf'
  Size: 313             Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d      Inode: 1100323     Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2005-07-12 12:17:27.000000000 -0400
Modify: 2005-07-12 12:16:31.000000000 -0400
Change: 2005-07-12 12:29:17.000000000 -0400
             

3. Edit xinetd.d/<service_name> files using vi /etc/xinetd.d/<service_name> and change disable = false to disable = true for services like: ftp, telnet, shell, login, exec, talk, ntalk, imap, pop-2, pop-3, finger, auth, etc. unless you plan to use it. If it's turned off, it's much less of a risk.

   # /etc/init.d/xinetd reload

4. One more security measure you can take to secure the xinetd.conf file is to set it immutable, using the chattr command. To set the file immutable simply, execute the following command:

   # chattr +i /etc/xinetd.conf

   This will prevent any changes accidental or otherwise to the xinetd.conf file. A file with the immutable attribute set i cannot be modified, deleted or renamed, no link can be created to this file and no data can be written to it. The only person that can set or clear this attribute is the super-user root. If you wish later to modify the xinetd.conf file you will need to unset the immutable flag: To unset the immutable flag, simply execute the following command:

1.8. The /etc/host.conf file

Linux uses a resolver library to obtain the IP address corresponding to a host name. The /etc/host.conf file specifies how names are resolved. The entries in the etc/host.conf file tell the resolver library what services to use, and in what order, to resolve names. Edit the host.conf file vi /etc/host.conf and add the following lines:

# Lookup names via DNS first then fall back to /etc/hosts.
order bind,hosts
# We have machines with multiple IP addresses.
multi on
# Check for IP address spoofing.
nospoof on
           

The order option indicates the order of services. The sample entry specifies that the resolver library should first consult the name server to resolve a name and then check the /etc/hosts file. It is recommended to set the resolver library to first check the name server, bind and then the hosts file (hosts) for better performance and security on all your servers. Of course you must have the DNS/BIND software installed or this configuration will not work.

The multi option determines whether a host in the /etc/hosts file can have multiple IP addresses i.e.multiple interface ethN. Hosts that have more than one IP address are said to be multiomed, because the presence of multiple IP addresses implies that host has several network interfaces. As an example, a Gateway Server will always have multiple IP address and must have this option set to ON.

The nospoof option indicates to take care of not permitting spoofing on this machine. IP-Spoofing is a security exploit that works by tricking computers in a trust relationship that you are someone that you really aren't. In this type of attack, a machine is set up to look like a legitimate server and then issue connections and other types of network activities to legitimate end systems, other servers or large data repository systems. This option must be set ON for all types of servers.

1.9. The /etc/services file

The port numbers on which certain standard services are offered are defined in the RFC 1700 Assigned Numbers. The /etc/services file enables server and client programs to convert service names to these numbers -ports. The list is kept on each host and it is stored in the file /etc/services. Only the "root" user is allowed to make modification in this file and it is rare to edit the /etc/services file to make change since it already contains the more common service names to port numbers. To improve security, we can immunize this file to prevent unauthorized deletion or addition of services. To immunize the /etc/services file, use the command:

#chattr  +i /etc/services
           

1.10. The /etc/securetty file

The /etc/securetty file allows you to specify which TTY devices the root user 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 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 that you do not need by commenting them out # at the beginning of the line. Edit the securetty file vi, /etc/securetty and comment out the following lines:

tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
             

Which means only root is allowed to login on tty1. This is my recommendation, allowing root to log in only on one tty device and use the su command to switch to root if you need more. devices to log in as root.

1.11. 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. Linux provides these accounts for various system activities, which you may not need if the services are not installed on your server. If you do not need the accounts, remove them. The more accounts you have, the easier it is to access your system.

We assume you are using the Shadow password suite on your Linux system. If you are not, you should consider doing so, as it helps to tighten up security somewhat. To delete user on your system, use the command:

# userdel username
               

To delete group on your system, use the command:

# groupdel username
               

1. Add the necessary user to the system, to add a new user on your system, use the command:

   # useradd username

   To add or change password for user on your system, use the command:

   # passwd username

   For example:

   # useradd admin # passwd admin

   The output should look something like this.

   Changing password for user admin New UNIX password: somepasswd passwd: all authentication tokens updated successfully

2. The immutable bit can be used to prevent accidentally deleting or overwriting a file that must be protected. It also prevents someone from creating a symbolic link to this file, which has been the source of attacks involving the deletion of /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow. To set the immutable bit on the passwords and groups files, use the command:

# chattr   +i /etc/passwd
# chattr   +i /etc/shadow
# chattr   +i /etc/group
# chattr   +i /etc/gshadow
               

Note: In future, if you intend to add or delete users, passwords, usergroups, or group files, you must unset the immutable bit on all those files or you will not be able to make your changes. Also if you intend to install an RPM program that will automatically add a new user to the different immunized passwd and group files, then you will receive an error message during the install if you have not unset the immutable bit from those files.

1.12. Block su to root

The su Substitute User command allows you to become other existing users on the system. For example you can temporarily become root and execute commands as the super-user root. If you don't want anyone to su to root or restrict su command to certain users then add the following two lines to the top of your su configuration file in the /etc/pam.d/ directory. We highly recommend that you limit the person allowed to su to the root account.

1. Edit the su file vi /etc/pam.d/su and add the following two lines to the top of the file:

   auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/pam_wheel.so group=wheel

   After adding the two lines above, the /etc/pam.d/su file should look like this:

   #%PAM-1.0 auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/pam_wheel.so group=wheel auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow use_authtok nullok session required /lib/security/pam_pwdb.so session optional /lib/security/pam_xauth.so

   Which mean only those who are a member of the wheel group can su to root; it also includes logging. Note that the wheel group is a special account on your system that can be used for this purpose. You cannot use any group name you want to make this hack. This hack combined with specifying which TTY devices root is allowed to login on will improve your security a lot on the system.

2. Now that we have defined the wheel group in our /etc/pam.d/su file configuration, it is time to add some users allowed to su to root account. If you want to make, for example, the user admin a member of the wheel group, and thus be able to su to root, use the following command:

# usermod -G10 admin
               

• Which means G is a list of supplementary groups,

• Where the user is also a member of, 10 is the numeric value of the user's ID wheel,

• admin is the user we want to add to wheel group.

Use the same command above for all users on your system you want to be able to su to root account.

1.13. Put limits on resource

The limits.conf file located under the /etc/security directory can be used to control and limit resources for the users on your system. It is important to set resource limits on all your users so they can't perform denial of service attacks number of processes, amount of memory, etc). These limits will have to be set up for the user when he or she logs in. For example, limits for all users on your system might look like this.

1. Edit the limits.conf file vi /etc/security/limits.conf and add or change the lines to read:

   * hard core 0 * hard rss 5000 * hard nproc 20

   This says to prohibit the creation of core files - core 0, restrict the number of processes to 20 - nproc 20, and restrict memory usage to 5M - rss 5000 for everyone except the super user root. All of the above only concern users who have entered through the login prompt on your system. With this kind of quota, you have more control on the processes, core files, and memory usage that users may have on your system. The asterisk * mean: all users that logs in on the server.

2. You must also edit the /etc/pam.d/login file and add the following line to the bottom of the file:

   session required /lib/security/pam_limits.so

   After adding the line above, the /etc/pam.d/login file should look like this:

   #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow session required /lib/security/pam_pwdb.so session required /lib/security/pam_limits.so #session optional /lib/security/pam_console.so

3. Finally edit the /etc/profile file and change the following line:

   ulimit -c 1000000

   to read:

   ulimit -S -c 1000000 > /dev/null 2<&1

   This modification is required so as to avoid getting error messages like this Unable to reach limit during login:.

1.14. Control mounting a file system

You can have more control on mounting a file system like /home and /tmp partitions with some nifty options like noexec, nodev, and nosuid. This can be setup in the /etc/fstab text file. The fstab file contains descriptive information about the various file systems mount options; each line addresses one file system. Details regarding to security options in the fstab text 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.

For more information on options that you can set in this file fstab, see the man pages about mount(8).

Edit the fstab file vi /etc/fstab and change it depending on your needs. For example:

/dev/sda11         /tmp            ext2    defaults        1 2
/dev/sda6          /home           ext2    defaults        1 2
             

To read:

/dev/sda11         /tmp      ext2    defaults,rw,nosuid,nodev,noexec 1 2
/dev/sda6          /home     ext2    defaults,rw,nosuid,nodev        1 2
             

Take a note that we have added the rw option to the modified lines above. This is because the default options for these lines are defaults, which means to set quota, read-write, and suid, so we must add the rw option to continue having read-write access on these modified file systems. For our example above, the /dev/sda11 represent our /tmp directory partition on the system, and /dev/sda6 the /home directory partition. Of course this will be not the same for you, depending on how you have partitioned your hard disk and what kind of disks are installed on your system, IDE -hda, hdb, etc or SCSI -sda, sdb, etc.

Once you have made the necessary adjustments to the /etc/fstab file, it is time to makethe Linux system aware about the modification. This can be accomplished with the following commands:

#mount -oremount /home/
#mount -oremount /tmp/
             

Each file system that has been modified must be remounted with the command show above. In our example we have modified the /home/, and /tmp/ file system and it is for this reason that we remount these file system with the above commands.

1.15. Conceal binary RPM

Once you have installed all the software that you need on yo42ur Linux server with the RPM command, it's a good idea for better security to move it to a safe place like a floppy disk or other safe place of your choice. With this method if some one accesses your server and has the intention to install software like trojan horses, password thieves etc. with RPM command, he shouldn't be able to do so. Of course, if in the future you want to install or upgrade new software via RPM, all you have to do is to replace the RPM binary to its original directory again. To move the RPM binary on the floppy disk, use the command:

# mount /dev/fd0 /mnt/floppy/
# mv /bin/rpm /mnt/floppy/
# umount /mnt/floppy
             

Never uninstall the RPM program completely from your system or you will be unable to reinstall it again later, since to install RPM or other software you need to have RPM commands available. Another thing you can do is change the default permission of the rpm command from 755 to 700. With this modification, non-root users can't use the rpm program to query, install etc; in case you forget to move it to a safe place after installation of new programs. To change the default permission of /bin/rpm, use the command:

# chmod 700  /bin/rpm
             

1.16. Shell logging

To make it easy for you to repeat long commands, the bash shell stores up to 500 old commands in the ~/.bash_history file where ~/ is your home directory. Each user that has an account on the system will have this file .bash_history in their home directory. Reducing the number of old commands the .bash_history files can hold may protect users on the server who enter by mistake their password on the screen in plain text and have their password stored for a long time in the .bash_history file.

1. The HISTFILESIZE and HISTSIZE lines in the /etc/profile file determine the size of old commands the .bash_history file for all users on your system can hold. For all accounts I would highly recommend setting the HISTFILESIZE and HISTSIZE in /etc/profile file to a low value such as 20. Edit the profile file vi /etc/profile and change the lines to:

   HISTFILESIZE=20 HISTSIZE=20

   Which mean, the .bash_history file in each users home directory can store 20 old commands and no more. Now, if a cracker tries to see the ~/.bash_history file of users on your server to find some password typed by mistake in plain text, he or she has less chance to find one.

2. The administrator should also add into the /etc/skel/.bash_logout file the rm -f $HOME/.bash_history line, so that each time a user logs out, its .bash_history file will be deleted so crackers will not be able to use .bash_history file of users who are not presently logged into the system. Edit the .bash_logout file vi /etc/skel/.bash_logout and add the following line:

# rm -f  $HOME/.bash_history
                      

The above hack will only work for future users you'll add in the server. If you already have existing users in the /etc/passwd file, you must edit and add the above line into their .bash_logout files manually.

4.17. The GRUB and grub.conf file

GRUB is the most 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. GRUB is very important in the Linux system and for this reason, we must protect it the best we can. The most important configuration file of GRUB is the /boot/grub/menu.1 file. It is with those files that we can configure and improve the security of our GRUB program and Linux system. Following are three important options that will improve the security of our valuable GRUB program.

Adding: timeout=00

This option controls how long in seconds GRUB waits for user 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: password MD5 <password>

This option asks the user for a password when trying to load the Linux system in single mode. Passwords are always case-sensitive, also make sure the /boot/grub/menu.1st file is no longer world readable, or any user will be able to read the password.

An example of protected /boot/grub/menu.1st file.

1. Edit the file vi /boot/grub/menu.1st and add or change the above three options as show:

default=0
timeout=10
password –md5 <PASSWORD>
splashimage=(hd0,1)/boot/grub/splash.xpm.gz
title Linux (2.6.11-1.14_smp)
        root (hd0,1)
        kernel /boot/vmlinuz-2.6.11-1.14_smp ro root=LABEL=/  rhgb quiet
        initrd /boot/initrd-2.6.11-1.14_smp.img
              

2. Because the configuration file /boot/grub/menu.1st now contains sensitive information, it should only be readable for the super-user root.

   # chmod 600 /boot/grub/menu.1st will be no longer world readable.

3. One more security measure you can take to secure the /boot/grub/menu.1stfile is to set it immutable, using the chattr command. To set the file immutable simply, use the command:

   # chattr +i /boot/grub/menu.1st

   And this will prevent any changes accidental or otherwise to the /boot/grub/menu.1stfile. If you wish to modify the /boot/grub/menu.1st file you will need to unset the immutable flag: To unset the immutable flag, use the command:

# chattr -i /boot/grub/menu.1st
              

1.19. Disable Ctrl-Alt-Delete keyboard shutdown command

Commenting out the line with a # listed below in your /etc/inittab file will disable the possibility of using the Ctrl-Alt-Delete command to shutdown your computer. This is pretty important if you don't have the best physical security on the box. To do this, edit the inittab file vi /etc/inittab and change the line:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now
            

To read:

#ca::ctrlaltdel:/sbin/shutdown -t3 -r now
            

Now, for the change to take effect type in the following at a prompt:

#/sbin/init q
            

1.21. Tighten scripts under /etc/rc.d/

Fix the permissions of the script files that are responsible for starting and stopping all your normal processes that need to run at boot time.

# chmod -R 700  /etc/rc.d/init.d/*
            

Which means just root is allowed to Read, Write, and Execute scripts files on this directory. I don't think regular users need to know what is inside those script files.

Note: If you install a new program or update a program that use the init system V script located under /etc/rc.d/init.d/ directory, don't forget to change or verify the permission of this script file again.

1.21.1. The /etc/rc.d/rc.local file

By default, when you login to a Linux box, it tells you the Linux distribution name, version, kernel version, and the name of the server. This is giving away too much info. We'd rather just prompt users with a Login:

1. To do this, Edit the /etc/rc.d/rc.local file and Place # in front of the following lines as shown:

   # 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 # #cp -f /etc/issue /etc/issue.net #echo >> /etc/issue

2. Then, remove the following files: issue.net and issue under /etc directory:

# rm -f  /etc/issue
# rm -f  /etc/issue.net
            

The /etc/issue.net file is the login banner that users will see when they make a networked i.e. telnet, SSH connection to your machine. You will find it in the /etc directory, along with a similar file called issue, which is the login banner that gets displayed to local users. It is simply a text file and can be customized to your own taste, but be aware that as noted above, if you do change it or remove it like we do, you'll also need to modify the /etc/rc.d/rc.local shell script, which re-creates both the issue and issue.net files every time the system boots.

1.22. SUID/GUID 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 your computer with the s bits appearing on its mode, have the SUID -rwsr-xr-x or SGID -r-xr-sr-x bit enabled. Because these programs grant special privileges to the user who is executing them, it is important to remove the s bits from root-owned programs that won't absolutely require such privilege. This can be accomplished by executing the command chmod a-s with the name(s) of the SUID/SGID files as its arguments. Such programs include, but aren't limited to:

• Programs you never use.

• Programs that you don't want any non-root users to run.

• Programs you use occasionally, and don't mind having to su to root to run.

We've placed an asterisk * next to each program we personally might disable and consider to be not absolutely required for the working of our server. Remember that your system needs some suid root programs to work properly, so be careful. make your choices based on your requirements. To find all files with the s bits from root-owned programs, use the command:

#find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -lg {} \;
             

-r-s--x--x  1 root 18188 Jan 21 11:16 /sbin/pam_timestamp_check
-r-sr-xr-x  1 root 251554 Jan 21 11:16 /sbin/pwdb_chkpwd
-rwxr-sr-x  1 root 10839 Mar 30 16:13 /sbin/netreport
-r-sr-xr-x  1 root 40964 Jan 21 11:16 /sbin/unix_chkpwd
-rwsr-xr-x  1 root 52770 Oct  5  2004 /bin/su
-rwsr-xr-x  1 root 12408 Jun 15  2004 /bin/traceroute6
-rwsr-xr-x  1 root 35108 Jun 15  2004 /bin/ping
-rwsr-xr-x  1 root 49228 Jun 16 17:08 /bin/umount
-rwsr-xr-x  1 root 23332 Oct 11  2004 /bin/traceroute
-rwsr-xr-x  1 root 30948 Jun 15  2004 /bin/ping6
-rwsr-xr-x  1 root 82696 Jun 16 17:08 /bin/mount
            

To disable the suid bits on selected programs above, type the following commands:

# chmod a-s /sbin/pam_timestamp_check
# chmod a-s /sbin/pwdb_chkpwd
# chmod a-s /sbin/netreport
# chmod a-s /sbin/unix_chkpwd
# chmod a-s /bin/su
# chmod a-s /bin/traceroute6
# chmod a-s /bin/ping
# chmod a-s /bin/mount
# chmod a-s /bin/traceroute
# chmod a-s /bin/ping6
# chmod a-s /bin/umount

If you want to know what those programs do, type man program-name and read the man page.

          
# man su
            

1.23. The kernel tunable parameters

With the new version of Red Hat Linux 6.2 all kernel parameters available under the /proc/sys subdirectory of Linux can be configured at runtime. You can now use the new /etc/sysctl.conf file under Red Hat Linux 6.2 to modify and set kernel parameters at runtime. The sysctl.conf file is read and loaded each time the system reboots. All settings are now stored in the /etc/sysctl.conf file. All modifications to /proc/sys should be made through /etc/sysctl.conf, because they offer better for control, and are executed before rc.local or any other users scripts. We have shown you the networking security options that you must configure on your server for both Red Hat Linux version 6.1 and 6.2 below.

1.23.1. Prevent your system responding to Ping

Preventing your system for responding to ping request can be a big improvement in your network security since no one can ping on your server and receive an answer. The TCP/IP protocol suite has a number of loopholes that allows an attacker to leverage techniques in the form of covert channels to surreptitiously pass data in otherwise benign packets. Preventing your server from responding to ping requests can help to minimize this problem. An...

#echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
            

... should do the job such that your system won't respond to ping on any interface. You can add this line in your /etc/rc.d/rc.local file so the command will be automatically set if your system reboots. Not responding to pings would at least keep most "crackers" out because they would never even know it's there. To turn it backs on, simply do this:

#echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
            

You can add this line in your /etc/rc.d/rc.local file so the command will be automatically set if your system reboots.

Edit the /etc/sysctl.conf file and add the following line:

# Enable ignoring ping request
net.ipv4.icmp_echo_ignore_all = 1
            

You must restart your network for the change to take effect. The command to restart the network is the following: To restart all network devices manually on your system, use the following command:

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

1.24. Refuse responding to broadcasts request

As for the ping request, it's also important to disable broadcast request. When a packet is sent to an IP broadcast address (i.e. 192.168.1.255) from a machine on the local network, that packet is delivered to all machines on that network. Then all the machines on a network respond to this ICMP echo request and the result can be severe network congestion or outages -denial-of-service attacks. See the RFC 2644 for more information.

  # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
             

You can add this line in your /etc/rc.d/rc.local file so the command will be automatically set if your system reboots.

Edit the /etc/sysctl.conf file and add the following line:

# Enable ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts = 1
              

You must restart your network for the change to take effect. The command to restart the network is the following:

To restart all networks devices manually on your system, use the following command:

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

1.25. Routing Protocols

Routing and routing protocols can create several problems. The IP source routing, where an IP packet contains details of the path to its intended destination, is dangerous because according to RFC 1122 the destination host must respond along the same path. If an attacker was able to send a source routed packet into your network, then he would be able to intercept the replies and fool your host into thinking it is communicating with a trusted host. I strongly recommend that you disable IP source routing to protect your server from this hole.

To disable IP source routing on your server, type the following command in your terminal:

# for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
> echo 0 > $f
> done
           

#
              

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Disables IP source routing
net.ipv4.conf.all.accept_source_route = 0
              

You must restart your network for the change to take effect. The command to restart the network is the following:

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

1.26. Enable TCP SYN Cookie Protection

A SYN Attack is a denial of service DoS attack that consumes all the resources on your machine, forcing you to reboot. Denial of service attacks -attacks which incapacitate a server due to high traffic volume or ones that tie-up system resources enough that the server cannot respond to a legitimate connection request from a remote system) are easily achievable from internal resources or external connections via extranets and Internet. To enable it, you have to do:

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
            

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Enable TCP SYN Cookie Protection
  net.ipv4.tcp_syncookies = 1
            

You must restart your network for the change to take effect. The command to restart the network is the following:

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

Note: SYN cookies work to alleviate SYN floods by calculating cookies that are functions of the source address, source port, destination address, destination port, and a random secret seed. These cookies are sent to the requesting client, and state is not kept for the initiated session. Since state is not kept, the SYN queue is not exhausted, and normal TCP communications can continue.

1.27. Disable ICMP Redirect Acceptance

When hosts use a non-optimal or defunct route to a particular destination, an ICMP redirect packet is used by routers to inform the hosts what the correct route should be. If an attacker is able to forge ICMP redirect packets, he or she can alter the routing tables on the host and possibly subvert the security of the host by causing traffic to flow via a path you didn't intend. It's strongly recommended to disable ICMP Redirect Acceptance to protect your server from this hole.

# for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
> echo 0 > $f
> done
              

#
              

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
              

You must restart your network for the change to take effect. The command to restart manually the network is the following:

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

1.28. Enable always-defragging Protection

This protection must be enabled if you use your Linux server as a gateway to masquerade internal traffic to the Internet IP Masquerading.

#echo 1 > /proc/sys/net/ipv4/ip_always_defrag
            

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Enable always defragging Protection
net.ipv4.ip_always_defrag = 1
            

You must restart your network for the change to take effect. The command to manually restart the network is the following:

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

1.29. Enable bad error message Protection

This option will alert you to all bad error messages in your network.

#echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
              

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Enable bad error message Protection
  net.ipv4.icmp_ignore_bogus_error_responses = 1
              

You must restart your network for the change to take effect. The command to manually restart the network is the following:

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

1.30. Enable IP spoofing protection

The spoofing protection prevents your network from being the source of spoofed i.e. forged communications that are often used in DoS attacks.

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
> echo 1 > $f
> done
              

#
              

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Enable IP spoofing protection, turn on Source Address Verification
  net.ipv4.conf.all.rp_filter = 1
              

You must restart your network for the change to take effect. The command to manually restart the network is the following:

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

1.31. Log Spoofed, Source Routed and Redirect Packets

WARNING: Can generate a lot of messages depending on network traffic.

This protection will log all Spoofed Packets, Source Routed Packets, and Redirect Packets to your log files.

# for f in /proc/sys/net/ipv4/conf/*/log_martians; do
> echo 1 > $f
> done
            

#
            

Add the above commands to the /etc/rc.d/rc.local script file and you'll not have to type it again the next time you reboot your system.

Edit the /etc/sysctl.conf file and add the following line:

# Log Spoofed Packets, Source Routed Packets, Redirect Packets
  net.ipv4.conf.all.log_martians = 1
            

You must restart your network for the change to take effect. The command to manually restart the network is the following:

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

1.32. Unusual or hidden files

It is important to not forget to look everywhere on the system for unusual or hidden files -files that start with a period and are normally not shown by the ls command, as these can be used to hide tools and information password cracking programs, password files from other systems, etc.. A common technique on UNIX systems is to put a hidden directory or file in a user's account with an unusual name, something like '...' or '.. ' -dot dot space or ..-^G -dot dot ctrl-G. The find program can be used to look for hidden files.

# find / -name ".. " -print -xdev
# find / -name ".*" -print -xdev | cat -v
            

Note: Files with names such as .xx and .mail have been used that is, files that might appear to be normal.

All SUID and SGID files that still exist on your system after we have removed those that won't absolutely require such privilege are a potential security risk, and should be monitored closely. Because these programs grant special privileges to the user who is executing them, it is necessary to ensure that insecure programs are not installed.

A favorite trick of crackers is to exploit SUID root programs, and leave a SUID program as a backdoor to get in the next time. Find all SUID and SGID programs on your system, and keep track of what they are so that you are aware of any changes, which could indicate a potential intruder. Use the following command to find all SUID/SGID programs on your system:

# find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -lg {} \;
            

Group 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 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:

# find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;
            

To locate all group & world-writable directories on your system, use the command:

# find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;
            

Don't permit any unowned file. 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:

#find / -nouser -o -nogroup
            

Please Note Once again, files reported under /dev directory don't count.

Finding all the .rhosts files that could exist on your server should be a part of your regular system administration duties, as these files should not be permitted on your system. Remember that a cracker only needs one insecure account to potentially gain access to your entire network. You can locate all .rhosts files on your system with the following command:

#find /home -name .rhosts
            

You can also use a cron job to periodically check for, report the contents of, and delete $HOME/.rhosts files. Also, users should be made aware that you regularly perform this type of audit, as directed by policy.

To use a cron job to periodically check and report via mail all .rhosts files, do the following: Create as root the find_rhosts_files script file under /etc/cron.daily directory touch /etc/cron.daily/find_rhosts_files and add the following lines in this script file:

#!/bin/sh
/usr/bin/find /home -name .rhosts | (cat <<EOF
This is an automated report of possible existent .rhosts files on the server
host.mydomain.org, generated by the find utility command.

New detected .rhosts files under the /home directory include:
EOF
cat
) | /bin/mail -s "Content of .rhosts file audit report" root
            

Now make this script file executable, verify the owner, and change the group to root.

#chmod 755 /etc/cron.daily/find_rhosts_files
#chown 0.0 /etc/cron.daily/find_rhosts_files
            

Each day mail will be sent to root with a subject: Content of .rhosts file audit report containing potential new .rhosts files.

Acknowledgment

Gerhard Mourani

Open Network Architecture www.openna.com

             gmourani@openna.com
             gmourani@netscape.net
             

Madhu "Maddy"

Copyright © 2000 by Gerhard Mourani and OpenDocs, LLC.

Copyright © 2000 by Madhusudan (Madhu "Maddy") XML Source