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

<chapt>Before and during the installation


<sect id="bios-passwd">Choose a BIOS password
<p>
Before you install any operating system on your computer, set up a
BIOS password. After installation (once you have enabled bootup
from the hard disk) you should go back to the BIOS and change the 
boot sequence to disable booting from floppy, CD-ROM and other 
devices that shouldn't boot. Otherwise a cracker only needs 
physical access and a boot disk to access your entire system.

<p>Disabling booting unless a password is supplied is even better. This can be 
very effective if you run a server, because it is not rebooted very often. The 
downside to this tactic is that rebooting requires human intervention which 
can cause problems if the machine is not easily accessible.

<p>Note: many BIOSes have well known default master passwords, and
applications also exist to retrieve the passwords from the
BIOS. Corollary: don't depend on this measure to secure console access
to system.

<sect>Partitioning the system

<sect1>Choose an intelligent partition scheme
<p>
An intelligent partition scheme depends on how the machine is
used. A good rule of thumb is to be fairly liberal with your
partitions and to pay attention to the following factors:

<list>
<item>Any directory tree which a user has write permissions to, such
as e.g. <file>/home</file>, <file>/tmp</file> and
<file>/var/tmp/</file>, should be on a separate partition. This
reduces the risk of a user DoS by filling up your "/" mount point and
rendering the system unusable (Note: this is not strictly true, since
there is always some space reserved for root which a normal user
cannot fill), and it also prevents hardlink attacks.
<footnote>
A very good example of this kind of attacks using /tmp is detailed in
<url id="http://www.hackinglinuxexposed.com/articles/20031111.html"
name="The mysteriously persistently exploitable program (contest)">
and
<url id="http://www.hackinglinuxexposed.com/articles/20031214.html"
name="The mysteriously persistently exploitable program explained">
(notice that the incident is Debian-related). It is basicly an attack
in which a local user <em>stashes</em> away a vulnerable setuid
application by making a hard link to it, effectively avoiding any
updates (or removal) of the binary itself made by the system
administrator. Dpkg was recently fixed to prevent this (see <url
id="http://bugs.debian.org/225692" name="225692">) but other setuid
binaries (not controlled by the package manager) are at risk if
partitions are not setup correctly. 
</footnote>
</item>

<item>Any partition which can fluctuate, e.g. <file>/var</file>
(especially <file>/var/log</file>) should also be on a separate
partition. On a Debian system, you should create <file>/var</file> a
little bit bigger than on other systems, because downloaded packages (the apt
cache) are stored in <file>/var/cache/apt/archives</file>. 

<item>Any partition where you want to install non-distribution
software should be on a separate partition. According to the File
Hierarchy Standard, this is <file>/opt</file> or <file>/usr/local</file>.
If these are separate partitions, they will not be erased if you 
(have to) reinstall Debian itself.

<item>From a security point of view, it makes sense to try to move
static data to its own partition, and then mount that partition
read-only. Better yet, put the data on read-only media. See below for
more details.
</list>

<p>In the case of a mail server it is important to have a separate
partition for the mail spool. Remote users (either knowingly or
unknowingly) can fill the mail spool (<file>/var/mail</file> and/or
<file>/var/spool/mail</file>). If the spool is on a separate
partition, this situation will not render the system
unusable. Otherwise (if the spool directory is on the same
partition as <file>/var</file>) the system might have important
problems: log entries will not be created, packages cannot be
installed, and some programs might even have problems starting up (if
they use <file>/var/run</file>).

<p>Also, for partitions in which you cannot be sure of the needed
space, installing Logical Volume Manager
(<package>lvm-common</package> and the needed binaries for your
kernel, this might be either <package>lvm10</package>,
<package>lvm6</package>, or <package>lvm5</package>). Using
<tt>lvm</tt>, you can create volume groups that expand multiple
physical volumes.

<sect2>Selecting the appropriate file systems

<p>During the system partitioning you also have to decide which file system you
want to use. The default file system<footnote>Since Debian GNU/Linux 4.0,
codename <tt>etch</tt></footnote> selected in the
Debian installation for Linux partitions is <tt>ext3</tt>, a journaling 
file system. It is recommended that you always use a journaling file system,
such as <tt>ext3</tt>, <tt>reiserfs</tt>, <tt>jfs</tt> or <tt>xfs</tt>, to
minimize the problems derived from a system crash in the following
cases:

<list>

<item>for laptops in all the file systems installed. That way if you
run out of battery unexpectedly or the system freezes due to a
hardware issue (such as X configuration which is somewhat common) you
will be less likely to lose data during a hardware reboot.

<item>for production systems which store large amounts of data (like
mail servers, ftp servers, network file systems...) it is recommended
on these partitions. That way, in the event of a system crash, the
server will take less time to recover and check the file systems, and
data loss will be less likely.

</list>

<p>Leaving aside the performance issues regarding journalling
file systems (since this can sometimes turn into a religious war), it
is usually better to use the <tt>ext3</tt> file system. The reason for
this is that it is backwards compatible with <tt>ext2</tt>, so if
there are any issues with the journalling you can disable it and still
have a working file system. Also, if you need to recover the system
with a bootdisk (or CD-ROM) you do not need a custom kernel. If the
kernel is 2.4 or 2.6 <tt>ext3</tt> support is already available, if it
is a 2.2 kernel you will be able to boot the file system even if you
lose journalling capabilities. If you are using other journalling
file systems you will find that you might not be able to recover unless
you have a 2.4 or 2.6 kernel with the needed modules built-in.
If you are stuck with a 2.2 kernel on the rescue disk, it might be even
more difficult to have it access <tt>reiserfs</tt> or <tt>xfs</tt>.

<p>In any case, data integrity might be better under <tt>ext3</tt> since it 
does file-data journalling while others do only meta-data journalling, see
<url id="http://lwn.net/2001/0802/a/ext3-modes.php3">.

<p>Notice, however, that there are some partitions that might not
benefit from using a journaling filesystem. For example, if you are using a
separate partition for <file>/tmp/</file> you might be better off
using a standard <tt>ext2</tt> filesystem as it will be cleaned up
when the system boots.

<sect>Do not plug to the Internet until ready

<p>The system should not be immediately connected to the Internet
during installation. This could sound stupid but network installation
is a common method. Since the system will install and activate
services immediately, if the system is connected to the Internet and
the services are not properly configured you are opening it to attack.

<p>Also note that some services might have security
vulnerabilities not fixed in the packages you are using for
installation. This is usually true if you are installing from old
media (like CD-ROMs). In this case, the system could even be compromised
before you finish installation!

<p>Since Debian installation and upgrades can be done over the
Internet you might think it is a good idea to use this feature on
installation. If the system is going to be directly connected to the
Internet (and not protected by a firewall or NAT), it is best to
install without connection to the Internet, using a local packages
mirror for both the Debian package sources and the security
updates. You can set up package mirrors by using another system
connected to the Internet with Debian-specific tools (if it's a Debian
system) like <package>apt-move</package> or
<package>apt-proxy</package>, or other common mirroring tools, to
provide the archive to the installed system. If you cannot do this,
you can set up firewall rules to limit access to the system while doing
the update (see <ref id="fw-security-update">).

<sect>Set a root password
<p>
Setting a good root password is the most basic requirement for having
a secure system. See <manref section="1" name="passwd"> for some hints
on how to create good passwords. You can also use an automatic
password generation program to do this for you (see <ref
id="user-pwgen">).

<p>
Plenty of information on choosing good passwords can be found on the
Internet; two that provide a decent summary and rationale are Eric Wolfram's 
<url name="How to: Pick a Safe Password"
id="http://wolfram.org/writing/howto/password.html"> and 
Walter Belgers' 
<url name="Unix Password Security"
id="http://www.belgers.com/write/pwseceng.txt">
<!--Also at http://citeseer.ist.psu.edu/8481.html -->


<sect>Activate shadow passwords and MD5 passwords
<p>
At the end of the installation, you will be asked if shadow passwords
should be enabled. Answer yes to this question, so passwords will be
kept in the file <file>/etc/shadow</file>. Only the root user and the
group shadow have read access to this file, so no users will be able
to grab a copy of this file in order to run a password cracker against
it. You can switch between shadow passwords and normal passwords at
any time by using <tt>shadowconfig</tt>.


<p>Read more on shadow passwords in
<url
name="Shadow Password"
id="http://www.tldp.org/HOWTO/Shadow-Password-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz</file>).

<p>Furthermore, the installation uses MD5 hashed passwords per
default. This is generally a very good idea since
it allows longer passwords and better encryption. MD5 allows for
passwords longer than 8 characters. This, if used wisely, can make it
more difficult for attackers to brute-force the system's
passwords. Regarding MD5 passwords, this is the default option when
installing the latest <package>passwd</package> package.
You can recognize MD5 passwords in the
<file>/etc/shadow</file> file by their $1$ prefix.

<p>This, as a matter of fact, modifies all files under
<file>/etc/pam.d</file> by substituting the password line and include
md5 in it:
<example>
  password required pam_unix.so md5 nullok obscure min=6 max=16
</example>
<p>If <tt>max</tt> is not set over 8 the change will not be useful at
all. For more information on this read <ref id="auth-pam">.

<p>Note: the default configuration in Debian, even when activating MD5
passwords, does not modify the previously set <tt>max</tt> value.

<sect>Run the minimum number of services required

<p>Services are programs such as ftp servers and web servers. Since
they have to be <em>listening</em> for incoming connections that
request the service, external computers can connect to yours. Services
are sometimes vulnerable (i.e. can be compromised under a given
attack) and hence present a security risk.

<p>You should not install services which are not needed on your
machine. Every installed service might introduce new, perhaps not
obvious (or known), security holes on your computer.

<p>As you may already know, when you install a given service the
default behavior is to activate it. In a default Debian installation,
with no services installed, the number of running services is quite
low and the number of network-oriented services is even lower. In a
default Debian 3.1 standard installation you will end up with OpenSSH,
Exim (depending on how you configured it) and the RPC portmapper
available as network services<footnote>The footprint in Debian 3.0 and
earlier releases wasn't as tight, since some <prgn>inetd</prgn>
services were enabled by default. Also standard installations of
Debian 2.2 installed the NFS server as well as the telnet
server.</footnote>. If you did not go through a standard installation
but selected an expert installation you can end up with no active
network services. The RPC portmapper is installed by default because
it is needed for many services, for example NFS, to run on a given
system. However, it can be easily removed, see <ref id="rpc"> for more
information on how to secure or disable RPC services.

<p>When you install a new network-related service (daemon) in your
Debian GNU/Linux system it can be enabled in two ways: through the
<prgn>inetd</prgn> superdaemon (i.e. a line will be added to
<file>/etc/inetd.conf</file>) or through a standalone program that
binds itself to your network interfaces. Standalone programs are
controlled through the <file>/etc/init.d</file> files, which are
called at boot time through the SysV mechanism (or an alternative one)
by using symlinks in <file>/etc/rc?.d/*</file> (for more information
on how this is done read
<file>/usr/share/doc/sysvinit/README.runlevels.gz</file>).

<p>If you want to keep some services but use them rarely, use the
<prgn>update-*</prgn> commands, e.g. <prgn>update-inetd</prgn> and
<prgn>update-rc.d</prgn> to remove them from the startup process. For
more information on how to disable network services read <ref
id="disableserv">. If you want to change the default behaviour of
starting up services on installation of their associated
packages<footnote>This is desirable if you are setting up a
development chroot, for example.</footnote> use
<prgn>policy-rc.d</prgn>, please read
<file>/usr/share/doc/sysv-rc/README.policy-rc.d.gz</file> for more
information.

<p><prgn>invoke-rc.d</prgn> support is mandatory in Debian, which means that
for Debian 4.0 <em>etch</em> and later releases you can write a policy-rc.d
file that forbids starting new daemons before you configure them. Although no
such scripts are packaged yet, they are quite simple to write. See
<package>policyrcd-script-zg2</package>.

<sect1 id="disableserv">Disabling daemon services

<p>Disabling a daemon service is quite simple. You either remove the
package providing the program for that service or you remove or rename
the startup links under <file>/etc/rc${runlevel}.d/</file>. If you
rename them make sure they do not begin with 'S' so that they don't
get started by <prgn>/etc/init.d/rc</prgn>. Do not remove all the
available links or the package management system will regenerate them
on package upgrades, make sure you leave at least one link (typically
a 'K', i.e. kill, link). For more information read
<url id="http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-custombootscripts"
name="Customizing runlevels"> section of the 
Debian Reference (Chapter 2 - Debian fundamentals).

<p>You can remove these links manually or using <tt>update-rc.d</tt>
(see <manref section="8" name="update-rc.d">). For example, you can
disable a service from executing in the multi-user runlevels by doing:

<example>
  # update-rc.d <var>name</var> stop <var>XX</var> 2 3 4 5 .
</example>


<p>Where <em>XX</em> is a number that determines when the stop action
for that service will be executed. Please note that, if you are
<em>not</em> using <package>file-rc</package>, <tt>update-rc.d -f
<var>service</var> remove</tt> will not work properly, since
<em>all</em> links are removed, upon re-installation or upgrade of the
package these links will be re-generated (probably not what you
wanted). If you think this is not intuitive you are probably right
(see <url id="http://bugs.debian.org/67095" name="Bug 67095">). From
the manpage:


<example>
  If any files /etc/rc<var>runlevel</var>.d/[SK]??name already exist then
  update-rc.d does nothing.  This is so that the system administrator 
  can rearrange the  links,  provided that  they  leave  at  least one
  link remaining, without having their configuration overwritten.
</example>

<p>If you are using <package>file-rc</package> all the information
regarding services bootup is handled by a common configuration file
and is maintained even if packages are removed from the system.

<p>You can use the TUI (Text User Interface) provided by
<package>sysv-rc-conf</package> to do all these changes easily
(<prgn>sysv-rc-conf</prgn> works both for <package>file-rc</package>
and normal System V runlevels). You will also find similar GUIs for 
desktop systems. You can also use the command line interface
of <package>sysv-rc-conf</package>:

<example>
  # sysv-rc-conf foobar off
</example>
 
<p>The advantage of using this utility is that 
the rc.d links are returned to the status they had before the 'off' call 
if you re-enable the service with:

<example>
  # sysv-rc-conf foobar on
</example>


<p>Other (less recommended) methods of disabling services are: 

<list>

<item>Removing the  <file>/etc/init.d/<var>service_name</var></file> script
and removing the startup links using:

<example>
  # update-rc.d <var>name</var> remove
</example>

<item>Move the script file
(<file>/etc/init.d/<var>service_name</var></file>) to another name
(for example <file>/etc/init.d/OFF.<var>service_name</var></file>).
This will leave dangling symlinks under
<file>/etc/rc${runlevel}.d/</file> and will generate error messages
when booting up the system.

<item>Remove the execute permission from the
<file>/etc/init.d/<var>service_name</var></file> file. That will
also generate error messages when booting.

<item>Edit the <file>/etc/init.d/<var>service_name</var></file> script
to have it stop immediately once it is executed (by adding an
<prgn>exit 0</prgn> line at the beginning or commenting out the
<tt>start-stop-daemon</tt> part in it). If you do this, you will not be able to 
use the script to startup the service manually later on.

</list>

<p>Nevertheless, the files under <file>/etc/init.d</file> are
configuration files and should not get overwritten due to package
upgrades if you have made local changes to them.

<p>Unlike other (UNIX) operating systems, services in
Debian cannot be disabled by modifying files in
<file>/etc/default/<var>service_name</var></file>.

<p>FIXME: Add more information on handling daemons using
<package>file-rc</package>.

<sect1 id="inetd">Disabling <prgn>inetd</prgn> or its services
<p>
You should check if you really need the <prgn>inetd</prgn> daemon nowadays.
Inetd was always a way to compensate for kernel deficiencies, but those have
been taken care of in modern Linux kernels.
Denial of Service possibilities exist against <prgn>inetd</prgn> (which can
increase the machine's load tremendously), and many people always preferred
using stand-alone daemons instead of calling services via <prgn>inetd</prgn>.
If you still want to run some kind of <prgn>inetd</prgn> service, then at 
least switch to a more configurable Inet daemon like <prgn>xinetd</prgn>,
<prgn>rlinetd</prgn> or <prgn>openbsd-inetd</prgn>.
<p>
You should stop all unneeded Inetd services on your system, like
<prgn>echo</prgn>, <prgn>chargen</prgn>, <prgn>discard</prgn>,
<prgn>daytime</prgn>, <prgn>time</prgn>, <prgn>talk</prgn>,
<prgn>ntalk</prgn> and r-services (<prgn>rsh</prgn>, <prgn>rlogin</prgn>
and <prgn>rcp</prgn>) which are
considered HIGHLY insecure (use <prgn>ssh</prgn> instead). 

<p>You can disable services by editing <file>/etc/inetd.conf</file> 
directly, but Debian provides a better alternative: <tt>update-inetd</tt> 
(which comments the services in a way that it can easily be turned on again). 
You could remove the <prgn>telnet</prgn> daemon by executing this commands to 
change the config file and to restart the daemon (in this case the 
<prgn>telnet</prgn> service is disabled):

<example>
  /usr/sbin/update-inetd --disable telnet
</example>
<!-- # /etc/init.d/inetd restart Not needed since the manpage says update-inetd
sends a SIGHUP, commented out as suggested by Dariusz Puchalak -->

<p>If you do want services listening, but do not want to have them listen on 
all IP addresses of your host, you might want to use an undocumented feature 
on <prgn>inetd</prgn> (replace service name with service@ip syntax) or use
an alternative <prgn>inetd</prgn> daemon like <prgn>xinetd</prgn>.

<sect>Install the minimum amount of software required

<p>Debian comes with <em>a lot</em> of software, for example the
Debian 3.0 <em>woody</em> release includes 6 or 7 (depending on
architecture) CD-ROMs of software and thousands of packages,
and the Debian 3.1 <em>sarge</em> release ships with around 13 CD-ROMs
of software. With so much software, and even if
the base system installation is quite reduced
<footnote>For example, in Debian woody it is around 400-500 Mbs, try this:
<example>
  $ size=0
  $ for i in `grep -A 1 -B 1 "^Section: base" /var/lib/dpkg/available |
  grep -A 2 "^Priority: required" |grep "^Installed-Size" |cut -d : -f 2
  `; do size=$(($size+$i)); done
  $ echo $size
  47762
</example>
</footnote>
you might get carried away and install more than is really needed
for your system.

<p>Since you already know what the system is for (don't you?) you
should only install software that is really needed for it to work. Any
unnecessary tool that is installed might be used by a user that wants
to compromise the system or by an external intruder that has gotten
shell access (or remote code execution through an exploitable
service).

<p>The presence, for example, of development utilities (a C compiler) or 
interpreted languages (such as <prgn>perl</prgn> - but see below -, 
<prgn>python</prgn>, <prgn>tcl</prgn>...) may help an attacker compromise the 
system even further:

<list>
<item>allowing him to do privilege escalation. It's easier, for
example, to run local exploits in the system if there is a debugger
and compiler ready to compile and test them!

<item>providing tools that could help the attacker to use the
compromised system as a <em>base of attack</em> against other systems.
<footnote>
Many intrusions are made just to get access to resources to do
illegitimate activity (denial of service attacks, spam, rogue ftp
servers, dns pollution...) rather than to obtain confidential
data from the compromised system.
</footnote>

</list>

<p>Of course, an intruder with local shell access can download his own
set of tools and execute them, and even the shell itself can be used
to make complex programs. Removing unnecessary software will not help
<em>prevent</em> the problem but will make it slightly more difficult
for an attacker to proceed (and some might give up in this situation
looking for easier targets). So, if you leave tools in a production
system that could be used to remotely attack systems (see <ref
id="vuln-asses">) you can expect an intruder to use them too if
available.

<p>Please notice that a default installation of Debian <em>sarge</em>
(i.e. an installation where no individual packages are selected) will
install a number of development packages that are not usually needed.
This is because some development packages are of <em>Standard</em> priority.
If you are not going to do any development you can safely remove the
following packages from your system, which will also help free up some
space:

<example>
Package                    Size
------------------------+--------
gdb                     2,766,822
gcc-3.3                 1,570,284
dpkg-dev                  166,800
libc6-dev               2,531,564
cpp-3.3                 1,391,346
manpages-dev            1,081,408
flex                      257,678
g++                         1,384 (Note: virtual package)
linux-kernel-headers    1,377,022
bin86                      82,090
cpp                        29,446
gcc                         4,896 (Note: virtual package)
g++-3.3                 1,778,880
bison                     702,830
make                      366,138
libstdc++5-3.3-dev        774,982
</example>

<p>This is something that is fixed in releases post-sarge,
see <url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301273"
name="Bug #301273"> 
and <url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301138"
name="Bug #301138">. Due to a bug in the installation system this did not
happen when installing with the installation system of the Debian 3.0
<em>woody</em> release.

<sect1>Removing Perl

<p>You must take into account that removing <prgn>perl</prgn> might not be too 
easy (as a matter of fact it can be quite difficult) in a Debian system since 
it is used by many system utilities. Also, the <package>perl-base</package> is 
<em>Priority: required</em> (that about says it all). It's still doable, but 
you will not be able to run any <prgn>perl</prgn> application in the system; 
you will also have to fool the package management system to think that the
<package>perl-base</package> is installed even if it's not. <footnote>You can 
make (on another system) a dummy package with <package>equivs</package>.
</footnote>

<p>Which utilities use <prgn>perl</prgn>? You can see for yourself:

<example>
  $ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
  type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done
</example>

<p>These include the following utilities in packages with priority
<em>required</em> or <em>important</em>:

<list>
<item><file>/usr/bin/chkdupexe</file> of package
<package>util-linux</package>.

<item><file>/usr/bin/replay</file> of package
<package>bsdutils</package>.

<item><file>/usr/sbin/cleanup-info</file> of package
<package>dpkg</package>.

<item><file>/usr/sbin/dpkg-divert</file> of package
<package>dpkg</package>.

<item><file>/usr/sbin/dpkg-statoverride</file> of package
<package>dpkg</package>.

<item><file>/usr/sbin/install-info</file> of package
<package>dpkg</package>.

<item><file>/usr/sbin/update-alternatives</file> of package
<package>dpkg</package>.

<item><file>/usr/sbin/update-rc.d</file> of package
<package>sysvinit</package>.

<item><file>/usr/bin/grog</file> of package
<package>groff-base</package>.

<item><file>/usr/sbin/adduser</file> of package
<package>adduser</package>.

<item><file>/usr/sbin/debconf-show</file> of package
<package>debconf</package>.

<item><file>/usr/sbin/deluser</file> of package
<package>adduser</package>.

<item><file>/usr/sbin/dpkg-preconfigure</file> of package
<package>debconf</package>.

<item><file>/usr/sbin/dpkg-reconfigure</file> of package
<package>debconf</package>.

<item><file>/usr/sbin/exigrep</file> of package
<package>exim</package>.

<item><file>/usr/sbin/eximconfig</file> of package
<package>exim</package>.

<item><file>/usr/sbin/eximstats</file> of package
<package>exim</package>.

<item><file>/usr/sbin/exim-upgrade-to-r3</file> of package
<package>exim</package>.

<item><file>/usr/sbin/exiqsumm</file> of package
<package>exim</package>.

<item><file>/usr/sbin/keytab-lilo</file> of package
<package>lilo</package>.

<item><file>/usr/sbin/liloconfig</file> of package
<package>lilo</package>.

<item><file>/usr/sbin/lilo_find_mbr</file> of package
<package>lilo</package>.

<item><file>/usr/sbin/syslogd-listfiles</file> of package
<package>sysklogd</package>.

<item><file>/usr/sbin/syslog-facility</file> of package
<package>sysklogd</package>.

<item><file>/usr/sbin/update-inetd</file> of package
<package>netbase</package>.

</list>

<p>So, without Perl and, unless you remake these utilities in shell
script, you will probably not be able to manage any packages (so you
will not be able to upgrade the system, which is <em>not a Good
Thing</em>).

<p>If you are determined to remove Perl from the Debian base system,
and you have spare time, submit bug reports to the previous packages
including (as a patch) replacements for the utilities above written in
shell script.

<p>If you wish to check out which Debian packages depend on Perl you can use

<example>
$ grep-available -s Package,Priority -F Depends perl
</example>

<p>or
<example>
$ apt-cache rdepends perl
</example>

<sect>Read the Debian security mailing lists

<p>It is never wrong to take a look at either the debian-security-announce 
mailing list, where advisories and fixes to released packages are announced by 
the Debian security team, or at 
<url id="mailto:debian-security@lists.debian.org">, where you can participate 
in discussions about things related to Debian security.

<p>In order to receive important security update alerts, send an email
to <url name="debian-security-announce-request@lists.debian.org"
id="mailto:debian-security-announce-request@lists.debian.org"> with
the word "subscribe" in the subject line. You can also subscribe to
this moderated email list via the web page at
<url name="http://www.debian.org/MailingLists/subscribe"
id="http://www.debian.org/MailingLists/subscribe">.

<p>This mailing list has very low volume, and by subscribing to it you
will be immediately alerted of security updates for the Debian
distribution. This allows you to quickly download new packages with
security bug fixes, which is very important in maintaining a secure
system (see <ref id="security-update"> for details on how to do this).