This is Info file Security-HOWTO.info, produced by Makeinfo version 1.68 from the input file /tmp/sgmltmp.Security-HOWTO26383.info.2. \input texinfo  File: Security-HOWTO.info, Node: Top, Next: Introduction, Up: (dir) Linux Security HOWTO ******************** Kevin Fenzi, `kevin@scrye.com' [amp ] Dave Wreski, `dave@nic.com' v0.9.20, 22 April 1999 This document is a general overview of security issues that face the administrator of Linux systems. It covers general security philosophy and a number of specific examples of how to better secure your Linux system from intruders. Also included are pointers to security-related material and programs. `Note': This is a beta version of this document. Improvements, constructive criticism, additions and corrections are gratefully accepted. Please mail your feedback to both authors. Be sure and include "Linux", "security" or "HOWTO" in the subject line of to mail to avoid spam filters and to bring your mail to the quick attention of the authors. * Menu: * Introduction:: * Overview:: * Physical Security:: * Local Security:: * Files and Filesystem Security:: * Password Security and Encryption:: * Kernel Security:: * Network Security:: * Security Preparation (before you go on-line):: * What To Do During and After a Breakin:: * Security Sources:: * Glossary:: * Frequently Asked Questions:: * Conclusion:: * Thanks to::  File: Security-HOWTO.info, Node: Introduction, Next: Overview, Prev: Top, Up: Top Introduction ************ This document covers some of the main issues that affect Linux security. General philosophy and net born resources are discussed. A number of other HOWTO documents overlap with security issues, and those documents have been pointed to wherever appropriate. This document is `not' meant to be a up to date exploits document. Large numbers of new exploits happen all the time. This document will tell you where to look for such up to date information, and will give some general methods to prevent such exploits from taking place. * Menu: * New Versions of this Document:: * Feedback:: * Disclaimer:: * Copyright Information::  File: Security-HOWTO.info, Node: New Versions of this Document, Next: Feedback, Up: Introduction New Versions of this Document ============================= New versions of this document will be periodically posted to `comp.os.linux.answers'. They will also be added to the various anonymous FTP sites that archive such information, including: `ftp://metalab.unc.edu/pub/Linux/docs/HOWTO' In addition, you should generally be able to find this document on the Linux World Wide Web home page via: `http://metalab.unc.edu/mdw/linux.html' Finally, the very latest version of this document should also be available in various formats from: `http://scrye.com/~kevin/lsh/'  File: Security-HOWTO.info, Node: Feedback, Next: Disclaimer, Prev: New Versions of this Document, Up: Introduction Feedback ======== All comments, error reports, additional information and criticism of all sorts should be directed to: `kevin@scrye.com' and `dave@nic.com' `Note': Please send your feedback to `both' authors. Also, be sure and include "Linux" "security", or "HOWTO" in your subject to avoid Kevin's spam filter.  File: Security-HOWTO.info, Node: Disclaimer, Next: Copyright Information, Prev: Feedback, Up: Introduction Disclaimer ========== No liability for the contents of this document can be accepted. Use the concepts, examples and other content at your own risk. Additionally, this is an early version, possibly with many inaccuracies or errors. A number of the examples and descriptions use the RedHat(tm) package layout and system setup. Your mileage may vary. As far as we know, only programs that, under certain terms may be used or evaluated for personal purposes will be described. Most of the programs will be available, complete with source, under GNU (http://www.gnu.org/copyleft/gpl.html)-like terms.  File: Security-HOWTO.info, Node: Copyright Information, Prev: Disclaimer, Up: Introduction Copyright Information ===================== This document is copyrighted (c)1998,1999 Kevin Fenzi and Dave Wreski, and distributed under the following terms: * Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium, physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the authors would like to be notified of any such distributions. * All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. * If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator, at `tjbynum@metalab.unc.edu'  File: Security-HOWTO.info, Node: Overview, Next: Physical Security, Prev: Introduction, Up: Top Overview ******** This document will attempt to explain some procedures and commonly-used software to help your Linux system be more secure. It is important to discuss some of the basic concepts first, and create a security foundation, before we get started. * Menu: * Why Do We Need Security?:: * How Secure Is Secure?:: * What Are You Trying to Protect?:: * Developing A Security Policy:: * Means of Securing Your Site:: * Organization of This Document::  File: Security-HOWTO.info, Node: Why Do We Need Security?, Next: How Secure Is Secure?, Up: Overview Why Do We Need Security? ======================== In the ever-changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becoming more and more of an issue. Security is now a basic requirement because global computing is inherently insecure. As your data goes from point A to point B on the Internet, for example, it may pass through several other points along the way, giving other users the opportunity to intercept, and even alter, it. Even other users on your system may maliciously transform your data into something you did not intend. Unauthorized access to your system may be obtained by intruders, also known as "crackers", who then use advanced knowledge to impersonate you, steal information from you, or even deny you access to your own resources. If you're wondering what the difference is between a "Hacker" and a "Cracker", see Eric Raymond's document, "How to Become A Hacker", available at http://sagan.earthspace.net/~esr/faqs/hacker-howto.html.  File: Security-HOWTO.info, Node: How Secure Is Secure?, Next: What Are You Trying to Protect?, Prev: Why Do We Need Security?, Up: Overview How Secure Is Secure? ===================== First, keep in mind that no computer system can ever be "completely secure". All you can do is make it increasingly difficult for someone to compromise your system. For the average home Linux user, not much is required to keep the casual cracker at bay. For high profile Linux users (banks, telecommunications companies, etc), much more work is required. Another factor to take into account is that the more secure your system is, the more intrusive your security becomes. You need to decide where in this balancing act your system will still usable, and yet secure for your purposes. For instance, you could require everyone dialing into your system to use a call-back modem to call them back at their home number. This is more secure, but if someone is not at home, it makes it difficult for them to login. You could also setup your Linux system with no network or connection to the Internet, but this makes it harder to surf the Web. If you are a large to medium-sized site, you should establish a Security Policy stating how much security is required by your site and what auditing is in place to check it. You can find a well-known security policy example at http://ds.internic.net/rfc/rfc2196.txt. It has been recently updated, and contains a great framework for establishing a security policy for your company.  File: Security-HOWTO.info, Node: What Are You Trying to Protect?, Next: Developing A Security Policy, Prev: How Secure Is Secure?, Up: Overview What Are You Trying to Protect? =============================== Before you attempt to secure your system, you should determine what level of threat you have to protect against, what risks you should or should not take, and how vulnerable your system is as a result. You should analyze your system to know what you're protecting, why you're protecting it, what value it has, and who has responsibility for your data and other assets. * Risk is the possibility that an intruder may be successful in attempting to access your computer. Can an intruder read or write files, or execute programs that could cause damage? Can they delete critical data? Can they prevent you or your company from getting important work done? Don't forget: someone gaining access to your account, or your system, can also impersonate you. Additionally, having one insecure account on your system can result in your entire network being compromised. If you allow a single user to login using a `.rhosts' file, or to use an insecure service, such as `tftp', you risk an intruder getting 'his foot in the door'. Once the intruder has a user account on your system, or someone else's system, it can be used to gain access to another system, or another account. * Threat is typically from someone with motivation to gain unauthorized access to your network or computer. You must decide who you trust to have access to your system, and what threat they could pose. There are several types of intruders, and it is useful to keep their different characteristics in mind as you are securing your systems. * `The Curious' - This type of intruder is basically interested in finding out what type of system and data you have. * `The Malicious' - This type of intruder is out to either bring down your systems, or deface your web page, or otherwise force you to spend time and money recovering from the damage he has caused. * `The High-Profile Intruder' - This type of intruder is trying to use your system to gain popularity and infamy. He might use your high-profile system to advertise his abilities. * `The Competition' - This type of intruder is interested in what data you have on your system. It might be someone who thinks you have something that could benefit him, financially or otherwise. * `The Borrowers' - This type of intruder is interested in setting up shop on your system and using it's resources for their own purposes. They typically will run chat or irc servers, porn archive sites, or even DNS servers. * `The Leapfrogger' - This type of intruder is only interested in your system to use it to get into other systems. If your system is well connected or a gateway to a number of internal hosts, you may well see this type trying to compromise your system. * "Vulnerability" describes how well-protected your computer is from another network, and the potential for someone to gain unauthorized access. What's at stake if someone breaks into your system? Of course the concerns of a dynamic PPP home user will be different from those of a company connecting their machine to the Internet, or another large network. How much time would it take to retrieve/recreate any data that was lost? An initial time investment now can save ten times more time later if you have to recreate data that was lost. Have you checked your backup strategy, and verified your data lately?  File: Security-HOWTO.info, Node: Developing A Security Policy, Next: Means of Securing Your Site, Prev: What Are You Trying to Protect?, Up: Overview Developing A Security Policy ============================ Create a simple, generic policy for your system that your users can readily understand and follow. It should protect the data you're safeguarding as well as the privacy of the users. Some things to consider adding are: who has access to the system (Can my friend use my account?), who's allowed to install software on the system, who owns what data, disaster recovery, and appropriate use of the system. A generally accepted security policy starts with the phrase ` That which is not permitted is prohibited' This means that unless you grant access to a service for a user, that user shouldn't be using that service until you do grant access. Make sure the policies work on your regular user account. Saying, "Ah, I can't figure this permissions problem out, I'll just do it as root" can lead to security holes that are very obvious, and even ones that haven't been exploited yet. rfc1244 is a docuemnt that describes how to create your own network security polity. rfc1281 is a document that shows an example security policy with detailed descriptions of each step. Finally, you might want to look at the COAST policy archive to see what some real life security policies look like.  File: Security-HOWTO.info, Node: Means of Securing Your Site, Next: Organization of This Document, Prev: Developing A Security Policy, Up: Overview Means of Securing Your Site =========================== This document will discuss various means with which you can secure the assets you have worked hard for: your local machine, your data, your users, your network, even your reputation. What would happen to your reputation if an intruder deleted some of your users' data? Or defaced your web site? Or published your company's corporate project plan for next quarter? If you are planning a network installation, there are many factors you must take into account before adding a single machine to your network. Even if you have a single dialup PPP account, or just a small site, this does not mean intruders won't be interested in your systems. Large, high profile sites are not the only targets - many intruders simply want to exploit as many sites as possible, regardless of their size. Additionally, they may use a security hole in your site to gain access to other sites you're connected to. Intruders have a lot of time on their hands, and can avoid guessing how you've obscured your system just by trying all the possibilities. There are also a number of reasons an intruder may be interested in your systems, which we will discuss later. * Menu: * Host Security:: * Your Network Security:: * Security Through Obscurity::  File: Security-HOWTO.info, Node: Host Security, Next: Your Network Security, Up: Means of Securing Your Site Host Security ------------- Perhaps the area of security on which administrators concentrate most is host-based security. This typically involves making sure your own system is secure, and hoping everyone else on your network does the same. Choosing good passwords, securing your host's local network services, keeping good accounting records, and upgrading programs with known security exploits are among the things the local security administrator is responsible for doing. Although this is absolutely necessary, it can become a daunting task once your network becomes larger than a few machines.  File: Security-HOWTO.info, Node: Your Network Security, Next: Security Through Obscurity, Prev: Host Security, Up: Means of Securing Your Site Your Network Security --------------------- Network security is also as necessary as local host security. With hundreds, thousands, or more computers on the same network, you can't rely on each one of those systems being secure. Ensuring that only authorized users can use your network, building firewalls, using strong encryption, and ensuring there are no "rogue" (that is, unsecured) machines on your network are all part of the network security administrator's duties. This document will discuss some of the techniques used to secure your site, and hopefully show you some of the ways to prevent an intruder from gaining access to what you are trying to protect.  File: Security-HOWTO.info, Node: Security Through Obscurity, Prev: Your Network Security, Up: Means of Securing Your Site Security Through Obscurity -------------------------- One type of security that must be discussed is "security through obscurity". This means, for example, moving a service that has known security vunerabilities to a non standard port in hopes that attackers won't notice it's there and thus won't exploit it. Rest assured that they can determine that its there and will exploit it. Security through obscurity is no security at all. Simply because you may have a small site, or a relatively low profile, does not mean an intruder won't be interested in what you have. We'll discuss what you're protecting in the next sections.  File: Security-HOWTO.info, Node: Organization of This Document, Prev: Means of Securing Your Site, Up: Overview Organization of This Document ============================= This document has been divided into a number of sections. They cover several broad security issues. The first, *Note Physical Security:: , covers how you need to protect your physical machine from tampering. The second, *Note Local Security:: , describes how to protect your system from tampering by local users. The third, *Note Files and Filesystem Security:: , shows you how to setup your filesystems and premissions on your files. The next, *Note Password Security and Encryption:: ,discusses how to use encryption to better secure your machine and network. *Note Kernel Security:: discusses what kernel options you should set or be aware of for a more secure system. *Note Network Security:: describes how to better secure your Linux system from network attacks. *Note Security Preparation (before you go on-line):: discusses how to prepair your machine(s) before bringing them on-line. Next, *Note What To Do During and After a Breakin:: discusses what to do when you detect a system compromise in progress or detect one that has recently happened. Then *Note Security Sources:: resources are enumerated, and finally *Note Frequently Asked Questions:: and *Note Conclusion:: . few closing words. The two main points to realize when reading this document are: * Be aware of your system. Check system logs such as `/var/log/messages' and keep an eye on your system, and * Keep your system up to date by making sure you have installed the current versions of software and have upgraded per security alerts. Just doing this will help make your system markedly more secure.  File: Security-HOWTO.info, Node: Physical Security, Next: Local Security, Prev: Overview, Up: Top Physical Security ***************** The first layer of security you need to take into account is the physical security of your computer systems. Who has direct physical access to your machine? Should they? Can you protect your machine from their tampering? Should you? How much physical security you need on your system is very dependent on your situation, and/or budget. If you are a home user, you probably don't need a lot (although you might need to protect your machine from tampering by children or annoying relatives). If you are in a Lab, you need considerably more, but users will still need to be able to get work done on the machines. Many of the following sections will help out. If you are in an office, you may or may not need to secure your machine off hours or while you are away. At some companies, leaving your console unsecured is a termination offense. Obvious physical security methods such as locks on doors, cables, locked cabinets, and video surveillance are all good ideas, but beyond the scope of this document. :) * Menu: * Computer locks:: * BIOS Security:: * Boot Loader Security:: * xlock and vlock:: * Detecting Physical Security Compromises::  File: Security-HOWTO.info, Node: Computer locks, Next: BIOS Security, Up: Physical Security Computer locks ============== Many modern PC cases include a "locking" feature. Usually this will be a socket on the front of the case that allows you to turn an included key to a locked or unlocked position. Case locks can help prevent someone from stealing your PC, or opening up the case and directly manipulating/stealing your hardware. They can also sometimes prevent someone from rebooting your computer on their own floppy or other hardware. These case locks do different things according to the support in the motherboard and how the case is constructed. On many PC's they make it so you have to break the case to get the case open. On some others, they make it so that it will not let you plug in new keyboards and mice. Check your motherboard or case instructions for more information. This can sometimes be a very useful feature, even though the locks are usually very low quality and can easily be defeated by attackers with locksmithing. Some cases (most notably SPARCs and macs) have a dongle on the back that, if you put a cable through attackers would have to cut the cable or break the case to get into it. Just putting a padlock or combo lock through these can be a good deterrent to someone stealing your machine.  File: Security-HOWTO.info, Node: BIOS Security, Next: Boot Loader Security, Prev: Computer locks, Up: Physical Security BIOS Security ============= The BIOS is the lowest level of software that configures or manipulates your x86-based hardware. LILO and other Linux boot methods access the BIOS to determine how to boot up your Linux machine. Other hardware that Linux runs on has similar software (OpenFirmware on Macs and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent attackers from rebooting your machine and manipulating your Linux system. Many PC BIOSs let you set a boot password. This doesn't provide all that much security (the BIOS can be reset, or removed if someone can get into the case), but might be a good deterrent (i.e. it will take time and leave traces of tampering). Similarly, on S/Linux (Linux for SPARC(tm) porcessor machines), your EEPROM can be set to require a boot-up password. This might slow attackers down. Many x86 BIOSs also allow you to specify various other good security settings. Check your BIOS manual or look at it the next time you boot up. For example, some BIOSs disallow booting from floppy drives and some require passwords to access some BIOS features. `Note': If you have a server machine, and you set up a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure. ;(  File: Security-HOWTO.info, Node: Boot Loader Security, Next: xlock and vlock, Prev: BIOS Security, Up: Physical Security Boot Loader Security ==================== The various Linux boot loaders also can have a boot password set. LILO, for example, has `password' and `restricted' settings; `password' always requires password at boot time, whereas `restricted' requires a boot-time password only if you specify options (such as `single') at the `LILO ' prompt. Keep in mind when setting all these passwords that you need to remember them. :) Also remember that these passwords will merely slow the determined attacker. They won't prevent someone from booting from a floppy, and mounting your root partition. If you are using security in conjunction with a boot loader, you might as well disable booting from a floppy in your computer's BIOS, and password-protect the BIOS. If anyone has security-related information from a different boot loader, we would love to hear it. (`grub', `silo', `milo', `linload', etc). `Note': If you have a server machine, and you set up a boot password, your machine will `not' boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure. ;(  File: Security-HOWTO.info, Node: xlock and vlock, Next: Detecting Physical Security Compromises, Prev: Boot Loader Security, Up: Physical Security xlock and vlock =============== If you wander away from your machine from time to time, it is nice to be able to "lock" your console so that no one tampers with or looks at your work. Two programs that do this are: `xlock' and `vlock'. `xlock' is a X display locker. It should be included in any Linux distributions that support X. Check out the man page for it for more options, but in general you can run `xlock' from any xterm on your console and it will lock the display and require your password to unlock. `vlock' is a simple little program that allows you to lock some or all of the virtual consoles on your Linux box. You can lock just the one you are working in or all of them. If you just lock one, others can come in and use the console; they will just not be able to use your virtual console until you unlock it. `vlock' ships with redhat Linux, but your mileage may vary. Of course locking your console will prevent someone from tampering with your work, but won't prevent them from rebooting your machine or otherwise disrupting your work. It also does not prevent them from accessing your machine from another machine on the network and causing problems. More importantly, it does not prevent someone from switching out of the X Window System entirely, and going to a normal virtual console login prompt, or to the VC that X11 was started from, and suspending it, thus obtaining your priviledges. For this reason, you might consider only using it while under control of xdm.  File: Security-HOWTO.info, Node: Detecting Physical Security Compromises, Prev: xlock and vlock, Up: Physical Security Detecting Physical Security Compromises ======================================= The first thing to always note is when your machine was rebooted. Since Linux is a robust and stable OS, the only times your machine should reboot is when `you' take it down for OS upgrades, hardware swapping, or the like. If your machine has rebooted without you doing it, that may be a sign that an intruder has compromised it. Many of the ways that your machine can be compromised require the intruder to reboot or power off your machine. Check for signs of tampering on the case and computer area. Although many intruders clean traces of their presence out of logs, it's a good idea to check through them all and note any discrepancy. It is also a good idea to store log data at a secure location, such as a dedicated log server within your well-protected network. Once a machine has been compromised, log data becomes of little use as it most likely has also been modified by the intruder. The syslog daemon can be configured to automatically send log data to a central syslog server, but this is typically sent in cleartext data, allowing an intruder to view data as it is being transferred. This may reveal information about your network that is not intended to be public. There are syslog daemons available that encrypt the data as it is being sent. Also be aware that faking syslog messages is easy - with an exploit program having been published. Syslog even accepts net log entries claiming to come from the local host without indicating their true origin. Some things to check for in your logs: * Short or incomplete logs. * Logs containing strange timestamps. * Logs with incorrect permissions or ownership. * Records of reboots or restarting of services. * missing logs. * su entries or logins from strange places. We will discuss system log data *Note Keep Track of Your System Accounting Data:: in the HOWTO.  File: Security-HOWTO.info, Node: Local Security, Next: Files and Filesystem Security, Prev: Physical Security, Up: Top Local Security ************** The next thing to take a look at is the security in your system against attacks from local users. Did we just say `local' users? yes. Getting access to a local user account is one of the first things that system intruders attempt while on their way to exploiting the root account. With lax local security, they can then "upgrade" their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump. Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or have no contact information for is a very bad idea. * Menu: * Creating New Accounts:: * Root Security::  File: Security-HOWTO.info, Node: Creating New Accounts, Next: Root Security, Up: Local Security Creating New Accounts ===================== You should make sure to provide user accounts with only the minimal requirements for the task they need to do. If you provide your son (age 10) with an account, you might want him to only have access to a word processor or drawing program, but be unable to delete data that is not his. Several good rules of thumb when allowing other people legitimate access to your Linux machine: * Give them the minimal amount of privileges they need. * Be aware when/where they login from, or should be logging in from. * Make sure to remove inactive accounts * The use of the same user-ID on all computers and networks is advisable to ease account maintence, as well as permit easier analysis of log data. * The creation of group user-IDs should be absolutely prohibited. User accounts also provide accountability, and this is not possible with group accounts. Many local user accounts that are used in security compromises are ones that have not been used in months or years. Since no one is using them they, provide the ideal attack vehicle.  File: Security-HOWTO.info, Node: Root Security, Prev: Creating New Accounts, Up: Local Security Root Security ============= The most sought-after account on your machine is the root (superuser) account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short, specific tasks, and should mostly run as a normal user. Even small mistakes made while logged in as the root user can cause problems. The less time you are on with root privledges, the safer you will be. Several tricks to avoid messing up your own box as root: * When doing some complex command, try running it first in a non-destructive way...especially commands that use globbing: e.g., if you want to do ` "rm foo*.bak"', first do `"ls foo*.bak"' and make sure you are going to delete the files you think you are. Using `echo' in place of destructive commands also sometimes works. * Provide your users with a default alias to the rm command to ask for confirmation for deletion of files. * Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are `sure' what needs to be done by root. * The command path for the root user is very important. The command path (that is, the `PATH' environment variable) specifies the directories in which the shell searches for programs. Try to limit the command path for the root user as much as possible, and never include `.' (which means "the current directory") in your PATH. Additionally, never have writable directories in your search path, as this can allow attackers to modify or place new binaries in your search path, allowing them to run as root the next time you run that command. * Never use the rlogin/rsh/rexec suite of tools (called the r-utilities) as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a `.rhosts' file for root. * The `/etc/securetty' file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles(vtys). Be very careful of adding anything else to this file. You should be able to login remotely as your regular user account and then `su' if you need to (hopefully over ` *Note `ssh' (Secure Shell) and `stelnet':: ' or other encrypted channel), so there is no need to be able to login directly as root. * Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type! If you absolutely positively need to allow someone (hopefully very trusted) to have root access to your machine, there are a few tools that can help. `sudo' allows users to use their password to access a limited set of commands as root. This would allow you to, for instance, let a user be able to eject and mount removable media on your Linux box, but have no other root privileges. `sudo' also keeps a log of all successful and unsuccessful sudo attempts, allowing you to track down who used what command to do what. For this reason `sudo' works well even in places where a number of people have root access, because it helps you keep track of changes made. Although `sudo' can be used to give specific users specific privileges for specific tasks, it does have several shortcomings. It should be used only for a limited set of tasks, like restarting a server, or adding new users. Any program that offers a shell escape will give root access to a user invoking it via `sudo'. This includes most editors, for example. Also, a program as innocuous as `/bin/cat' can be used to overwrite files, which could allow root to be exploited. Consider `sudo' as a means for accountability, and don't expect it to replace the root user and still be secure.  File: Security-HOWTO.info, Node: Files and Filesystem Security, Next: Password Security and Encryption, Prev: Local Security, Up: Top Files and Filesystem Security ***************************** A few minutes of preparation and planning ahead before putting your systems online can help to protect them and the data stored on them. * There should never be a reason for users' home directories to allow SUID/SGID programs to be run from there. Use the `nosuid' option in `/etc/fstab' for partitions that are writable by others than root. You may also wish to use `nodev' and `noexec' on users' home partitions, as well as `/var', thus prohibiting execution of programs, and creation of character or block devices, which should never be necessary anyway. * If you are exporting filesystems using NFS, be sure to configure `/etc/exports' with the most restrictive access possible. This means not using wildcards, not allowing root write access, and exporting read-only wherever possible. * Configure your users' file-creation `umask' to be as restrictive as possible. See *Note Umask Settings:: . * If you are mounting filesystems using a network filesystem such as NFS, be sure to configure /etc/exports with suitable restrictions. Typically, using `nodev', `nosuid', and perhaps `noexec', are desireable. * Set filesystem limits instead of allowing `unlimited' as is the default. You can control the per-user limits using the resource-limits PAM module and `/etc/pam.d/limits.conf'. For example, limits for group `users' might look like this: @users hard core 0 @users hard nproc 50 @users hard rss 5000 This says to prohibit the creation of core files, restrict the number of processes to 50, and restrict memory usage per user to 5M. * The `/var/log/wtmp' and `/var/run/utmp' files contain the login records for all users on your system. Their integrity must be maintained because it can be used to determine when and from where a user (or potential intruder) has entered your system. These files should also have `644' permissions, without affecting normal system operation. * The immutable bit can be used to prevent accidentally deleting or overwriting a file that must be protected. It also prevents someone from creating a symbolic link to the file (such symbolic links have been the source of attacks involving deleting `/etc/passwd' or `/etc/shadow'). See the `chattr'(1) man page for information on the immutable bit. * SUID and SGID files on your system are a potential security risk, and should be monitored closely. Because these programs grant special privileges to the user who is executing them, it is necessary to ensure that insecure programs are not installed. A favorite trick of crackers is to exploit SUID-root programs, then leave a SUID program as a backdoor to get in the next time, even if the original hole is plugged. Find all SUID/SGID programs on your system, and keep track of what they are, so you are aware of any changes which could indicate a potential intruder. Use the following command to find all SUID/SGID programs on your system: root# find / -type f \( -perm -04000 -o -perm -02000 \) The debian distribution runs a job each night to determine what SUID files exist. It then compairs this to the previous nights run. You can look in /var/log/suid* for this log. You can remove the SUID or SGID permissions on a suspicious program with `chmod', then change it back if you absolutely feel it is necessary. * World-writable files, particularly system files, can be a security hole if a cracker gains access to your system and modifies them. Additionally, world-writable directories are dangerous, since they allow a cracker to add or delete files as he wishes. To locate all world-writable files on your system, use the following command: root# find / -perm -2 ! -type l -ls and be sure you know why those files are writable. In the normal course of operation, several files will be writable, including some from `/dev', and symbolic links. * Unowned files may also be an indication an intruder has accessed your system. You can locate files on your system that have no owner, or belong to no group with the command: root# find / -nouser -o -nogroup -print * Finding `.rhosts' files should be a part of your regular system administration duties, as these files should not be permitted on your system. Remember, a cracker only needs one insecure account to potentially gain access to your entire network. You can locate all `.rhosts' files on your system with the following command: root# find /home -name .rhosts -print * Finally, before changing permissions on any system files, make sure you understand what you are doing. Never change permissions on a file because it seems like the easy way to get things working. Always determine why the file has that permission before changing it. * Menu: * Umask Settings:: * File Permissions:: * Integrity Checking with Tripwire `Tripwire':: * Trojan Horses::  File: Security-HOWTO.info, Node: Umask Settings, Next: File Permissions, Up: Files and Filesystem Security Umask Settings ============== The `umask' command can be used to determine the default file creation mode on your system. It is the octal complement of the desired file mode. If files are created without any regard to their permissions settings, the user could inadvertently give read or write permission to someone that should not have this permission. Typically `umask' settings include `022', `027', and `077' (which is the most restrictive). Normally the umask is set in `/etc/profile', so it applies to all users on the system. For example, you may have a line that looks like this: # Set the user's default umask umask 033 Be sure to make root's umask `077', which will disable read, write, and execute permission for other users, unless explicitly changed using `chmod'. If you are using Red Hat, and adhere to their user and group ID creation scheme (User Private Groups), it is only necessary to use `002' for a `umask'. This is due to the fact that the default configuration is one user per group.  File: Security-HOWTO.info, Node: File Permissions, Next: Integrity Checking with Tripwire `Tripwire', Prev: Umask Settings, Up: Files and Filesystem Security File Permissions ================ It's important to ensure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintenance. Unix seperates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else. A quick explanation of Unix permissions: Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node Permissions - Bits capable of being set or reset to allow certain types of access to it. Permissions for directories may have a different meaning than the same set of permissions on files. `Read:' * To be able to view contents of a file * To be able to read a directory `Write:' * To be able to add to or change a file * To be able to delete or move files in a directory `Execute:' * To be able to run a binary program or shell script * To be able to search in a directory, combined with read permission `Save Text Attribute: (For directories)' The "sticky bit" also has a different meaning when applied to directories than when applied to files. If the sticky bit is set on a directory, then a user may only delete files that the he owns or for which he has explicit write permission granted, even when he has write access to the directory. This is designed for directories like `/tmp', which are world-writable, but where it may not be desirable to allow any user to delete files at will. The sticky bit is seen as a `t' in a long directory listing. `SUID Attribute: (For Files)' This describes set-user-id permissions on the file. When the set user ID access mode is set in the owner permissions, and the file is executable, processes which run it are granted access to system resources based on user who owns the file, as opposed to the user who created the process. This is the cause of many "buffer overflow" exploits. `SGID Attribute: (For Files)' If set in the group permissions, this bit controls the "set group id" status of a file. This behaves the same way as SUID, except the group is affected instead. The file must be executable for this to have any effect. `SGID Attribute: (For directories)' If you set the SGID bit on a directory (with `chmod g+s `directory"), files created in that directory will have their group set to the directory's group. You - The owner of the file Group - The group you belong to Everyone - Anyone on the system that is not the owner or a member of the group `File Example:' -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directory? (no) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (no) 5th bit - read by group? (yes, by users) 6th bit - write by group? (no) 7th bit - execute by group? (no) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (no) The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed here, but this should describe what these minimum permissions on files do: -r-------- Allow read access to the file by owner --w------- Allows the owner to modify or delete the file (Note that anyone with write permission to the directory the file is in can overwrite it and thus delete it) ---x------ The owner can execute this program, but not shell scripts, which still need read permission ---s------ Will execute with effective User ID = to owner --------s- Will execute with effective Group ID = to group -rw------T No update of "last modified time". Usually used for swap files ---t------ No effect. (formerly sticky bit) `Directory Example:' drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directory? (yes, it contains many files) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (yes, by kevin) 5th bit - read by group? (yes, by users 6th bit - write by group? (no) 7th bit - execute by group? (yes, by users) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (yes, by everyone) The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed, but this should describe what these minimum permissions on directories do: dr-------- The contents can be listed, but file attributes can't be read d--x------ The directory can be entered, and used in full execution paths dr-x------ File attributes can be read by owner d-wx------ Files can be created/deleted, even if the directory isn't the current one d------x-t Prevents files from deletion by others with write access. Used on /tmp d---s--s-- No effect System configuration files (usually in `/etc') are usually mode `640' (`-rw-r----'), and owned by root. Depending on your sites security requirements, you might adjust this. Never leave any system files writable by a group or everyone. Some configuration files, including `/etc/shadow', should only be readable by root, and directories in `/etc' should at least not be accessible by others. `SUID Shell Scripts' SUID shell scripts are a serious security risk, and for this reason the kernel will not honor them. Regardless of how secure you think the shell script is, it can be exploited to give the cracker a root shell.  File: Security-HOWTO.info, Node: Integrity Checking with Tripwire `Tripwire', Next: Trojan Horses, Prev: File Permissions, Up: Files and Filesystem Security Integrity Checking with Tripwire `Tripwire' =========================================== Another very good way to detect local (and also network) attacks on your system is to run an integrity checker like `Tripwire'. `Tripwire' runs a number of checksums on all your important binaries and config files and compares them against a database of former, known-good values as a reference. Thus, any changes in the files will be flagged. It's a good idea to install `Tripwire' onto a floppy, and then physically set the write protect on the floppy. This way intruders can't tamper with `Tripwire' itself or change the database. Once you have `Tripwire' setup, it's a good idea to run it as part of your normal security administration duties to see if anything has changed. You can even add a `crontab' entry to run `Tripwire' from your floppy every night and mail you the results in the morning. Something like: # set mailto MAILTO=kevin # run Tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire will mail you a report each morning at 5:15am. `Tripwire' can be a godsend to detecting intruders before you would otherwise notice them. Since a lot of files change on the average system, you have to be careful what is cracker activity and what is your own doing.