[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ next ]

Securing Debian Manual
Chapter 4 - After Installation


Once the system is installed you can still secure the system more, some of the steps described in this chapter can be taken. Of course this really depends on your setup but for physical access prevention you should read Change the BIOS (again), Section 4.1,Set a LILO or GRUB password, Section 4.2,Remove root prompt on the kernel, Section 4.3, Disallow floppy booting, Section 4.4, Restricting console login access, Section 4.5, and Restricting system reboots through the console, Section 4.6.

Before connecting to any network, specially if it's a public one you should, at the very least: execute a security update (see Execute a security update, Section 4.8). Optionally, you could take a snapshot of your system (see Taking a snapshot of the system, Section 4.17).


4.1 Change the BIOS (again)

Remember Choose a BIOS password, Section 3.1? Well, then you should now, once you do not need to boot from removable media, to change the default BIOS setup so that it only boots from the hard drive. Make sure you will not lose the BIOS password, otherwise, in the event of a hard disk failure you will not be able to return to the BIOS and change the setup so you can recover it using, for example, a CD-ROM.

Another less secure but more convenient setup would change the setup to have the system boot up from the hard disk and, if it fails, try removable media. By the way, this is often done because since few people use the BIOS password that much often it's easily forgotten.


4.2 Set a LILO or GRUB password

Anybody can easily get a root-shell and change your passwords by entering "<name-of-your-bootimage> init=/bin/sh" at the boot prompt. After changing the passwords and rebooting the system, the person has unlimited root-access and can do anything he/she wants to the system. After this procedure you will not have root access to your system, as you do not know the root password.

To make sure that this can not happen, you should set a password for the boot loader. You can choose between a global password or a password for a certain image.

For LILO you need to edit the config file /etc/lilo.conf and add a "password" and "restricted" line as in the example below.

     image=/boot/2.2.14-vmlinuz
        label=Linux
        read-only
        password=hackme
        restricted

When done, rerun lilo. Omitting the "restricted" line causes lilo to always prompt for a password, regardless of whether LILO was passed parameters. The default permissions for /etc/lilo.conf grant root read and write permissions, and enable read-only access for lilo.conf's group, root.

If you use GRUB instead of LILO, edit /boot/grub/menu.lst and add the following two lines at the top (substituting, of course 'hackme' with the desired password). This prevents users from editing the boot items. 'timeout 3' specifies a 3 second delay before grub boots the default item.

     timeout 3
     password hackme

To further harden the integrity of the password, you may store the password in a encrypted form. The utility grub-md5-crypt generates a hashed password which is compatible with grub's encrypted password algorithm (md5). To specify in grub that md5 format password will be used, use the following directive:

     timeout 3
     password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0

The --md5 parameter was added to instruct grub to perform the md5 authentication process. The provided password is the md5 en crypted version of hackme. Using the md5 password method is preferable to choosing its cleartext counterpart. More information about grub passwords may be found in the grub-doc package.


4.3 Remove root prompt on the kernel

Linux 2.4 kernels provide a way to access a root shell while booting which will be presented just after loading the cramfs filesystem. A message will appear to permit the administrator to enter an executable shell with root permissions, this shell can be used to manually load modules when autodetection fails. This behavior is the default for initrd's linuxrc. The following message will appear:

     Press ENTER to obtain a shell (waits 5 seconds)

In order to remove this behavior you need to change /etc/mkinitrd/mkinitrd.conf and set:

     # DELAY  The  number  of seconds the linuxrc script should wait to
     # allow the user to interrupt it before the system is brought up
     DELAY=0

Then regenerate your ramdisk image. You can do this for example with:

     º
     # cd /boot
     # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7

or doing (preferred):

     # dpkg-reconfigure kernel-image-2.4.x-yz

Note that Debian 3.0 woody allows users to install 2.4 kernels (selecting flavors), however the default kernel is 2.2 (save for some architectures for which kernel 2.2 was not ported to). If you consider this a bug consider Bug 145244 before sending it.


4.4 Disallow floppy booting

The default MBR in Debian before version 2.2 did not act as a usual master boot record and left open a method to easily break into a system:

This behavior can be changed by entering:

     lilo -b /dev/hda

Now LILO is put into the MBR. This can also be achieved by adding "boot=/dev/hda" to lilo.conf. There is another solution which will disable the MBR prompt completely:

     install-mbr -i n /dev/hda

On the other hand, this "back door", of which many people are just not aware, may save your skin as well if you run into deep trouble with your installation for whatever reasons.

FIXME check whether this really is true as of 2.2 or was it 2.1? INFO: The bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO


4.5 Restricting console login access

Some security policies might want to force administrators to log in the system through the console with their user/password and then become superuser (with su or sudo). This policy is implemented in Debian by editing the /etc/login.defs file or /etc/securetty when using PAM. In:

When using PAM other changes to the login process, which might include restrictions to users and groups at given times, can be configured at /etc/pam.d/login. An interesting feature that can be disabled is the possibility to login with null (blank) passwords. This feature can be limited by removing nullok from the line:

     auth       required   pam_unix.so nullok

4.6 Restricting system reboots through the console

If you system has a keyboard attached to it anyone (yes anyone) can reboot the system through it without login in the system. This might, or might not, adhere to your security policy. If you want to restrict this, you must check the /etc/inittab so that the line that includes ctrlaltdel calls shutdown with the -a switch (remember to run init q after making any changes to this file). The default in Debian includes this switch:

     ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Now, in order to allow some users to shutdown the system, as the manpage shutdown(8) describes, you must create the file /etc/shutdown.allow and include there the name of users which can boot the system. When the three finger salute (a.k.a. ctrl+alt+del) is given the program will check if any of the users listed in the file are logged in. If none of them is shutdown will not reboot the system.


4.7 Mounting partitions the right way

When mounting an ext2 partition, you have several additional options you apply to the mount call or to /etc/fstab. For instance, this my fstab entry for the /tmp partition:

     /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

You see the difference in the options sections. The option nosuid ignores the setuid and setgid bits completely, while noexec forbids execution of any program on that mount point, and nodev, ignores devices. This sounds great, but it

The noexec option prevents binaries from being executed directly, but is easily circumvented:

     alex@joker:/tmp# mount | grep tmp
     /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
     alex@joker:/tmp# ./date
     bash: ./date: Permission denied
     alex@joker:/tmp# /lib/ld-linux.so.2 ./date
     Sun Dec  3 17:49:23 CET 2000

However, many script kiddies have exploits which try to create and execute files in /tmp. If they do not have a clue, they will fall into this pit. In other words, a user cannot be tricked into executing a trojanized binary in /tmp e.g. when he incidentally adds /tmp into his PATH.

Also be forewarned, some script might depend on /tmp begin executable. Most notably, Debconf has (had?) some issues regarding this, for more information see Bug 116448.

The following is a more thorough example. A note, though: /var could be set noexec, but some software like Smartlist keeps its programs in /var. The same applies to the nosuid option.

     /dev/sda6       /usr            ext2    defaults,ro,nodev       0       2
     /dev/sda12      /usr/share      ext2    defaults,ro,nodev,nosuid        0       2
     /dev/sda7       /var            ext2    defaults,nodev,usrquota,grpquota          0       2
     /dev/sda8       /tmp            ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda9       /var/tmp        ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda10      /var/log        ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda11      /var/account    ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda13      /home           ext2    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
     /dev/fd0        /mnt/fd0        ext2    defaults,users,nodev,nosuid,noexec      0       0
     /dev/fd0        /mnt/floppy     vfat    defaults,users,nodev.nosuid,noexec      0       0
     /dev/hda        /mnt/cdrom      iso9660 ro,users,nodev.nosuid,noexec            0       0

4.7.1 Setting /tmp noexec

Be careful if setting /tmp noexec and you want to install new software, since some might use it for installation. Apt is one such program (see http://bugs.debian.org/116448) if not configured properly APT::ExtractTemplates::TempDir (see apt-extracttemplates(1)). You can set this variable in /etc/apt/apt.conf to another directory with exec privileges other than /tmp

Regarding noexec, please be aware that it might not offer you that much security. Consider this:

     $ cp /bin/date /tmp
     $ /tmp/date
     (does not execute due to noexec)
     $/lib/ld-linux.so.2 /tmp/date
     (works since date is not executed directly)

4.7.2 Setting /usr read-only

If you set /usr read-only you will not be able to install new packages on your Debian GNU/Linux system. You will have, first to remount it read-write, install the packages and then remount it read-only. The latest apt version (in Debian 3.0 'woody') can be configured to run commands before and after installing packages, so you might want to configure it properly.

To do this modify /etc/apt/apt.conf and add:

       DPkg
       {
           Pre-Invoke  { "mount /usr -o remount,rw" };
           Post-Invoke { "mount /usr -o remount,ro" };
       };

Note that the Post-Invoke may fail with a "/usr busy" error message. This happens mainly when you are using files during the update that got updated. Annoying but not really a big deal. Just make sure these are no longer used and run the Post-Invoke manually.


4.8 Execute a security update

As soon as new security bugs are detected in packages, Debian maintainers and upstream authors generally patch them within days or even hours. After the bug is fixed, a new package is provided on http://security.debian.org.

If you are installing a Debian release you must take in account that since the release was made there might have been security updates after it has been determined that a given package is vulnerable. Also, there might have been minor releases (there were up to seven in Debian 2.2 potato release) which include these package updates.

You need to note down the date the removable media (if you are using it) was made and check the security site in order to see if there are security updates. If there are and you cannot download the packages from the security site on another system (you are not connected to the Internet yet? aren't you?) before connecting to the network you could consider (if not protected by a firewall for example) adding firewall rules so that you system could only connect to security.debian.org and then run the update. A sample configuration is shown in Security update protected by a firewall, Appendix F.

To update the system, put the following line in your sources.list and you will get security updates automatically, whenever you update your system.

     deb http://security.debian.org/debian-security stable/updates main contrib non-free

Most people, who don't live in a country which prohibits importing or using strong cryptography, should add this line as well:

     deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free

If you like, you can add the deb-src lines to apt as well. See apt(8) for further details.

You should conduct security updates frequently, the vast majority of exploitations result from known vulnerabilities that have not been patched in time, as a http://www.cs.umd.edu/~waa/vulnerability.html name="paper by Bill Arbaugh"> (presented on the 2001 IEEE Symposium on Security and Privacy) explains.

FIXME: Add info on how the signature of packages is done so that this can be done automatically through a cron job (big warning: DNS spoofing).


4.9 Providing secure user's access


4.9.1 User authentication: PAM

PAM (Pluggable Authentication Modules) allows system administrators to choose how applications authenticate users. Note that PAM can do nothing unless an application is compiled with support for PAM. Most of the applications that are shipped with Debian 2.2 have this support built in. Furthermore, Debian did not have PAM support before 2.2. The current default configuration for any PAM-enabled service is to emulate UNIX authentication (read /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz for more information on how PAM services should work in Debian).

Each application with PAM support provides a configuration file in /etc/pam.d/ which can be used to modify its behavior:

The following description is far from complete, for more information you might want to read the The Linux-PAM System Administrator's Guide (at the primary PAM distribution site), this document is also provided in the libpam-doc.

PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if he authenticates correct in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to "requisite", which returns a login failure if one module fails.

The first thing I like to do, is to add MD5 support to PAM applications, since this helps protects against dictionary cracks (passwords can be longer if using MD5). The following two lines should be added to all files in /etc/pam.d/ that grant access to the machine, like login and ssh.

     # Be sure to install libpam-cracklib first or you will not be able to log in
     password   required     pam_cracklib.so retry=3 minlen=12 difok=3
     password   required     pam_unix.so use_authtok nullok md5

So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum length of 12 characters, a difference of at least 3 characters from the old password, and allows 3 retries. The second line introduces the standard authentication module with MD5 passwords and allows a zero length password. The use_authtok directive is necessary to hand over the password from the previous module.

To make sure that the user root can only log into the system from local terminals, the following line should be enabled in /etc/pam.d/login:

     auth     requisite  pam_securetty.so

Then you should add the terminals from which the user root can log into the system into /etc/security/access.conf. Last but not least the following line should be enabled if you want to set up user limits.

     session  required   pam_limits.so

This restricts the system resources that users are allowed (see below in Limiting resource usage: the limits.conf file, Section 4.9.2. For example, you could restrict the number of concurrent logins (of a given group of users, or system-wide) you may have, the number of processes, the memory size...

Now edit /etc/pam.d/passwd and change the first line. You should add the option "md5" to use MD5 passwords, change the minimum length of password from 4 to 6 (or more) and set a maximum length, if you desire. The resulting line will look something like:

     password   required   pam_unix.so nullok obscure min=6 max=11 md5

If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group "wheel" to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to su to the root user to this group. Then add the following line to /etc/pam.d/su:

     auth        requisite   pam_wheel.so group=wheel debug

This makes sure that only people from the group wheel can use su to become root. Other users will not be able to become root. In fact they will get a denied message if they try to become root.

If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow user 'ref' to login via ssh. So you put him into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh:

     auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

Last, but not least, create /etc/pam.d/other and enter the following lines:

     auth     required       pam_securetty.so
     auth     required       pam_unix_auth.so
     auth     required       pam_warn.so
     auth     required       pam_deny.so
     account  required       pam_unix_acct.so
     account  required       pam_warn.so
     account  required       pam_deny.so
     password required       pam_unix_passwd.so
     password required       pam_warn.so
     password required       pam_deny.so
     session  required       pam_unix_session.so
     session  required       pam_warn.so
     session  required       pam_deny.so

These lines will provide a good default configuration for all applications that support PAM (access is denied per default).


4.9.2 Limiting resource usage: the limits.conf file

You should really take a serious look into this file. Here you can define user resource limits. If you use PAM, the file /etc/limits.conf is ignored and you should use /etc/security/limits.conf instead.

If you do not restrict resource usage, any user with a valid shell in your system (or even an intruder who compromised the system through a service) can use up as much CPU, memory, stack, etc. the system can provide. This resource exhaustion problem can only be fixed by the use of PAM. Note that there is a way to add resource limits to some shells (for example, bash has ulimit, see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules.

For more information read:

FIXME: Get a good limits.conf up here


4.9.3 User Login actions: edit /etc/login.defs

The next step is to edit the basic configuration and action upon user login.

     FAIL_DELAY          10

This variable should be set to a higher value to make it harder to use the terminal to log in using brute force. If a wrong password is typed in, the possible attacker (or normal user!) has to wait for 10 seconds to get a new login prompt, which is quite time consuming when you test passwords. Pay attention to the fact that this setting is useless if using program other than getty, such as mingetty for example.

     FAILLOG_ENAB        yes

If you enable this variable, failed logins will be logged. It is important to keep track of them to catch someone who tries a brute force attack.

     LOG_UNKFAIL_ENAB    yes

If you set the variable "FAILLOG_ENAB" to yes, then you should also set this variable to yes. This will record unknown usernames if the login failed. If you do this, make sure the logs have to the proper permissions (640 for example, with an appropriate group setting such as adm), because users often accidentally enter their password as the username and you do not want others to see it.

     SYSLOG_SU_ENAB      yes

This one enables logging of su attempts to syslog. Quite important on serious machines but note that this can create privacy issues as well.

     SYSLOG_SG_ENAB      yes

The same as SYSLOG_SU_ENAB but applies to the sg program.

     MD5_CRYPT_ENAB      yes

As stated above, MD5 sum passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. If you are using slink, read the docs about MD5 before enabling this option. Otherwise this is set in PAM.

     PASS_MAX_LEN        50

If MD5 passwords are activated in your PAM configuration, then this variable should be set to the same value as used there.


4.9.4 Restricting ftp: editing /etc/ftpusers

The /etc/ftpusers file contains a list of users who are not allowed to log into the host using ftp. Only use this file if you really want to allow ftp (which is not recommended in general, because it uses cleartext passwords). If your daemon supports PAM, you can also use that to allow and deny users for certain services.

FIXME (BUG): Is it a bug that the default ftpusers in Debian does not include all the administrative users (in base-passwd).


4.9.5 Using su

If you really need users to become the super user on your system, e.g. for installing packages or adding users, you can use the command su to change your identity. You should try to avoid any login as user root and instead use su. Actually, the best solution is to remove su and switch to sudo, as it has more features than su. However, su is more common as is used on many other Unices.


4.9.6 Using sudo

sudo allows the user to execute defined commands under another user's identity, even as root. If the user is added to /etc/sudoers and authenticates himself correctly, he is able to run commands which have been defined in /etc/sudoers. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root.


4.9.7 Disallow remote adminitrative access

You should modify /etc/security/access.conf also so that remote administrative login is disallowed. This way the users need to use su (or sudo) so that there is always an audit trace whenever a local user wants to use administrative powers.

You need to add the following line to /etc/security/access.conf, the default Debian configuration file has a sample line commented out:

        -:wheel:ALL EXCEPT LOCAL

4.9.8 Restricting users

Sometimes you might think you need to have users created in your local system in order to provide a given service (pop3 mail service or ftp). Before doing so, first remember that the PAM implementation in Debian GNU/Linux allows you to validate users with a wide variety of external directory services (radius, ldap, etc.) provided by the libpam packages.

If users need to be created and the system can be accessed remotely take into account that users will be able to login to the system. You can fix this by giving users a null (/dev/null) shell (it would need to be listed in /etc/shells). If you want to allow users to access the system but limit their movements, you can use the /bin/rbash, equivalent to adding the -r option in bash (RESTRICTED SHELL see bash(1)). Please note that even with restricted shell, a user that access an interactive program (that might allow execution of a subshell) could be able to bypass the limits of the shell.

Debian currently provides in the unstable release (and might be included in the next stable releases) the pam_chroot module. An alternative to it is to chroot the service that provides remote logging (ssh, telnet).

If you wish to restrict when users can access the system you will have to customize /etc/security/access.conf for your needs.


4.9.8.1 Restricting ssh for users

Debian's sshd will not allow you to restrict user's movement through the server since it lacks the Chroot function that the commercial (sshd2) program has (using 'ChrootGroups' or 'ChrootUsers', see sshd2_config(5)). However, there is a patch available that will allow you to do this, the patch can be retrieved from Bug report 139047 or http://www.cag.lcs.mit.edu/~raoul/ (and might be applied in the OpenSSH package in the future). Emanuel Lacour has ssh packages with this feature at http://debian.home-dn.net/woody/ssh/, going through the compilation step is recommended, though. A description of all the steps needed can be found at http://mail.incredimail.com/howto/openssh/ (almost all is applicable to Debian even if it talks about Red Hat 7.2). After applying the patch you just need to modify the /etc/passwd by changing the home path of the users (with the special /./ token):

     joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash

This will restrict both remote shell access as well as remote copy through the ssh channel.

Make sure to have all the needed binaries and libraries in the chrooted path for users. These files should be owned by root to avoid tampering by the user (so as to exit the chrooted jailed). A sample might include:

     ./bin:
     total 660
     drwxr-xr-x    2 root     root         4096 Mar 18 13:36 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -r-xr-xr-x    1 root     root       531160 Feb  6 22:36 bash
     -r-xr-xr-x    1 root     root        43916 Nov 29 13:19 ls
     -r-xr-xr-x    1 root     root        16684 Nov 29 13:19 mkdir
     -rwxr-xr-x    1 root     root        23960 Mar 18 13:36 more
     -r-xr-xr-x    1 root     root         9916 Jul 26  2001 pwd
     -r-xr-xr-x    1 root     root        24780 Nov 29 13:19 rm
     lrwxrwxrwx    1 root     root            4 Mar 30 16:29 sh -> bash
     
     ./etc:
     total 24
     drwxr-xr-x    2 root     root         4096 Mar 15 16:13 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rw-r--r--    1 root     root           54 Mar 15 13:23 group
     -rw-r--r--    1 root     root          428 Mar 15 15:56 hosts
     -rw-r--r--    1 root     root           44 Mar 15 15:53 passwd
     -rw-r--r--    1 root     root           52 Mar 15 13:23 shells
     
     ./lib:
     total 1848
     drwxr-xr-x    2 root     root         4096 Mar 18 13:37 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rwxr-xr-x    1 root     root        92511 Mar 15 12:49 ld-linux.so.2
     -rwxr-xr-x    1 root     root      1170812 Mar 15 12:49 libc.so.6
     -rw-r--r--    1 root     root        20900 Mar 15 13:01 libcrypt.so.1
     -rw-r--r--    1 root     root         9436 Mar 15 12:49 libdl.so.2
     -rw-r--r--    1 root     root       248132 Mar 15 12:48 libncurses.so.5
     -rw-r--r--    1 root     root        71332 Mar 15 13:00 libnsl.so.1
     -rw-r--r--    1 root     root        34144 Mar 15 16:10
     libnss_files.so.2
     -rw-r--r--    1 root     root        29420 Mar 15 12:57 libpam.so.0
     -rw-r--r--    1 root     root       105498 Mar 15 12:51 libpthread.so.0
     -rw-r--r--    1 root     root        25596 Mar 15 12:51 librt.so.1
     -rw-r--r--    1 root     root         7760 Mar 15 12:59 libutil.so.1
     -rw-r--r--    1 root     root        24328 Mar 15 12:57 libwrap.so.0
     
     ./usr:
     total 16
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 bin
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 lib
     
     ./usr/bin:
     total 340
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rwxr-xr-x    1 root     root        10332 Mar 15 15:55 env
     -rwxr-xr-x    1 root     root        13052 Mar 15 13:13 id
     -r-xr-xr-x    1 root     root        25432 Mar 15 12:40 scp
     -rwxr-xr-x    1 root     root        43768 Mar 15 15:15 sftp
     -r-sr-xr-x    1 root     root       218456 Mar 15 12:40 ssh
     -rwxr-xr-x    1 root     root         9692 Mar 15 13:17 tty
     
     ./usr/lib:
     total 852
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rw-r--r--    1 root     root       771088 Mar 15 13:01
     libcrypto.so.0.9.6
     -rw-r--r--    1 root     root        54548 Mar 15 13:00 libz.so.1
     -rwxr-xr-x    1 root     root        23096 Mar 15 15:37 sftp-server

4.9.9 Hand-made user auditing

If you are paranoid you might want to add users a defined .profile that sets the environment in a way such that they cannot remove audit capabilities from the shell (commands are dumped to $HISTFILE. The .profile could be set as follows:

     HISTFILE=/home/_user_/.bash_history
     HISTSIZE=100000000000000000
     HISTFILESIZE=10000000000000000
     set -o HISTFILE
     set -o HISTSIZE
     set -o HISTFILESIZE
     export HISTFILE HISTSIZE HISTFILESIZE

Note: the -o attribute sets a variable read-only in bash.

For this to work the user cannot modify the .profile or .bash_history but must be able to read the first one and write in the second one. You can do this easily by changing these files and the directory where they reside to be owned by another user (root), and give write permissions to the user's group to the history file. Another option is through the use of the chattr program.

If you are completely paranoid and want to audit every user's command, you could take bash source code, edit it and have it send all that the user typed into another file. Or have ttysnoop constantly monitor any new ttys and dump the output into a file. Other useful program is Snoopy which is a user-transparent program that hooks in as a library providing a wrapper around execve() calls, any command execute is logged to syslogd using the authpriv facility (usually stored at /var/log/auth.log.

Note that you cannot use the script command for this since it will not work as a shell (even if you add it to /etc/shells.


4.9.10 Complete user audit

The previous example is a simple way to configure user auditing which might be not useful for complex systems. If this is your case, you need to look at acct, the accounting utilities. These will log all the commands run by users or processes in the system, at the expense of disk space.

When activating accounting, all the information on processes and user is kept under /var/account/, more specifically in the pacct. The accounting package includes some tools (sa and ac) to analyse this data.


4.9.11 Reviewing user profiles

If you want to see what are users usually doing, when are they connecting you can use the wtmp database that includes all login information. This file can be processed with several utilities, amongst them sac which can output a profile on each user showing in which timeframe they usually log on to the system.

In case you have accounting activated, you can also use the tools provided by it in order to determine when the users access to the system and what do they execute.


4.9.12 Setting users umasks

Depending on your user policy you might want to change how information is shared between users, that is, what are the default permissions of new files created by users. This change is set by defining a proper umask setting for all users. You can change the UMASK setting in /etc/limits.conf, /etc/profile, /etc/csh.cshrc, /etc/csh.login, /etc/zshrc and probably some others (depeding on the shells you have installed on your system). Of all of these the last one that gets loaded takes precedence. The order is: PAM's limits.conf, the default system configuration for the user's shell, the user's shell (his ~/.profile, ~/.bash_profile...)

Debian's default umask setting is 022 this means that files (and directories) can be read and accessed by the user's group and by any other users in the system. If this is too permissive for your system you will have to change the umask setting for all the shells (and for PAM). Don't forget to modify the files under /etc/skel/ since these will be a user's defaults when it gets created with the adduser command.

Note, however that users can modify their own umask setting if they want too, making it more permissive or more restricted.


4.9.13 Limiting what users can see/access

FIXME: Content needed. Tell of consequences of changing packages permissiones when upgrading (and admin this paranoid should chroot his users BTW).

If you need to grant users acces to the system with a shell think it very carefully. A user can, by default, and unless a severely restricted environment (like a chroot jail) can retrieve quite a lot of information from your system including:

What can a user see in your system? Probably quite a lot of things, try this (take a deep breath):

     find / -type f -a -perm +006 2>/dev/null  
     find / -type d -a -perm +007 2>/dev/null

The output is the list of files that a user can see and the directories he has access to.


4.10 Using tcpwrappers

TCP wrappers were developed when there were no real packet filters available and access control was needed. The TCP wrappers allow you to allow or deny a service for a host or a domain and define a default allow or deny rule. If you want more informations take a look at hosts_access(5).

Many services installed in Debian are either:

On the first hand, of services are configured in /etc/inetd.conf, this includes telnet, ftp, netbios, swat and finger (you will see that the configuration file executes first /usr/sbin/tcpd. On the other hand, even if a service is not launched by the inetd superdaemon can, in any case, subjected to the tcp wrappers rules by compiling its support in it. Services compiled with tcp wrappers in Debian include ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf (the GNOME activator daemon), nessus and many others.

To see which packages use tcpwrappers try:

     $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
             sed 's/,libwrap0$//;s/^[[:space:]]\+//'

Take this into account when running tcpchk. You can add services that are linked to the wrapper library into the host.deny and hosts.allow files but tcpchk will warn that he is not able to find those services since it looks for them in /etc/inetd.conf (the manpage is not totally accurate here).

Now, here comes a small trick, and probably the smallest intrusion detection system available. In general, you should have a decent firewall policy as a first line, and tcp wrappers as the second line of defense. One little trick is to set up a SPAWN [4] command in /etc/hosts.deny that sends mail to root whenever a denied service triggers wrappers:

     ALL: ALL: SPAWN ( \
       echo -e "\n\
       TCP Wrappers\: Connection refused\n\
       By\: $(uname -n)\n\
       Process\: %d (pid %p)\n\
       User\: %u\n\
       Host\: %c\n\
       Date\: $(date)\n\
     " | /usr/bin/mail -s "Connection to %d blocked" root) &

Beware: The above printed example can easily be DoSed by doing lots of connections in a short period of time. Many emails mean a lot of file I/O by sending only a few packets.


4.11 The importance of logs and alerts

How log and alerts are treated is an important issue in a secure system. It is easily to see that, even if the system is perfectly configured and, supposedly, 99% secure. If the 1% comes to happen, and there are no security measures in place to, first, detect this and, second, raise alarms, the system is not secure at all.

Debian GNU/Linux provides some tools to make loganalysis, most notably logcheck or loganalysis (both will need some customisation to remove unnecessary things from the report). It might be also useful, if the system is nearby, to have the system logs printed on a virtual console. This is useful since you can (from a distance) see if the system is behaving properly. Debian's /etc/syslog.conf comes with a commented default configuration, to enable it uncomment the lines and restart syslog (/etc/init.d/syslogd restart):

     daemon,mail.*;\
             news.=crit;news.=err;news.=notice;\
             *.=debug;*.=info;\
             *.=notice;*.=warn       /dev/tty8

There is a lot regarding log analysis that cannot be fully covered here, a good resource for information is Counterpane's Log Analysis Resources. In any case, even automated tools are no match for the best analysis tool: your brain.


4.11.1 Using and customising logcheck.

The logcheck package in Debian is divided into two packages logcheck (the main program) an logcheck-database (a database of regular expressions for the program). The Debian default (at /etc/cron.d/logcheck) is that logcheck is run daily at 2 am and once after each reboot.

This tool can be quite useful if properly customised to alert the administrator on unusual events in the system. Logcheck can be fully customised so that it can send mails from events recovered from the logs that are worthy of attention. The default installation includes profiles for ignored events and policy violations for three different setups (workstation, server and paranoid). The Debian package includes a configuration file /etc/logcheck/logcheck.conf, sourced by the program, that defines which user are the checks send to. It also provides a way for packages that provide services to implement new policies in the directories: /etc/logcheck/hacking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, and /etc/logcheck/ignore.d.workstation/_packagename_. However, not many packages currently do so. If you have a policy that can be useful for other users, please send it as a bug report for the appropiate package (as a wishlist bug). See For more information read /usr/share/doc/logcheck/README.Debian

The best way to configure logcheck is to install it (it will ask for the user to mail reports to and generate /etc/logcheck/logcheck.logfiles from syslog entries). If you wish to add new logfiles just change /etc/logcheck/logcheck.logfiles adding them there. The package dependancy will make the logcheck-database package get installed too, during installation it will ask which security level is desired: workstation, server or paranoid. This will make /etc/logcheck/ignore.d point to the appropiate directories (through symbolic links). To change this run dpkg-reconfigure -plow logcheck-database. Then create the /etc/ignore.d/local, this file will hold all the rules to exclude messages that should not be reported. Leave it empty for the moment (a simple cp /dev/null /etc/ignore.d/local will work).

Once this is done you might want to check the mails that are sent, for the first few days/weeks/months, if you find are sent messages you do not wish to recive you just have to add to the /etc/ignore.d/local the regular expressions (see regex(7)) that correspond to these messages. It's an ongoing tuning process, once the messages that are sent are always relevant you can consider the tuning finished. Note that if logcheck does not find anything relevant in your system it will not mail you even if it does run (so you might get only a mail once a week, if you are lucky).


4.11.2 Configuring where alerts are sent

Debian comes with a standard syslog configuration (in /etc/syslog.conf) that logs messages to the appropriate files depending on the system facility. You should be familiar with this; have a look at the syslog.conf file and the documentation if not. If you intend to maintain a secure system you should be aware of where log messages are sent so they do not go unnoticed.

For example, sending messages to the console also is an interesting setup useful for many production-level systems. But for many such systems it is important to also add a new machine that will serve as loghost (i.e. it receives logs from all other systems).

Root's mail should be considered also, many security controls (like snort) send alerts to root's mailbox. This mailbox usually points to the first user created in the system (check /etc/aliases). Take care to send root's mail to some place where it will be read (either locally or remotely).

There are other role accounts and aliases on your system. On a small system, it's probably simplest to make sure that all such aliases point to the root account, and that mail to root is forwarded to the system administrator's personal mailbox.

FIXME: it would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptraglogd, snmp and snmpd.


4.11.3 Using a loghost

A loghost is a host which collects syslog data remotely over the network. If one of your machines is cracked, the intruder is not able to cover his tracks, unless he hacks the loghost as well. So, the loghost should be especially secure. Making a machine a loghost is simple. Just start the syslogd with 'syslogd -r' and a new loghost is born. In order to do this permanently in Debian, edit /etc/init.d/sysklogd and change the line

     SYSLOGD=""

to

     SYSLOGD="-r"

Next, configure the other machines to send data to the loghost. Add an entry like the following to /etc/syslog.conf:

     facility.level            @your_loghost

See the documentation for what to use in place of facility and level (they should not be entered verbatim like this). If you want to log everything remotely, just write:

     *.*                       @your_loghost

into your syslog.conf. Logging remotely as well as locally is the best solution (the attacker might presume to have covered his tracks after deleting the local log files). See the syslog(3), syslogd(8) and syslog.conf(5) manpages for additional information.


4.11.4 Logfile permissions

It is not only important to decide how alerts are used, but also who has access to them, i.e. can read or modify the logfiles (if not using a remote loghost). Security alerts which the attacker can change or disable are not much worth in the event of an intrusion. Also, you have to take into account that logfiles might reveal an intruder quite a lot of information about your system and it's normal (or abnormal) operations if he has access to them.

Some logfile permissions are not perfect after the installation (but of course this really depends on your local security policy). First /var/log/lastlog and /var/log/faillog do not need to be readable by normal users. In the lastlog file you can see who logged recently, and in the faillog you see a summary of failed logins. The author recommends chmod'ing both to 660. Take a brief look over your log files and decide very carefully which logfiles you make readable/writeable for a user with an UID other than 0 and a group other than 'adm' or 'root'. You can easily check this in your system with:

     #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
     (see to what users do files in /var/log belong to)
     #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
     (see to what groups do files in /var/log belong to)
     # find /var/log -perm +004
     (files which are readable by any user)
     #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
     (files which belong to groups not root or adm)

To customize how logfiles are created you will probably have to customize the program that generates them. If the logfile gets rotated, however, you can customize the behavior of creation and rotation


4.12 Using chroot

chroot is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). If you do not trust a user, you can create a change root environment for him. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. Even if the user does something malicious, the scope of the damage is limited to the jail.

A good example for this case is, if you do not authenticate against /etc/passwd but use LDAP or MySQL instead. So your ftp-daemon only needs a binary and perhaps a few libraries. A chrooted environment would be an excellent security improvement; if a new exploit is known for this ftp-daemon, then attackers can only exploit the UID of the ftp-daemon-user and nothing else.

Of course, many other daemons could benefit from this sort of arrangement as well.

However, be forewarned that a chroot jail can be broken if the user running in it is the superuser. So, you need to make the service run as a non-privileged user. By limiting its environment you are limiting the world readable/executable files the service can access, thus, you limit the possibilities of a privilege escalation by use of local system security vulnerabilities. Even in this situation you cannot be completely sure that there is no way for a clever attacker to somehow break out of the jail. Using only server programs which have a reputation for being secure is a good additional safety measure. Even minuscule holes like open file handles can be used by a skilled attacker for breaking into the system. After all, chroot was not designed as a security tool but as a testing tool.

As an additional note, the Debian default BIND (the Internet name service) is not shipped chrooted per default; in fact, no daemons come chrooted.

There is also some software (not currently in Debian but which might be packaged in the future) that can help setup chroot environments. makejail for example, can create and update a chroot jail with short configuration files. It also attempts to guess and install into the jail all files required by the daemon. More information at http://www.floc.net/makejail/. Jailer is a similar tool which can be retrieved from http://www.balabit.hu/downloads/jailer/.

Also useful to create chroots (or jails) is deb.pl, a script that analyses dependencies of a set of files.


4.12.1 Kernel configuration


4.12.2 Configuring kernel network features

FIXME: Content missing

Many features of the kernel can be modified while running by echoing something into the /proc file system or by using sysctl. By entering sysctl -A you can see what you can configure and what the options are. Only in rare cases do you need to edit something here, but you can increase security that way as well.

     net/ipv4/icmp_echo_ignore_broadcasts = 1

This is a 'windows emulator' because it acts like windows on broadcast ping if this one is set to 1. Otherwise, it does nothing.

     net/ipv4/icmp_echo_ignore_all = 0

If you don't want to block ICMP on your firewall, enable this.

     net/ipv4/tcp_syncookies = 1

This option is a double-edged sword. On the one hand it protects your system against syn flooding; on the other hand it violates defined standards (RFCs). This option is quite dumb as it floods the other side like it floods you, so the other side is also busy. If you want to change this option you also can change it in /etc/network/options by setting syncookies=yes.

     /proc/sys/net/ipv4/conf/all/log_martians = 1

Packets with impossible addresses (due to wrong routes) on your network get logged.

Here is an example to set up this and other useful stuff. You should add this information to a script in /etc/network/interface-secure (the name is given as an example) and call it from /etc/network/interfaces like this:

     auto eth0
     iface eth0 inet static
             address xxx.xxx.xxx.xxx
             netmask 255.255.255.xxx
             broadcast xxx.xxx.xxx.xxx
             gateway xxx.xxx.xxx.xxx
             pre-up /etc/network/interface-secure
     # Script-name: /etc/network/interface-secure
     # Modifies some default behaviour in order to secure against 
     # some TCP/IP spoofing & attacks
     #
     # Contributed by Dariusz Puchalak  
     #
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                                # broadcast echo protection enabled
     echo 0 > /proc/sys/net/ipv4/ip_forward     # ip forwarding disabled
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians 
                                                # Log packets with impossible addresses
                              # but be careful with this on heavy loaded web servers
     echo 1 > /proc/sys/net/ipv4/ip_always_defrag 
                                                #  defragging protection always enabled
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                                # bad error message protection enabled
     
     # now ip spoofing protection
     for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
             echo 1 > $f
     done
     
     # and finally some more things:
     # Disable ICMP Redirect Acceptance
     for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
             echo 0 > $f
     done
     
     for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
           echo 0 > $f
     done
     
     # Disable Source Routed Packets
     for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
             echo 0 > $f
     done
     
     # Log Spoofed Packets, Source Routed Packets, Redirect Packets
     for f in /proc/sys/net/ipv4/conf/*/log_martians; do
             echo 1 > $f
     done

4.12.3 Configuring firewall features

In order to have firewall capabilities, either to protect the local system or others behind it, the kernel needs to be compiled with firewall capabilities. The standard Debian 2.2 kernel (also 2.2) provides the packet filter ipchains firewall, Debian 3.0 standard kernel (kernel 2.4) provides the stateful packet filter iptables (netfilter) firewall. Older Debian distributions would need the appropiate kernel patch (Debian 2.1 uses kernel 2.0.34).

In any case, it is pretty easy to use a kernel different from the one provided by Debian. You can find pre-compiled kernels as packages you can easily install in the Debian system. You can also download the kernel sources using the kernel-source-X and build custom kernel packages using make-kpkg.

Setting up firewalls in Debian is discussed more thoroughly in Adding firewall capabilities, Section 5.15.


4.13 Adding kernel patches

FIXME: More content

Debian GNU/Linux provides some of the patches for the Linux kernel that enhace its security. These include:

However, some patches have not been provided in Debian yet. If you feel that some of these should be included please ask for it at the Work Needing and Prospective Packages. Some of these are:


4.14 Protecting against buffer overflows

Buffer overflow is the name of a common attack to software which makes use of insufficient boundary checking (a common programming error) in order to execute machine code through a program's inputs. These attacks, against server software which listens to connections remotely and against local software which grant higher priviledges to users (setuid or setgid) can result in the compromise of any given system.

There are mainly four methods to protect against buffer overflows:

Debian GNU/Linux, as of the 3.0 release, only provides software to implement the first and last of these methods (kernel patches and tools to detect possible buffer overflows). The use of tools to detect buffer overflows requires, in any case, of programming experience in order to fix (and recompile) the code. Debian provides, for example: bfbtester (a buffer overflow tester that brute-forces binaries through command line and environment overflows) and njamd.

As for kernel patches (described in the section Adding kernel patches, Section 4.13), the openwall patch provides protection against buffer overflows in 2.2 linux kernels. However, for 2.4 kernels, you need to use the Grsecurity patch (in the kernel-patch-2.4-grsecurity which includes the Openwall patch and many more features (including ACLs and network randomness to make it more difficult to remote OS fingerprinting), or the Linux Security Modules (in the kernel-patch-2.4-lsm and kernel-patch-2.5-lsm packages).

In any case, be aware, that even these workarounds might not prevent buffer overflows since there are ways to circumvent these, as described in phrack's magazine issue 58.


4.15 Secure file transfers

During normal system administration one usually needs to transfer files in and out from the installed system. Copying files in a secure manner from a host to another can be achieved by using the sshd server package. Another possibility is the use of ftpd-ssl, a ftp server which uses the Secure Socket Layer to encrypt the transmissions.

Any of these methods needs, of course, special clients. Debian provides clients, for example the ssh provides scp. It works like rcp but is encrypted completely, so the bad guys cannot even find out WHAT you copy. There is also a ftp-ssl client package for the equivalent server. You can find clients for these software even for other operating systems (non-UNIX), putty and winscp provide secure copy implementations for any version of Microsoft's operating system.


4.16 Filesystem limits and control


4.16.1 Using quotas

Having a good quota policy is important, as it keeps users from filling up the hard disk(s).

You can use two different quota systems: user quota and group quota. As you probably figured out, user quota limits the amount of space a user can take up, group quota does the equivalent for groups. Keep this in mind when you're working out quota sizes.

There are a few important points to think about in setting up a quota system:

Every partition/directory which users have full write access should be quota enabled. Find out those partitions and directories and calculate a workable quota size, which combines usability and security.

So, now you want to use quotas. First of all you need to check whether you enabled quota support in your kernel. If not, you will need to recompile it. After this, control whether the package 'quota' is installed. If not you will need this one as well.

Enabling quota for the respective filesystems is as easy as modifying the defaults setting to defaults,usrquota in your /etc/fstab file. If you need group quota, substitute usrquota to grpquota. You can also use them both. Then create empty quota.user and quota.group files in the roots of the filesystems you want to use quotas on (e.g. touch /home/quota.user /home/quota.group for a /home filesystem).

Restart quota by doing /etc/init.d/quota stop;/etc/init.d/quota start. Now quota should be running, and quota sizes can be set.

Editing quotas for a specific user (say 'ref') can be done by edquota -u ref. Group quotas can be modified with edquota -g <group>. Then set the soft and hard quota and/or inode quotas as needed.

For more information about quotas, read the quota man page, and the quota mini-howto(/usr/share/doc/HOWTO/en-html/mini/Quota.html).

You might or might not like lshell, since it violates the FHS. Also take into account that pam_limits.so might provide the same functionality and lshell is currently orphaned


4.16.2 chattr/lsattr

These two commands are very useful, but they only work for the ext2 filesystem. With 'lsattr' you can list the attributes of a file and with 'chattr' you can change them. Note that attributes are not the same thing as permissions. There are many attributes, but only the most important for increasing security are mentioned here. There are two flags which can only be set by the superuser.

First there is the 'a' flag. If set on a file, this file can only be opened for appending. This attribute is useful for some of the files in /var/log/, though you should consider they get moved sometimes due to the log rotation scripts.

The second flag is the 'i' flag, short for immutable. If set on a file, it can neither be modified nor deleted or renamed and no link be created to it. If you do not want users to look into your config files you could set this flag and remove readability. Furthermore it can give you a little bit more security against intruders, because the cracker might be confused by not being able to remove a file. Nevertheless, you should never assume that the cracker is blind. After all, he got into your system.

You can, also, remove the chattr and lsattr programs from the system so that an intruder with root access cannot change (or list) this attributes. Since they are part of the e2fsprogs and it's Required priority you cannot simply remove it. However, you can safely delete these two applications (and probably some others) from the filesystem. Copy them before to a removable media (floppy disk?) along with they md5sums.

An intruder in the system would have to download his own copies of the binaries in the system (probably even compile them in it) which might give you a littler more time to detect and recover from the compromise before the whole system is overrun.

FIXME: This is a bug that could be reported, are any of the binaries provided by the program useful in production systems? If not, and since the libraries are needed by many packages a new package e2fsprogs-utils could be included with less than Required priority.

Remember: lsattr and chattr are only available on ext2 filesystems.


4.16.3 Checking filesystem integrity

Are you sure /bin/login on your hard drive is still the binary you installed there some months ago? What if it is a hacked version, which stores the entered password in a hidden file or mails it in cleartext version all over the internet?

The only method to have some kind of protection is to check your files every hour/day/month (I prefer daily) by comparing the actual and the old md5sum of this file. Two files cannot have the same md5sum (the MD5 digest is 128 bits, so the chance that two different files will have the same md5sum is roughly one in 3.4e3803), so you're on the safe site here, unless someone has also hacked the algorithm that creates md5sums on that machine. This is, well, extremely difficult and very unlikely. You really should consider this auditing of your binaries as very important, since it is an easy way to recognize changes at your binaries. Common tools used for this are sXid, AIDE (Advanced Intrusion Detection Environment), TripWire (non-free; the new version will be GPL), integrit and samhain.

Installing debsums will help to check the filesystem integrity, by comparing the md5sums of every file against the md5sums used in the Debian package archive. But beware, those files can easily be changed.

Furthermore you can replace locate with slocate. slocate is a security enhanced version of GNU locate. When using slocate, the user only sees the files he really has access to and you can exclude any files or directories on the system.

FIXME: put references to the snapshot taken after installation.

FIXME: Add a note regarding packages not providing debsums for all apps installed (not mandatory).


4.16.4 Setting up setuid check

Debian provides a cron job that runs daily in /etc/cron.daily/standard. This cron job will run the /usr/sbin/checksecurity script that will store information of this changes.

In order for this check to be made you must set CHECKSECURITY_DISABLE="FALSE" in /etc/checksecurity.conf. Note, this is the default, so unless you have changed something, this option will already be set to "FALSE".

The default behavior does not send this information to the superuser but, instead keeps daily copies of the changes in /var/log/setuid.changes. You should set the CHECKSECURITY_EMAIL (in /etc/checksecurity.conf) to 'root' to have this information mailed to him. . See checksecurity(8) for more configuration info.


4.17 Taking a snapshot of the system

Before putting the system into production system you culd take a snapshot of the whole system. This snapshot could be used in the event of a compromise (see After the compromise, Chapter 10). You should remake this upgrade whenever the system is upgraded, specially if you upgrade to a new Debian release.

For this you can use a writable removable-media that can be setup read-only, this could be a floppy disk (read protected after use) or a CD on a CD-ROM unit (you could use a rewriteable CD-ROM so you could even keep backups of md5sums in different dates).

The following script creates such a snapshot:

     #!/bin/bash
     /bin/mount /dev/fd0 /mnt/floppy
     /bin/cp /usr/bin/md5sum /mnt/floppy
     echo "Calculating md5 database"
     >/mnt/floppy/md5checksums.txt
     for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
     do
        find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
     done
     /bin/umout /dev/fd0
     echo "post installation md5 database calculated"

Note that the md5sum binary is placed on the floppy drive so it can be used later on to check the binaries of the system (just in case it gets trojaned).

The snapshot does not include the files under /var/lib/dpkg/info which includes the md5 hashes of installed packages (in files ended with .md5sums). You could copy this information along too, however you should notice:

Once the snapshot is done you should make sure to set the medium read-only. You can then store it for backup or place it in the drive and use it to drive a cron check nightly comparing the original md5sums against those on the snapshot.


4.18 Other recommendations


4.18.1 Do not use software depending on svgalib

SVGAlib is very nice for console lovers like me, but in the past it has been proven several times that it is very insecure. Exploits against zgv were released, and it was simple to become root. Try to prevent using SVGAlib programs wherever possible.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ next ]

Securing Debian Manual

2.5 (beta) 29 augusti 2002Sat, 17 Aug 2002 12:23:36 +0200
Javier Fernández-Sanguino Peña jfs@computer.org