[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
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.
A system is only as secure as its administrator is capable of making it. Debian's default installation of services aims to be secure, but may not be as paranoid as some other operating systems which install all services disabled by default. In any case, the system administrator needs to adapt the security of the system to his local security policy.
For a collection of data regarding security vulnerabilities for many operating
systems, see the US-CERT stats or
generate stats using the 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.[77] Also, keep
in mind that some reported vulnerabilities regarding Debian apply only to the
unstable (i.e. unreleased) branch.
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 rpc.statd
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 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.
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:
Debian provides more security tools than other distributions, see Security tools in Debian, Chapter 8.
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 Lion
Ramen).
Debian's installation is not as limited as OpenBSD (no daemons are active per
default), but it's a good compromise. [78]
Debian documents best security practices in documents like this one.
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 Common Criteria. 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
EAL
levels. Notice that some of the CC tests are being integrated into the
Linux Testing Project
which is available in Debian in the ltp.
Yes. Bastille Linux,
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
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:
Is the software maintained upstream? When was the last release?
Is the package mature? The version number really does not tell you about its maturity. Try to trace the software's history.
Is the software bug-ridden? Have there been security advisories related to it?
Does the software provide all the functionality you need? Does it provide more than you really need?
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. [79] 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:
Processes might not be able to write to log files if you restrict their permissions.
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
/etc/samba/smb.conf, the smbclient program will not
work when run by a normal user.
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 Limiting access to other user's information, Section 4.10.12.1.
This Debian security mailing list thread
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 dmesg(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 */
Yes and no. Debian comes with some predefined users (user id (UID) < 99 as
described in Debian
Policy or /usr/share/doc/base-passwd/README) 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).
To easily find users who don't own any files, execute the following command[80] (run it as root, since a common user might not have enough permissions to go through some sensitive directories):
cut -f 1 -d : /etc/passwd | \
while read i; do find / -user "$i" | grep -q . || echo "$i"; done
These users are provided by base-passwd. 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:
root: Root is (typically) the superuser.
daemon: Some unprivileged daemons that need to write to files on disk run as
daemon.daemon (e.g., portmap, atd, 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.
bin: maintained for historic reasons.
sys: same as with bin. However, /dev/vcs* and /var/spool/cups are
owned by group sys.
sync: The shell of user sync is /bin/sync. 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.
games: Many games are SETGID to games so they can write their high score files. This is explained in policy.
man: The man program (sometimes) runs as user man, so it can write cat pages to
/var/cache/man
lp: Used by printer daemons.
mail: Mailboxes in /var/mail are owned by group mail, as explained
in policy. The user and group are used for other purposes by various MTA's as
well.
news: Various news servers and other associated programs (such as
suck) use user and group news in various ways. Files in the news
spool are often owned by user and group news. Programs such as
inews that can be used to post news are typically SETGID news.
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.
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 pdnsd, and squid
runs as user proxy.
majordom: Majordomo has a statically allocated UID on Debian
systems for historical reasons. It is not installed on new systems.
postgres: Postgresql databases are owned by this user and group.
All files in /var/lib/postgresql are owned by this user to enforce
proper security.
www-data: Some web servers run as www-data. Web content should not 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.
backup: So backup/restore responsibilities can be locally delegated to someone without full root permissions.
operator: Operator is historically (and practically) the only 'user' account that can login remotely, and doesn't depend on NIS/NFS.
list: Mailing list archives and data are owned by this user and group. Some mailing list programs may run as this user as well.
irc: Used by irc daemons. A statically allocated user is needed only because
of a bug in ircd, which SETUID()s itself to a given UID on
startup.
gnats.
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.
Other groups which have no associated user:
adm: Group adm is used for system monitoring tasks. Members of this group can
read many log files in /var/log, and can use xconsole.
Historically, /var/log was /usr/adm (and later
/var/adm), thus the name of the group.
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.
disk: Raw access to disks. Mostly equivalent to root access.
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.
dialout: Full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc.
dip: The group's name stands for "Dial-up IP", and membership in dip
allows you to use tools like ppp, dip,
wvdial, 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.
fax: Allows members to use fax software to send / receive faxes.
voice: Voicemail, useful for systems that use modems as answering machines.
cdrom: This group can be used locally to give a set of users access to a CDROM drive.
floppy: This group can be used locally to give a set of users access to a floppy drive.
tape: This group can be used locally to give a set of users access to a tape drive.
sudo: Members of this group don't need to type their password when using
sudo. See /usr/share/doc/sudo/OPTIONS.
audio: This group can be used locally to give a set of users access to an audio device.
src: This group owns source code, including files in /usr/src. It
can be used locally to give a user the ability to manage system source code.
shadow: /etc/shadow is readable by this group. Some programs that
need to be able to access the file are SETGID shadow.
utmp: This group can write to /var/run/utmp and similar files.
Programs that need to be able to write to it are SETGID utmp.
video: This group can be used locally to give a set of users access to a video device.
staff: Allows users to add local modifications to the system
(/usr/local, /home) without needing root privileges.
Compare with group "adm", which is more related to
monitoring/security.
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.
If you have removed a system user and have not made a backup of your
password and group files you can try recovering from
this issue using update-passwd (see
update-passwd(8)).
The 'adm' group are usually administrators, and this group permission allows
them to read log files without having to su. The 'staff' group
are usually help-desk/junior sysadmins, allowing them to work in
/usr/local and create directories in /home.
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.
That's just an approach to the problem of being, on one side, security conscious and on the other side user friendly. Unlike OpenBSD, which disables all services unless activated by the administrator, Debian GNU/Linux will activate all installed services unless deactivated (see Disabling daemon services, Section 3.6.1 for more information). After all you installed the service, didn't you?
There has been 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.
inetd?
Inetd is not easy to remove since netbase depends on
the package that provides it (netkit-inetd). If you want to
remove it, you can either disable it (see Disabling daemon services, Section 3.6.1)
or remove the package by using the equivs package.
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 Securing RPC services, Section 5.13.
In versions of the portmap package later than 5-5 you can actually
have the portmapper installed but listening only on localhost (by modifying
/etc/default/portmap)
identd (port 113) for?
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, inetd 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.
There has been extensive discussion on the security of identd (See
mailing
list archives). In general, identd 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, please use a reject
policy and not a deny policy, otherwise a connection to a server utilizing
identd will hang until a timeout expires (see reject or deny
issues).
If you have run the command netstat -an and receive:
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
-
You are not seeing processes listening on TCP/UDP port 1 and 6. In
fact, you are seeing a process listening on a raw socket for protocols
1 (ICMP) and 6 (TCP). Such behavior is common to both Trojans and some
intrusion detection systems such as iplogger and
portsentry. If you have these packages simply remove them. If
you do not, try netstat's -p (process) option to see which process
is running these listeners.
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 inetd (see Disabling inetd or its services,
Section 3.6.2), or by other installed packages and take the appropriate
measures (i.e, configure inetd, remove the package, avoid it running on
boot-up).
/etc/services help secure my box?
No, /etc/services 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
/etc/services is modified, but that's not the norm. To properly
disable the service, see Disabling daemon
services, Section 3.6.1.
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
lilo and your system's BIOS.
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.
Once you have enabled booting from a CD-ROM or diskette enable, try the following:
Boot-up from a rescue disk and start the kernel
Go to the virtual console (Alt+F2)
Mount the hard disk where your /root is
Edit (Debian 2.2 rescue disk comes with the editor ae, and Debian
3.0 comes with nano-tiny which is similar to vi)
/etc/shadow and change the line:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)
to:
root::XXXX:X:XXXX:X:::
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.
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 lilo
just after the root reset above. This is quite tricky since your
/etc/lilo.conf will need to be tweaked due to the root (/) file
system being a ramdisk and not the real hard disk.
Once LILO is unrestricted, try the following:
Press the Alt, shift or Control key just before the system BIOS finishes, and you should get the LILO prompt.
Type linux single, linux init=/bin/sh or linux 1 at the prompt.
This will give you a shell prompt in single-user mode (it will ask for a password, but you already know it)
Re-mount read/write the root (/) partition, using the mount command.
# mount -o remount,rw /
Change the superuser password with passwd (since you are superuser
it will not ask for the previous password).
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 User authentication: PAM,
Section 4.10.1) 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:
/etc/pam.d/imap:where=imap=1.
/etc/pam.d/qpopper:where=pop=1.
/etc/nss-mysql*.conf:users.where_clause = user.sys =
1;.
/etc/proftpd.conf:SQLWhereClause "ftp=1".
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 Debian Security Advisories, Section 7.2) 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 After the compromise (incident response), Chapter 11). 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 Configuring syncookies, Section 4.17.2. 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:
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 SANS Top 20 Security
Vulnerabilities.
Read this document, especially the After the compromise (incident response), Chapter 11 section.
Ask for assistance. You might use the debian-security mailing list and ask for advice on how to recover/patch your system.
Notify your local 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 blackhat community.
By watching the logs (if they have not been tampered with), using intrusion
detection systems (see Set up
Intrusion Detection, Section 10.3), 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 team@security.debian.org.
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.
proftpd is vulnerable to a Denial of Service attack.
Add DenyFilter \*.*/ to your configuration file, and for more
information see http://www.proftpd.org/bugs.html.
portsentry, there are a lot of ports open.
That's just the way portsentry works. It opens about twenty
unused ports to try to detect port scans.
This information is derived from the 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.
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 security
area).
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).
This is most likely a problem on your end. The debian-security-announce
list has a filter that only allows messages with a correct signature from one
of the security team members to be posted.
Most likely some piece of mail software on your end slightly changes the message, thus breaking the signature. Make sure your software does not do any MIME encoding or decoding, or tab/space conversions.
Known culprits fetchmail (with the mimedecode option enabled), formail (from procmail 3.14 only) and evolution.
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.
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.
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.
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.
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.
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.
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.
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.
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 testing security
team which has begun work to offer security support for testing, and
to some extent, for unstable. For more information see Security support for the testing
branch, Section 10.1.4
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).
You can review public vulnerabilities affecting the testing and
unstable release at the Security Bug
Tracker.
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.
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.
The testing security
team also makes security fixes available in their repository when
the normal migration process is not fast enough.
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.
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.
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.
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.
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.
Please use the packages from the latest security advisories, which are
distributed through the debian-security-announce
mailing list. It's best to simply run apt-get update
before upgrading the package.
Security information can be sent to security@debian.org, which is read
by all Debian developers. If you have sensitive information please use
team@security.debian.org
which only the members of the team can read. If desired, email can be
encrypted with the Debian Security Contact key (key ID 0x363CCD95).
See also the PGP/GPG
keys for the security team.
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 [81] (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
subscribe, and
there are searchable archives available here.
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.
If the vulnerability is already publicly known, be sure to file a bug report in the Debian BTS, and tag it security.
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.
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 WNPP bug and ask for
software you think would be useful, but is not currently provided.
Audit applications in Debian or help solve security bugs and report issues to security@debian.org.
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.
The Debian security team consists of several officers and
secretaries. The security team itself appoints people to join the
team.
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.
The Debian security team works quickly to send advisories and produce fixed
packages for the stable branch once a vulnerability is discovered. A report
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 same day the
advisory was released.
However, when asking this question people tend to forget that:
DSAs are not sent until:
packages are available for all 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).
new packages are thoroughly tested in order to ensure that no new bugs are introduced
Packages might be available before the DSA is sent (in the incoming queue or on the mirrors).
Debian is a volunteer-based project.
Debian is licensed with a "no guarantees" clause.
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 Debian Security Advisories, Section 7.2) published
on the 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
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.
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.
This process involve checking the Release file signature against the public key
(available at 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 Package
signing in Debian, Section 7.5.
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.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
Securing Debian Manual
Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000jfs@debian.org