Securing Debian Manual ---------------------- Javier Ferna'ndez-Sanguino Pen~a Section 1.1, `Authors' Version: 3.12, Mon, 07 Jan 2008 19:32:39 +0100 ------------------------------------------------------------------------------- Abstract -------- This document describes security in the Debian project and in the Debian operating system. Starting with the process of securing and hardening the default Debian GNU/Linux distribution installation, it also covers some of the common tasks to set up a secure network environment using Debian GNU/Linux, gives additional information on the security tools available and talks about how security is enforced in Debian by the security and audit team. Copyright Notice ---------------- Copyright (C) 2002-2007 Javier Fernández-Sanguino Peña Copyright (C) 2001 Alexander Reelsen, Javier Fernández-Sanguino Peña Copyright (C) 2000 Alexander Reelsen Some sections are copyright (C) their respective authors, for details please refer to Section 1.7, `Credits and thanks!'. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 (http://www.gnu.org/copyleft/gpl.html) or any later version published by the Free Software Foundation. It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English. ------------------------------------------------------------------------------- Contents -------- 1. Introduction 1.1. Authors 1.2. Where to get the manual (and available formats) 1.3. Organizational notes/feedback 1.4. Prior knowledge 1.5. Things that need to be written (FIXME/TODO) 1.6. Changelog/History 1.7. Credits and thanks! 2. Before you begin 2.1. What do you want this system for? 2.2. Be aware of general security problems 2.3. How does Debian handle security? 3. Before and during the installation 3.1. Choose a BIOS password 3.2. Partitioning the system 3.3. Do not plug to the Internet until ready 3.4. Set a root password 3.5. Activate shadow passwords and MD5 passwords 3.6. Run the minimum number of services required 3.7. Install the minimum amount of software required 3.8. Read the Debian security mailing lists 4. After installation 4.1. Subscribe to the Debian Security Announce mailing list 4.2. Execute a security update 4.3. Change the BIOS (again) 4.4. Set a LILO or GRUB password 4.5. Disable root prompt on the initramfs 4.6. Remove root prompt on the kernel 4.7. Restricting console login access 4.8. Restricting system reboots through the console 4.9. Mounting partitions the right way 4.10. Providing secure user access 4.11. Using tcpwrappers 4.12. The importance of logs and alerts 4.13. Adding kernel patches 4.14. Protecting against buffer overflows 4.15. Secure file transfers 4.16. File system limits and control 4.17. Securing network access 4.18. Taking a snapshot of the system 4.19. Other recommendations 5. Securing services running on your system 5.1. Securing ssh 5.2. Securing Squid 5.3. Securing FTP 5.4. Securing access to the X Window System 5.5. Securing printing access (the lpd and lprng issue) 5.6. Securing the mail service 5.7. Securing BIND 5.8. Securing Apache 5.9. Securing finger 5.10. General chroot and suid paranoia 5.11. General cleartext password paranoia 5.12. Disabling NIS 5.13. Securing RPC services 5.14. Adding firewall capabilities 6. Automatic hardening of Debian systems 6.1. Harden 6.2. Bastille Linux 7. Debian Security Infrastructure 7.1. The Debian Security Team 7.2. Debian Security Advisories 7.3. Debian Security Build Infrastructure 7.4. Package signing in Debian 8. Security tools in Debian 8.1. Remote vulnerability assessment tools 8.2. Network scanner tools 8.3. Internal audits 8.4. Auditing source code 8.5. Virtual Private Networks 8.6. Public Key Infrastructure (PKI) 8.7. SSL Infrastructure 8.8. Antivirus tools 8.9. GPG agent 9. Developer's Best Practices for OS Security 9.1. Best practices for security review and design 9.2. Creating users and groups for software daemons 10. Before the compromise 10.1. Keep your system secure 10.2. Do periodic integrity checks 10.3. Set up Intrusion Detection 10.4. Avoiding root-kits 10.5. Genius/Paranoia Ideas --- what you could do 11. After the compromise (incident response) 11.1. General behavior 11.2. Backing up the system 11.3. Contact your local CERT 11.4. Forensic analysis 12. Frequently asked Questions (FAQ) 12.1. Security in the Debian operating system 12.2. My system is vulnerable! (Are you sure?) 12.3. Questions regarding the Debian security team A. The hardening process step by step B. Configuration checklist C. Setting up a stand-alone IDS D. Setting up a bridge firewall D.1. A bridge providing NAT and firewall capabilities D.2. A bridge providing firewall capabilities D.3. Basic IPtables rules E. Sample script to change the default Bind installation. F. Security update protected by a firewall G. `Chroot' environment for `SSH' G.1. Chrooting the ssh users G.2. Chrooting the ssh server H. `Chroot' environment for `Apache' H.1. Introduction H.2. Installing the server H.3. See also ------------------------------------------------------------------------------- 1. Introduction --------------- One of the hardest things about writing security documents is that every case is unique. Two things you have to pay attention to are the threat environment and the security needs of the individual site, host, or network. For instance, the security needs of a home user are completely different from a network in a bank. While the primary threat a home user needs to face is the script kiddie type of cracker, a bank network has to worry about directed attacks. Additionally, the bank has to protect their customer's data with arithmetic precision. In short, every user has to consider the trade-off between usability and security/paranoia. Note that this manual only covers issues relating to software. The best software in the world can't protect you if someone can physically access the machine. You can place it under your desk, or you can place it in a hardened bunker with an army in front of it. Nevertheless the desktop computer can be much more secure (from a software point of view) than a physically protected one if the desktop is configured properly and the software on the protected machine is full of security holes. Obviously, you must consider both issues. This document just gives an overview of what you can do to increase the security of your Debian GNU/Linux system. If you have read other documents regarding Linux security, you will find that there are common issues which might overlap with this document. However, this document does not try to be the ultimate source of information you will be using, it only tries to adapt this same information so that it is meaningful to a Debian GNU/Linux system. Different distributions do some things in different ways (startup of daemons is one example); here, you will find material which is appropriate for Debian's procedures and tools. 1.1. Authors ------------ The current maintainer of this document is Javier Fernández-Sanguino Peña (mailto:jfs@debian.org). Please forward him any comments, additions or suggestions, and they will be considered for inclusion in future releases of this manual. This manual was started as a _HOWTO_ by Alexander Reelsen (mailto:ar@rhwd.de). After it was published on the Internet, Javier Fernández-Sanguino Peña (mailto:jfs@debian.org) incorporated it into the Debian Documentation Project (http://www.debian.org/doc). A number of people have contributed to this manual (all contributions are listed in the changelog) but the following deserve special mention since they have provided significant contributions (full sections, chapters or appendices): * Stefano Canepa * Era Eriksson * Carlo Perassi * Alexandre Ratti * Jaime Robles * Yotam Rubin * Frederic Schutz * Pedro Zorzenon Neto * Oohara Yuuma * Davor Ocelic 1.2. Where to get the manual (and available formats) ---------------------------------------------------- You can download or view the latest version of the Securing Debian Manual from the Debian Documentation Project (http://www.debian.org/doc/manuals/securing-debian-howto/). If you are reading a copy from another site, please check the primary copy in case it provides new information. If you are reading a translation, please review the version the translation refers to to the latest version available. If you find that the version is behind please consider using the original copy or review the Section 1.6, `Changelog/History' to see what has changed. If you want a full copy of the manual you can either download the text version (http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.txt) or the PDF version (http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf) from the Debian Documentation Project's site. These versions might be more useful if you intend to copy the document over to a portable device for offline reading or you want to print it out. Be forewarned, the manual is over two hundred pages long and some of the code fragments, due to the formatting tools used, are not wrapped in the PDF version and might be printed incomplete. The document is also provided in text, html and PDF formats in the harden-doc (http://packages.debian.org/harden-doc) package. Notice, however, that the package maybe not be completely up to date with the document provided on the Debian site (but you can always use the source package to build an updated version yourself). You can also check out the changes introduced in the document by reviewing its version control logs through its CVS server (http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc). 1.3. Organizational notes/feedback ---------------------------------- Now to the official part. At the moment I (Alexander Reelsen) wrote most paragraphs of this manual, but in my opinion this should not stay the case. I grew up and live with free software, it is part of my everyday use and I guess yours, too. I encourage everybody to send me feedback, hints, additions or any other suggestions you might have. If you think, you can maintain a certain section or paragraph better, then write to the document maintainer and you are welcome to do it. Especially if you find a section marked as FIXME, that means the authors did not have the time yet or the needed knowledge about the topic. Drop them a mail immediately. The topic of this manual makes it quite clear that it is important to keep it up to date, and you can do your part. Please contribute. 1.4. Prior knowledge -------------------- The installation of Debian GNU/Linux is not very difficult and you should have been able to install it. If you already have some knowledge about Linux or other Unices and you are a bit familiar with basic security, it will be easier to understand this manual, as this document cannot explain every little detail of a feature (otherwise this would have been a book instead of a manual). If you are not that familiar, however, you might want to take a look at Section 2.2, `Be aware of general security problems' for where to find more in-depth information. 1.5. Things that need to be written (FIXME/TODO) ------------------------------------------------ This section describes all the things that need to be fixed in this manual. Some paragraphs include _FIXME_ or _TODO_ tags describing what content is missing (or what kind of work needs to be done). The purpose of this section is to describe all the things that could be included in the future in the manual, or enhancements that need to be done (or would be interesting to add). If you feel you can provide help in contributing content fixing any element of this list (or the inline annotations), contact the main author (Section 1.1, `Authors'). * Expand the incident response information, maybe add some ideas derived from Red Hat's Security Guide's chapter on incident response (http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/ch-response.html). * Write about remote monitoring tools (to check for system availability) such as `monit', `daemontools' and `mon'. See http://linux.oreillynet.com/pub/a/linux/2002/05/09/sysadminguide.html. * Consider writing a section on how to build Debian-based network appliances (with information such as the base system, `equivs' and FAI). * Check if http://www.giac.org/practical/gsec/Chris_Koutras_GSEC.pdf has relevant info not yet covered here. * Add information on how to set up a laptop with Debian http://www.giac.org/practical/gcux/Stephanie_Thomas_GCUX.pdf. * Add information on how to set up a firewall using Debian GNU/Linux. The section regarding firewalling is oriented currently towards a single system (not protecting others...) also talk on how to test the setup. * Add information on setting up a proxy firewall with Debian GNU/Linux stating specifically which packages provide proxy services (like `xfwp', `ftp-proxy', `redir', `smtpd', `dnrd', `jftpgw', `oops', `pdnsd', `perdition', `transproxy', `tsocks'). Should point to the manual for any other info. Note that `zorp' is now available as a Debian package and _is_ a proxy firewall (they also provide Debian packages upstream). * Information on service configuration with file-rc. * Check all the reference URLs and remove/fix those no longer available. * Add information on available replacements (in Debian) for common servers which are useful for limited functionality. Examples: * local lpr with cups (package)? * remote lrp with lpr * bind with dnrd/maradns * apache with dhttpd/thttpd/wn (tux?) * exim/sendmail with ssmtpd/smtpd/postfix * squid with tinyproxy * ftpd with oftpd/vsftp * ... * More information regarding security-related kernel patches in Debian, including the ones shown above and specific information on how to enable these patches in a Debian system. * Linux Intrusion Detection (`kernel-patch-2.4-lids') * Linux Trustees (in package `trustees') * NSA Enhanced Linux (http://wiki.debian.org/SELinux) * `linux-patch-openswan' * Details of turning off unnecessary network services (besides `inetd'), it is partly in the hardening procedure but could be broadened a bit. * Information regarding password rotation which is closely related to policy. * Policy, and educating users about policy. * More about tcpwrappers, and wrappers in general? * `hosts.equiv' and other major security holes. * Issues with file sharing servers such as Samba and NFS? * suidmanager/dpkg-statoverrides. * lpr and lprng. * Switching off the GNOME IP things. * Talk about pam_chroot (see http://lists.debian.org/debian-security/2002/debian-security-200205/msg00011.html) and its usefulness to limit users. Introduce information related to http://online.securityfocus.com/infocus/1575. `pdmenu', for example is available in Debian (whereas flash is not). * Talk about chrooting services, some more info on http://www.linuxfocus.org/English/January2002/article225.shtml, http://www.nuclearelephant.com/papers/chroot.html, and http://www.linuxsecurity.com/feature_stories/feature_story-99.html. * Talk about programs to make chroot jails. `compartment' and `chrootuid' are waiting in incoming. Some others (makejail, jailer) could also be introduced. * More information regarding log analysis software (i.e. logcheck and logcolorise). * 'advanced' routing (traffic policing is security related). * limiting `ssh' access to running certain commands. * using dpkg-statoverride. * secure ways to share a CD burner among users. * secure ways of providing networked sound in addition to network display capabilities (so that X clients' sounds are played on the X server's sound hardware). * securing web browsers. * setting up ftp over `ssh'. * using crypto loopback file systems. * encrypting the entire file system. * steganographic tools. * setting up a PKA for an organization. * using LDAP to manage users. There is a HOWTO of ldap+kerberos for Debian at http://www.bayour.com written by Turbo Fredrikson. * How to remove information of reduced utility in production systems such as `/usr/share/doc', `/usr/share/man' (yes, security by obscurity). * More information on lcap based on the packages README file (well, not there yet, see Bug #169465 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169465)) and from the article from LWN: Kernel development (http://lwn.net/1999/1202/kernel.php3). * Add Colin's article on how to setup a chroot environment for a full sid system (http://people.debian.org/~walters/chroot.html) * Add information on running multiple `snort' sensors in a given system (check bug reports sent to `snort'). * Add information on setting up a honeypot (`honeyd'). * Describe situation wrt to FreeSwan (orphaned) and OpenSwan. VPN section needs to be rewritten. * Add a specific section about databases, current installation defaults and how to secure access. * Add a section about the usefulness of virtual servers (Xen et al) * Explain how to use some integrity checkers (AIDE, integrit or samhain). The basics are simple and could even explain some configuration improvements. 1.6. Changelog/History ---------------------- 1.6.1. Version 3.13 (November 2007) ----------------------------------- Changes by Javier Fernández-Sanguino Peña. * Change URLs pointing to Bastille Linux since the domain has been purchased by a cybersquatter (http://www.bastille-unix.org/press-release-newname.html). 1.6.2. Version 3.12 (August 2007) --------------------------------- Changes by Javier Fernández-Sanguino Peña. * Update the information related to security updates. Drop the text talking about Tiger and include information on the update-notifier and adept tools (for Desktops) as well as debsecan. Also include some pointers to other tools available. * Divide the firewall applications based on target users and add fireflier to the Desktop firewall applications list. * Remove references to libsafe, it's not in the archive any loger (was removed january 2006) * Fix the location of syslog's configuration, thanks to John Talbut. 1.6.3. Version 3.11 (January 2007) ---------------------------------- Changes by Javier Fernández-Sanguino Peña. Thanks go to Francesco Poli for his extensive review of the document. * Remove most references to the woody release as it is no longer available (in the archive) and security support for it is no longer available. * Describe how to restrict users so that they can only do file transfers. * Added a note regarding the debian-private declasiffication decission. * Updated link of incident handling guides. * Added a note saying that development tools (compilers, etc.) are not installed now in the default 'etch' installation. * Fix references to the master security server. * Add pointers to additional APT-secure documentation * Improve the description of APT signatures * Comment out some things which are not yet final related to the mirror's official public keys. * Fixed name of the Debian Testing Security Team. * Remove reference to sarge in an example. * Update the antivirus section, clamav is now available on the release. Also mention the f-prot installer * Removes all references to freeswan as it is obsolete * Describe issues related to ruleset changes to the firewall if done remotely and provide some tips (in footnotes) * Update the information related to the IDS installation, mention BASE and the need to setup a logging database. * Rewrite the "running bind as a non-root user" section as this no longer applies to Bind9. Also remove the reference to the init.d script since the changes need to be done through /etc/default. * Remove the obsolete way to setup iptables rulesets as woody is no longer supported. * Revert the advice regarding LOG_UNKFAIL_ENAB it should be set to 'no' (as per default). * Added more information related to updating the system with desktop tools (including update-notifier) and describe aptitude usage to update the system. Also note that dselect is deprecated. * Updated the contents of the FAQ and remove redundant paragraphs. * Review and update the section related to forensic analysis of malware. * Remove or fix some dead links. * Fix many typos and gramatical errors reported by Francesco Poli. 1.6.4. Version 3.10 (November 2006) ----------------------------------- Changes by Javier Fernández-Sanguino Peña * Provide examples using apt-cache's rdepends as suggested by Ozer Sarilar. * Fix location of Squid's user's manual because of its relocation as notified by Oskar Pearson (its maintainer). * Fix information regarding umask, it's logins.defs (and not limits.conf) where this can be configured for all login connections. Also state what is Debian's default and what would be a more restrictive value for both users and root. Thanks to Reinhard Tartler for spotting the bug. 1.6.5. Version 3.9 (October 2006) --------------------------------- Changes by Javier Fernández-Sanguino Peña * Add information on how to track security vulnerabilities and add references to the Debian Testing Security Tracker. * Add more information on the security support for testing. * Fix a large number of typos with a patch provided by Simon Brandmair. * Added section on how to disable root prompt on initramfs provided by Max Attems. * Remove references to queso. * Note that testing is now security-supported in the introduction. 1.6.6. Version 3.8 (July 2006) ------------------------------ Changes by Javier Fernández-Sanguino Peña * Rewrote the information on how to setup ssh chroots to clarify the different options available, thank to Bruce Park for bringing up the different mistakes in this appendix. * Fix lsof call as suggested by Christophe Sahut. * Include patches for typo fixes from Uwe Hermann. * Fix typo in reference spotted by Moritz Naumann. 1.6.7. Version 3.7 (April 2006) ------------------------------- Changes by Javier Fernández-Sanguino Peña * Add a section on Debian Developer's best practices for security. * Ammended firewall script with comments from WhiteGhost. 1.6.8. Version 3.6 (March 2006) ------------------------------- Changes by Javier Fernández-Sanguino Peña * Included a patch from Thomas Sjögren which describes that `noexec' works as expected with "new" kernels, adds information regarding tempfile handling, and some new pointers to external documentation. * Add a pointer to Dan Farmer's and Wietse Venema's forensic discovery web site, as suggested by Freek Dijkstra, and expanded a little bit the forensic analysis section with more pointers. * Fixed URL of Italy's CERT, thanks to Christoph Auer. * Reuse Joey Hess' information at the wiki on secure apt and introduce it in the infrastructure section. * Review sections referring to old versions (woody or potato) * Fix some cosmetic issues with patch from Simon Brandmair. * Included patches from Carlo Perassi: acl patches are obsolete, openwall patches are obsolete too, removed fixme notes about 2.2 and 2.4 series kernels, hap is obsolete (and not present in WNPP), remove references to Immunix (StackGuard is now in Novell's hands), and fix a FIXME about the use of bsign or elfsign. * Updated references to SElinux web pages to point to the Wiki (currently the most up to date source of information) * Include file tags and make a more consistent use of "MD5 sum" with a patch from Jens Seidel. * Patch from Joost van Baal improving the information on the firewall section (pointing to the wiki instead of listing all firewall packages available) (Closes: #339865) * Review the FAQ section on vulnerability stats, thanks to Carlos Galisteo de Cabo for pointing out that it was out of date. * Use the quote from the Social Contract 1.1 instead of 1.0 as suggested by Francesco Poli. 1.6.9. Version 3.5 (November 2005) ---------------------------------- Changes by Javier Fernández-Sanguino Peña * Note on the SSH section that the chroot will not work if using the nodev option in the partition and point to the latest ssh packages with the chroot patch, thanks to Lutz Broedel for pointing these issues out. * Fix typo spotted by Marcos Roberto Greiner (md5sum should be sha1sum in code snippet) * Included Jens Seidel's patch fixing a number of package names and typos. * Slightly update of the tools section, removed tools no longer available and added some new ones. * Rewrite parts of the section related to where to find this document and what formats are available (the website does provide a PDF version). Also note that copies on other sites and translations might be obsolete (many of the Google hits for the manual in other sites are actually out of date). 1.6.10. Version 3.4 (August-September 2005) ------------------------------------------- Changes by Javier Fernández-Sanguino Peña * Improved the after installation security enhancements related to kernel configuration for network level protection with a sysctl.conf file provided by Will Moy. * Improved the gdm section, thanks to Simon Brandmair. * Typo fixes from Frédéric Bothamy and Simon Brandmair. * Improvements in the after installation sections related to how to generate the MD5 (or SHA-1) sums of binaries for periodic review. * Updated the after installation sections regarding checksecurity configuration (was out of date). 1.6.11. Version 3.3 (June 2005) ------------------------------- Changes by Javier Fernández-Sanguino Peña * Added a code snippet to use grep-available to generate the list of packages depending on Perl. As requested in #302470. * Rewrite of the section on network services (which ones are installed and how to disable them) * Added more information to the honeypot deployment section mentioning useful Debian packages. 1.6.12. Version 3.2 (March 2005) -------------------------------- Changes by Javier Fernández-Sanguino Peña * Expanded the PAM configuration limits section. * Added information on how to use pam_chroot for openssh (based on pam_chroot's README) * Fixed some minor issues reported by Dan Jacobson. * Updated the kernel patches information partially based on a patch from Carlo Perassi and also by adding deprecation notes and new kernel patches available (adamantix) * Included patch from Simon Brandmair that fixes a sentence related to login failures in terminal. * Added Mozilla/Thunderbird to the valid GPG agents as suggested by Kapolnai Richard. * Expanded the section on security updates mentioning library and kernel updates and how to detect when services need to be restarted. * Rewrote the firewall section, moved the information that applies to woody down and expand the other sections including some information on how to manually set the firewall (with a sample script) and how to test the firewall configuration. * Added some information preparing for the 3.1 release. * Added more detailed information on kernel upgrades, specifically targeted at those that used the old installation system. * Added a small section on the experimental apt 0.6 release which provides package signing checks. Moved old content to the section and also added a pointer to changes made in aptitude. * Typo fixes spotted by Frédéric Bothamy 1.6.13. Version 3.1 (January 2005) ---------------------------------- Changes by Javier Fernández-Sanguino Peña * Added clarification to ro /usr with patch from Joost van Baal * Apply patch from Jens Seidel fixing many typos. * FreeSWAN is dead, long live OpenSWAN. * Added information on restricting access to RPC services (when they cannot be disabled) also included patch provided by Aarre Laakso. * Update aj's apt-check-sigs script. * Apply patch Carlo Perassi fixing URLs. * Apply patch from Davor Ocelic fixing many errors, typos, urls, grammar and FIXMEs. Also adds some additional information to some sections. * Rewrote the section on user auditing, highlight the usage of script which does not have some of the issues associated to shell history. 1.6.14. Version 3.0 (December 2004) ----------------------------------- Changes by Javier Fernández-Sanguino Peña * Rewrote the user-auditing information and include examples on how to use script. 1.6.15. Version 2.99 (March 2004) --------------------------------- Changes by Javier Fernández-Sanguino Peña * Added information on references in DSAs and CVE-Compatibility. * Added information on apt 0.6 (apt-secure merge in experimental) * Fixed location of Chroot daemons HOWTO as suggested by Shuying Wang. * Changed APACHECTL line in the Apache chroot example (even if its not used at all) as suggested by Leonard Norrgard. * Added a footnote regarding hardlink attacks if partitions are not setup properly. * Added some missing steps in order to run bind as named as provided by Jeffrey Prosa. * Added notes about Nessus and Snort out-of-dateness in woody and availability of backported packages. * Added a chapter regarding periodic integrity test checks. * Clarified the status of testing regarding security updates. (Debian bug 233955) * Added more information regarding expected contents in securetty (since it's kernel specific). * Added pointer to snoopylogger (Debian bug 179409) * Added reference to guarddog (Debian bug 170710) * `apt-ftparchive' is in `apt-utils', not in `apt' (thanks to Emmanuel Chantreau for pointing this out) * Removed jvirus from AV list. 1.6.16. Version 2.98 (December 2003) ------------------------------------ Changes by Javier Fernández-Sanguino Peña * Fixed URL as suggested by Frank Lichtenheld. * Fixed PermitRootLogin typo as suggested by Stefan Lindenau. 1.6.17. Version 2.97 (September 2003) ------------------------------------- Changes by Javier Fernández-Sanguino Peña * Added those that have made the most significant contributions to this manual (please mail me if you think you should be in the list and are not). * Added some blurb about FIXME/TODOs * Moved the information on security updates to the beginning of the section as suggested by Elliott Mitchell. * Added grsecurity to the list of kernel-patches for security but added a footnote on the current issues with it as suggested by Elliott Mitchell. * Removed loops (echo to 'all') in the kernel's network security script as suggested by Elliott Mitchell. * Added more (up-to-date) information in the antivirus section. * Rewrote the buffer overflow protection section and added more information on patches to the compiler to enable this kind of protection. 1.6.18. Version 2.96 (August 2003) ---------------------------------- Changes by Javier Fernández-Sanguino Peña * Removed (and then re-added) appendix on chrooting Apache. The appendix is now dual-licensed. 1.6.19. Version 2.95 (June 2003) -------------------------------- Changes by Javier Fernández-Sanguino Peña * Fixed typos spotted by Leonard Norrgard. * Added a section on how to contact CERT for incident handling (#after-compromise) * More information on setting up a Squid proxy. * Added a pointer and removed a FIXME thanks to Helge H. F. * Fixed a typo (save_inactive) spotted by Philippe Faes. * Fixed several typos spotted by Jaime Robles. 1.6.20. Version 2.94 (April 2003) --------------------------------- Changes by Javier Fernández-Sanguino Peña * Following Maciej Stachura's suggestions I've expanded the section on limiting users. * Fixed typo spotted by Wolfgang Nolte. * Fixed links with patch contributed by Ruben Leote Mendes. * Added a link to David Wheeler's excellent document on the footnote about counting security vulnerabilities. 1.6.21. Version 2.93 (March 2003) --------------------------------- Changes made by Frédéric Schütz. * rewrote entirely the section of ext2 attributes (lsattr/chattr) 1.6.22. Version 2.92 (February 2003) ------------------------------------ Changes by Javier Fernández-Sanguino Peña and Frédéric Schütz. * Merge section 9.3 ("useful kernel patches") into section 4.13 ("Adding kernel patches"), and added some content. * Added a few more TODOs * Added information on how to manually check for updates and also about cron-apt. That way Tiger is not perceived as the only way to do automatic update checks. * Slightly rewrite of the section on executing a security updates due to Jean-Marc Ranger comments. * Added a note on Debian's installation (which will suggest the user to execute a security update right after installation) 1.6.23. Version 2.91 (January/February 2003) -------------------------------------------- Changes by Javier Fernández-Sanguino Peña (me). * Added a patch contributed by Frédéric Schütz. * Added a few more references on capabilities thanks to Frédéric. * Slight changes in the bind section adding a reference to BIND's 9 online documentation and proper references in the first area (Hi Pedro!) * Fixed the changelog date - new year :-) * Added a reference to Colin's articles for the TODOs. * Removed reference to old ssh+chroot patches. * More patches from Carlo Perassi. * Typo fixes (recursive in Bind is recursion), pointed out by Maik Holtkamp. 1.6.24. Version 2.9 (December 2002) ----------------------------------- Changes by Javier Fernández-Sanguino Peña (me). * Reorganized the information on chroot (merged two sections, it didn't make much sense to have them separated) * Added the notes on chrooting Apache provided by Alexandre Ratti. * Applied patches contributed by Guillermo Jover. 1.6.25. Version 2.8 (November 2002) ----------------------------------- Changes by Javier Fernández-Sanguino Peña (me). * Applied patches from Carlo Perassi, fixes include: re-wrapping the lines, URL fixes, and fixed some FIXMEs * Updated the contents of the Debian security team FAQ. * Added a link to the Debian security team FAQ and the Debian Developer's reference, the duplicated sections might (just might) be removed in the future. * Fixed the hand-made auditing section with comments from Michal Zielinski. * Added links to wordlists (contributed by Carlo Perassi) * Fixed some typos (still many around). * Fixed TDP links as suggested by John Summerfield. 1.6.26. Version 2.7 (October 2002) ---------------------------------- Changes by Javier Fernández-Sanguino Peña (me). Note: I still have a lot of pending changes in my mailbox (which is currently about 5 Mbs in size). * Some typo fixes contributed by Tuyen Dinh, Bartek Golenko and Daniel K. Gebhart. * Note regarding /dev/kmem rootkits contributed by Laurent Bonnaud * Fixed typos and FIXMEs contributed by Carlo Perassi. 1.6.27. Version 2.6 (September 2002) ------------------------------------ Changes by Chris Tillman, tillman@voicetrak.com. * Changed around to improve grammar/spelling. * s/host.deny/hosts.deny/ (1 place) * Applied Larry Holish's patch (quite big, fixes a lot of FIXMEs) 1.6.28. Version 2.5 (September 2002) ------------------------------------ Changes by Javier Fernández-Sanguino Peña (me). * Fixed minor typos submitted by Thiemo Nagel. * Added a footnote suggested by Thiemo Nagel. * Fixed an URL link. 1.6.29. Version 2.5 (August 2002) --------------------------------- Changes by Javier Fernández-Sanguino Peña (me). There were many things waiting on my inbox (as far back as February) to be included, so I'm going to tag this the _back from honeymoon_ release :) * Applied a patch contributed by Philipe Gaspar regarding the Squid which also kills a FIXME. * Yet another FAQ item regarding service banners taken from the debian-security mailing list (thread "Telnet information" started 26th July 2002). * Added a note regarding use of CVE cross references in the _How much time does the Debian security team..._ FAQ item. * Added a new section regarding ARP attacks contributed by Arnaud "Arhuman" Assad. * New FAQ item regarding dmesg and console login by the kernel. * Small tidbits of information to the signature-checking issues in packages (it seems to not have gotten past beta release). * New FAQ item regarding vulnerability assessment tools false positives. * Added new sections to the chapter that contains information on package signatures and reorganized it as a new _Debian Security Infrastructure_ chapter. * New FAQ item regarding Debian vs. other Linux distributions. * New section on mail user agents with GPG/PGP functionality in the security tools chapter. * Clarified how to enable MD5 passwords in woody, added a pointer to PAM as well as a note regarding the max definition in PAM. * Added a new appendix on how to create chroot environments (after fiddling a bit with makejail and fixing, as well, some of its bugs), integrated duplicate information in all the appendix. * Added some more information regarding `SSH' chrooting and its impact on secure file transfers. Some information has been retrieved from the debian-security mailing list (June 2002 thread: _secure file transfers_). * New sections on how to do automatic updates on Debian systems as well as the caveats of using testing or unstable regarding security updates. * New section regarding keeping up to date with security patches in the _Before compromise_ section as well as a new section about the debian-security-announce mailing list. * Added information on how to automatically generate strong passwords. * New section regarding login of idle users. * Reorganized the securing mail server section based on the _Secure/hardened/minimal Debian (or "Why is the base system the way it is?")_ thread on the debian-security mailing list (May 2002). * Reorganized the section on kernel network parameters, with information provided in the debian-security mailing list (May 2002, _syn flood attacked?_ thread) and added a new FAQ item as well. * New section on how to check users passwords and which packages to install for this. * New section on PPTP encryption with Microsoft clients discussed in the debian-security mailing list (April 2002). * Added a new section describing what problems are there when binding any given service to a specific IP address, this information was written based on the Bugtraq mailing list in the thread: _Linux kernel 2.4 "weak end host" issue (previously discussed on debian-security as "arp problem")_ (started on May 9th 2002 by Felix von Leitner). * Added information on `ssh' protocol version 2. * Added two subsections related to Apache secure configuration (the things specific to Debian, that is). * Added a new FAQ related to raw sockets, one related to /root, an item related to users' groups and another one related to log and configuration files permissions. * Added a pointer to a bug in libpam-cracklib that might still be open... (need to check) * Added more information regarding forensics analysis (pending more information on packet inspection tools such as `tcpflow'). * Changed the "what should I do regarding compromise" into a bullet list and included some more stuff. * Added some information on how to set up the Xscreensaver to lock the screen automatically after the configured timeout. * Added a note related to the utilities you should not install in the system. Included a note regarding Perl and why it cannot be easily removed in Debian. The idea came after reading Intersect's documents regarding Linux hardening. * Added information on lvm and journalling file systems, ext3 recommended. The information there might be too generic, however. * Added a link to the online text version (check). * Added some more stuff to the information on firewalling the local system, triggered by a comment made by Hubert Chan in the mailing list. * Added more information on PAM limits and pointers to Kurt Seifried's documents (related to a post by him to Bugtraq on April 4th 2002 answering a person that had ``discovered'' a vulnerability in Debian GNU/Linux related to resource starvation). * As suggested by Julián Muñoz, provided more information on the default Debian umask and what a user can access if he has been given a shell in the system (scary, huh?) * Included a note in the BIOS password section due to a comment from Andreas Wohlfeld. * Included patches provided by Alfred E. Heggestad fixing many of the typos still present in the document. * Added a pointer to the changelog in the Credits section since most people who contribute are listed here (and not there). * Added a few more notes to the chattr section and a new section after installation talking about system snapshots. Both ideas were contributed by Kurt Pomeroy. * Added a new section after installation just to remind users to change the boot-up sequence. * Added some more TODO items provided by Korn Andras. * Added a pointer to the NIST's guidelines on how to secure DNS provided by Daniel Quinlan. * Added a small paragraph regarding Debian's SSL certificates infrastructure. * Added Daniel Quinlan's suggestions regarding `ssh' authentication and exim's relay configuration. * Added more information regarding securing bind including changes suggested by Daniel Quinlan and an appendix with a script to make some of the changes commented on in that section. * Added a pointer to another item regarding Bind chrooting (needs to be merged). * Added a one liner contributed by Cristian Ionescu-Idbohrn to retrieve packages with tcpwrappers support. * Added a little bit more info on Debian's default PAM setup. * Included a FAQ question about using PAM to provide services without shell accounts. * Moved two FAQ items to another section and added a new FAQ regarding attack detection (and compromised systems). * Included information on how to set up a bridge firewall (including a sample Appendix). Thanks to Francois Bayart who sent this to me in March. * Added a FAQ regarding the syslogd's _MARK_ _heartbeat_ from a question answered by Noah Meyerhans and Alain Tesio in December 2001. * Included information on buffer overflow protection as well as some information on kernel patches. * Added more information (and reorganized) the firewall section. Updated the information regarding the iptables package and the firewall generators available. * Reorganized the information regarding log checking, moved logcheck information from host intrusion detection to that section. * Added some information on how to prepare a static package for bind for chrooting (untested). * Added a FAQ item regarding some specific servers/services (could be expanded with some of the recommendations from the debian-security list). * Added some information on RPC services (and when it's necessary). * Added some more information on capabilities (and what lcap does). Is there any good documentation on this? I haven't found any documentation on my 2.4 kernel. * Fixed some typos. 1.6.30. Version 2.4 ------------------- Changes by Javier Fernández-Sanguino Peña. * Rewritten part of the BIOS section. 1.6.31. Version 2.3 ------------------- Changes by Javier Fernández-Sanguino Peña. * Wrapped most file locations with the file tag. * Fixed typo noticed by Edi Stojicevi. * Slightly changed the remote audit tools section. * Added some todo items. * Added more information regarding printers and cups config file (taken from a thread on debian-security). * Added a patch submitted by Jesus Climent regarding access of valid system users to Proftpd when configured as anonymous server. * Small change on partition schemes for the special case of mail servers. * Added Hacking Linux Exposed to the books section. * Fixed directory typo noticed by Eduardo Pérez Ureta. * Fixed /etc/ssh typo in checklist noticed by Edi Stojicevi. 1.6.32. Version 2.3 ------------------- Changes by Javier Fernández-Sanguino Peña. * Fixed location of dpkg conffile. * Remove Alexander from contact information. * Added alternate mail address. * Fixed Alexander mail address (even if commented out). * Fixed location of release keys (thanks to Pedro Zorzenon for pointing this out). 1.6.33. Version 2.2 ------------------- Changes by Javier Fernández-Sanguino Peña. * Fixed typos, thanks to Jamin W. Collins. * Added a reference to apt-extracttemplate manpage (documents the APT::ExtractTemplate config). * Added section about restricted SSH. Information based on that posted by Mark Janssen, Christian G. Warden and Emmanuel Lacour on the debian-security mailing list. * Added information on antivirus software. * Added a FAQ: su logs due to the cron running as root. 1.6.34. Version 2.1 ------------------- Changes by Javier Fernández-Sanguino Peña. * Changed FIXME from lshell thanks to Oohara Yuuma. * Added package to sXid and removed comment since it *is* available. * Fixed a number of typos discovered by Oohara Yuuma. * ACID is now available in Debian (in the acidlab package) thanks to Oohara Yuuma for noticing. * Fixed LinuxSecurity links (thanks to Dave Wreski for telling). 1.6.35. Version 2.0 ------------------- Changes by Javier Fernández-Sanguino Peña. I wanted to change to 2.0 when all the FIXMEs were fixed but I ran out of 1.9X numbers :( * Converted the HOWTO into a Manual (now I can properly say RTFM) * Added more information regarding tcp wrappers and Debian (now many services are compiled with support for them so it's no longer an `inetd' issue). * Clarified the information on disabling services to make it more consistent (rpc info still referred to update-rc.d) * Added small note on lprng. * Added some more info on compromised servers (still very rough) * Fixed typos reported by Mark Bucciarelli. * Added some more steps in password recovery to cover the cases when the admin has set paranoid-mode=on. * Added some information to set paranoid-mode=on when login in console. * New paragraph to introduce service configuration. * Reorganized the _After installation_ section so it is more broken up into several issues and it's easier to read. * Wrote information on how to set up firewalls with the standard Debian 3.0 setup (iptables package). * Small paragraph explaining why installing connected to the Internet is not a good idea and how to avoid this using Debian tools. * Small paragraph on timely patching referencing to IEEE paper. * Appendix on how to set up a Debian snort box, based on what Vladimir sent to the debian-security mailing list (September 3rd 2001) * Information on how logcheck is set up in Debian and how it can be used to set up HIDS. * Information on user accounting and profile analysis. * Included apt.conf configuration for read-only /usr copied from Olaf Meeuwissen's post to the debian-security mailing list * New section on VPN with some pointers and the packages available in Debian (needs content on how to set up the VPNs and Debian-specific issues), based on Jaroslaw Tabor's and Samuli Suonpaa's post to debian-security. * Small note regarding some programs to automatically build chroot jails * New FAQ item regarding identd based on a discussion in the debian-security mailing list (February 2002, started by Johannes Weiss). * New FAQ item regarding `inetd' based on a discussion in the debian-security mailing list (February 2002). * Introduced note on rcconf in the "disabling services" section. * Varied the approach regarding LKM, thanks to Philipe Gaspar * Added pointers to CERT documents and Counterpane resources 1.6.36. Version 1.99 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added a new FAQ item regarding time to fix security vulnerabilities. * Reorganized FAQ sections. * Started writing a section regarding firewalling in Debian GNU/Linux (could be broadened a bit) * Fixed typos sent by Matt Kraai * Fixed DNS information * Added information on whisker and nbtscan to the auditing section. * Fixed some wrong URLs 1.6.37. Version 1.98 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added a new section regarding auditing using Debian GNU/Linux. * Added info regarding finger daemon taken from the security mailing list. 1.6.38. Version 1.97 -------------------- Changes by Javier Fernández-Sanguino Peña. * Fixed link for Linux Trustees * Fixed typos (patches from Oohara Yuuma and Pedro Zorzenon) 1.6.39. Version 1.96 -------------------- Changes by Javier Fernández-Sanguino Peña. * Reorganized service installation and removal and added some new notes. * Added some notes regarding using integrity checkers as intrusion detection tools. * Added a chapter regarding package signatures. 1.6.40. Version 1.95 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added notes regarding Squid security sent by Philipe Gaspar. * Fixed rootkit links thanks to Philipe Gaspar. 1.6.41. Version 1.94 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added some notes regarding Apache and Lpr/lpng. * Added some information regarding noexec and read-only partitions. * Rewrote how users can help in Debian security issues (FAQ item). 1.6.42. Version 1.93 -------------------- Changes by Javier Fernández-Sanguino Peña. * Fixed location of mail program. * Added some new items to the FAQ. 1.6.43. Version 1.92 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added a small section on how Debian handles security * Clarified MD5 passwords (thanks to `rocky') * Added some more information regarding harden-X from Stephen van Egmond * Added some new items to the FAQ 1.6.44. Version 1.91 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added some forensics information sent by Yotam Rubin. * Added information on how to build a honeynet using Debian GNU/Linux. * Added some more TODOS. * Fixed more typos (thanks Yotam!) 1.6.45. Version 1.9 ------------------- Changes by Javier Fernández-Sanguino Peña. * Added patch to fix misspellings and some new information (contributed by Yotam Rubin) * Added references to other online (and offline) documentation both in a section (see Section 2.2, `Be aware of general security problems') by itself and inline in some sections. * Added some information on configuring Bind options to restrict access to the DNS server. * Added information on how to automatically harden a Debian system (regarding the harden package and bastille). * Removed some done TODOs and added some new ones. 1.6.46. Version 1.8 ------------------- Changes by Javier Fernández-Sanguino Peña. * Added the default user/group list provided by Joey Hess to the debian-security mailing list. * Added information on LKM root-kits (Section 10.4.1, `Loadable Kernel Modules (LKM)') contributed by Philipe Gaspar. * Added information on Proftp contributed by Emmanuel Lacour. * Recovered the checklist Appendix from Era Eriksson. * Added some new TODO items and removed other fixed ones. * Manually included Era's patches since they were not all included in the previous version. 1.6.47. Version 1.7 ------------------- Changes by Era Eriksson. * Typo fixes and wording changes Changes by Javier Fernández-Sanguino Peña. * Minor changes to tags in order to keep on removing the tt tags and substitute prgn/package tags for them. 1.6.48. Version 1.6 ------------------- Changes by Javier Fernández-Sanguino Peña. * Added pointer to document as published in the DDP (should supersede the original in the near future) * Started a mini-FAQ (should be expanded) with some questions recovered from my mailbox. * Added general information to consider while securing. * Added a paragraph regarding local (incoming) mail delivery. * Added some pointers to more information. * Added information regarding the printing service. * Added a security hardening checklist. * Reorganized NIS and RPC information. * Added some notes taken while reading this document on my new Visor :) * Fixed some badly formatted lines. * Fixed some typos. * Added a Genius/Paranoia idea contributed by Gaby Schilders. 1.6.49. Version 1.5 ------------------- Changes by Josip Rodin and Javier Fernández-Sanguino Peña. * Added paragraphs related to BIND and some FIXMEs. 1.6.50. Version 1.4 ------------------- * Small setuid check paragraph * Various minor cleanups * Found out how to use `sgml2txt -f' for the txt version 1.6.51. Version 1.3 ------------------- * Added a security update after installation paragraph * Added a proftpd paragraph * This time really wrote something about XDM, sorry for last time 1.6.52. Version 1.2 ------------------- * Lots of grammar corrections by James Treacy, new XDM paragraph 1.6.53. Version 1.1 ------------------- * Typo fixes, miscellaneous additions 1.6.54. Version 1.0 ------------------- * Initial release 1.7. Credits and thanks! ------------------------ * Alexander Reelsen wrote the original document. * Javier Fernández-Sanguino added more info to the original doc. * Robert van der Meulen provided the quota paragraphs and many good ideas. * Ethan Benson corrected the PAM paragraph and had some good ideas. * Dariusz Puchalak contributed some information to several chapters. * Gaby Schilders contributed a nice Genius/Paranoia idea. * Era Eriksson smoothed out the language in a lot of places and contributed the checklist appendix. * Philipe Gaspar wrote the LKM information. * Yotam Rubin contributed fixes for many typos as well as information regarding bind versions and MD5 passwords. * Francois Bayart provided the appendix describing how to set up a bridge firewall. * Joey Hess wrote the section describing how Secure Apt works on the Debian Wiki (http://wiki.debian.org/SecureApt). * Martin F. Krafft wrote some information on his blog regarding fingerprint verification which was also reused for the Secure Apt section. * Francesco Poli did an extensive review of the manual and provided quite a lot of bug reports and typo fixes which improved and helped update the document. * All the people who made suggestions for improvements that (eventually) were included here (see Section 1.6, `Changelog/History'). * (Alexander) All the folks who encouraged me to write this HOWTO (which was later turned into a manual). * The whole Debian project. ------------------------------------------------------------------------------- 2. Before you begin ------------------- 2.1. What do you want this system for? -------------------------------------- Securing Debian is not very different from securing any other system; in order to do it properly, you must first decide what you intend to do with it. After this, you will have to consider that the following tasks need to be taken care of if you want a really secure system. You will find that this manual is written from the bottom up, that is, you will read some information on tasks to do before, during and after you install your Debian system. The tasks can also be thought of as: * Decide which services you need and limit your system to those. This includes deactivating/uninstalling unneeded services, and adding firewall-like filters, or tcpwrappers. * Limit users and permissions in your system. * Harden offered services so that, in the event of a service compromise, the impact to your system is minimized. * Use appropriate tools to guarantee that unauthorized use is detected so that you can take appropriate measures. 2.2. Be aware of general security problems ------------------------------------------ The following manual does not (usually) go into the details on why some issues are considered security risks. However, you might want to have a better background regarding general UNIX and (specific) Linux security. Take some time to read over security related documents in order to make informed decisions when you are encountered with different choices. Debian GNU/Linux is based on the Linux kernel, so much of the information regarding Linux, as well as from other distributions and general UNIX security also apply to it (even if the tools used, or the programs available, differ). Some useful documents include: * The Linux Security HOWTO (http://www.tldp.org/HOWTO/Security-HOWTO/) (also available at LinuxSecurity (http://www.linuxsecurity.com/docs/LDP/Security-HOWTO.html)) is one of the best references regarding general Linux security. * The Security Quick-Start HOWTO for Linux (http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/) is also a very good starting point for novice users (both to Linux and security). * The Linux Security Administrator's Guide (http://seifried.org/lasg/) is a complete guide that touches all the issues related to security in Linux, from kernel security to VPNs. Note that it has not been updated since 2001, but some information is still relevant. [1] * Kurt Seifried's Securing Linux Step by Step (http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html). * In Securing and Optimizing Linux: RedHat Edition (http://www.tldp.org/links/p_books.html#securing_linux) you can find a similar document to this manual but related to Red Hat, some of the issues are not distribution-specific and also apply to Debian. * Another Red Hat related document is EAL3 Evaluated Configuration Guide for Red Hat Enterprise (http://ltp.sourceforge.net/docs/RHEL-EAL3-Configuration-Guide.pdf). * IntersectAlliance has published some documents that can be used as reference cards on how to harden Linux servers (and their services), the documents are available at their site (http://www.intersectalliance.com/projects/index.html). * For network administrators, a good reference for building a secure network is the Securing your Domain HOWTO (http://www.linuxsecurity.com/docs/LDP/Securing-Domain-HOWTO/). * If you want to evaluate the programs you are going to use (or want to build up some new ones) you should read the Secure Programs HOWTO (http://www.tldp.org/HOWTO/Secure-Programs-HOWTO/) (master copy is available at http://www.dwheeler.com/secure-programs/, it includes slides and talks from the author, David Wheeler) * If you are considering installing firewall capabilities, you should read the Firewall HOWTO (http://www.tldp.org/HOWTO/Firewall-HOWTO.html) and the IPCHAINS HOWTO (http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html) (for kernels previous to 2.4). * Finally, a good card to keep handy is the Linux Security ReferenceCard (http://www.linuxsecurity.com/docs/QuickRefCard.pdf). In any case, there is more information regarding the services explained here (NFS, NIS, SMB...) in many of the HOWTOs of the The Linux Documentation Project (http://www.tldp.org/). Some of these documents speak on the security side of a given service, so be sure to take a look there too. The HOWTO documents from the Linux Documentation Project are available in Debian GNU/Linux through the installation of the `doc-linux-text' (text version) or `doc-linux-html' (HTML version). After installation these documents will be available at the `/usr/share/doc/HOWTO/en-txt' and `/usr/share/doc/HOWTO/en-html' directories, respectively. Other recommended Linux books: * Maximum Linux Security : A Hacker's Guide to Protecting Your Linux Server and Network. Anonymous. Paperback - 829 pages. Sams Publishing. ISBN: 0672313413. July 1999. * Linux Security By John S. Flowers. New Riders; ISBN: 0735700354. March 1999. * Hacking Linux Exposed (http://www.linux.org/books/ISBN_0072127732.html) By Brian Hatch. McGraw-Hill Higher Education. ISBN 0072127732. April, 2001 Other books (which might be related to general issues regarding UNIX and security and not Linux specific): * Practical Unix and Internet Security (2nd Edition) (http://www.ora.com/catalog/puis/noframes.html) Garfinkel, Simpson, and Spafford, Gene; O'Reilly Associates; ISBN 0-56592-148-8; 1004pp; 1996. * Firewalls and Internet Security Cheswick, William R. and Bellovin, Steven M.; Addison-Wesley; 1994; ISBN 0-201-63357-4; 320pp. Some useful web sites to keep up to date regarding security: * NIST Security Guidelines (http://csrc.nist.gov/fasp/index.html). * Security Focus (http://www.securityfocus.com) the server that hosts the Bugtraq vulnerability database and list, and provides general security information, news and reports. * Linux Security (http://www.linuxsecurity.com/). General information regarding Linux security (tools, news...). Most useful is the main documentation (http://www.linuxsecurity.com/resources/documentation-1.html) page. * Linux firewall and security site (http://www.linux-firewall-tools.com/linux/). General information regarding Linux firewalls and tools to control and administrate them. [1] At a given time it was superseded by the "Linux Security Knowledge Base". This documentation is also provided in Debian through the `lskb' package. Now it's back as the _Lasg_ again. 2.3. How does Debian handle security? ------------------------------------- Just so you have a general overview of security in Debian GNU/Linux you should take note of the different issues that Debian tackles in order to provide an overall secure system: * Debian problems are always handled openly, even security related. Security issues are discussed openly on the debian-security mailing list. Debian Security Advisories (DSAs) are sent to public mailing lists (both internal and external) and are published on the public server. As the Debian Social Contract (http://www.debian.org/social_contract) states: _We will not hide problems_ _We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others._ * Debian follows security issues closely. The security team checks many security related sources, the most important being Bugtraq (http://www.securityfocus.com/cgi-bin/vulns.pl), on the lookout for packages with security issues that might be included in Debian. * Security updates are the first priority. When a security problem arises in a Debian package, the security update is prepared as fast as possible and distributed for our stable, testing and unstable releases, including all architectures. * Information regarding security is centralized in a single point, http://security.debian.org/. * Debian is always trying to improve the overall security of the distribution by starting new projects, such as automatic package signature verification mechanisms. * Debian provides a number of useful security related tools for system administration and monitoring. Developers try to tightly integrate these tools with the distribution in order to make them a better suite to enforce local security policies. Tools include: integrity checkers, auditing tools, hardening tools, firewall tools, intrusion detection tools, etc. * Package maintainers are aware of security issues. This leads to many "secure by default" service installations which could impose certain restrictions on their normal use. Debian does, however, try to balance security and ease of administration - the programs are not de-activated when you install them (as it is the case with say, the BSD family of operating systems). In any case, prominent security issues (such as `setuid' programs) are part of the Debian Policy (http://www.debian.org/doc/debian-policy/). By publishing security information specific to Debian and complementing other information-security documents related to Debian (see Section 2.2, `Be aware of general security problems'), this document aims to produce better system installations security-wise. ------------------------------------------------------------------------------- 3. Before and during the installation ------------------------------------- 3.1. Choose a BIOS password --------------------------- 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. 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. 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. 3.2. Partitioning the system ---------------------------- 3.2.1. Choose an intelligent partition scheme --------------------------------------------- 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: * Any directory tree which a user has write permissions to, such as e.g. `/home', `/tmp' and `/var/tmp/', 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. [1] * Any partition which can fluctuate, e.g. `/var' (especially `/var/log') should also be on a separate partition. On a Debian system, you should create `/var' a little bit bigger than on other systems, because downloaded packages (the apt cache) are stored in `/var/cache/apt/archives'. * Any partition where you want to install non-distribution software should be on a separate partition. According to the File Hierarchy Standard, this is `/opt' or `/usr/local'. If these are separate partitions, they will not be erased if you (have to) reinstall Debian itself. * 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. 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 (`/var/mail' and/or `/var/spool/mail'). 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 `/var') 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 `/var/run'). Also, for partitions in which you cannot be sure of the needed space, installing Logical Volume Manager (`lvm-common' and the needed binaries for your kernel, this might be either `lvm10', `lvm6', or `lvm5'). Using `lvm', you can create volume groups that expand multiple physical volumes. [1] A very good example of this kind of attacks using /tmp is detailed in The mysteriously persistently exploitable program (contest) (http://www.hackinglinuxexposed.com/articles/20031111.html) and The mysteriously persistently exploitable program explained (http://www.hackinglinuxexposed.com/articles/20031214.html) (notice that the incident is Debian-related). It is basicly an attack in which a local user _stashes_ 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 225692 (http://bugs.debian.org/225692)) but other setuid binaries (not controlled by the package manager) are at risk if partitions are not setup correctly. 3.2.1.1. Selecting the appropriate file systems ----------------------------------------------- During the system partitioning you also have to decide which file system you want to use. The default file system selected in the Debian installation for Linux partitions is `ext2'. However, it is recommended you switch to a journalling file system, such as `ext3', `reiserfs', `jfs' or `xfs', to minimize the problems derived from a system crash in the following cases: * 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. * 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. 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 `ext3' file system. The reason for this is that it is backwards compatible with `ext2', 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 `ext3' 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 `reiserfs' or `xfs'. In any case, data integrity might be better under `ext3' since it does file-data journalling while others do only meta-data journalling, see http://lwn.net/2001/0802/a/ext3-modes.php3. 3.3. Do not plug to the Internet until ready -------------------------------------------- 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. 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! 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 `apt-move' or `apt-proxy', 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 Appendix F, `Security update protected by a firewall'). 3.4. Set a root password ------------------------ Setting a good root password is the most basic requirement for having a secure system. See passwd(1) for some hints on how to create good passwords. You can also use an automatic password generation program to do this for you (see Section 4.10.13, `Generating user passwords'). 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 How to: Pick a Safe Password (http://wolfram.org/writing/howto/password.html) and Walter Belgers' Unix Password Security (http://www.belgers.com/write/pwseceng.txt) 3.5. Activate shadow passwords and MD5 passwords ------------------------------------------------ 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 `/etc/shadow'. 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 `shadowconfig'. Read more on shadow passwords in Shadow Password (http://www.tldp.org/HOWTO/Shadow-Password-HOWTO.html) (`/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz'). 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 `passwd' package. You can recognize MD5 passwords in the `/etc/shadow' file by their $1$ prefix. This, as a matter of fact, modifies all files under `/etc/pam.d' by substituting the password line and include md5 in it: password required pam_unix.so md5 nullok obscure min=6 max=16 If `max' is not set over 8 the change will not be useful at all. For more information on this read Section 4.10.1, `User authentication: PAM'. Note: the default configuration in Debian, even when activating MD5 passwords, does not modify the previously set `max' value. 3.6. Run the minimum number of services required ------------------------------------------------ Services are programs such as ftp servers and web servers. Since they have to be _listening_ 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. 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. 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[1]. 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 Section 5.13, `Securing RPC services' for more information on how to secure or disable RPC services. When you install a new network-related service (daemon) in your Debian GNU/Linux system it can be enabled in two ways: through the `inetd' superdaemon (i.e. a line will be added to `/etc/inetd.conf') or through a standalone program that binds itself to your network interfaces. Standalone programs are controlled through the `/etc/init.d' files, which are called at boot time through the SysV mechanism (or an alternative one) by using symlinks in `/etc/rc?.d/*' (for more information on how this is done read `/usr/share/doc/sysvinit/README.runlevels.gz'). If you want to keep some services but use them rarely, use the `update-*' commands, e.g. `update-inetd' and `update-rc.d' to remove them from the startup process. For more information on how to disable network services read Section 3.6.1, `Disabling daemon services'. If you want to change the default behaviour of starting up services on installation of their associated packages[2] use `policy-rc.d', please read `/usr/share/doc/sysv-rc/README.policy-rc.d.gz' for more information. `invoke-rc.d' support is mandatory in Debian, which means that for Debian 4.0 _etch_ 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 `policyrcd-script-zg2'. [1] The footprint in Debian 3.0 and earlier releases wasn't as tight, since some `inetd' services were enabled by default. Also standard installations of Debian 2.2 installed the NFS server as well as the telnet server. [2] This is desirable if you are setting up a development chroot, for example. 3.6.1. Disabling daemon services -------------------------------- 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 `/etc/rc${runlevel}.d/'. If you rename them make sure they do not begin with 'S' so that they don't get started by `/etc/init.d/rc'. 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 Customizing runlevels (http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-custombootscripts) section of the Debian Reference (Chapter 2 - Debian fundamentals). You can remove these links manually or using `update-rc.d' (see update-rc.d(8)). For example, you can disable a service from executing in the multi-user runlevels by doing: # update-rc.d stop 2 3 4 5 . Where _XX_ is a number that determines when the stop action for that service will be executed. Please note that, if you are _not_ using `file-rc', `update-rc.d -f remove' will not work properly, since _all_ 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 Bug 67095 (http://bugs.debian.org/67095)). From the manpage: If any files /etc/rcrunlevel.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. If you are using `file-rc' all the information regarding services bootup is handled by a common configuration file and is maintained even if packages are removed from the system. You can use the TUI (Text User Interface) provided by `sysv-rc-conf' to do all these changes easily (`sysv-rc-conf' works both for `file-rc' and normal System V runlevels). You will also find similar GUIs for desktop systems. You can also use the command line interface of `sysv-rc-conf': # sysv-rc-conf foobar off 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: # sysv-rc-conf foobar on Other (not recommended) methods of disabling services are: * move the script file (`/etc/init.d/') to another name (for example `/etc/init.d/OFF.') or remove it. However, that will leave dangling symlinks under `/etc/rc${runlevel}.d/' and will generate error messages when booting. * remove the execute permission from the `/etc/init.d/' file. That will also generate error messages when booting. * edit the `/etc/init.d/' script to have it stop immediately once it is executed (by adding an `exit 0' line at the beginning or commenting out the `start-stop-daemon' part in it). If you do this, you will not be able to use the script to startup the service manually later on. Nevertheless the files under `/etc/init.d' are configuration files and should not get overwritten due to package upgrades if you have made local changes to them. Unlike other (UNIX) operating systems, services in Debian cannot be disabled by modifying files in `/etc/default/'. FIXME: Add more information on handling daemons using `file-rc'. 3.6.2. Disabling `inetd' or its services ---------------------------------------- You should check if you really need the `inetd' 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 `inetd' (which can increase the machine's load tremendously), and many people always preferred using stand-alone daemons instead of calling services via `inetd'. If you still want to run some kind of `inetd' service, then at least switch to a more configurable Inet daemon like `xinetd', `rlinetd' or `openbsd-inetd'. You should stop all unneeded Inetd services on your system, like `echo', `chargen', `discard', `daytime', `time', `talk', `ntalk' and r-services (`rsh', `rlogin' and `rcp') which are considered HIGHLY insecure (use `ssh' instead). You can disable services by editing `/etc/inetd.conf' directly, but Debian provides a better alternative: `update-inetd' (which comments the services in a way that it can easily be turned on again). You could remove the `telnet' daemon by executing this commands to change the config file and to restart the daemon (in this case the `telnet' service is disabled): /usr/sbin/update-inetd --disable telnet 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 `inetd' (replace service name with service@ip syntax) or use an alternative `inetd' daemon like `xinetd'. 3.7. Install the minimum amount of software required ---------------------------------------------------- Debian comes with _a lot_ of software, for example the Debian 3.0 _woody_ release includes 6 or 7 (depending on architecture) CD-ROMs of software and thousands of packages, and the Debian 3.1 _sarge_ release ships with around 13 CD-ROMs of software. With so much software, and even if the base system installation is quite reduced [1] you might get carried away and install more than is really needed for your system. 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). The presence, for example, of development utilities (a C compiler) or interpreted languages (such as `perl' - but see below -, `python', `tcl'...) may help an attacker compromise the system even further: * 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! * providing tools that could help the attacker to use the compromised system as a _base of attack_ against other systems. [2] 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 _prevent_ 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 Section 8.1, `Remote vulnerability assessment tools') you can expect an intruder to use them too if available. Please notice that a default installation of Debian _sarge_ (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 _Standard_ 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: 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 This is something that is fixed in releases post-sarge, see Bug #301273 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301273) and Bug #301138 (http://bugs.debian.org/cgi-bin/bugreport.cgi?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 _woody_ release. [1] For example, in Debian woody it is around 400-500 Mbs, try this: $ 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 [2] 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. 3.7.1. Removing Perl -------------------- You must take into account that removing `perl' 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 `perl-base' is _Priority: required_ (that about says it all). It's still doable, but you will not be able to run any `perl' application in the system; you will also have to fool the package management system to think that the `perl-base' is installed even if it's not. [1] Which utilities use `perl'? You can see for yourself: $ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && { type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done These include the following utilities in packages with priority _required_ or _important_: * `/usr/bin/chkdupexe' of package `util-linux'. * `/usr/bin/replay' of package `bsdutils'. * `/usr/sbin/cleanup-info' of package `dpkg'. * `/usr/sbin/dpkg-divert' of package `dpkg'. * `/usr/sbin/dpkg-statoverride' of package `dpkg'. * `/usr/sbin/install-info' of package `dpkg'. * `/usr/sbin/update-alternatives' of package `dpkg'. * `/usr/sbin/update-rc.d' of package `sysvinit'. * `/usr/bin/grog' of package `groff-base'. * `/usr/sbin/adduser' of package `adduser'. * `/usr/sbin/debconf-show' of package `debconf'. * `/usr/sbin/deluser' of package `adduser'. * `/usr/sbin/dpkg-preconfigure' of package `debconf'. * `/usr/sbin/dpkg-reconfigure' of package `debconf'. * `/usr/sbin/exigrep' of package `exim'. * `/usr/sbin/eximconfig' of package `exim'. * `/usr/sbin/eximstats' of package `exim'. * `/usr/sbin/exim-upgrade-to-r3' of package `exim'. * `/usr/sbin/exiqsumm' of package `exim'. * `/usr/sbin/keytab-lilo' of package `lilo'. * `/usr/sbin/liloconfig' of package `lilo'. * `/usr/sbin/lilo_find_mbr' of package `lilo'. * `/usr/sbin/syslogd-listfiles' of package `sysklogd'. * `/usr/sbin/syslog-facility' of package `sysklogd'. * `/usr/sbin/update-inetd' of package `netbase'. 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 _not a Good Thing_). 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. If you wish to check out which Debian packages depend on Perl you can use $ grep-available -s Package,Priority -F Depends perl or $ apt-cache rdepends perl [1] You can make (on another system) a dummy package with `equivs'. 3.8. Read the Debian security mailing lists ------------------------------------------- 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 mailto:debian-security@lists.debian.org, where you can participate in discussions about things related to Debian security. In order to receive important security update alerts, send an email to debian-security-announce-request@lists.debian.org (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 http://www.debian.org/MailingLists/subscribe. 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 Section 4.2, `Execute a security update' for details on how to do this). ------------------------------------------------------------------------------- 4. After installation --------------------- Once the system is installed you can still do more to secure the system; some of the steps described in this chapter can be taken. Of course this really depends on your setup but for physical access prevention you should read Section 4.3, `Change the BIOS (again)',Section 4.4, `Set a LILO or GRUB password',Section 4.6, `Remove root prompt on the kernel', Section 4.7, `Restricting console login access', and Section 4.8, `Restricting system reboots through the console'. Before connecting to any network, especially if it's a public one you should, at the very least, execute a security update (see Section 4.2, `Execute a security update'). Optionally, you could take a snapshot of your system (see Section 4.18, `Taking a snapshot of the system'). 4.1. Subscribe to the Debian Security Announce mailing list ----------------------------------------------------------- In order to receive information on available security updates you should subscribe yourself to the debian-security-announce mailing list in order to receive the Debian Security Advisories (DSAs). See Section 7.1, `The Debian Security Team' for more information on how the Debian security team works. For information on how to subscribe to the Debian mailing lists read http://lists.debian.org. DSAs are signed with the Debian Security Team's signature which can be retrieved from http://security.debian.org. You should consider, also, subscribing to the debian-security mailing list (http://lists.debian.org/debian-security) for general discussion on security issues in the Debian operating system. You will be able to contact other fellow system administrators in the list as well as Debian developers and upstream developers of security tools who can answer your questions and offer advice. FIXME: Add the key here too? 4.2. Execute a security update ------------------------------ As soon as new security bugs are detected in packages, Debian maintainers and upstream authors generally patch them within days or even hours. After the bug is fixed, a new package is provided on http://security.debian.org. If you are installing a Debian release you must take into account that since the release was made there might have been security updates after it has been determined that a given package is vulnerable. Also, there might have been minor releases (there have been four for the Debian 3.0 _sarge_ release) which include these package updates. You need to note down the date the removable media (if you are using it) was made and check the security site in order to see if there are security updates. If there are and you cannot download the packages from the security site on another system (you are not connected to the Internet yet? are you?) before connecting to the network you could consider (if not protected by a firewall for example) adding firewall rules so that your system could only connect to security.debian.org and then run the update. A sample configuration is shown in Appendix F, `Security update protected by a firewall'. _Note:_ Since Debian woody 3.0, after installation you are given the opportunity to add security updates to the system. If you say 'yes' to this, the installation system will take the appropriate steps to add the source for security updates to your package sources and your system, if you have an Internet connection, will download and install any security updates that might have been produced after your media was created. If you are upgrading a previous version of Debian, or you asked the installation system not to do this, you should take the steps described here. To manually update the system, put the following line in your `sources.list' and you will get security updates automatically, whenever you update your system. deb http://security.debian.org/ stable/updates main contrib non-free _Note_: If you are using the _testing_ branch use the security testing mirror sources as described in Section 10.1.4, `Security support for the testing branch'. Once you've done this you can use multiple tools to upgrade your system. If you are running a desktop system you will have[1] an application called `update-notifier' that will make it easy to check if new updates are available, by selecting it you can make a system upgrade from the desktop (using `update-manager'). For more information see Section 10.1.2.2, `Checking for updates at the Desktop'. In desktop environments you can also use `synaptic' (GNOME), `kpackage' or `adept' (KDE) for more advanced interfaces. If you are running a text-only terminal you can use `aptitude', `apt' or `dselect' (deprecated) to upgrade: * If you want to use `aptitude''s text interface you just have to press _u_ (update) followed by _g_ (to upgrade). Or just do the following from the command line (as root): # aptitude update # aptitude upgrade * If you want to use `apt' do just like with aptitude but substitute the `aptitude' lines above with `apt-get'. * If you want to use `dselect' then first [U]pdate, then [I]nstall and finally, [C]onfigure the installed/upgraded packages. If you like, you can add the deb-src lines to `/etc/apt/sources.list' as well. See apt(8) for further details. Note: You do _not_ need to add the following line: deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free this is because security.debian.org is hosted in a non-US location and doesn't have a separate non-US archive. [1] In _etch_ and later releases 4.2.1. Security update of libraries ----------------------------------- Once you have executed a security update you might need to restart some of the system services. If you do not do this, some services might still be vulnerable after a security upgrade. The reason for this is that daemons that are running before an upgrade might still be using the old libraries before the upgrade [1]. In order to detect which daemons might need to be restarted you can use the `checkrestart' program (available in the `debian-goodies' package) or use this one liner[2] (as root): # lsof | grep | awk '{print $1, $9}' | uniq | sort +0 Some packages (like `libc6') will do this check in the postinst phase for a limited set of services specially since an upgrade of essential libraries might break some applications (until restarted)[3]. Bringing the system to run level 1 (single user) and then back to run level 3 (multi user) should take care of the restart of most (if not all) system services. But this is not an option if you are executing the security upgrade from a remote connection (like ssh) since it will be severed. Excercise caution when dealing with security upgrades if you are doing them over a remote connection like ssh. A suggested procedure for a security upgrade that involves a service restart is to restart the SSH daemon and then, inmediately, attempt a new ssh connection without breaking the previous one. If the connection fails, revert the upgrade and investigate the issue. [1] Even though the libraries have been removed from the filesystem the inodes will not be cleared up until no program has an open file descriptor pointing to them. [2] Depending on your lsof version you might need to use $8 instead of $9 [3] This happened, for example, in the upgrade from libc6 2.2.x to 2.3.x due to NSS authentication issues, see http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html. 4.2.2. Security update of the kernel ------------------------------------ First, make sure your kernel is being managed through the packaging system. If you have installed using the installation system from Debian 3.0 or previous releases, your kernel is _not_ integrated into the packaging system and might be out of date. You can easily confirm this by running: $ dpkg -S `readlink -f /vmlinuz` kernel-image-2.4.27-2-686: /boot/vmlinuz-2.4.27-2-686 If your kernel is not being managed you will see a message saying that the package manager did not find the file associated to any package instead of the message above, which says that the file associated to the current running kernel is being provided by the `kernel-image-2.4.27-2-686'. So first, you will need to manually install a kernel image package. The exact kernel image you need to install depends on your architecture and your prefered kernel version. Once this is done, you will be able to manage the security updates of the kernel just like those of any other package. In any case, notice that the kernel updates will _only_ be done for kernel updates of the same kernel version you are using, that is, `apt' will not automatically upgrade your kernel from the 2.4 release to the 2.6 release (or from the 2.4.26 release to the 2.4.27 release[1]). The installation system of the Debian 3.1 release will handle the selected kernel (either 2.4 or 2.6) as part of the package system. You can review which kernels you have installed by running: $ COLUMNS=150 dpkg -l 'kernel-image*' | awk '$1 ~ /ii/ { print $0 }' To see if your kernel needs to be updated run: $ kernfile=`readlink -f /vmlinuz` $ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'` $ apt-cache policy $kernel kernel-image-2.4.27-2-686: Installed: 2.4.27-9 Candidate: 2.4.27-9 Version Table: *** 2.4.27-9 0 (...) If you are doing a security update which includes the kernel image you _need_ to reboot the system in order for the security update to be useful. Otherwise, you will still be running the old (and vulnerable) kernel image. If you need to do a system reboot (because of a kernel upgrade) you should make sure that the kernel will boot up correctly and network connectivity will be restored, specially if the security upgrade is done over a remote connection like ssh. For the former you can configure your boot loader to reboot to the original kernel in the event of a failure (for more detailed information read Remotely rebooting Debian GNU/Linux machines (http://www.debian-administration.org/?article=70)). For the later you have to introduce a network connectivity test script that will check if the kernel has started up the network subsystem properly and reboot the system if it did not[2]. This should prevent nasty surprises like updating the kernel and then realizing, after a reboot, that it did not detect or configure the network hardware properly and you need to travel a long distance to bring the system up again. Of course, having the system serial console [3] in the system connected to a console or terminal server should also help debug reboot issues remotely. [1] Unless you have installed a kernel metapackage like `kernel-image-2.4-686' which will always pull in the latest kernel minor revision for a kernel release and a given architecture. [2] A sample script called testnet (http://www.debian-administration.org/articles/70/testnet) is available in the Remotely rebooting Debian GNU/Linux machines (http://www.debian-administration.org/?article=70) article. A more elaborate network connectivity testing script is available in the Testing network connectivity (http://www.debian-administration.org/?article=128) article. [3] Setting up a serial console is beyond the scope of this document, for more information read the Serial HOWTO (http://www.tldp.org/HOWTO/Serial-HOWTO.html) and the Remote Serial Console HOWTO (http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/index.html). 4.3. Change the BIOS (again) ---------------------------- Remember Section 3.1, `Choose a BIOS password'? Well, then you should now, once you do not need to boot from removable media, to change the default BIOS setup so that it _only_ boots from the hard drive. Make sure you will not lose the BIOS password, otherwise, in the event of a hard disk failure you will not be able to return to the BIOS and change the setup so you can recover it using, for example, a CD-ROM. Another less secure but more convenient way is to change the setup to have the system boot up from the hard disk and, if it fails, try removable media. By the way, this is often done because most people don't use the BIOS password that often; it's easily forgotten. 4.4. Set a LILO or GRUB password -------------------------------- Anybody can easily get a root-shell and change your passwords by entering ` init=/bin/sh' at the boot prompt. After changing the passwords and rebooting the system, the person has unlimited root-access and can do anything he/she wants to the system. After this procedure you will not have root access to your system, as you do not know the root password. To make sure that this cannot happen, you should set a password for the boot loader. You can choose between a global password or a password for a certain image. For LILO you need to edit the config file `/etc/lilo.conf' and add a `password' and `restricted' line as in the example below. image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted Then, make sure that the configuration file is not world readable to prevent local users from reading the password. When done, rerun lilo. Omitting the `restricted' line causes lilo to always prompt for a password, regardless of whether LILO was passed parameters. The default permissions for `/etc/lilo.conf' grant read and write permissions to root, and enable read-only access for `lilo.conf''s group, root. If you use GRUB instead of LILO, edit `/boot/grub/menu.lst' and add the following two lines at the top (substituting, of course `hackme' with the desired password). This prevents users from editing the boot items. `timeout 3' specifies a 3 second delay before `grub' boots the default item. timeout 3 password hackme To further harden the integrity of the password, you may store the password in an encrypted form. The utility `grub-md5-crypt' generates a hashed password which is compatible with GRUB's encrypted password algorithm (MD5). To specify in `grub' that an MD5 format password will be used, use the following directive: timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0 The --md5 parameter was added to instruct `grub' to perform the MD5 authentication process. The provided password is the MD5 encrypted version of hackme. Using the MD5 password method is preferable to choosing its clear-text counterpart. More information about `grub' passwords may be found in the `grub-doc' package. 4.5. Disable root prompt on the initramfs ----------------------------------------- Note: This applies to the default kernels provided for releases after Debian 3.1 Linux 2.6 kernels provide a way to access a root shell while booting which will be presented during loading the initramfs on error. This is helpful to permit the administrator to enter an rescue shell with root permissions. This shell can be used to manually load modules when autodetection fails. This behavior is the default for `initramfs-tools' generated initramfs. The following message will appear: "ALERT! /dev/sda1 does not exist. Dropping to a shell! In order to remove this behavior you need to set the following boot argument:_panic=0_. Either add it to the kopt section of `/boot/grub/menu.lst' and issue `update-grub' or to the append section of `/etc/lilo.conf'. 4.6. Remove root prompt on the kernel ------------------------------------- Note: This does not apply to the kernels provided for Debian 3.1 as the timeout for the kernel delay has been changed to 0. Linux 2.4 kernels provide a way to access a root shell while booting which will be presented just after loading the cramfs file system. A message will appear to permit the administrator to enter an executable shell with root permissions, this shell can be used to manually load modules when autodetection fails. This behavior is the default for `initrd''s `linuxrc'. The following message will appear: Press ENTER to obtain a shell (waits 5 seconds) In order to remove this behavior you need to change `/etc/mkinitrd/mkinitrd.conf' and set: # DELAY The number of seconds the linuxrc script should wait to # allow the user to interrupt it before the system is brought up DELAY=0 Then regenerate your ramdisk image. You can do this for example with: # cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7 or (preferred): # dpkg-reconfigure -plow kernel-image-2.4.x-yz 4.7. Restricting console login access ------------------------------------- Some security policies might force administrators to log in to the system through the console with their user/password and then become superuser (with `su' or `sudo'). This policy is implemented in Debian by editing the `/etc/login.defs' file or `/etc/securetty' when using PAM. In: * `login.defs', editing the CONSOLE variable which defines a file or list of terminals on which root logins are allowed * `securetty'[1] by adding/removing the terminals to which root access will be allowed. If you wish to allow only local console access then you need _console_, _ttyX_[2] and _vc/X_ (if using _devfs_ devices), you might want to add also _ttySX_[3] if you are using a serial console for local access (where X is an integer, you might want to have multiple instances[4] depending on the number of virtual consoles you have enabled in `/etc/inittab'[5]). For more information on terminal devices read the Text-Terminal-HOWTO (http://tldp.org/HOWTO/Text-Terminal-HOWTO-6.html). When using PAM, other changes to the login process, which might include restrictions to users and groups at given times, can be configured in `/etc/pam.d/login'. An interesting feature that can be disabled is the possibility to login with null (blank) passwords. This feature can be limited by removing _nullok_ from the line: auth required pam_unix.so nullok [1] The `/etc/securetty' is a configuration file that belongs to the `login' package. [2] Or _ttyvX_ in GNU/FreeBSD, and _ttyE0_ in GNU/KNetBSD. [3] Or _comX_ in GNU/Hurd, _cuaaX_ in GNU/FreeBSD, and _ttyXX_ in GNU/KNetBSD. [4] The default configuration in _woody_ includes 12 local tty and vc consoles, as well as the _console_ device but does not allow remote logins. In _sarge_ the default configuration provides 64 consoles for tty and vc consoles. You can safely remove this if you are not using that many consoles. [5] Look for the _getty_ calls. 4.8. Restricting system reboots through the console --------------------------------------------------- If your system has a keyboard attached to it anyone (yes _anyone_) can reboot the system through it without login to the system. This might, or might not, adhere to your security policy. If you want to restrict this, you must check the `/etc/inittab' so that the line that includes `ctrlaltdel' calls `shutdown' with the `-a' switch (remember to run `init q' after making any changes to this file). The default in Debian includes this switch: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now Now, in order to allow _some_ users to shutdown the system, as the manpage shutdown(8) describes, you must create the file `/etc/shutdown.allow' and include there the name of users which can boot the system. When the _three finger salute_ (a.k.a. _ctrl+alt+del_) is given the program will check if any of the users listed in the file are logged in. If none of them is, `shutdown' will _not_ reboot the system. 4.9. Mounting partitions the right way -------------------------------------- When mounting an ext2 partition, there are several additional options you can apply to the mount call or to `/etc/fstab'. For instance, this is my fstab entry for the `/tmp' partition: /dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2 You see the difference in the options sections. The option `nosuid' ignores the setuid and setgid bits completely, while `noexec' forbids execution of any program on that mount point, and `nodev' ignores device files. This sounds great, but it: * only applies to ext2 file systems * can be circumvented easily The `noexec' option prevents binaries from being executed directly, but was easily circumvented in earlier versions of the kernel: alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000 Newer versions of the kernel do however handle the `noexec' flag properly: angrist:/tmp# mount | grep /tmp /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev) angrist:/tmp# ./date bash: ./tmp: Permission denied angrist:/tmp# /lib/ld-linux.so.2 ./date ./date: error while loading shared libraries: ./date: failed to map segment from shared object: Operation not permitted However, many script kiddies have exploits which try to create and execute files in `/tmp'. If they do not have a clue, they will fall into this pit. In other words, a user cannot be tricked into executing a trojanized binary in `/tmp' e.g. when he incidentally adds `/tmp' into his PATH. Also be forewarned, some script might depend on `/tmp' being executable. Most notably, Debconf has (had?) some issues regarding this, for more information see Bug 116448 (http://bugs.debian.org/116448). The following is a more thorough example. A note, though: `/var' could be set noexec, but some software [1] keeps its programs under in `/var'. The same applies to the nosuid option. /dev/sda6 /usr ext3 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext3 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext3 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext3 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext3 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0 [1] Some of this includes the package manager `dpkg' since the installation (post,pre) and removal (post,pre) scripts are at `/var/lib/dpkg/' and Smartlist 4.9.1. Setting `/tmp' noexec ---------------------------- Be careful if setting `/tmp' noexec when you want to install new software, since some programs might use it for installation. `apt' is one such program (see http://bugs.debian.org/116448) if not configured properly `APT::ExtractTemplates::TempDir' (see apt-extracttemplates(1)). You can set this variable in `/etc/apt/apt.conf' to another directory with exec privileges other than `/tmp'. 4.9.2. Setting /usr read-only ----------------------------- If you set `/usr' read-only you will not be able to install new packages on your Debian GNU/Linux system. You will have to first remount it read-write, install the packages and then remount it read-only. `apt' can be configured to run commands before and after installing packages, so you might want to configure it properly. To do this modify `/etc/apt/apt.conf' and add: DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; }; Note that the Post-Invoke may fail with a "/usr busy" error message. This happens mainly when you are using files during the update that got updated. You can find these programs by running # lsof +L1 Stop or restart these programs and run the Post-Invoke manually. _Beware!_ This means you'll likely need to restart your X session (if you're running one) every time you do a major upgrade of your system. You might want to reconsider whether a read-only `/usr' is suitable for your system. See also this discussion on debian-devel about read-only /usr (http://lists.debian.org/debian-devel/2001/11/threads.html#00212). 4.10. Providing secure user access ---------------------------------- 4.10.1. User authentication: PAM -------------------------------- PAM (Pluggable Authentication Modules) allows system administrators to choose how applications authenticate users. Note that PAM can do nothing unless an application is compiled with support for PAM. Most of the applications that are shipped with Debian have this support built in (Debian did not have PAM support before 2.2). The current default configuration for any PAM-enabled service is to emulate UNIX authentication (read `/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz' for more information on how PAM services _should_ work in Debian). Each application with PAM support provides a configuration file in `/etc/pam.d/' which can be used to modify its behavior: * what backend is used for authentication. * what backend is used for sessions. * how do password checks behave. The following description is far from complete, for more information you might want to read the The Linux-PAM System Administrator's Guide (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html) (at the primary PAM distribution site (http://www.kernel.org/pub/linux/libs/pam/)). This document is also provided in the `libpam-doc' Debian package. PAM offers you the po