[ previous ] [ Abstract ] [ Copyright Notice ] [ Contents ] [ next ]

Securing Debian HOWTO
Chapter 8 Frequently asked Questions

FIXME: write them, extract from mailing list

8.1 Is Debian more secure than X?

A system is as secure as its administrator is capable of making it.

8.2 Is there are hardening program for Debian?

Yes. Bastille Linux, originally oriented towards some Linux distributions (Red Hat and Mandrake) currently works for Debian. Steps are being taken to integrate the changes made to the upstream version, in any case the package in Debian is, of course, name bastille.

Some people believe, however, that a hardening tool does not eliminate the need for good administration.

8.3 How can I make service XYZ more secure?

You will find information in this document to make some services (FTP, Bind) more secure in Debian GNU/Linux. For services not covered here, however, check the program's documentation, or general Linux information. Most of the security guidelines for Unix systems apply also to Debian so securing service X in Debian is, most of the time, like securing the service for any other Linux distribution (or Unix, for that matter).

8.4 My system is vulnerable!

8.5 I have suffered a break-in what do I do?

Read this document and take the appropiate measures outlined here. If you need assistance you might use the debian-security@lists.debian.org to ask for advice on how to recover/patch your system.

8.6 Program X in Debian is vulnerable, what do I do?

Take a moment, first, to see if the vulnerability has been announced in public security mailing lists (like Bugtraq) or other forums, the Debian Security Team keeps up to date with this lists, so they might already be aware of the problem. Do not take any further actions if you see an announcement already at http://security.debian.org.

If you do not see any of this, please send mail on the affected packages as well as a description of the vulnerability as detailed as possible (proof of concept code is also ok) to security@debian.org which will get you in touch with the security team.

8.7 The version number for a package indicates that I am still running a vulnerable version!

Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release. The reason we do this is to make sure that a release changes as little as possible so things will not change or break unexpectedly as a result of a security fix. You can check if you are running a secure version of a package by looking at the package changelog, or comparing its exact (upstream version -slash- debian release) version number with the version indicated in the Debian Security Advisory.

8.8 Questions regarding users and groups

8.9 Are all system users necessary?

Yes and no. Debian comes with some predefined users (id < 99 as described in Debian Policy) for some services so that installing new services is easy (they are already run by the appropriate user). If you do not intend to install new services, you can safely remove those users who do not own any files in your system and do not run any services.

You can easily find users not owning any files by executing the following command (be sure to run it as root, since a common user might not have enough permissions to go through some sensitive directories):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

These users are provided by base-passwd. You will find in its documentation more information on how these users are handled in Debian.

The list of default users (with a corresponding group) follows:

Other groups which have no associated user:

8.9.1 What is the difference between the adm and the staff group?

'adm' are administrators and is mostly useful to allow them to read logfiles without having to su. 'staff' is useful for more helpdesk/junior sysadmins type of people and gives them the ability to do things in /usr/local and create directories in /home.

8.10 Question regarding open ports

8.10.1 Why do I have port 111 open?

Port 111 is sunrpc's portmapper, it is installed by default in all base installations of a Debian system since there is no need to know when a user's program might need RPC to work out correctly. In any case, it is used mostly for NFS. If you do not need it, remove it as explained in Disabling RPC services, Section 5.12.

8.10.2 I have checked I have the following port (XYZ) open, can I close it?

Of course you can, the ports you are leaving open should adhere to your site's policy regarding public services available to other systems. Check if they are open by inetd (see Customize /etc/inetd.conf, Section 4.7) or by other installed packages and take appropriate measures (configure inetd, remove the package, avoid it running on bootup...)

8.11 I have lost my password and cannot access the system!!

The steps you need to take in order to recover from this depends on whether or not you have applied the suggested procedure for limiting access to Lilo and BIOS.

If you have limited both. You need to disable the BIOS features (only boot from hard disk) before proceeding, if you also forgot your BIOS password, you will have to open your system and manually remove the BIOS battery.

If you have bootup of CD-ROM or diskette enable, you can:

If you are using LILO and have not restricted it. You can:

8.12 Questions regarding the Debian security team

8.12.1 The signature on Debian advisories does not verify correctly!

This is most likely a problem on your end. The debian-security-announce list has a filter that only allows messages with a correct signature from one of the security team members to be posted.

Most likely some piece of mail software on your end slightly changes the message that breaks the signature. Make sure your software does not do any MIME encoding or decoding, or tab/space conversions.

Known culprits are fetchmail (with the mimedecode option enabled) and formail (from procmail 3.14 only).

8.12.2 How is security handled for testing and unstable?

The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable.

8.12.3 Why are there no official mirrors for security.debian.org?

A: The purpose of security.debian.org is to make security updates available as quickly and easily as possible. Mirrors would add extra complexity that is not needed and can cause frustration if they are not up to date.

8.12.4 How can I reach the security team?

A: Security information can be sent to security@debian.org, which is read by all Debian developers. If you have sensitive information please use team@security.debian.org which only the members of the security team read. If desired email can be encrypted with the Debian Security Contact key (key ID 363CCD95).

8.12.5 How can I help with security?

Please review each problem before reporting it to security@debian.org. If you are able to provide patches, that would speed up the process. Do not simply forward bugtraq mails, since they are received already. Providing additional information, however, is always a good idea.

8.12.6 How are security incidents handled in Debian?

Once the Security Team receives a notification of an incident, one or more members review it and consider Debian/stable vulnerable or not. If our system is vulnerable, it is worked on a fix for the problem. The package maintainer is contacted as well, if he didn't contact the Security Team already. Finally the fix is tested and new packages are prepared, which then are compiled on all stable architectures and uploaded afterwards. After all this tasks are done a Debian Security Advisory (DSA) is sent to public mailing lists.

8.12.7 How is the Security Team composed?

The Debian Security Team currently consists of five members and two secretaries. The Security Team itself appoints people to join the team.

[ previous ] [ Abstract ] [ Copyright Notice ] [ Contents ] [ next ]
Securing Debian HOWTO
v1.93 20 November 2001Tue, 13 Nov 2001 15:54:35 +0100
Javier Fernández-Sanguino Peña jfs@computer.org