<!-- CVS revision of this document "$Revision: 1.20 $"  -->

<chapt>Frequently asked Questions (FAQ)

<p>This chapter introduces some of the most common questions from the
Debian security mailing list. You should read them before posting
there or else people might tell you to RTFM.

<sect>Security in the Debian operating system

<sect1>Is Debian more secure than X?

<p>A system is only as secure as its administrator is capable of
making it. Debian's default installation of services aims to be
<em>secure</em>, but may not be as paranoid as some other operating
systems which install all services <em>disabled by default</em>. In
any case, the system administrator needs to adapt the security of the
system to his local security policy.

<p>For a collection of data regarding security vulnerabilities for
many operating systems, see the
<url id="http://www.cert.org/stats/cert_stats.html" name="US-CERT stats"> or
generate stats using the
<url id="http://nvd.nist.gov/statistics.cfm" name="National Vulnerability Database">
(formerly ICAT)
Is this data useful?
There are several factors to consider when interpreting the data,
and it is worth noticing that the data cannot be used to compare the vulnerabilities
of one operating system versus another.<footnote>For example, based on
some data, it might seem that Windows NT is more secure
than Linux, which is a questionable assertion. After all, Linux
distributions usually provide many more applications compared to
Microsoft's Windows NT. This <em>counting vulnerabilities</em>
issues are better described in 
<url id="http://www.dwheeler.com/oss_fs_why.html#security" 
name="Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!">
by David A. Wheeler</footnote> Also, keep in mind that some
reported vulnerabilities regarding Debian apply only to the
<em>unstable</em> (i.e. unreleased) branch.

<sect2>Is Debian more secure than other Linux distributions (such as
Red Hat, SuSE...)?

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

<p>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 <url
id="http://www.cert.org/advisories/CA-2000-17.html" name="rpc.statd">
problem from a couple years ago.

<p>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 <url
id="http://www.cert.org" name="CERT">. As a result, necessary security
updates are usually released at the same time, and the relative
security of the different distributions is very similar.

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

<list>

<item>Debian provides more security tools than other distributions,
see <ref id="sec-tools">.

<item>Debian's standard installation is smaller (less functionality),
and thus more secure. Other distributions, in the name of usability,
tend to install many services by default, and sometimes they are not
properly configured (remember the <url
id="http://www.sophos.com/virusinfo/analyses/linuxlion.html" name="Lion"> <url
id="http://www.sophos.com/virusinfo/analyses/linuxramen.html" name="Ramen">).
Debian's installation is not as limited as OpenBSD (no
daemons are active per default), but it's a good compromise.

<footnote>Without diminishing the fact that some distributions, such
as Red Hat or Mandrake, are also taking into account security in their
standard installations by having the user select <em>security
profiles</em>, or using wizards to help with configuration of
<em>personal firewalls</em>.</footnote>

<item>Debian documents best security practices in documents like this
one.

</list>

<sect1>There are many Debian bugs in Bugtraq. Does this mean that it
is very vulnerable?

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

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

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

<sect1>Does Debian have any certification related to security?

<p>Short answer: no. 

<p>Long answer: certification costs money (specially a <em>serious</em>
security certification), nobody has dedicated the
resources in order to certify Debian GNU/Linux to any level of, for
example, the
<!-- NOTE: commoncriteria.org is no longer available, jfs -->
<url id="http://niap.nist.gov/cc-scheme/st/" name="Common Criteria">.
If you are interested in having a
security-certified GNU/Linux distribution, try to provide the resources 
needed to make it possible. 

<p>There are currently at least two linux distributions certified at
different 
<url id="http://en.wikipedia.org/wiki/Evaluation_Assurance_Level" name="EAL">
levels. Notice that some of the CC tests are being integrated into the
<url id="http://ltp.sourceforge.net" name="Linux Testing Project"> which
is available in Debian in the <package>ltp</package>.

<sect1>Are there any hardening programs for Debian?

<p>Yes. <url name="Bastille Linux"
id="http://www.bastille-unix.org">, originally oriented toward other
Linux distributions (Red Hat and Mandrake), currently works for
Debian. Steps are being taken to integrate the changes made to the
upstream version into the Debian package, named
<package>bastille</package>.

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

<sect1>I want to run XYZ service, which one should I choose?

<p>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:

<list>

<item>Is the software maintained upstream? When was the last release?

<item>Is the package mature? The version number really does
<em>not</em> tell you about its maturity. Try to trace the software's
history.

<item>Is the software bug-ridden? Have there been security advisories
related to it?

<item>Does the software provide all the functionality you need? Does
it provide more than you really need?

</list>

<sect1>How can I make service XYZ more secure in Debian?
<!-- Changed to XYZ in order to avoid confusion :) jfs -->

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

<sect1>How can I remove all the banners for services?

<p>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.
<footnote>Note that this is 'security by obscurity', and will probably
not be worth the effort in the long term.</footnote> Doing so depends
on the software you are running for a given service. For example, in
<prgn>postfix</prgn>, you can set your SMTP banner in
<file>/etc/postfix/main.cf</file>: 
<example> 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 
</example>

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

<sect1>Are all Debian packages safe?

<p>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.
<!-- FIXME kernel-audit doesn't exist on sourceforge:
or by other projects like the <url name="Linux
Kernel Security Audit Project"
id="http://sourceforge.net/projects/kernel-audit/">, or the <url name="Linux
Security-Audit Project" id="http://www.lsap.org/">.
-->

<p>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 <em>"no guarantees"</em> license clause.

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

<sect1>Why are some log files/configuration files world-readable, isn't
this insecure?

<p>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 <em>unless</em> they provide sensitive
information.

<p>Be careful if you do make changes since:

<list>

<item>Processes might not be able to write to log files if you
restrict their permissions.

<item>Some applications may not work if the configuration file they
depend on cannot be read. For example, if you remove the
world-readable permission from <file>/etc/samba/smb.conf</file>, the
<prgn>smbclient</prgn> program will not work when run by a normal
user.

</list>

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

<sect1>Why does /root/ (or UserX) have 755 permissions?

<p>As a matter of fact, the same questions stand for any other
user. Since Debian's installation does not place <em>any</em> 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 <ref
id="limit-user-perm">.

<p>This Debian security mailing list <url
id="http://lists.debian.org/debian-devel/2000/debian-devel-200011/msg00783.html"
name= "thread"> has more on this issue.

<sect1>After installing a grsec/firewall, I started receiving many
console messages! How do I remove them?

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

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

<p>To reduce messages sent to the console, you can use
<prgn>dmesg</prgn> (<tt>-n</tt> option, see <manref section="8"
name="dmesg">), which examines and <em>controls</em> the kernel ring
buffer. To fix this after the next reboot, change
<file>/etc/init.d/klogd</file> from:

<example>
  KLOGD=""
</example>

<p>to:

<example>
  KLOGD="-c 4"
</example>

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

<example>
  #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 */
</example>

<sect1 id="faq-os-users">Operating system users and groups

<sect2>Are all system users necessary?

<p>Yes and no. Debian comes with some predefined users (user id (UID)
&lt; 99 as described in <url name="Debian Policy"
id="http://www.debian.org/doc/debian-policy/"> or
<file>/usr/share/doc/base-passwd/README</file>) to ease the
installation of some services that require that they run under an
appropriate user/UID. 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. In any case, the default behavior
is that UID's from 0 to 99 are reserved in Debian, and UID's from 100
to 999 are created by packages on install (and deleted when the
package is purged).

<p>To easily find users who don't own any files, execute the following
command<footnote>Be careful, as this will traverse your whole system.  If you
have a lot of disk and partitions you might want to reduce it in
scope.</footnote> (run it as root, since a common user might not have enough
permissions to go through some sensitive directories):

<!-- Took the liberty to make this script more secure ... >:^) // era -->
<example>
  cut -f 1 -d : /etc/passwd | \
  while read i; do find / -user "$i" | grep -q . || echo "$i"; done
</example>

<p>These users are provided by <package>base-passwd</package>. Look in
its documentation for more information on how these users are handled
in Debian. The list of default users (with a corresponding group)
follows:

<list>

<item>root: Root is (typically) the superuser.

<item>daemon: Some unprivileged daemons that need to write to files on
disk run as daemon.daemon (e.g., <prgn>portmap</prgn>,
<prgn>atd</prgn>, probably others). Daemons that don't need to own any
files can run as nobody.nogroup instead, and more complex or security
conscious daemons run as dedicated users. The daemon user is also
handy for locally installed daemons.

<item>bin: maintained for historic reasons.

<item>sys: same as with bin. However, /dev/vcs* and
<file>/var/spool/cups</file> are owned by group sys.

<item>sync: The shell of user sync is <file>/bin/sync</file>. Thus, if
its password is set to something easy to guess (such as ""), anyone
can sync the system at the console even if they have don't have an
account.

<item>games: Many games are SETGID to games so they can write their
high score files. This is explained in policy.

<item>man: The man program (sometimes) runs as user man, so it can
write cat pages to <file>/var/cache/man</file>

<item>lp: Used by printer daemons.

<item>mail: Mailboxes in <file>/var/mail</file> are owned by group
mail, as explained in policy. The user and group are used for other
purposes by various MTA's as well.

<item>news: Various news servers and other associated programs (such
as <prgn>suck</prgn>) use user and group news in various ways. Files
in the news spool are often owned by user and group news. Programs
such as <prgn>inews</prgn> that can be used to post news are typically
SETGID news.

<item>uucp: The uucp user and group is used by the UUCP subsystem. It
owns spool and configuration files. Users in the uucp group may run
uucico.

<item>proxy: Like daemon, this user and group is used by some daemons
(specifically, proxy daemons) that don't have dedicated user id's and
that need to own files. For example, group proxy is used by
<prgn>pdnsd</prgn>, and <prgn>squid</prgn> runs as user proxy.

<item>majordom: <prgn>Majordomo</prgn> has a statically allocated UID
on Debian systems for historical reasons. It is not installed on new
systems.

<item>postgres: <prgn>Postgresql</prgn> databases are owned by this
user and group. All files in <file>/var/lib/postgresql</file> are
owned by this user to enforce proper security.

<item>www-data: Some web servers run as www-data. Web content should
<em>not</em> be owned by this user, or a compromised web server would be able
to rewrite a web site. Data written out by web servers, including log
files, will be owned by www-data.

<item>backup: So backup/restore responsibilities can be locally
delegated to someone without full root permissions.

<item>operator: Operator is historically (and practically) the only
'user' account that can login remotely, and doesn't depend on NIS/NFS.

<item>list: Mailing list archives and data are owned by this user and
group. Some mailing list programs may run as this user as well.

<item>irc: Used by irc daemons. A statically allocated user is needed
only because of a bug in <prgn>ircd</prgn>, which SETUID()s itself to
a given UID on startup.

<item>gnats.

<item>nobody, nogroup: Daemons that need not own any files run as user
nobody and group nogroup. Thus, no files on a system should be owned
by this user or group.

</list>

<p>Other groups which have no associated user:

<list>

<item>adm: Group adm is used for system monitoring tasks. Members of
this group can read many log files in <file>/var/log</file>, and can
use xconsole. Historically, <file>/var/log</file> was
<file>/usr/adm</file> (and later <file>/var/adm</file>), thus the name
of the group.

<item>tty: TTY devices are owned by this group. This is used by write
and wall to enable them to write to other people's TTYs.

<item>disk: Raw access to disks. Mostly equivalent to root access.

<item>kmem: /dev/kmem and similar files are readable by this
group. This is mostly a BSD relic, but any programs that need direct
read access to the system's memory can thus be made SETGID kmem.

<item>dialout: Full and direct access to serial ports. Members of this
group can reconfigure the modem, dial anywhere, etc.

<item>dip: The group's name stands for "Dial-up IP", and membership in
dip allows you to use tools like <prgn>ppp</prgn>, <prgn>dip</prgn>,
<prgn>wvdial</prgn>, etc. to dial up a connection. The users in this
group cannot configure the modem, but may run the programs that make
use of it.

<item>fax: Allows members to use fax software to send / receive faxes.

<item>voice: Voicemail, useful for systems that use modems as
answering machines.

<item>cdrom: This group can be used locally to give a set of users
access to a CDROM drive.

<item>floppy: This group can be used locally to give a set of users
access to a floppy drive.

<item>tape: This group can be used locally to give a set of users
access to a tape drive.

<item>sudo: Members of this group don't need to type their password
when using <prgn>sudo</prgn>. See
<file>/usr/share/doc/sudo/OPTIONS</file>.

<item>audio: This group can be used locally to give a set of users
access to an audio device.

<item>src: This group owns source code, including files in
<file>/usr/src</file>. It can be used locally to give a user the
ability to manage system source code.

<item>shadow: <file>/etc/shadow</file> is readable by this group. Some
programs that need to be able to access the file are SETGID shadow.

<item>utmp: This group can write to <file>/var/run/utmp</file> and
similar files. Programs that need to be able to write to it are SETGID
utmp.

<item>video: This group can be used locally to give a set of users
access to a video device.

<item>staff: Allows users to add local modifications to the system
(<file>/usr/local</file>, <file>/home</file>) without needing root
privileges. Compare with group "adm", which is more related to
monitoring/security.

<item>users: While Debian systems use the private user group system by
default (each user has their own group), some prefer to use a more
traditional group system, in which each user is a member of this
group.

</list>

<sect2>I removed a system user! How can I recover?

<p>If you have removed a system user and have not made a backup of
your <file>password</file> and <file>group</file> files you can try
recovering from this issue
using <prgn>update-passwd</prgn> (see 
<manref name="update-passwd" section="8">).

<sect2>What is the difference between the adm and the staff group?

<p>The 'adm' group are usually administrators, and this group
permission allows them to read log files without having to
<prgn>su</prgn>. The 'staff' group are usually help-desk/junior
sysadmins, allowing them to work in <file>/usr/local</file> and create
directories in <file>/home</file>.

<sect1>Why is there a new group when I add a new user? (or Why does
Debian give each user one group?)

<p>The default behavior in Debian is that each user has its own,
private group. The traditional UN*X scheme assigned all users to the
<em>users</em> 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').

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

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

<sect1>Questions regarding services and open ports

<sect2>Why are all services activated upon installation?

<p>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 <ref id="disableserv"> for more
information). After all you installed the service, didn't you?

<p>There has been much discussion on Debian mailing lists (both at
debian-devel and at debian-security) regarding which is the better
approach for a standard installation. However, as of this writing
(March 2002), there still isn't a consensus.

<sect2>Can I remove <prgn>inetd</prgn>?

<p><prgn>Inetd</prgn> is not easy to remove since
<package>netbase</package> depends on the package that provides it
(<package>netkit-inetd</package>). If you want to remove it, you can
either disable it (see <ref id="disableserv">) or remove the package by
using the <package>equivs</package> package.

<sect2>Why do I have port 111 open?

<p>Port 111 is sunrpc's portmapper, and it is installed by default as
part of Debian's base installation since there is no need to know when
a user's program might need RPC to work correctly. In any case, it is
used mostly for NFS. If you do not need it, remove it as explained in
<ref id="rpc">.

<p>In versions of the <package>portmap</package> package later than 5-5 you can
actually have
the portmapper installed but listening only on localhost (by modifying
<file>/etc/default/portmap</file>)

<sect2>What use is <prgn>identd</prgn> (port 113) for?

<p>Identd service is an authentication service that identifies the
owner of a specific TCP/IP connection to the remote server accepting
the connection. Typically, when a user connects to a remote host,
<prgn>inetd</prgn> on the remote host sends back a query to port 113
to find the owner information. It is often used by mail, FTP and IRC
servers, and can also be used to track down which user in your local
system is attacking a remote system.

<p>There has been extensive discussion on the security of
<prgn>identd</prgn> (See <url
id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html"
name="mailing list archives">). In general, <prgn>identd</prgn> is
more helpful on a multi-user system than on a single user
workstation. If you don't have a use for it, disable it, so that you
are not leaving a service open to the outside world. If you decide to
firewall the identd port, <em>please</em> use a reject policy and not
a deny policy, otherwise a connection to a server utilizing
<prgn>identd</prgn> will hang until a timeout expires (see <url
id="http://logi.cc/linux/reject_or_deny.php3" name="reject or deny
issues">).

<sect2>I have services using port 1 and 6, what are they and how can I
remove them?

<p>If you have run the command <tt>netstat -an</tt> and receive:

<example>
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
  PID/Program name
  raw        0      0 0.0.0.0:1               0.0.0.0:*               7
  -
  raw        0      0 0.0.0.0:6               0.0.0.0:*               7
  -
</example>

<p>You are <em>not</em> seeing processes listening on TCP/UDP port 1
and 6. In fact, you are seeing a process listening on a <em>raw</em>
socket for protocols 1 (ICMP) and 6 (TCP). Such behavior is common to
both Trojans and some intrusion detection systems such as
<package>iplogger</package> and
<package>portsentry</package>. If you have these packages simply
remove them. If you do not, try netstat's <tt>-p</tt> (process)
option to see which process is running these listeners.

<sect2>I found the port XYZ open, can I close it?

<p>Yes, of course. The ports you are leaving open should adhere to
your individual site's policy regarding public services available to
other networks. Check if they are being opened by <prgn>inetd</prgn>
(see <ref id="inetd">), or by other installed packages and take the
appropriate measures (i.e, configure inetd, remove the package, avoid
it running on boot-up).

<sect2>Will removing services from <file>/etc/services</file> help
secure my box?

<p><em>No</em>, <file>/etc/services</file> only provides a mapping
between a virtual name and a given port number. Removing names from
this file will not (usually) prevent services from being started. Some
daemons may not run if <file>/etc/services</file> is modified, but
that's not the norm. To properly disable the service, see <ref
id="disableserv">.

<sect1>Common security issues

<sect2>I have lost my password and cannot access the system!

<p>The steps you need to take in order to recover from this depend on
whether or not you have applied the suggested procedure for limiting
access to <prgn>lilo</prgn> and your system's BIOS.

<p>If you have limited both, you need to disable the BIOS setting that
only allows booting from the hard disk before proceeding. If you have
also forgotten your BIOS password, you will have to reset your BIOS by
opening the system and manually removing the BIOS battery.

<p>Once you have enabled booting from a CD-ROM or diskette enable, try
the following:

<list>

<item>Boot-up from a rescue disk and start the kernel

<item>Go to the virtual console (Alt+F2)

<item>Mount the hard disk where your /root is

<item>Edit (Debian 2.2 rescue disk comes with the editor
<prgn>ae</prgn>, and Debian 3.0 comes with <prgn>nano-tiny</prgn>
which is similar to <prgn>vi</prgn>) <file>/etc/shadow</file> and
change the line:

<example>
  root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
</example>

<p>to:

<example>
  root::XXXX:X:XXXX:X:::
</example>

</list>

<p>This will remove the forgotten root password, contained in the
first colon separated field after the user name. Save the file, reboot
the system and login with root using an empty password. Remember to
reset the password. This will work unless you have configured the
system more tightly, i.e. if you have not allowed users to have null
passwords or not allowed root to login from the console.

<p>If you have introduced these features, you will need to enter into
single user mode. If LILO has been restricted, you will need to rerun
<prgn>lilo</prgn> just after the root reset above. This is quite
tricky since your <file>/etc/lilo.conf</file> will need to be tweaked
due to the root (/) file system being a ramdisk and not the real
hard disk.

<p>Once LILO is unrestricted, try the following:

<list>

<item>Press the Alt, shift or Control key just before the system BIOS
finishes, and you should get the LILO prompt.

<item>Type <tt>linux single</tt>, <tt>linux init=/bin/sh</tt> or 
<tt>linux 1</tt> at the prompt.

<item>This will give you a shell prompt in single-user mode (it will
ask for a password, but you already know it)

<item>Re-mount read/write the root (/) partition, using the mount
command. 
<example>
  # mount -o remount,rw / 
</example>

<item>Change the superuser password with <prgn>passwd</prgn> (since
you are superuser it will not ask for the previous password).

</list>

<sect1>How do I accomplish setting up a service for my users without
giving out shell accounts?

<p>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 (<package>libpam-radius-auth</package>,
<package>libpam-ldap</package>, <package>libpam-pgsql</package> or
<package>libpam-mysql</package>), read the documentation (for
starters, see <ref id="auth-pam">) and configure the PAM-enabled
service to use the back end you have chosen. This is done by editing
the files under <file>/etc/pam.d/</file> for your service and
modifying the 
<example> 
  auth   required    pam_unix_auth.so shadow nullok use_first_pass 
</example> 
to, for example, ldap: 
<example>
  auth   required    pam_ldap.so 
</example>

<!-- FIXME: check if this i right (jfs) -->

<p>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 <em>where</em> clause when configuring the PAM
modules. For example, if you have a database with the following table
attributes:

<example>
  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
</example>

<p>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:

<list>

<item><file>/etc/pam.d/imap</file>:<tt>where=imap=1</tt>.

<item><file>/etc/pam.d/qpopper</file>:<tt>where=pop=1</tt>.

<item><file>/etc/nss-mysql*.conf</file>:<tt>users.where_clause =
user.sys = 1;</tt>.

<item><file>/etc/proftpd.conf</file>:<tt> SQLWhereClause "ftp=1"</tt>.

</list>

<sect id="vulnerable-system">My system is vulnerable! (Are you sure?)

<sect1 id="vulnasses-false-positive">Vulnerability assessment scanner X
says my Debian system is vulnerable!

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

<p>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 <ref id="dsa">) to weed out
false positives, if the tool you are using includes CVE references.

<sect1>I've seen an attack in my system's logs. Is my system
compromised?

<p>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 <ref id="after-compromise">). 
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.

<sect1>I have found strange 'MARK' lines in my logs: Am I compromised?

<p>You might find the following lines in your system logs:

<example>
  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --
</example>

<p>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
<prgn>syslogd</prgn> daemon is running properly. From <manref
section="8" name="syslogd">:

<example>
       -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.
</example>

<sect1>I found users using 'su' in my logs: Am I compromised?

<p>You might find lines in your logs like:
<example>
  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)
</example>

<p>Don't worry too much. Check to see if these entries are due to
<prgn>cron</prgn> jobs (usually <file>/etc/cron.daily/find</file> or
<prgn>logrotate</prgn>):

<example>
  $ 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
</example>

<sect1>I have found 'possible SYN flooding' in my logs: Am I under
attack?

<p>If you see entries like these in your logs:

<example>
  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.
</example>

<p>Check if there is a high number of connections to the server using
<prgn>netstat</prgn>, for example:

<example>
  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000
</example>

<p>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 <ref id="tcp-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.

<sect1>I have found strange root sessions in my logs: Am I
compromised?

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

<example>
  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
</example>

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

<sect1>I have suffered a break-in, what do I do?

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

<list>

<item>Check if your system is up to date with security patches for
published vulnerabilities. If your system is vulnerable, the chances
that the system is in fact compromised are increased. The chances
increase further if the vulnerability has been known for a while,
since there is usually more activity related to older
vulnerabilities. Here is a link to <url
id="http://www.sans.org/top20/" name="SANS Top 20 Security
Vulnerabilities">.

<item>Read this document, especially the <ref id="after-compromise">
section.

<item>Ask for assistance. You might use the debian-security mailing
list and ask for advice on how to recover/patch your system.

<item>Notify your local <url id="http://www.cert.org" name="CERT"> (if
it exists, otherwise you may want to consider contacting CERT
directly). This might or might not help you, but, at the very least,
it will inform CERT of ongoing attacks. This information is very
valuable in determining which tools and attacks are being used by the
<em>blackhat</em> community.

</list>

<sect1>How can I trace an attack?

<p>By watching the logs (if they have not been tampered with), using
intrusion detection systems (see <ref id="intrusion-detect">),
<prgn>traceroute</prgn>, <prgn>whois</prgn> 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 <em>you</em> consider is an
attack. Is a remote scan an attack? Is a vulnerability probe an
attack?

<sect1>Program X in Debian is vulnerable, what do I do?

<p>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 <url id="http://security.debian.org">.

<p>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
<url id="mailto:team@security.debian.org" name="team@security.debian.org">.
This will get you in touch with Debian's security team.

<sect1 id="version-backport">The version number for a package indicates that I am still
running a vulnerable version!

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

<sect1>Specific software

<sect2><package>proftpd</package> is vulnerable to a Denial of Service
attack.

<p>Add <tt>DenyFilter \*.*/</tt> to your configuration file, and for
more information see <url id="http://www.proftpd.org/bugs.html">.

<sect2>After installing <package>portsentry</package>, there are a lot
of ports open.

<p>That's just the way <prgn>portsentry</prgn> works. It opens about
twenty unused ports to try to detect port scans.

<sect id="debian-sec-team-faq">Questions regarding the Debian security team

<p>This information is derived from the 
<url id="http://www.debian.org/security/faq" 
name="Debian Security FAQ">. It includes the information as of 
January, 2006, and provides answers for some other common questions asked in
the debian-security mailing list.


<!-- FIXME: should this be included in the FAQ? -->
<sect1>What is a Debian Security Advisory (DSA)?

<p>It is information sent by the Debian Security Team (see below)
regarding the discovery and fix for a security related vulnerability
in a package available in Debian GNU/Linux. Signed DSAs are sent to
public mailing lists (debian-security-announce) and posted on Debian's
web site (both in the front page and in the <url
id="http://www.debian.org/security/" name="security area">).

<p>DSAs include information on the affected package(s), the security
flaw that was discovered and where to retrieve the updated packages
(and their MD5 sums).

<!-- FIXME: update from web page automatically -->

<sect1>The signature on Debian advisories does not verify correctly!

<p>This is most likely a problem on your end. The
<url id="http://www.debian.org/security/faq" 
name="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.

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

<p>Known culprits fetchmail (with the mimedecode option enabled), 
formail (from procmail 3.14 only) and evolution.

<sect1>How is security handled in Debian?

<p>Once the Security Team receives a notification of an incident, one
or more members review it and consider its impact on the stable release
of Debian (i.e. if it's vulnerable or not). If our system is vulnerable, 
we work 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 of that is done, an advisory is published.

<sect1>Why are you fiddling with an old version of that package?

<p>The most important guideline when making a new package that fixes a 
security problem is to make as few changes as possible. Our users 
and developers are relying on the exact behavior of a release once 
it is made, so any change we make can possibly break someone's system. 
This is especially true in case of libraries: make sure you never change 
the Application Program Interface (API) or Application Binary Interface 
(ABI), no matter how small the change is.

<p>This means that moving to a new upstream version is not a good solution, 
instead the relevant changes should be backported. Generally upstream 
maintainers are willing to help if needed, if not the Debian security team 
might be able to help.

<p>In some cases it is not possible to backport a security fix, for example 
when large amounts of source code need to be modified or rewritten. If 
that happens it might be necessary to move to a new upstream version, but 
this has to be coordinated with the security team beforehand.

<sect1>What is the policy for a fixed package to appear in security.debian.org?

<p>Security breakage in the stable distribution warrants a package on 
security.debian.org. Anything else does not. The size of a breakage is 
not the real problem here. Usually the security team will prepare packages 
together with the package maintainer. Provided someone (trusted) tracks the 
problem and gets all the needed packages compiled and submit them to the 
security team, even very trivial security problem fixes will make it to 
security.debian.org. Please see below.

<p>Security updates serve one purpose: to supply a fix for a security
vulnerability. They are not a method for sneaking additional changes into the
stable release without going through normal point release procedure.

<sect1>What does "local (remote)" mean?

<p>Some advisories cover vulnerabilities that cannot be identified with the
classic scheme of local and remote exploitability. Some vulnerabilities cannot
be exploited from remote, i.e. don't correspond to a daemon listening to a
network port. If they can be exploited by special files that could be provided
via the network while the vulnerable service is not permanently connected with
the network, we write "local (remote)" in such cases.

<p>Such vulnerabilities are somewhat between local and remote vulnerabilities
and often cover archives that could be provided through the network, e.g. as
mail attachment or from a download page.

<sect1>The version number for a package indicates that I am still running a vulnerable version!

<p>See <ref id="version-backport">.

<sect1 id="sec-unstable">How is security handled for <tt>testing</tt> and <tt>unstable</tt>?

<p>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, work is in progress to change this, with the formation of a
<url id="http://secure-testing-master.debian.net/" name="testing security
team"> which has begun work to offer security support for testing, and to some
extent, for unstable. For more information see <ref id="security-support-testing">

<!-- Note: the following paragraph is not in the FAQ (jfs) -->
<p>In some cases, however, the unstable branch usually gets security fixes
quite quickly, because those fixes are usually available upstream
faster (other versions, like those in the stable branch, usually need
to be back ported).

<p>You can review public vulnerabilities affecting the <tt>testing</tt> and
<tt>unstable</tt> release at the <url
id="http://security-tracker.debian.net/tracker/" name="Security Bug Tracker">.


<!-- The following section is not on the FAQ -->
<sect1 id="sec-older">I use an older version of Debian, is it supported by the Debian Security Team?

<p>No. Unfortunately, the Debian Security Team cannot handle both the
stable release (unofficially, also the unstable) and other older
releases. However, you can expect security updates for a limited
period of time (usually several months) immediately following the
release of a new Debian distribution.

<sect1>How does <em>testing</em> get security updates?

<p>Security updates will migrate into the testing distribution via unstable.
They are usually uploaded with their priority set to high, which will reduce
the quarantine time to two days. After this period, the packages will migrate
into testing automatically, given that they are built for all architectures and
their dependencies are fulfilled in testing.

<p>The <url id="http://secure-testing-master.debian.net/" name="testing
security team"> also makes security fixes available in their repository when
the normal migration process is not fast enough.

<sect1>How is security handled for contrib and non-free?

<p>The short answer is: it's not. Contrib and non-free aren't official parts of
the Debian Distribution and are not released, and thus not supported by the
security team. Some non-free packages are distributed without source or without
a license allowing the distribution of modified versions. In those cases no
security fixes can be made at all. If it is possible to fix the problem, and
the package maintainer or someone else provides correct updated packages, then
the security team will generally process them and release an advisory.

<sect1>Why are there no official mirrors for security.debian.org?

<p>Actually, there are. There are several official mirrors, implemented through
DNS aliases. The purpose of security.debian.org is to make security updates
available as quickly and easily as possible.

<p>Encouraging the use of unofficial mirrors would add extra complexity that is
usually not needed and that can cause frustration if these mirrors are not kept
up to date. 

<sect1>I've seen DSA 100 and DSA 102, now where is DSA 101?

<p>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 release an
advisory at the same time. This was decided in order to not
discriminate against some vendors that need more time (e.g. when the 
vendor has to pass packages through lengthy QA tests or has to support 
several architectures or binary distributions). Our own security team 
also prepares advisories in advance. Every now and then, other security 
issues have to be dealt with before the parked advisory could be released,
and hence temporarily leaving out one or more advisories by number.

<!--
<p>In some cases, the Debian Security Team prepares advisories in
advance, and holds the advisory number until the advisory can be
released. Hence, the gaps in DSA numbers.
-->

<sect1>I tried to download a package listed in one of the security advisories, but I got a `file not found' error.

<p>Whenever a newer bugfix supersedes an older package on security.debian.org,
chances are high that the old package will be removed by the time the new one
gets installed. Hence, you'll get this `file not found' error. We don't want to
distribute packages with known security bugs longer than absolutely necessary.

<p>Please use the packages from the latest security advisories, which are
distributed through the <url
id="http://lists.debian.org/debian-security-announce"
name="debian-security-announce mailing list">. It's best to simply run
<em>apt-get update</em> before upgrading the package.

<sect1>How can I reach the security team?

<p>Security information can be sent to
<url id="mailto:security@debian.org" name="security@debian.org">,
which is read by all Debian developers. If you have sensitive information
please use <url id="mailto:team@security.debian.org"
name="team@security.debian.org"> which only the members of the
team can read. If desired, email can be encrypted with the Debian
Security Contact key (key ID 
<url id="http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=0x363CCD95&amp;op=vindex"
name="0x363CCD95">). See also the
<url id="http://www.debian.org/security/keys.txt" name="PGP/GPG keys for the security team">.

<!-- This old link doesn't work any more 
<url id="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&amp;exact=on&amp;search=0x363CCD95" name="0x363CCD95"> -->


<!-- The following item is not included in the Debian Security Team FAQ -->
<sect1>What difference is there between security@debian.org and
debian-security@lists.debian.org?

<p>When you send messages to security@debian.org, they are sent to the
developers' mailing list (debian-private). All Debian developers are
subscribed to this list and posts are kept private
<footnote>There has been a declassification decision, voted in <url
id="http://www.debian.org/vote/2005/vote_002" name="GR-2005-002">, that might
make some posts available in the future, however.</footnote>
(i.e. are not archived at the public website). The public mailing list,
debian-security@lists.debian.org, is open to anyone that wants to <url
id="http://www.debian.org/MailingLists/" name="subscribe">, and there
are searchable archives available
<url id="http://lists.debian.org/search.html" name="here">.

<!-- The following items are not included in the Debian Security Team FAQ -->
<sect1>I guess I found a security problem, what should I do?

<p>If you learn about a security problem, either in one of your own packages or
in someone else's please always contact the security team. If the Debian
security team confirms the vulnerability and other vendors are likely to be
vulnerable as well, they usually contact other vendors as well. If the
vulnerability is not yet public they will try to coordinate security advisories
with the other vendors, so all major distributions are in sync.

<p>If the vulnerability is already publicly known, be sure to file a bug report
in the Debian BTS, and tag it <em>security</em>.

<sect1>How can I contribute to the Debian security team?
<p>
<list>

<item>By contributing to this document, fixing FIXMEs or providing new
content. Documentation is important and reduces the overhead of
answering common issues. Translation of this documentation into other
languages is also of great help.

<item>By packaging applications that are useful for checking or
enhancing security in a Debian GNU/Linux system. If you are not a
developer, file a <url name="WNPP bug"
id="http://www.debian.org/devel/wnpp/"> and ask for software you think
would be useful, but is not currently provided.

<item>Audit applications in Debian or help solve security bugs and
report issues to security@debian.org. 

</list>

<p>In all cases, 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 already received. Providing additional information, however, is
always a good idea.

<sect1>Who is the Security Team composed of?

<P>The Debian security team consists of <url
id="http://www.debian.org/intro/organization" name="several officers and
secretaries">. The security team itself appoints people to join the team.

<sect1>Does the Debian Security team check every new package in
Debian?

<p>No, the Debian security team does not check every new package and
there is no automatic (lintian) check to detect new
packages including malicious codes, since those checks are rather impossible to 
perform automatically. Maintainers, however, are fully responsible for the
packages they introduce into Debian, and all packages are first signed
by an authorized developer(s). The developer is in charge of analyzing
the security of all packages that they maintain.

<sect1>How much time will it take Debian to fix vulnerability XXXX?

<p>The Debian security team works quickly to send advisories and
produce fixed packages for the stable branch once a vulnerability is
discovered. A report <url
id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html"
name="published in the debian-security mailing list"> showed that in
the year 2001, it took the Debian Security Team an average of 35 days
to fix security-related vulnerabilities. However, over 50% of the
vulnerabilities where fixed in a 10-day time frame, and over 15% of
them where fixed the <em>same day</em> the advisory was released.

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

<list>

<item>DSAs are not sent until:

<list>

<item>packages are available for <em>all</em> architectures supported
by Debian (which takes some time for packages that are part of the
system core, especially considering the number of architectures
supported in the stable release).

<item>new packages are thoroughly tested in order to ensure that no
new bugs are introduced

</list>

<item>Packages might be available before the DSA is sent (in the
incoming queue or on the mirrors).

<item>Debian is a volunteer-based project.

<item>Debian is licensed with a "no guarantees" clause.

</list>

<p>If you want more in-depth analysis on the time it takes for the
Security Team to work on vulnerabilities, you should consider that new
DSAs (see <ref id="dsa">) published on the <url
id="http://security.debian.org" name="security website">, and the
metadata used to generate them, include links to vulnerability
databases. You could download the sources from the web server (from
the <url id="http://cvs.debian.org" name="CVS">) or use the HTML pages
to determine the time that it takes for Debian to fix vulnerabilities
and correlate this data with public databases.

<!-- These items are in the FAQ -->
<sect1>How long will security updates be provided?

<p>The security team tries to support a stable distribution for about one year
after the next stable distribution has been released, except when another
stable distribution is released within this year. It is not possible to support
three distributions; supporting two simultaneously is already difficult enough.

<sect1>How can I check the integrity of packages?

<!-- TODO: Where will the 2007 key be? -->

<p>This process involve checking the Release file signature against the public key
(available at <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc">, substitute
2006 for the current year) for
the archive. The Release file contains the MD5 checksums of Packages and
Sources files, which contain MD5 checksums of binary and source
packages. Detailed instruction on how to check packages integrity can be found
<url id="deb-pack-sign" name="here">.

<sect1>What to do if a random package breaks after a security update?

<p>First of all, you should figure out why the package breaks and how it is
connected to the security update, then contact the security team if it is
serious or the stable release manager if it is less serious. We're talking
about random packages that break after a security update of a different
package. If you can't figure out what's going wrong but have a correction, talk
to the security team as well. You may be redirected to the stable release
manager though.