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

Securing Debian Manual
Chapter 11 - Frequently asked Questions (FAQ)

This chapter will introduce some of the most common questions that usually appear in the security mailing list. You should read them before posting there or else people might tell you just to RTFM.

11.1 Security in the Debian operating system

11.1.1 Is Debian more secure than X?

A system is as secure as its administrator is capable of making it. Debian tries to install services in a secure by default way and might not try to be as paranoid as other operating systems which install all the services disabled by default. However, the system administrator needs to adapt the security of the system to his local security policy.

11.1.2 There are many Debian bugs in bugtraq does this mean that it is very vulnerable?

Debian contains quite a number of packages and different software, probably more that provided by some propietary operating systems. This means that there might be lurking more potential security issues than in systems with less software.

However, there are many advisories related to source code audits done to major software components included in Debian. Whenever such source code audit turn out a major flaw it is fixed and a advisory is sent to list such as bugtraq.

Bugs that are present in the Debian distribution usually affect other vendors and other distributions as well. Check the "Debian specific: yes/no" part on top of each advisory (DSA). If there is a "yes", it only affects Debian, if there is a "no" it probably also affects other distributions as well.

Debian contains quite a lot of packages, and nowadays there are many groups looking for security problems in software (for whichever reasons).

11.1.3 Has Debian any certification security-wise?

Simple answer: no.

Long answer: certification costs money and nobody has dedicated resources in order to certificate the Debian GNU/Linux distribution to any level of, for example, the Common Criteria. If you are interested in having a certified GNU/Linux distribution try to provide resources in order to make it possible.

11.1.4 Is there any 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.

11.1.5 I want to run XYZ service, which one should I choose?

One of the benefits of Debian, which might confuse the novice administrator, is that it provides a lot of software to offer the same service (dns servers, mail servers, ftp servers, web servers...). If you want information on what server you should be installing there's no general answer, it really depends on your feature and security needs (which might need to be balanced).

Things you should check:

11.1.6 How can I make service XYZ more secure in Debian?

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).

11.1.7 Are all Debian packages safe?

The Debian security team cannot analise all the packages included in Debian for potential security vulnerabilities, since there are just not enough resources to source-code audit all the project. However, Debian does benefit from the source code audits made by upstream developers or other projects like the Linux Kernel Security Audit Project or the Linux Security-Audit Project.

As a matter of fact, a Debian developer could distribute a trojan in a package and there is no possible way to check it out. Even if they would be introduced in Debian it would be impossible to cover all the possible situations in which the trojan would execute.

This sticks to the no guarantees license clause. In any case, Debian users can take confidence in that the stable code has a wide audience and most problems would be uncovered through use. It is not recommended to install untested software in a valuable system in any case (if you cannot provide the necessary code audit). And, in any case, if there were an induced security vulnerability in the distibution, the process used to include them (using digital signatures) ensures that the problem can be ultimately traced to the developer, and the Debian project has not taken this issues lightly.

11.1.8 Operating system users and groups 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: 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.

11.1.9 Question regarding services and open ports Why are all services activated on installation?

That's just an approach to the problem of being, on one side, security conscious and on the other side user friendly. Unlike OpenBSD, which disables all services unless activated by the administrator, Debian GNU/Linux will activate all installed services unless deactivated (see Disabling daemon services, Section 3.6.1 for more information). After all you installed the service, didn't you?

There has been a lot of discussion on Debian mailing lists (both at debian-devel and at debian-security) regarding which should be the standard setup. However, there is not a consensus as of this writting (march 10th 2002) on how it should be tackled. Can I remove inetd?

Inetd is not easy to remove since netbase depends on the package that provides it (netkit-inetd. If you want to remove it you can either disable it (see Disabling daemon services, Section 3.6.1 or remove the package by using the equivs package. 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.14. What use is identd (113) for?

Identd is used for administrators to provide userid details to remote systems who want to know who's responsible for a given connection from your machine. Notably this includes mail, FTP and IRC servers, however, it can also be used to trace down which user in your local system is attacking a remote system.

There has been extensive discussion for this see the mailing list archives, basicly if you do not know what it is for, don't activate it. But if you firewall it, please make it a reject rule and not a deny rule, otherwise communications might hang until a timeout expires (see reject or deny issues). 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 Disabling inetd services, Section 3.6.2) or by other installed packages and take appropriate measures (configure inetd, remove the package, avoid it running on bootup...) I have removed services from /etc/services, am I ok?

No, /etc/services just provides a mapping from a virtual name to a given port number, removing names from there will not (usually) prevent services from being started. Some daemons might not run if /etc/services is modified but that's not the norm, and it's not the recommended way to do it, see Disabling daemon services, Section 3.6.1.

11.1.10 Common security issues 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:

This will remove the root password. You can startup the system and root from the login: prompt as root (with an empty password). This will work unless you have configured the system more tightly, i.e. if you have allowed users with null passwords and root can login from the console.

If you have introduced also this features you will need to enter in single mode. LILO needs not to be restricted, if you have done this too you will need to rerun lilo just after the root reset above. This is quite tricky since your /etc/lilo.conf will need to be tweaked due to having a / filesystem that is a ramdisk and not the real harddisk.

Once LILO is not restricted it. You can:

11.1.11 I want to setup a service for my users bot not give shell accounts.

If you want to give a POP service, for example, you do not need to setup a user account for each user accessing it. It's best to setup a directory-based authentication through an external service (like Radius, LDAP or an SQL database). Just install the appropiate PAM library (libpam-radius-auth, libpam-ldap, libpam-pgsql or libpam-mysql), read the documentation (for starters, see User authentication: PAM, Section 4.9.1 and configure the PAM-enabled service to use the backend you have chosen. This is done by editing the files under /etc/pam.d/ for your service and modify the

     auth    required        pam_unix_auth.so shadow nullok use_first_pass

to, for example, ldap:

     auth    required        pam_ldap.so

In the case of LDAP directories, some services provide LDAP schemas to be included in your directory that need to be included in order to use LDAP autentication for it. If you are using a relational database, a useful trick is to use the where clause when configuring the PAM modules. For example if you have a database with the following table:


You can use the last (boolean) values to enable or disable access to the different services just by inserting the appropiate lines in the following files:

11.2 My system is vulnerable! (are you sure?)

11.2.1 I've seen an attack on my system logs: am I compromised?

A trace of an attack does not always mean that you've been cracked into, you should take the usual steps to determine if the system is compromised (see After the compromise, Chapter 10). Also notice that sometimes, the fact that you see the attacks in the log might mean you system is already vulnerable to it (a determined attacker might have used some other besides the ones you have seen, however).

11.2.2 I have found strange 'MARKs' in my logs: Am I compromised?

You might find the following in your system logs. If your system does not have a lot of load (and services) they probably be one of the few appearing in your logs:

     Dec 30 07:33:36 debian -- MARK --
     Dec 30 07:53:36 debian -- MARK --
     Dec 30 08:13:36 debian -- MARK --

This does not indicate any cand of compromise, and users changing between Debian releases might find it strange. It is, a matter of fact an indication of syslogd running properly. From syslogd(8):

            -m interval
                   The syslogd logs a mark timestamp  regularly.   The
                   default interval between two -- MARK -- lines is 20
                   minutes.  This can be  changed  with  this  option.
                   Setting the interval to zero turns it off entirely.

11.2.3 I found users doing 'su' in my logs: Am I compromised?

You might find lines in your logs like:

      Apr  1 09:25:01 server su[30315]: + ??? root-nobody
      Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)

Don't worry too much, check out if this is due to a job running through the cron (usually /etc/cron.daily/find or logrotate):

     $ grep 25 /etc/crontab
     25 6    * * *   root    test -e /usr/sbin/anacron || run-parts --report
     $ grep nobody /etc/cron.daily/*
     find:cd / && updatedb --localuser=nobody 2>/dev/null

11.2.4 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.

11.2.5 How can I trace an attack?

Watching the logs (if they have not been changed), using intrusion detection systems (see Set up Intrusion Detection., Section 9.1), traceroute, whois and similar tools (including forensic analysis) you can trace an attack to the source. The way you should react on this information depends, solely, on your appropiate security policy, and what you consider an attack is. Is a remote scan an attack? Is a vulnerability probe an attack?

11.2.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.

11.2.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.

11.2.8 Specific software Proftpd is vulnerable to a Denial of Service attack

Add DenyFilter \*.*/ to your configuration file, for more information see http://www.proftpd.org/critbugs.html.

11.3 Questions regarding the Debian security team

11.3.1 What is a Debian Security Advisory (DSA)

It is the information sent by the Debian Security Team (see below) informing of a fix of a security related vulnerability available for the Debian operating system. Signed DSAs are sent to public mailing lists and posted in Debian's web site (both in the front page and in the security area).

DSAs include information on the affected package/s, the bug discovered and where to retrieve the updated packages (and their MD5 sums).

11.3.2 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).

11.3.3 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.

11.3.4 How much time will it take Debian to fix vulnerability XXXX?

Analysis of the time it takes the Debian security team to send an advisory and produce fixed packages once a vulnerability is known show that it does not take much time for vulnerabilities to be fixed in the stable distribution.

A report published in the debian-security mailinglist showed that in the year 2001, it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. However, over 50% of the vulnerabilities where fixed in a 10-days time frame, and over 15% of them where fixed the same day the advisory was released.

However, when asking this question people tend to forget that:

11.3.5 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.

However, as a matter of fact, unstable usually gets fixed really quick since security updates sometimes get they are usually available upstream faster (other versions, like those in stable need usually to be backported).

11.3.6 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.

11.3.7 I've seen DSA 100 and DSA 102, now where is DSA 101?

Several vendors (mostly of GNU/Linux, but also of BSD derivatives) coordinate security advisories for some incidents and agree to a particular timeline so that all vendors are able to properly determine if they are (or not) vulnerable and create the patchs needed.

The Debian Security Team holds, in this case, the numbers before the advisory can be released, and hence temporarily leaving out one or more advisories by number.

11.3.8 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).

11.3.9 What different is there between security@debian.org and debian-security@lists.debian.org?

When you send messages to security@debian.org these are sent to the developers mailing list (debian-private) to which all Debian developers are subscribed to, posts to this list are kept private (i.e. are not archived at the public website). Debian-security@lists.debian.org is a public mailinglist, open to anyone that wants to subscribe to it, and there are searchable archives available at the web site.

11.3.10 How can I contribute with the Debian security team?

In any case, 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.

11.3.11 Who is the Security Team composed of?

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

11.3.12 Does the Debian Security team check every new package in Debian?

No, the Debian security team does not check every new package and neither is there an automatic (lintian) check in order to detect malicious new packages, since those checks are rather impossible to detect automatically. Maintainers, however, are fully responsible for the software that is introduced in Debian and no software is introduced that is not first signed by an authorised developers. They are in charge of analysing the software they maintain and are security-aware.

11.3.13 I have an older version of Debian, is it security-supported?

Unfortunately no, the Debian Security Team cannot handle both the stable release (unofficially also the unstable) and other older releases. However, you can expect security updated for a limited period of time (usually several months) just after a new Debian distribution is released.

[ 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