Securing Debian Manual ---------------------- Javier Fernández-Sanguino Peña 2.97 3 October 2003Fri, 3 Oct 2003 22:23:28 +0200 ----------------------------------------------------------------------- -------- Abstract -------- This document describes security in the Debian project. 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 team. Copyright Notice ---------------- Copyright (C) 2002, 2003 Javier Fernández-Sanguino Peña Copyright (C) 2001 Alexander Reelsen, Javier Fernández-Sanguino Peña Copyright (C) 2000 Alexander Reelsen Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Public License, Version 2 (http://www.fsf.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. ----------------------------------------------------------------------- -------- Contents -------- 1. Introduction 1.1. Author 1.2. Download the manual 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. Remove root prompt on the kernel 4.6. Disallow floppy booting 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. Disabling 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 assesment 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. Before the compromise 9.1. Continuously update the system 9.2. Set up Intrusion Detection 9.3. Avoiding root-kits 9.4. Genius/Paranoia Ideas --- what you could do 10. After the compromise (incident response) 10.1. General behavior 10.2. Backing up the system 10.3. Contact your local CERT 10.4. Forensic analysis 11. Frequently asked Questions (FAQ) 11.1. Security in the Debian operating system 11.2. My system is vulnerable! (Are you sure?) 11.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. Automatically making the environment (the easy way) G.2. Patching `SSH' to enable `chroot' functionality G.3. Handmade environment (the hard way) 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 tradeoff 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. Author ----------- The current maintainer of this document is Javier Fernández- Sanguino (mailto:jfs@debian.org) . Please forward him any have 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 (mailto:jfs@debian.org) incorporated it into the Debian Documentation Project (http://www.debian.org/doc). A number of people have contributed to these 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 1.2. Download the manual ------------------------ You can download or view the newest version of the Securing Debian Manual from the Debian Documentation Project (http://www.debian.org/doc/manuals/securing-debian-howto/). Feel free to check out the version control system through its CVS server (http://cvs.debian.org/ddp/manuals.sgml/securing- howto/?cvsroot=debian-doc). You can download also a text version (http://www.debian.org/doc/manuals/securing-debian-howto/securing- debian-howto.txt) from the Debian Documentation's Project site. Other formats, like PDF, are not (yet) provided. However, you can download or install the harden-doc (http://packages.debian.org/harden-doc) package which provides this same document in HTML, txt and PDF formats. Notice, however, that the package maybe not be completely up to date with the document provided on the Internet (but you can always use the source package to build an updated version yourself!) 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, `Author' * Expand the incident response information, maybe add some ideas derived from RedHat'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 writting a section on how to build Debian-based network appliances (with information such as the base system, `equivs' and FAI). * Check if http://rr.sans.org/linux/hardening.php has relevant info not yet covered here. * Add Information on how to set up a laptop with Debian http://rr.sans.org/linux/debian_laptop.php. * 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', `xproxy', `ftp-proxy', `redir', `smtpd', `nntp-cache', `dnrd', `jftpgw', `oops', `pnsd', `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 (`lids-2.2.19') * Linux Trustees (in package `trustees') * NSA Enhanced Linux (http://www.coker.com.au/selinux/) * kernel-patch-2.2.18-openwall (http://packages.debian.org/kernel-patch-2.2.18- openwall) * `kernel-patch-2.2.19-harden' * `kernel-patch-freeswan, kernel-patch-int' * 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://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 (while as flash is not). * Talk about chrooting services, some more info on http://www.linuxfocus.org/English/January2002/aritcle225.shtml, http://www.networkdweebs.com/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. * Add information provided by Karl Hegbloom regarding chrooting Bind 9, see http://people.pdxlinux.org/~karlheg/Secure_Bind9_uHOWTO/Secure_Bind_9_u HOWTO.xhtml. * Add information provided by Pedro Zornenon to chrooting Bind 8 only for potato though :(, see http://people.debian.org/~pzn/howto/chroot-bind.sh.txt (include the whole script?). * 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 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') 1.6. Changelog/History ---------------------- 1.6.1. 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.2. Version 2.96 (august 2003) --------------------------------- Changes by Javier Fernández-Sanguino Peña * Removed (and then readded) appendix on chrooting Apache. The appendix is now dual-licensed. 1.6.3. 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.4. 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.5. Version 2.93 (march 2003) -------------------------------- Changes made by Frédéric Schütz. * rewrote entirely the section of ext2 attributes (lsattr/chattr) 1.6.6. 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.7. 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.8. Version 2.9 (december 2002) ---------------------------------- Changes by Javier Fernández-Sanguino Peña (me). * Reorganised 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 Raitti. * Applied patches contributed by Guillermo Jover. 1.6.9. 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.10. 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.11. 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.12. 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.13. 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 reorganised 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. * Reorganised 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). * Reorganised 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 go to Francois Bayar 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 reorganised) 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.14. Version 2.4 ------------------- Changes by Javier Fernández-Sanguino Peña. * Rewritten part of the BIOS section. 1.6.15. 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.16. 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.17. 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.18. 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.19. Version 2.0 ------------------- Changes by Javier Fernández-Sanguino Peña. I wanted to change to 2.0 when all the FIXMEs were, er, 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. * Reorganised 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.20. Version 1.99 -------------------- Changes by Javier Fernández-Sanguino Peña. * Added a new FAQ item regarding time to fix security vulnerabilities. * Reorganised 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.21. 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.22. 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.23. 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.24. 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.25. 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.26. 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.27. 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.28. 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.29. 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.30. 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 9.3.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.31. 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.32. 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.33. Version 1.5 ------------------- Changes by Josip Rodin and Javier Fernández-Sanguino Peña. * Added paragraphs related to BIND and some FIXMEs. 1.6.34. Version 1.4 ------------------- * Small setuid check paragraph * Various minor cleanups * Found out how to use `sgml2txt -f' for the txt version 1.6.35. 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.36. Version 1.2 ------------------- * Lots of grammar corrections by James Treacy, new XDM paragraph 1.6.37. Version 1.1 ------------------- * Typo fixes, miscellaneous additions 1.6.38. 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. * All the people who made suggestions for improvement that (eventually) got 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/) (provided in Debian through the `lasg' package) 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 RedHat, some of the issues are not distribution-specific and also apply to Debian. * 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 (http://seifried.org/lskb). 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 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 Won't Hide Problems_ _We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately 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 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 for starting new projects, like 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 might put some limits, sometimes, on its normal use. However, Debian does try to balance security issues and ease of administration, systems are not installed de-activated, for example, like the BSD family distributions. In any case, some special security issues, like `setuid' programs, are part of the Debian Policy (http://www.debian.org/doc/debian-policy/). This document as well, tries to enforce a better distribution security-wise, by publishing security information specific to Debian which complements other information-security documents related to the tools used by Debian or the operating system itself (see Section 2.2, `Be aware of general security problems'. ----------------------------------------------------------------------- -------- 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, cdrom 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' and `/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.) * 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 can not 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. 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 sometimes can 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 CDROM) you do not need a custom kernel. If the kernel is 2.4 `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 kernel with the needed modules built-in. If you are stuck with a 2.2 kernel in the rescue disk it might even be 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.14, `Generating user passwords'). FIXME: Add pointers to information about good passwords. 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, you are queried during installation whether you want to use MD5 hashed passwords. 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 `password' package. You can change this anytime after installation by doing `dpkg-reconfigure -plow passwd'. 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 programmes 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 are hence 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 footprint of running services is quite low and it's even lower when talking about services offered to the network. The footprint in Debian 2.1 wasn't as tight as in Debian 2.2 (some `inetd' services were enabled by default) and in Debian 2.2 the rpc portmapper is enabled upon installation. Rpc is installed by default because it is needed for many services, for example NFS, to run on a given system. It can be easily removed, however, see Section 3.6.1, `Disabling daemon services' on how to disable it. 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. 3.6.1. Disabling daemon services -------------------------------- Disabling a daemon service is quite simple. There are different methods: * remove links from `/etc/rc${runlevel}.d/' or rename the links (so that they do not begin with 'S') * move the script file (`/etc/init.d/_service_name_') to another name (for example `/etc/init.d/OFF._service_name_') * remove the execute permission from the `/etc/init.d/_service_name_' file. * edit the `/etc/init.d/_service_name_' script to have it stop immediately. You can remove the links from `/etc/rc${runlevel}.d/' 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 XX 2 3 4 5 . Please note that, if you are _not_ using `file-rc', `update-rc.d - f _service_ 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 `rcconf' to do all these changes easily (`rcconf' works both for `file-rc' and normal System V runlevels). Other (not recommended) methods of disabling services are: `chmod 644 /etc/init.d/daemon' (but that gives an error message when booting), or modifying the `/etc/init.d/daemon' script (by adding an `exit 0' line at the beginning or commenting out the `start-stop-daemon' part in it). Since `init.d' files are config files, they will not get overwritten upon upgrade. Unfortunately, unlike other (UNIX) operating systems, services in Debian cannot be disabled by modifying files in `/etc/default/_servicename_'. FIXME: Add more information on handling daemons using file-rc 3.6.2. Disabling `inetd' services --------------------------------- You should stop all unneeded 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). After disabling those, you should check if you really need the `inetd' daemon. Many people prefer to use daemons instead of calling services via `inetd'. Denial of Service possibilities exist against `inetd', which can increase the machine's load tremendously. If you still want to run some kind of `inetd' service, switch to a more configurable inet daemon like `xinetd' or `rlinetd'. 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'. . Or use an alternate `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 almost 6 CD-ROMs of software and thousands of packages. 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 unnecesary 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 assesment tools') you can expect an intruder to use them too if available. [1] For example, in Debian woody it is around 40Mbs, 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 34234 [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. [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.5, `Remove root prompt on the kernel', Section 4.6, `Disallow floppy booting', 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 were seven in Debian 2.2 _potato_ 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 appropiate 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 Once you've done this you can either use `apt' or `dselect' to upgrade: * If you want to use `apt' just do (as root): # apt-get update # apt-get upgrade * 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 is hosted in a non-US location and doesn't have a seperate non-US archive. 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 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 cleartext counterpart. More information about `grub' passwords may be found in the `grub-doc' package. 4.5. Remove root prompt on the kernel ------------------------------------- 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 Note that Debian 3.0 woody allows users to install 2.4 kernels (selecting _flavors_), _however_ the default kernel is 2.2 (save for some architectures for which kernel 2.2 was not ported). If you consider this a bug consider Bug 145244 (http://bugs.debian.org/145244) before sending it. 4.6. Disallow floppy booting ---------------------------- The default MBR in Debian before version 2.2 did not act as a usual master boot record and left open a method to easily break into a system: * Press shift at boot time, and an MBR prompt appears * Then press F, and your system will boot from floppy disk. This can be used to get root access to the system. This behavior can be changed by entering: lilo -b /dev/hda Now LILO is put into the MBR. This can also be achieved by adding `boot=/dev/hda' to `lilo.conf'. There is another solution which will disable the MBR prompt completely: install-mbr -i n /dev/hda On the other hand, this "back door", of which many people are just not aware, may save your skin as well if you run into deep trouble with your installation for whatever reasons. FIXME check whether this really is true as of 2.2 or was it 2.1? INFO: The bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO. 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' by adding/removing the terminals to which root access will be allowed. 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 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 devices. 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 is easily circumvented: 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 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 ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 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'. Regarding noexec, please be aware that it might not offer you that much security. Consider this: $ cp /bin/date /tmp $ /tmp/date (does not execute due to noexec) $/lib/ld-linux.so.2 /tmp/date (works since date is not executed directly) 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. The latest `apt' version (in Debian 3.0 'woody') 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. Annoying but not really a big deal. Just make sure these are no longer used and run the Post-Invoke manually. 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 2.2 have this support built in. Furthermore, 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'. PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal `passwd' file, and the user only logs in if he authenticates correct in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to `requisite', which returns a login failure if one module fails. The first thing I like to do, is to add MD5 support to PAM applications, since this helps protect against dictionary cracks (passwords can be longer if using MD5). The following two lines should be added to all files in `/etc/pam.d/' that grant access to the machine, like `login' and `ssh'. # Be sure to install libpam-cracklib first or you will not be able to log in password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5 So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum length of 12 characters, a difference of at least 3 characters from the old password, and allows 3 retries. The second line introduces the standard authentication module with MD5 passwords and allows a zero length password. The `use_authtok' directive is necessary to hand over the password from the previous module. The package depends in a wordlist (such as `wenglish', `wspanish', `wbritish'...), make sure that you install the one appropiate to your language (otherwise it might not be useful at all). [1] To make sure that the user root can only log into the system from local terminals, the following line should be enabled in `/etc/pam.d/login': auth requisite pam_securetty.so Then you should add the terminals from which the user root can log into the system, in `/etc/security/access.conf'. Last but not least the following line should be enabled if you want to set up user limits. session required pam_limits.so This restricts the system resources that users are allowed (see below in Section 4.10.2, `Limiting resource usage: the `limits.conf' file' ). For example, you could restrict the number of concurrent logins (of a given group of users, or system-wide) you may have, the number of processes, the memory size... Now edit `/etc/pam.d/passwd' and change the first line. You should add the option "md5" to use MD5 passwords, change the minimum length of password from 4 to 6 (or more) and set a maximum length, if you desire. The resulting line will look something like: password required pam_unix.so nullok obscure min=6 max=11 md5 If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group "wheel" to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to `su' to the root user to this group. Then add the following line to `/etc/pam.d/su': auth requisite pam_wheel.so group=wheel debug This makes sure that only people from the group "wheel" can use `su' to become root. Other users will not be able to become root. In fact they will get a denied message if they try to become root. If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow user 'ref' to log in via `ssh'. So you put him into `/etc/sshusers-allowed' and write the following into `/etc/pam.d/ssh': auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail Last, but not least, create `/etc/pam.d/other' and enter the following lines: auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so These lines will provide a good default configuration for all applications that support PAM (access is denied by default). [1] This dependancy is not fixed, however, in the Debian 3.0 package. Please see Bug #112965 (http://bugs.debian.org/112965). 4.10.2. Limiting resource usage: the `limits.conf' file ------------------------------------------------------- You should really take a serious look into this file. Here you can define user resource limits. If you use PAM, the file `/etc/limits.conf' is ignored and you should use `/etc/security/limits.conf' instead. If you do not restrict resource usage, _any_ user with a valid shell in your system (or even an intruder who compromised the system through a service) can use up as much CPU, memory, stack, etc. as the system can provide. This _resource exhaustion_ problem can only be fixed by the use of PAM. Note that there is a way to add resource limits to some shells (for example, `bash' has `ulimit', see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules. For more information read: * PAM configuration article (http://www.samag.com/documents/s=1161/sam0009a/0009a.htm). * Seifried's Securing Linux Step by Step (http://seifried.org/security/os/linux/20020324-securing- linux-step-by-step.html) on the _Limiting users overview_ section. * LASG (http://seifried.org/lasg/users/) in the _Limiting and monitoring users_ section. FIXME: Get a good `limits.conf' up here 4.10.3. User Login actions: edit `/etc/login.defs' -------------------------------------------------- The next step is to edit the basic configuration and action upon user login. FAIL_DELAY 10 This variable should be set to a higher value to make it harder to use the terminal to log in using brute force. If a wrong password is typed in, the possible attacker (or normal user!) has to wait for 10 seconds to get a new login prompt, which is quite time consuming when you test passwords (manually). Pay attention to the fact that this setting is useless if using a program other than `getty', such as `mingetty' for example. FAILLOG_ENAB yes If you enable this variable, failed logins will be logged. It is important to keep track of them to catch someone who tries a brute force attack. LOG_UNKFAIL_ENAB yes If you set the variable to yes, then you should also set this variable to yes. This will record unknown usernames if the login failed. If you do this, make sure the logs have the proper permissions (640 for example, with an appropriate group setting such as adm), because users often accidentally enter their password as the username and you do not want others to see it. SYSLOG_SU_ENAB yes This one enables logging of `su' attempts to `syslog'. Quite important on serious machines but note that this can create privacy issues as well. SYSLOG_SG_ENAB yes The same as but applies to the `sg' program. MD5_CRYPT_ENAB yes As stated above, MD5 sum passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. If you are using slink, read the docs about MD5 before enabling this option. Otherwise this is set in PAM. PASS_MAX_LEN 50 If MD5 passwords are activated in your PAM configuration, then this variable should be set to the same value as used there. 4.10.4. Restricting ftp: editing `/etc/ftpusers' ------------------------------------------------ The `/etc/ftpusers' file contains a list of users who are not allowed to log into the host using ftp. Only use this file if you really want to allow ftp (which is not recommended in general, because it uses cleartext passwords). If your daemon supports PAM, you can also use that to allow and deny users for certain services. FIXME (BUG): Is it a bug that the default `ftpusers' in Debian does _not_ include all the administrative users (in `base-passwd'). 4.10.5. Using su ---------------- If you really need users to become the super user on your system, e.g. for installing packages or adding users, you can use the command `su' to change your identity. You should try to avoid any login as user root and instead use `su'. Actually, the best solution is to remove `su' and switch to `sudo', as it has more features than `su'. However, `su' is more common as it is used on many other Unices. 4.10.6. Using sudo ------------------ `sudo' allows the user to execute defined commands under another user's identity, even as root. If the user is added to `/etc/sudoers' and authenticates himself correctly, he is able to run commands which have been defined in `/etc/sudoers'. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root. 4.10.7. Disallow remote adminitrative access -------------------------------------------- You should modify `/etc/security/access.conf' also so that remote administrative login is disallowed. This way the users need to use `su' (or `sudo') so that there is always an audit trace whenever a local user wants to use administrative powers. You need to add the following line to `/etc/security/access.conf', the default Debian configuration file has a sample line commented out: -:wheel:ALL EXCEPT LOCAL 4.10.8. Restricting users's access ---------------------------------- Sometimes you might think you need to have users created in your local system in order to provide a given service (pop3 mail service or ftp). Before doing so, first remember that the PAM implementation in Debian GNU/Linux allows you to validate users with a wide variety of external directory services (radius, ldap, etc.) provided by the libpam packages. If users need to be created and the system can be accessed remotely take into account that users will be able to log in to the system. You can fix this by giving users a null (`/dev/null') shell (it would need to be listed in `/etc/shells'). If you want to allow users to access the system but limit their movements, you can use the `/bin/rbash', equivalent to adding the `-r' option in `bash' (_RESTRICTED SHELL_ see bash(1)). Please note that even with restricted shell, a user that access an interactive program (that might allow execution of a subshell) could be able to bypass the limits of the shell. Debian currently provides in the unstable release (and might be included in the next stable releases) the `pam_chroot' module (in the `libpam-chroot'). An alternative to it is to `chroot' the service that provides remote logging (`ssh', `telnet'). [1] If you wish to restrict _when_ users can access the system you will have to customize `/etc/security/access.conf' for your needs. Information on how to `chroot' users accessing the system through the `ssh' service is described in Appendix G, ``Chroot' environment for `SSH''. [1] `Libpam-chroot' has not been yet thoroughly tested, it does work for `login' but it might not be easy to set up the environment for other programs 4.10.9. Hand-made user auditing ------------------------------- If you are paranoid you might want to add a system-wide `/etc/profile' that sets the environment in a way such that they cannot remove audit capabilities from the shell (commands are dumped to `$HISTFILE'. The `/etc/profile' could be set as follows: HISTFILE=~/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE For this to work the user can only append information to `.bash_history'. You need _also_ to set the _append-only_ option using `chattr' program for `.bash_history' for all users. [1]. Note that you could do that per user's `.profile'. But then you would need to setup permissions properly: having the user's home directories _not_ belong to the users but enable them to read the configuration `.profile' and write on the `.bash_history'. It would be good to set the _inmutable_ flag (also using `chattr') for `.profile' too if you do it this way. If you are completely paranoid and want to audit every user's command, you could take `bash' source code, edit it and have it send all that the user typed into another file. Or have `ttysnoop' constantly monitor any new ttys [2] and dump the output into a file. Other useful program is `snoopy' which is a user-transparent program that hooks in as a library providing a wrapper around calls, any command executed is logged to `syslogd' using the `authpriv' facility (usually stored at `/var/log/auth.log'). Note that you cannot use the `script' command for this since it will not work as a shell (even if you add it to `/etc/shells'). [1] Without the append-only flag users would be able to empty the contents of the history file running `>.bash_history' [2] Ttys are spawned for local logins and remote logins through ssh and telnte 4.10.10. Complete user audit ---------------------------- The previous example is a simple way to configure user auditing which might be not useful for complex systems. If this is your case, you need to look at `acct', the accounting utilities. These will log all the commands run by users or processes in the system, at the expense of disk space. When activating accounting, all the information on processes and users is kept under `/var/account/', more specifically in the `pacct'. The accounting package includes some tools (`sa' and `ac') to analyse this data. 4.10.11. Reviewing user profiles -------------------------------- If you want to _see_ what users are usually doing, when they are connecting you can use the `wtmp' database that includes all login information. This file can be processed with several utilities, amongst them `sac' which can output a profile on each user showing in which timeframe they usually log on to the system. In case you have accounting activated, you can also use the tools provided by it in order to determine when the users access the system and what they execute. 4.10.12. Setting users umasks ----------------------------- Depending on your user policy you might want to change how information is shared between users, that is, what the default permissions of new files created by users are. This change is set by defining a proper `umask' setting for all users. You can change the setting in `/etc/limits.conf', `/etc/profile', `/etc/csh.cshrc', `/etc/csh.login', `/etc/zshrc' and probably some others (depending on the shells you have installed on your system). Of all of these the last one that gets loaded takes precedence. The order is: PAM's `limits.conf', the default system configuration for the user's shell, the user's shell (his `~/.profile', `~/.bash_profile'...) Debian's default `umask' setting is _022_ this means that files (and directories) can be read and accessed by the user's group and by any other users in the system. If this is too permissive for your system you will have to change the umask setting for all the shells (and for PAM). Don't forget to modify the files under `/etc/skel/' since these will be new user's defaults when created with the `adduser' command. Note, however that users can modify their own `umask' setting if they want too, making it more permissive or more restricted. 4.10.13. Limiting what users can see/access ------------------------------------------- FIXME: Content needed. Tell of consequences of changing packages permissions when upgrading (and admin this paranoid should `chroot' his users BTW). If you need to grant users access to the system with a shell think about it very carefully. A user can, by default unless in a severely restricted environment (like a `chroot' jail), retrieve quite a lot of information from your system including: * some configuration files in `/etc'. However, Debian's default permissions for some sensitive files (which might, for example, contain passwords), will prevent access to critical information. To see which files are only accessible by the root user for example `find /etc -type f -a -perm 600 -a -uid 0' as superuser. * your installed packages, either by looking at the package database, at the `/usr/share/doc' directory or by guessing by looking at the binaries and libraries installed in your system. * some log files at `/var/log'. Note also that some log files are only accessible to root and the `adm' group (try `find /var/log -type f -a -perm 640') and some are even only available to the root user (try `find /var/log -type f -a -perm 600 -a -uid 0'). What can a user see in your system? Probably quite a lot of things, try this (take a deep breath): find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null The output is the list of files that a user can _see_ and the directories to which he has access. 4.10.13.1. Limiting access to other user's information ------------------------------------------------------ If you still grant shell access to users you might want to limit what information they can view from other users. Users with shell access have a tendency to create quite a number of files under their $HOMEs: mailboxes, personal documents, configuration of X/GNOME/KDE applications... In Debian each user is created with one associated group, and no two users belong to the same group. This is the default behavior: when the userX is created a group with name userX is created and the user is assigned to it. This avoids the concept of a _users_ group which might make it more difficult for users to hide information from other users. However, users' <$HOME> directories are created with 0755 permissions (group-readable and world-readable). The group permissions is not an issue since only the user belongs to the group, however the world permissions might (or might not) be an issue depending on your local policy. You can change this behaviour so that user creation provides different <$HOME> permissions. To change the behaviour for _new_ users when they get created, change _DIR_MODE_ in the configuration file `/etc/adduser.conf' to 0750 (no world-readable access). Users can still share information, but not directly in their <$HOME> directories unless they change its permissions. Note that this will prevent users from being able to set up personal pages (`~userX') if a web server is present, since the web server will not be able to read the <$HOME> directory and thus, the `public_html' directory under it. If you want to permit users to publish HTML pages in their `~userX/public_html' then change _DIR_MODE_ to 0751. This will allow the webserver to access that directory (which should be mode 0755) and provide the content published by users. 4.10.14. Generating user passwords ---------------------------------- There are many cases when an administrator needs to create many user accounts and provide passwords for all of them. Of course, the administrator could easily just set the password to be the same as the user's account name, but that would not be very sensitive security-wise. A better approach is to use a password generating program. Debian provides `makepasswd', `apg' and `pwgen' packages which provide programs (the name is the same as the package) that can be used for this purpose. `Makepasswd' will generate true random passwords with an emphasis on security over pronounceability while `pwgen' will try to make meaningless but pronounceable passwords (of course this might depend on your mother language). `Apg' has algorithms to provide for both (there is a client/server version for this program but it is not included in the Debian package). `Passwd' does not allow non-interactive assignation of passwords (since it uses direct tty access). If you want to change passwords when creating a large number of users you can create them using `adduser' with the `--disabled-login' option and then use `chpasswd' [1] (in the `passwd' package so you already have it installed). If you want to use a file with all the information to make users as a batch process you might be better off using `newusers'. [1] `Chpasswd' cannot handle MD5 password generation so it needs to be given the password in encrypted form before using it, with the `- e' option. 4.10.15. Checking user passwords -------------------------------- User passwords can sometimes become the _weakest link_ in the security of a given system. This is due to some users choosing weak passwords for their accounts (and the more of them that have access to it the greater the chances of this happening). Even if you established checks with the cracklib PAM module and password limits as described in Section 4.10.1, `User authentication: PAM' users will still be able to use weak passwords. Since user access might include remote shell access (over `ssh', hopefully) it's important that a remote attacker is not able to guess user passwords (after he has been able to do user enumeration by other means). A system administrator must, given a big number of users, check if the passwords they have are consistent with the local security policy. How to check? Try to crack them as an attacker would if he had access to the hashed passwords (the `/etc/shadow' file). An administrator can use `john' or `crack' (both are brute force password crackers) together with an appropriate wordlist [1] to check users' passwords and take appropriate action when a weak password is detected. [1] Try `apt-cache search wordlist' for a list of available packages which might provide wordlists. You can also retrieve wordlists from many ftp sites over the Internet. See ftp://ftp.ox.ac.uk/pub/wordlists or ftp://ftp.cerias.purdue.edu/pub/dict. 4.10.16. Logging off idle users ------------------------------- Idle users are usually a security problem, a user might be idle maybe because he's out to lunch or because a remote connection was broken and not re-established. For whatever the reason, idle users might lead to a compromise: * because the user's console might not be locked and can be accessed by an intruder. * because an attacker might be able to re-attach himself to a closed network connection and send commands to the remote shell (this is fairly easy if the remote shell is not encrypted as in the case of `telnet'). Some remote systems have even been compromised through an idle (detached) `screen'. Automatic disconnection of idle users is usually a part of the local security policy that must be enforced. There are several ways to do this: * If `bash' is the user shell, a system administrator can set a default `TMOUT' value (see bash(1)) which will make the shell automatically remote idle users. Note that it must be set with the `-o' option or users will be able to change (or unset) it. * Install `timeoutd' and configure `/etc/timeouts' according to your local security policy. The daemon will watch for idle users and time out their shells accordingly. * Install `autolog' and configure it to remove idle users. The `timeoutd' or `autolog' daemons are the preferred method since, after all, users can change their default shell or can, after running their default shell, switch to another (uncontrolled) shell. 4.11. Using tcpwrappers ----------------------- TCP wrappers were developed when there were no real packet filters available and access control was needed. The TCP wrappers allow you to allow or deny a service for a host or a domain and define a default allow or deny rule. If you want more information take a look at hosts_access(5). Many services installed in Debian are either: * launched through the tcpwrapper service (`tcpd') * compiled with libwrapper support built-in. On the one hand, for services configured in `/etc/inetd.conf' (this includes `telnet', `ftp', `netbios', `swat' and `finger') you will see that the configuration file executes `/usr/sbin/tcpd' first. On the other hand, even if a service is not launched by the `inetd' superdaemon, support for the tcp wrappers rules can be compiled into it. Services compiled with tcp wrappers in Debian include `ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf' (the GNOME activator daemon), `nessus' and many others. To see which packages use tcpwrappers try: $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//' Take this into account when running `tcpchk'. You can add services that are linked to the wrapper library into the `hosts.deny' and `hosts.allow' files but `tcpchk' will warn that it is not able to find those services since it looks for them in `/etc/inetd.conf' (the manpage is not totally accurate here). Now, here comes a small trick, and probably the smallest intrusion detection system available. In general, you should have a decent firewall policy as a first line, and tcp wrappers as the second line of defense. One little trick is to set up a [1] command in `/etc/hosts.deny' that sends mail to root whenever a denied service triggers wrappers: ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /usr/bin/mail -s "Connection to %d blocked" root) & _Beware_: The above printed example is open to a DoS attack by making many connections in a short period of time. Many emails mean a lot of file I/O by sending only a few packets. [1] be sure to use uppercase here since _spawn_ will not work 4.12. The importance of logs and alerts --------------------------------------- It is easy to see that the treatment of logs and alerts is an important issue in a secure system. Suppose a system is perfectly configured and 99% secure. If the 1% attack occurs, and there are no security measures in place to, first, detect this and, second, raise alarms, the system is not secure at all. Debian GNU/Linux provides some tools to perform log analysis, most notably `swatch', [1] `logcheck' or `log-analysis' (all will need some customisation to remove unnecessary things from the report). It might also be useful, if the system is nearby, to have the system logs printed on a virtual console. This is useful since you can (from a distance) see if the system is behaving properly. Debian's `/etc/syslog.conf' comes with a commented default configuration; to enable it uncomment the lines and restart `syslogd' ( `/etc/init.d/syslogd restart'): daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8 There is a lot regarding log analysis that cannot be fully covered here, a good resource for information is Counterpane's Log Analysis Resources (http://www.counterpane.com/log-analysis.html). In any case, even automated tools are no match for the best analysis tool: your brain. [1] there's a very good article on it written by Lance Spitzner (http://www.enteract.com/~lspitz/swatch.html) 4.12.1. Using and customising `logcheck' ---------------------------------------- The `logcheck' package in Debian is divided into two packages `logcheck' (the main program) and `logcheck-database' (a database of regular expressions for the program). The Debian default (in `/etc/cron.d/logcheck') is that `logcheck' is run daily at 2 AM and once after each reboot. This tool can be quite useful if properly customised to alert the administrator to unusual events in the system. `Logcheck' can be fully customised so that it can send mails from events recovered from the logs that are worthy of attention. The default installation includes profiles for ignored events and policy violations for three different setups (workstation, server and paranoid). The Debian package includes a configuration file `/etc/logcheck/logcheck.conf', sourced by the program, that defines which user the checks are sent to. It also provides a way for packages that provide services to implement