Securing Linux - Part 2

Post install steps to securing a Linux box.

by Mike Peters, April 2004
(Originally published on Linux.com)

File Permissions

SUID and SGID Files

SUID and SGID files are executables which, when run by a normal user, may have access to resources not normally available to the user running the program. For example, an SUID program could have the permissions:

    -r-sr-xr-x    1 root     root      11267 Jan 21 00:28 /usr/sbin/foo
    

The s in the owner's permission field in place of the usual x indicates that /usr/sbin/foo is SUID. If run by a normal user, the executable will run with the privileges of the owner of the file, in this case root. In this case the program will have access to the same system resources as root.

Below is an example of an SGID file:

    -r-xr-sr-x    1 root     foo      11267 Jan 21 00:28 /usr/sbin/foo
    

Here there is an s in the place of the group's executable bit meaning the file is SGID and will be executed with the group permissions of the foo group. SGID and SUID programs potentially be used by a cracker to gain elevated permissions on a system. It is therefore important to keep track of such files. You can find SUID and SGID files using find:

    # find / -perm -4000 -o -perm -2000 -exec ls -ldb {} \; 
                >> SUID_files.txt
    

This command will find any SUID or SGID files and list them in a file called SUID_files.txt. You can unset SUID or SGID privileges with:

however be warned, unsetting the SUID or SGID bit on some programs may mean that they will no longer run. The important thing is that you keep the list of files safe and that you periodically check for new SUID or SGID files as their presence may indicate a system compromise.

There should be no reason for users to have SUID files in their home directories so you should use the nosuid option in /etc/fstab for the partition containing users $HOME directories For example:

/dev/hda3     /home   ext3   defaults,nosuid   1  1

World Readable/Writable Files

Files should only be world readable or writable if their is a very good reason. You should check for such files as you did above for SGID and SUID files:

    # find / \( -perm -a+r -o -perm -a+w \) ! -type l 
                >> world_readwrite.txt
    

Again, check through the list and remove permissions from files which do not need to be world readable or writable. Keep the output from the command in a safe place and run checks regularly for new world readable or writable files.

Files With No Owner or Group

Owner-less files could be an indication that someone has gained access to your system. You should check regularly using:

If you find any ownerless files, either delete them, or, if you know what they are and wish to keep them, assign them to an appropriate user and group. For example, assign myfile to the user foo and the group bar you would issue the command:

Using UMask

Umask can be used to determine the permissions given to newly created files on your system. For example, using the line:

in /etc/profile will mean that any files created by users will have the permissions 0644 or -rw-r--r--. This means users will have to explicitly make a file executable using chmod in their $HOME. More restrictive permissions can be provided using umasks of 027, 077 etc, depending upon your particular needs,.

The Immutable and Append Only Bits

With chattr root can set files to be read only or append only. Setting the immutable bit (making a file read-only) ensures that a file cannot be altered, even by root (of course root can remove the immutable bit and then alter the file so it's not water-tight). Setting the append only bit ensures that the existing contents of a file can not be changed, only added to. It is a good idea to set the append only bit on log files for example:

You can set the immutable bit to make it more difficult to replace important executables or change critical configuration files:

The attributes of files set by chattr can be displayed using the lsattr utility.

System Logs

In order to trace any unwanted activity on your computer, it is important to keep complete and accurate logs. On Linux machines, logging is handled by the syslog daemon, syslogd. Syslogd reads its configuration from the /etc/syslog.conf file. You can set the facilities to be logged, the log priority and the files in which to log information here. The default values in most distributions are not usually enough.

A sensible log policy, I find, is to log almost everything in /var/log/messages and /var/log/syslog and then to have each individual facility log to its own separate file as shown in the example below:

    --- Begin Example syslog.conf-----

    # Log anything 'info' or higher, but lower than 'warn'.
    # Exclude mail.  This is logged elsewhere.
    *.info;*.!warn;mail.none                        -/var/log/messages
     
    # Log anything 'warn' or higher.
    # Exclude mail.  This is logged elsewhere.
    *.warn;                                         -/var/log/syslog
     
    # Debugging information is logged here.
    *.=debug                                	    -/var/log/debug

    # Kernel related logs:
    kern.*  						-/var/log/kernel 

    # Private authentication message logging:
    authpriv.*                                      -/var/log/secure
     
    # Cron related logs:
    cron.*                                          -/var/log/cron
     
    # Mail related logs:
    mail.*                                          -/var/log/maillog
     
    # Daemon related logs:
    daemon.*                                        -/var/log/daemonlog
                                                                                                     
    # User related logs:
    user.*                                          -/var/log/userlog
                                                                                                     
    # Mark logs:
    mark.*                                          -/var/log/marklog
                                                                                                     
    # Emergency level messages go to all users consoles:
    *.emerg                                                 *

    --- End Example syslog.conf-----
    

Note the '-' before the log files' names. This tells syslogd not to sync after every log. The disadvantage of this is that log information may be lost in the event of a system crash, however, removing the '-' can cause a performance loss with heavy logging.

If you want to be able to track logs in real-time, you can open a log file using:

or alternatively you can have a permanent log console by adding the line

to the end of your syslog.conf file. This will display logs in real time on /dev/tty8 (be sure that tty8 exists of course).

In order to keep accurate logs, it is important that you ensure that your system clock is kept accurate at all times. You should look to enabling ntp to maintain your system clock's accuracy. The easiest way to do this is to regularly run ntpdate some.time.server from a cron job.

Finally, although no really related to your system logs, make sure you redirect root's mail to your normal user account. That way you won't miss any important warning mail messages sent to root. You should do this either by placing the line:

in /etc/aliases and running the command newaliases. Or, alternatively, create a file named .forward in /root containing the address you want mail to be forwarded to.

Continue to Part 3 >>>