Chapter 12. Frequently asked Questions (FAQ)

There are not really many differences between Linux distributions, with exceptions to the base installation and package management system. Most distributions share many of the same applications, with differences mainly in the versions of these applications that are shipped with the distribution's stable release. For example, the kernel, Bind, Apache, OpenSSH, Xorg, gcc, zlib, etc. are all common across Linux distributions.

For example, Red Hat was unlucky and shipped when foo 1.2.3 was current, which was then later found to have a security hole. Debian, on the other hand, was lucky enough to ship foo 1.2.4, which incorporated the bug fix. That was the case in the big http://www.cert.org/advisories/CA-2000-17.html problem from a couple years ago.

There is a lot of collaboration between the respective security teams for the major Linux distributions. Known security updates are rarely, if ever, left unfixed by a distribution vendor. Knowledge of a security vulnerability is never kept from another distribution vendor, as fixes are usually coordinated upstream, or by http://www.cert.org. As a result, necessary security updates are usually released at the same time, and the relative security of the different distributions is very similar.

One of Debian's main advantages with regards to security is the ease of system updates through the use of apt. Here are some other aspects of security in Debian to consider:

The Debian distribution boasts a large and growing number of software packages, probably more than provided by many proprietary operating systems. The more packages installed, the greater the potential for security issues in any given system.

More and more people are examining source code for flaws. There are many advisories related to source code audits of the major software components included in Debian. Whenever such source code audits turn up security flaws, they are fixed and an advisory is sent to lists such as Bugtraq.

Bugs that are present in the Debian distribution usually affect other vendors and distributions as well. Check the "Debian specific: yes/no" section at the top of each advisory (DSA).

Short answer: no.

Long answer: certification costs money (specially a serious security certification), nobody has dedicated the resources in order to certify Debian GNU/Linux to any level of, for example, the http://niap.nist.gov/cc-scheme/st/. If you are interested in having a security-certified GNU/Linux distribution, try to provide the resources needed to make it possible.

There are currently at least two linux distributions certified at different http://en.wikipedia.org/wiki/Evaluation_Assurance_Level levels. Notice that some of the CC tests are being integrated into the http://ltp.sourceforge.net which is available in Debian in the ltp.

Yes. http://bastille-linux.sourceforge.net/, originally oriented toward other Linux distributions (Red Hat and Mandrake), it currently works also for Debian. Steps are being taken to integrate the changes made to the upstream version into the Debian package, named bastille.

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

One of Debian's great strengths is the wide variety of choice available between packages that provide the same functionality (DNS servers, mail servers, ftp servers, web servers, etc.). This can be confusing to the novice administrator when trying to determine which package is right for you. The best match for a given situation depends on a balance between your feature and security needs. Here are some questions to ask yourself when deciding between similar packages:

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

If you do not like users connecting to your POP3 daemon, for example, and retrieving information about your system, you might want to remove (or change) the banner the service shows to users. ^[74] Doing so depends on the software you are running for a given service. For example, in postfix, you can set your SMTP banner in /etc/postfix/main.cf:

 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Other software is not as easy to change. ssh will need to be recompiled in order to change the version that it prints. Take care not to remove the first part (SSH-2.0) of the banner, which clients use to identify which protocol(s) is supported by your package.

The Debian security team cannot possibly analyze all the packages included in Debian for potential security vulnerabilities, since there are just not enough resources to source code audit the whole project. However, Debian does benefit from the source code audits made by upstream developers.

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 introduced into a Debian branch, it would be impossible to cover all the possible situations in which the Trojan would execute. This is why Debian has a "no guarantees" license clause.

However, Debian users can take confidence in the fact that the stable code has a wide audience and most problems would be uncovered through use. Installing untested software is not recommended in a critical system (if you cannot provide the necessary code audit). In any case, if there were a security vulnerability introduced into the distribution, the process used to include packages (using digital signatures) ensures that the problem can be ultimately traced back to the developer. The Debian project has not taken this issue lightly.

Of course, you can change the default Debian permissions on your system. The current policy regarding log files and configuration files is that they are world readable unless they provide sensitive information.

Be careful if you do make changes since:

FIXME: Check if this is written in the Policy. Some packages (i.e. ftp daemons) seem to enforce different permissions.

As a matter of fact, the same questions stand for any other user. Since Debian's installation does not place any file under that directory, there's no sensitive information to protect there. If you feel these permissions are too broad for your system, consider tightening them to 750. For users, read Section 4.11.19.1, “Limiting access to other user's information”.

This Debian security mailing list http://lists.debian.org/debian-devel/2000/11/msg00783.html has more on this issue.

If you are receiving console messages, and have configured /etc/syslog.conf to redirect them to either files or a special TTY, you might be seeing messages sent directly to the console.

The default console log level for any given kernel is 7, which means that any message with lower priority will appear in the console. Usually, firewalls (the LOG rule) and some other security tools log lower that this priority, and thus, are sent directly to the console.

To reduce messages sent to the console, you can use dmesg (-n option, see dmseg(8)), which examines and controls the kernel ring buffer. To fix this after the next reboot, change /etc/init.d/klogd from:

  KLOGD=""

to:

  KLOGD="-c 4"

Use a lower number for -c if you are still seeing them. A description of the different log levels can be found in /usr/include/sys/syslog.h:

  #define LOG_EMERG       0       /* system is unusable */
  #define LOG_ALERT       1       /* action must be taken immediately */
  #define LOG_CRIT        2       /* critical conditions */
  #define LOG_ERR         3       /* error conditions */
  #define LOG_WARNING     4       /* warning conditions */
  #define LOG_NOTICE      5       /* normal but significant condition */
  #define LOG_INFO        6       /* informational */
  #define LOG_DEBUG       7       /* debug-level messages */

The default behavior in Debian is that each user has its own, private group. The traditional UN*X scheme assigned all users to the users group. Additional groups were created and used to restrict access to shared files associated with different project directories. Managing files became difficult when a single user worked on multiple projects because when someone created a file, it was associated with the primary group to which they belong (e.g. 'users').

Debian's scheme solves this problem by assigning each user to their own group; so that with a proper umask (0002) and the SETGID bit set on a given project directory, the correct group is automatically assigned to files created in that directory. This makes it easier for people who work on multiple projects, because they will not have to change groups or umasks when working on shared files.

You can, however, change this behavior by modifying /etc/adduser.conf. Change the USERGROUPS variable to 'no', so that a new group is not created when a new user is created. Also, set USERS_GID to the GID of the users group which all users will belong to.

For example, if you want to set up a POP service, you don't need to set up a user account for each user accessing it. It's best to set up directory-based authentication through an external service (like Radius, LDAP or an SQL database). Just install the appropriate PAM library (libpam-radius-auth, libpam-ldap, libpam-pgsql or libpam-mysql), read the documentation (for starters, see Section 4.11.1, “User authentication: PAM”) and configure the PAM-enabled service to use the back end you have chosen. This is done by editing the files under /etc/pam.d/ for your service and modifying 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 are required in order to use LDAP authentication. 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 attributes:

  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

By making the services attributes boolean fields, you can use them to enable or disable access to the different services just by inserting the appropriate lines in the following files:

Many vulnerability assessment scanners give false positives when used on Debian systems, since they only use version checks to determine if a given software package is vulnerable, but do not really test the security vulnerability itself. Since Debian does not change software versions when fixing a package (many times the fix made for newer releases is back ported), some tools tend to think that an updated Debian system is vulnerable when it is not.

If you think your system is up to date with security patches, you might want to use the cross references to security vulnerability databases published with the DSAs (see Section 7.2, “Debian Security Advisories”) to weed out false positives, if the tool you are using includes CVE references.

A trace of an attack does not always mean that your system has been compromised, and you should take the usual steps to determine if the system is indeed compromised (see Chapter 11, After the compromise (incident response)). Even if your system was not vulnerable to the attack that was logged, a determined attacker might have used some other vulnerability besides the ones you have detected.

You might find the following lines in your system 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 kind of compromise, and users changing between Debian releases might find it strange. If your system does not have high loads (or many active services), these lines might appear throughout your logs. This is an indication that your syslogd daemon is 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.

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 to see if these entries are due to cron jobs (usually /etc/cron.daily/find or logrotate):

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

If you see entries like these in your logs:

  May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Check if there is a high number of connections to the server using netstat, for example:

  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000

This is an indication of a denial of service (DoS) attack against your system's X port (most likely against a public service such as a web server or mail server). You should activate TCP syncookies in your kernel, see Section 4.18.2, “Configuring syncookies”. Note, however, that a DoS attack might flood your network even if you can stop it from crashing your systems (due to file descriptors being depleted, the system might become unresponsive until the TCP connections timeout). The only effective way to stop this attack is to contact your network provider.

You might see these kind of entries in your /var/log/auth.log file:

  May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
  May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
  May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
  (UID=0)
  May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

These are due to a cron job being executed (in this example, every five minutes). To determine which program is responsible for these jobs, check entries under: /etc/crontab, /etc/cron.d, /etc/crond.daily and root's crontab under /var/spool/cron/crontabs.

There are several steps you might want to take in case of a break-in:

By watching the logs (if they have not been tampered with), using intrusion detection systems (see Section 10.3, “Set up Intrusion Detection”), traceroute, whois and similar tools (including forensic analysis), you may be able to trace an attack to the source. The way you should react to this information depends solely on your security policy, and what you consider is an attack. Is a remote scan an attack? Is a vulnerability probe an attack?

First, take a moment 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 these lists, so they may also be aware of the problem. Do not take any further actions if you see an announcement at http://security.debian.org.

If no information seems to be published, please send e-mail about the affected package(s), as well as a detailed description of the vulnerability (proof of concept code is also OK), to mailto:[email protected]. This will get you in touch with Debian's security team.

Instead of upgrading to a new release, Debian backports security fixes to the version that was shipped in the stable release. The reason for this is to make sure that the stable release changes as little as possible, so that 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.