Linux Security HOWTO <AUTHOR>Kevin Fenzi, <tt>kevin@scrye.com</tt> &ero Dave Wreski, <tt>dave@nic.com</tt> <DATE>v0.9.16, 24 June 1998 <ABSTRACT> 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 your mail to avoid spam filters and to bring your mail to the quick attention of the authors. </ABSTRACT> <TOC>  <SECT> Introduction This document covers some of the main security 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 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 some general methods to prevent such exploits from taking place.  <SECT1> New Versions of this Document New versions of this document will be periodically posted to <it>comp.os.linux.answers</it>. They will also be added to the various anonymous FTP sites who archive such information, including: <tt> <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO" name="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO"> </tt> In addition, you should generally be able to find this document on the Linux Worldwide Web home page via: <tt> <htmlurl url="http://sunsite.unc.edu/mdw/linux.html" name="http://sunsite.unc.edu/mdw/linux.html"> </tt> Finally, the very latest version of this document should also be available in various formats from: <tt> <htmlurl url="http://scrye.com/~kevin/lsh/" name="http://scrye.com/~kevin/lsh/"> </tt>  <SECT1> Feedback All comments, error reports, additional information and criticism of all sorts should be directed to: <tt> <htmlurl url="mailto:kevin@scrye.com" name="kevin@scrye.com"> </tt> and <tt> <htmlurl url="mailto:dave@nic.com" name="dave@nic.com"> </tt> 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.  <SECT1> Disclaimer No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. Additionally, this is an early version, with many possibilities for inaccuracies and 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-like terms.  <SECT1> Copyright Information This document is copyrighted (c)1998 Kevin Fenzi and Dave Wreski, and distributed under the following terms: <ITEMIZE> <ITEM> 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. <ITEM> 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. <ITEM> If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator, at </ITEMIZE> <tt> <htmlurl url="mailto:tjbynum@sunsite.unc.edu" name="tjbynum@sunsite.unc.edu"> </tt>  <SECT> 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 foundatation before we get started.  <SECT1> Why Do We Need Security? In the ever-changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becomming 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, your data. 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 still wondering what the difference is between a "Hacker" and a "Cracker", see Eric Raymond's document, "How to Become A Hacker", available at <htmlurl url="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html" name="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html">.  <SECT1> 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 is 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 <htmlurl url="http://ds.internic.net/rfc/rfc2196.txt" name="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. It is even advisable to generate a security policy for systems with more than one user.  <SECT1> 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. <ITEMIZE><ITEM> Risk is the possibility that an intruder may be successful in attempting to access your computer. Can an intruder read, write files, or execute programs that could cause damage? Can they delete critical data? 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. A single user that is allowed to login using an rhosts file, or allowing the use of an insecure service, such as tftp, you risk an intruder using this to 'get 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. <ITEM> Threat is typically from someone with motivation to gain unathorized access to your network, or computer. You must decide who you trust to have access to your system, and what threat they could impose. There are several types of intruders, and it is useful to keep the different characteristics in mind as you are securing your systems. <ITEMIZE> <ITEM><bf>The Curious</bf> - This type of intruder is basically interested in finding out what type of system and data, you have. </item> <ITEM><bf>The Malicious</bf> - This type of intruder is out to either bring down your systems, or deface your web page, or otherwise cause you time and money to recover. </item> <ITEM><bf>The High-Profile Intruder</bf> - 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. </item> <ITEM><bf>The Competition</bf> - 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. </item> </ITEMIZE><ITEM> Vulnerability describes how well protected your computer is from another network, and the potential for someone gaining unathorized access. What's at stake if someone breaks into your system? Of course the concerns of a dynamic PPP home user will be different than 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? </ITEMIZE>  <SECT1> 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: <quote><bf> "That which is not permitted is prohibited"</bf></quote> 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.  <SECT1> Means of Securing Your Site This document will discuss various means in which you can secure the assets you have worked hard for: your local machine, data, users, network, even your reputation. What would happen to your reputation if an intruder deleted some of your user's 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 several reasons an intruder may be interested in your systems, which we will discuss later.  <SECT2> Host Security Perhaps the area of most concentration on security is done with 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 of machines becomes larger.  <SECT2> Your Network Security Network security is also as necessary as local host security. With your single system, or a distributed computing network, the Internet, or hundreds, if not thousands or more computers on the same network, you can't rely on each one of those systems being secure. Making sure authorized users are the only ones permitted to use your network resources, building firewalls, using strong encryption, and ensuring there are no rogue, or 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.  <SECT2> Security Through Obscurity One type of security that must be discussed is "security through obscurity". This means that by doing something like changing the login name from 'root' to 'toor', for example, to try and obscure someone from breaking into your system as root is only a false sense of security, and will result in very unpleasant consequences. Rest assured that any system attacker will quickly see through such empty security measures. Simply because you may have a small site, or relatively low profile does not mean an intruder won't be interested in what you have. We'll discuss what your protecting in the next sections.  <SECT1> Organization of This Document This document has been segregated into a number of sections. They cover several broad kinds of security issues. The first, physical security, covers how you need to protect your physical machine from tampering. The second describes how to protect your system from tampering by local users. The third, files and filesystem security show you how to setup your filesystems and premissions on your files. The next, password security and encryption discusses how to use encryption to better secure your machine and network. Kernel security discusses what kernel options you should set or be aware of for a more secure machine. network security, describes how to better secure your Linux system from network attacks. Security preparation discusses how to prepair your machine(s) before bringing them on-line. The next discusses what to do when you detect a system compromise in progress or detect one that has recently happened. Then links to other security resources are enumerated, and finally some questions and answers and a few closing words. The two main points to realize when reading this document are: <ITEMIZE> <ITEM> Be aware of your system. Check system logs such as /var/log/messages and keep an eye on your system, and <ITEM> Keep your system up to date by making sure you have installed the current versions of software and have upgraded per security alerts, or otherwise improved the security of any suspect programs. Just doing this will help make your system markedly more secure. </ITEMIZE>  <SECT> 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 environment, 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 a 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 a good idea, but beyond the scope of this document. :)  <SECT1> Computer locks Many more 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.  <SECT1> 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. Under Linux/x86 many PC BIOSs let you set a boot password. This doesn't provide all that much security (BIOS can be reset, or removed if someone can get into the case), but might be a good deterrent (ie it will take time and leave traces of tampering). 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. Some examples are: disallow booting from floppy drives and passwords to access some bios features. On S/Linux, (Linux for SPARC(tm) processor machines) your EEPROM can be set to require a boot-up password. This might slow attackers down. NOTE: If you have a server machine, and you setup 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. ;(  <SECT1> Boot Loader Security The various Linux boot loaders also can have a boot password set. Using lilo, take a look at the "restricted" and "password" settings. "password" allows you to set a bootup password. "restricted" will let the machine boot _unless_ someone specifies options at the lilo: prompt (like 'single'). 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. This 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, as well as password-protecting your computer's BIOS. If anyone has security related information from a different boot loader, we would love to hear it. (grub, silo, milo, loadlin, etc). NOTE: If you have a server machine, and you setup 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. ;(  <SECT1> 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 vty 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 does not 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.  <SECT1> 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, a trouble light should go on. 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: <ITEMIZE> <ITEM>Short or incomplete logs. <ITEM>Logs containing strange timestamps. <ITEM>Logs with incorrect permissions or ownership. <ITEM>Records of reboots or restarting of services. <ITEM>missing logs. <ITEM>su entries or logins from strange places. </ITEMIZE> We will discuss system log data later in the HOWTO.  <SECT> 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 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.  <SECT1> 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 secretary, or another general user, with an account, you might want them to only have access to a word processor or drawing program, but be unable to delete data that is not his or hers. Several good rules of thumb when allowing other people legitimate access to your Linux machine: <ITEMIZE> <ITEM> Limit access privileges given to new uers. <ITEM> Be aware when/where they login from, or should be logging in from. <ITEM> Make sure to remove inactive accounts <ITEM> 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. <ITEM> The creation of group user-IDs should be absolutely prohibited. User accounts also provide accountability, and this is not possible with group accounts. </ITEMIZE> 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.  <SECT1> Root Security The most sought-after account on your machine is the 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. Running as root all the time is a very very very bad idea. Several tricks to avoid messing up your own box as root: <ITEMIZE> <ITEM> When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: ie, you are going to do a "rm foo*.bak", instead, 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. <ITEM> Provide your users with a default alias to the rm command to ask for confirmation for deletion of files. <ITEM> 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 <bf>sure</bf> what needs to be done by root. <ITEM> The command path for the root user is very important. The command path, or the PATH environment variable, defines the location the shell searches for programs. Try and limit the command path for the root user as much as possible, and never use '.', meaning 'the current directory', in your PATH statement. 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. <ITEM> Never use the rlogin/rsh/rexec (called the r-utilities) suite of tools as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a .rhosts file for root. <ITEM> 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 ssh or other encrypted channel), so there is no need to be able to login directly as root. <ITEM> Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type! </ITEMIZE> If you absolutely positively need to allow someone (hopefully very trusted) to have superuser 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. Sudo 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, but use sudo so you can 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 the user root access. This includes most editors, for example. Also, a program as innocous 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 yet be secure.  <SECT> Files and Filesystem Security A few minutes of preparation and planning ahead before putting your systems online can help to protect your system, and the data that is stored on them. <ITEMIZE> <ITEM> There should never be a reason for user's 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 user's home partitions, as well as /var, which prohibit execution of programs, and creation of character or block devices, which should never be necessary anyway. <ITEM> 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. <ITEM> Configure your user's file-creation umask to be as restrictive as possible. Commonly used settings are 022, 033, and the most restrictive 077, and are added to /etc/profile. The file creation mask must be set while keeping in mind the purpose of the account. Permissions that are too restrictive may cause users to start sharing accounts or passwords, or otherwise compromise security. Further information is available in the <ITEM> 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. <ITEM> 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: <tscreen><verb> @users hard core 0 @users hard nproc 50 @users hard rss 5000</verb></tscreen> This says to prohibit the creation of core files, restrict the number of processes to 50, and restrict memory usage per user to 5M. <ITEM> The /var/log/wtmp and /var/run/utmp files contain the login records for all users on your system. Its 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. <ITEM> 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: <tscreen><verb> root# find / -type f \( -perm -04000 -o -perm -02000 \) </verb></tscreen> 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 descriminitely remove the SUID or SGID permissions on a suspicious program with chmod(1), then change it back if you absolutely feel it is necessary. <ITEM> 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: <tscreen><verb> root# find / -perm -2 ! -type l -ls </verb></tscreen> 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. <ITEM> Unowned files may also be an indication an intruder has accessed your system. You can locate files on your system that do not have an owner, or belong to a group with the command: <tscreen><verb> root# find / -nouser -o -nogroup -print </verb></tscreen> <ITEM> The use of ~/.rhosts files should be absolutely prohibited. For this reason, it is recommended that /etc/inetd.conf disable their usage, thereby eliminating the threat of users creating ~/.rhosts files in their home directories. Perhaps a crontab script may still be used that searches user's home directories via /etc/passwd and removes any ~/.rhosts files. <ITEM> 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. </ITEMIZE>  <SECT1>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 inadvertantly 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: <tscreen><verb> # Set the user's default umask umask 033 </verb></tscreen> Be sure to make root's umask 077, which will disable read, write, and execute permission for other users, unless explicitly changed using chmod(1). If you are using Red Hat, and adhered 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.  <SECT1> File Permissions It's important to insure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintance. 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. <bf>Read:</bf> <ITEMIZE> <ITEM>To be able to view contents of a file <ITEM>To be able to read a directory </ITEMIZE> <bf>Write:</bf> <ITEMIZE> <ITEM>To be able to add to or change a file <ITEM>To be able to delete or move files in a directory </ITEMIZE> <bf>Execute:</bf> <ITEMIZE> <ITEM>To be able to run a binary program or shell script <ITEM>To be able to search in a directory, combined with read permission </ITEMIZE> <descrip> <tag/Save Text Attribute: (For directories)/ The sticky bit also has a different meaning when applied to directories. If the sticky bit is set on a directory, then a user may only delete files that the user 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. </descrip> <descrip> <tag/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 the owner of the file. This is the cause of many 'buffer overflow' exploits. </descrip> <descrip> <tag/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 also be executable for this to have any effect. </descrip> <descrip> <tag/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. </descrip> 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 <bf>File Example:</bf> <tscreen><verb> -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) </verb></tscreen> The following lines are examples of the minimum set of the permissions that are required to perform the access described. You may want to give more permission than what is listed here, but this should describe what these minimum permissions on files do: <tscreen><verb> -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 equal to owner --------s- Will execute with effective user ID equal to group -rw------T No update of "last modified time". Usually used for swap files ---t------ No effect. (formerly sticky bit) </verb></tscreen> <bf>Directory Example:</bf> <tscreen><verb> 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) </verb></tscreen> The following lines are examples of the minimum set of the 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: <tscreen><verb> 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 now be read by owner d-wx------ Files can now 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 </verb></tscreen> 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. <descrip> <tag /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. </descrip>  <SECT1> Integrity Checking with 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: <tscreen><verb> # set mailto MAILTO=kevin # run tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire </verb></tscreen> 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.  <SECT1> Trojan Horses A Trojan Horse is named after the fabled ploy in Homers great literary work. The idea is that you put up a program or binary that sounds great, and get other people to download it and run it as root. Then, you can compromise their system while they are not paying attention. While they think the binary they just pulled down does one thing (and it might very well), it also compromises their security. You should take care of what programs you install on your machine. redhat provides MD5 checksums, and PGP signs RPM files so you can verify you are installing the real thing. Other distributions have similar methods. You should never run any binary you don't have the source for or a well known binary as root! Few attackers are willing to release source code to public scrutiny. Although it can be complex, make sure you are getting the source for some program from it's real distribution site. If the program is going to run as root make sure either you or someone you trust has looked over the source and verified it.  <SECT> Password Security & Encryption One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent Linux distributions include password programs that do not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features. In depth discussion of encryption is beyond the scope of this document, but a introduction is in order. Encryption is very useful, possibly even necessary in this day and age. There are all sorts of methods of encrypting data, each with their own set of characteristics. Most unicies (and Linux is no exception) primarily use a one-way encryption algorithm, called DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, whatever you type in is encrypted again and compared with the entry in the file that stores your passwords. If they match, it must be the same password, and you are allowed access. Although DES is a two-way encryption algorithm (you can code and then decode a message, given the right keys), the variant that most unices use is one-way. This means that it should not be possible to reverse the encryption to get the password from the contents of /etc/passwd (or /etc/shadow). Brute force attacks, such as "Crack" or "John the Ripper" (see below) can often guess passwords unless your password is sufficently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can go to <htmlurl url="http://consult.cern.ch/writeup/security/security_3.html" name="http://consult.cern.ch/writeup/security/security_3.html"> for information on how to choose a good password.  <SECT1> PGP and Public Key Cryptography Public Key Cryptography, such as that which is used for PGP, involves cryptography that uses one key for encryption, and one key for decryption. Traditionally, cryptography involves using the same key for encryption that is used for decryption. This "secret key" must be known to both parties, and somehow transferred from one another securely. Public key encryption alleviates the need to securely transmit the key that is used for encryption by using two seperate keys, a public key and a private key. Each person's public key is available by anyone to do the encryption, while at the same time each person keeps his or her private key to decrypt messages encrypted with the correct public key. There are advantages to both public key and private key cryptography, and you can read about those differences in the RSA Cryptography FAQ, listed at the end of this section. PGP (Pretty Good Privacy) is well supported on Linux. Versions 2.6.2 and 5.0 are known to work well. For a good primer on PGP and how to use it, take a look a the PGP FAQ. <htmlurl url="http://www.pgp.com/service/export/faq/55faq.cgi" name="http://www.pgp.com/service/export/faq/55faq.cgi"> Be sure to use the version that is applicable to your country, as due to export restrictions by the US Government, strong-encryption is prohibited from being transferred in electronic form outside the country. US export controls are now managed by EAR (Export Administration Regulations). They are no longer governed by ITAR. There is also a step-by-step guide for configuring PGP on Linux available at <htmlurl url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html" name="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"> It was written for the International version of PGP, but is easily adaptable to the United States version. You may also need a patch for some of the latest versions of Linux, which is available at <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/crypto" name="ftp://sunsite.unc.edu/pub/Linux/apps/crypto">. There is a project working on a free re-implementation of pgp with open source. See the GNU Privacy Guard web page for more information: <htmlurl url="http://www.d.shuttle.de/isil/crypt/gnupg.html" name="http://www.d.shuttle.de/isil/crypt/gnupg.html">. More information on cryptography can be found in the RSA cryptography FAQ, available at <htmlurl url="http://www.rsa.com/rsalabs/newfaq/" name="http://www.rsa.com/rsalabs/newfaq/">. Here you will find information on such terms as "Diffie-Hellman", "public-key cryptography", "Digital Certificates", etc.  <SECT1> SSL, S-HTTP, HTTPS and S/MIME Often times users ask about the differences between the various security and encryption protocols, and how to use them. While this isn't an encryption document, it is a good idea to explain briefly what each are, and where to find more information. <ITEMIZE> <ITEM><bf>SSL:</bf> - SSL, or Secure Sockets Layer, is an encryption method developed by Netscape to provide security over the Internet. It supports several different encryption protocols, and provides client and server authentication. SSL operates at the transport layer, creates a secure encrypted channel of data, and thus can seamlessly encrypt data of many types. This is most commonly seen when going to a secure site to view a secure online document with Communicator, and serves as the basis for secure communications with Communicator, as well as many other Netscape Communications data encryption. More information can be found at <htmlurl url="http://www.consensus.com/security/ssl-talk-faq.html" name="http://www.consensus.com/security/ssl-talk-faq.html">. Information on Netscape's other security implementations, and a good starting point for these protocols is available at <htmlurl url="http://home.netscape.com/info/security-doc.html" name="http://home.netscape.com/info/security-doc.html">. <ITEM><bf>S-HTTP:</bf> - S-HTTP is another protocol that provides security services across the Internet. It was designed to provide confidentiality, authenticity, integrity, and non-repudiability &lsqb cannot be mistaken for someone else ] while supporting multiple key management mechanisms and cryptographic algorithms via option negotiation between the parties involved in each transaction. S-HTTP is limited to the specific software that is implementing it, and encrypts each message individually. &lsqb From RSA Cryptography FAQ, page 138] <ITEM><bf>S/MIME:</bf> - S/MIME, or Secure Multipurpose Internet Mail Extension, is an encryption standard used to encrypt electronic mail, or other types of messages on the Internet. It is an open standard developed by RSA, so it is likely we will see it on Linux one day soon. More information on S/MIME can be found at <htmlurl url="http://home.netscape.com/assist/security/smime/overview.html" name="http://home.netscape.com/assist/security/smime/overview.html">. </ITEMIZE>  <SECT1> Linux x-kernel IPSEC Implementation Along with CIPE, and other forms of data encryption, there is also an implemention of IPSEC for Linux. IPSEC is an effort by the IETF to create cryptographically secure communications at the IP network level, which also provides authentication, integrity, access control, and confidentiality. Information on IPSEC and Internet draft can be found at <htmlurl url="http://www.ietf.org/html.charters/ipsec-charter.html" name="http://www.ietf.org/html.charters/ipsec-charter.html">. You can also find links to other protocols involving key management, and an IPSEC mailing list and archives. The Linux implementation, which is being developed at the University of Arizona, uses an object-based framework for implementing network protocols called x-kernel, and can be found at <htmlurl url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html" name="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html">. Most simply, the x-kernel is a method of passing messages at the kernel level, which makes for an easier implementation. As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.  <SECT1> SSH (Secure Shell), stelnet SSH and stelnet are programs that allow you to login to remote systems and have a encrypted connection. SSH is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as for user authentication. This can be used to securely login to a remote host or copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts. The SSH home page can be found at <htmlurl url="http://www.cs.hut.fi/ssh/" name="http://www.cs.hut.fi/ssh/"> You can also use SSH from your Windows workstation to your Linux SSH server. There are several freely available Windows client implementations, including the one at <htmlurl url="http://guardian.htu.tuwien.ac.at/therapy/ssh/" name="http://guardian.htu.tuwien.ac.at/therapy/ssh/"> as well as a commercial implementation from DataFellows, at <htmlurl url="http://www.datafellows.com" name="http://www.datafellows.com">. There is also a open source project to re-implement ssh called "psst...". For more information see: <htmlutl url="http://www.net.lut.ac.uk/psst/" name="http://www.net.lut.ac.uk/psst/"> SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol, developed by Eric Young. It includes several applications, such as Secure telnet, a module for Apache, several databases, as well as several algorithms including DES, IDEA and Blowfish. Using this library, a secure telnet replacement has been created that does encryption over a telnet connection. Unlike SSH, stelnet uses SSL, the Secure Sockets Layer protocol developed by Netscape. You can find Secure telnet and Secure FTP by starting with the SSLeay FAQ, available at <htmlurl url="http://www.psy.uq.oz.au/~ftp/Crypto/" name="http://www.psy.uq.oz.au/~ftp/Crypto/">  <SECT1> PAM - Pluggable Authentication Modules Newer versions of the Red Hat Linux distribution ship with a unified authentication scheme called "PAM". PAM allows you to change on the fly your authentication methods, requirements, and encapsulate all local authentication methods without re-compiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be suer to take a look at the PAM web site for more information. <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/index.html" name="http://www.kernel.org/pub/linux/libs/pam/index.html"> Just a few of the things you can do with PAM: <ITEMIZE> <ITEM> Use a non DES encryption for your passwords. (Making them harder to brute force decode) <ITEM> Set resource limits on all your users so they can't perform denial of service attacks (number of processes, amount of memory, etc) <ITEM> Enable shadow passwords (see below) on the fly <ITEM> allow specific users to login only at specific times from specific places </ITEMIZE> Within a few hours of installing and configuring your system, you can prevent many attacks before they even occur. For example, use PAM to disable the system-wide usage of dot-rhosts files in user's home directories by adding these lines to /etc/pam.d/login: <tscreen><verb> # # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts </verb></tscreen>  <SECT1>Cryptographic IP Encapsulation (CIPE) The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet. CIPE encrypts the data at the network level. Packets travelling between hosts on the network are encrypted. The encryption engine is placed near the driver which sends and receives packets. This is unlike SSH, which encrypts the data by connection, at the socket level. A logical connection between programs running on different hosts is encrypted. CIPE can be used in tunnelling, in order to create a Virtual Private Network. Low-level encryption has the advantage that it can be made to work transparently between the two networks connected in the VPN, without any change to application software. Summarized from the CIPE documentation: The IPSEC standards define a set of protocols which can be used (among other things) to build encrypted VPNs. However, IPSEC is a rather heavyweight and complicated protocol set with a lot of options, implementations of the full protocol set are still rarely used and some issues (such as key management) are still not fully resolved. CIPE uses a simpler approach, in which many things which can be parameterized (such as the choice of the actual encryption algorithm used) are an install-time fixed choice. This limits flexibility, but allows for a simple (and therefore efficient, easy to debug...) implementation. Further information can be found at <htmlurl url="http://www.inka.de/~bigred/devel/cipe.html" name="http://www.inka.de/~bigred/devel/cipe.html"> As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.  <SECT1> Kerberos Kerberos is an authentication system developed by the Athena Project at MIT. When a user logs in, Kerberos authenticates that user (using a password), and provides the user with a way to prove her identity to other servers and hosts scattered around the network. This authentication is then used by programs such as rlogin to allow the user to login to other hosts without a password (in place of the .rhosts file). This authentication method can also used by the mail system in order to guarantee that mail is delivered to the correct person, as well as to guarantee that the sender is who he claims to be. The overall effect of installing Kerberos and the numerous other programs that go with it is to virtually eliminate the ability of users to "spoof" the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous stanard programs. You can find more information on kerberos at <htmlurl url="http://www.veritas.com/common/f/97042301.htm" name="http://www.veritas.com/common/f/97042301.htm"> and the code can be found at <htmlurl url="http://nii.isi.edu/info/kerberos/" name="http://nii.isi.edu/info/kerberos/"> [From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]  <SECT1> Shadow Passwords. Shadow passwords are a means of keeping your encrypted password information secret from normal users. Normally this encrypted password is stored in your /etc/passwd file for all to read. They can then run password guesser programs on it and attempt to determine what it is. Shadow passwords save this information to a /etc/shadow file that only privileged users can read. In order to run shadow passwords you need to make sure all your utilities that need access to password information are recompiled to support it. PAM (above) also allows you to just plug in a shadow module and doesn't require re-compilation of executables. You can refer to the Shadow-Password HOWTO for further information if necessary. It is available at <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html" name="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"> It is rather dated now, and will not be required for distributions supporting PAM.  <SECT1> Crack and John the Ripper If for some reason your passwd program is not enforcing non easily guessable passwords, you might want to run a password cracking program and make sure your users passwords are secure. Password cracking programs work on a simple idea. They try every word in the dictionary, and then variations on those words. They encrypt each one and check it against your encrypted password. If they get a match they are in. Also, the "dictionary" may include usernames, Star Trek ships, foreign words, keyboard patterns, etc... There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" <htmlurl url="http://www.false.com/security/john/index.html" name="http://www.false.com/security/john/index.html"> . They will take up a lot of your cpu time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to get your passwd (unix /etc/passwd) file, but these are more common than you might think.  <SECT1> CFS and TCFS - Cryptographic File Systems CFS is a way of encrypting an entire directory trees and allow users to store encrypted files on them. It uses a NFS server running on the local machine. rpms are avail at <htmlurl url="http://www.replay.com/redhat/" name="http://www.replay.com/redhat/"> and more information on how it all works is at: <htmlurl url="ftp://ftp.research.att.com/dist/mab/" name="ftp://ftp.research.att.com/dist/mab/"> TCFS improves on CFS, adding more integration with the file system, so that it's transparent to any users using the file system that it's encrypted. more information at: <htmlurl url="http://edu-gw.dia.unisa.it/tcfs/" name="http://edu-gw.dia.unisa.it/tcfs/" > It also need not be used on entire filesystems. It works on directories trees as well.  <SECT1> X11, SVGA and display security  <SECT2> X11 It's important for you to secure your graphical display to prevent attackers from doing things like: grabbing your passwords as you type them without you knowing it, reading documents or information you are reading on your screen, or even using a hole to gain superuser access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system. X has a number of access control mechanisms. The simplest of them is host based. You can use xhost to specify what hosts are allowed access to your display. This is not very secure at all. If someone has access to your machine they can xhost + their machine and get in easily. When using xdm (X Display Manager) to login, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and stored in your .Xauthority file. These cookies need to be transferred in confidence, and you really don't gain anything if your home directory is shared via NFS. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide only that connection access. See the Remote-X-Apps mini-howto, available at <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html">. You can also use ssh (see ssh, below) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no un-encrypted data flows across the network. Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites you wish to run X programs off of.  <SECT2> SVGA SVGAlib programs are typically SUID-root in order to access all your Linux machine's video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.  <SECT2> GGI (Generic Graphics Interface project) The Linux GGI project is trying to solve several of the problems with video interfaces on Linux. GGI will move a small piece of the video code into the Linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console. <htmlurl url="http://synergy.caltech.edu/~ggi/" name="http://synergy.caltech.edu/~ggi/">  <SECT> Kernel Security This is a description of the kernel configuration options that relate to security, and an explanation of what they do, and how to use them. As the kernel controls your computer's networking, it is important that the kernel is very secure, and the kernel itself won't be compromised. To prevent some of the latest networkworking attacks, you should try and keep your kernel version current. You can find new kernels at ftp://ftp.kernel.org.  <SECT1> Kernel Compile Options <ITEMIZE> <ITEM>IP: Drop source routed frames (CONFIG_IP_NOSR) This option should be enabled. Source routed frames contain the entire path to their destination inside of the packet. This means that routers the packet goes thru does not need to inspect the packet, and just forwards it on. This could lead to data entering your system that may be a potential exploit. <ITEM>IP: Firewalling (CONFIG_IP_FIREWALL) This option is necessary if you are going to configure your machine as a firewall, do masquerading, or wish to protect your dial-up workstation from someone entering via your PPP dial-up interface. <ITEM>IP: forwarding/gatewaying (CONFIG_IP_FORWARD) If you enable IP forwarding, your Linux box essentially becomes a router. If your machine is on a network, you could be forwarding data from one network to another, and perhaps subverting a firewall that was put there to prevent this from happening. Normal dial-up users will want to disable this, and other users should concentrate on the security implications of doing this. Firewall machines will want this enabled, and used in conjunction with firewall software. You can enable and disable IP forwarding dynamically using the following command: <tscreen><verb> root# echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> and disable it with the command: <tscreen><verb> root# echo 0 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> This file (and many other files in /proc) will always appear to be zero length, but in fact aren't. This is a newly introduced kernel feature, so be sure your using a kernel 2.0.33 or later. <ITEM>IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) This option gives you information about packets your firewall received, like sender, receipient, port, etc. <ITEM>IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) Generally this option is disabled, but if you are building a firewall or a masquerading host, you will want to enable it. When data is sent from one host to another, it does not always get sent as a single packet of data, but rather it is fragmented into several pieces. The problem with this is that the port numbers are only stored in the first fragment. This means that someone can insert information into the remaining packets for your connection that aren't supposed to be there. It could also prevent a teardrop attack against an internal host that is not yet itself patched against it. <ITEM>IP: syn cookies (CONFIG_SYN_COOKIES) SYN Attack is a denial of service (DoS) attack that consumes all the resources on your machine, forcing you to reboot. We can't think of a reason you wouldn't normally enable this. In the 2.1 kernel series this config option mearly allows syn cookies, but does not enable them. To enable them, you have to do: echo 1 > /proc/sys/net/ipv4/tcp_syncookies <ITEM>Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) This is an option that is available in the 2.1 kernel series that will sign NCP packets for stronger security. Normally you can leave it off, but it is there if you do need it. <ITEM>IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) This is a really neat option that allows you to analyze the first 128 bytes of the packets in a userspace program, to determine if you would like to accept or deny the packet, based on its validity. </ITEMIZE>  <SECT1> Kernel Devices There are a few block and character devices available on Linux that will also help you with security. The two devices /dev/random and /dev/urandom are provided by the kernel to retrieve random data at any time. Both /dev/random and /dev/urandom should be secure enough to use in generating PGP keys, SSH challenges, and other applications where secure random numbers are requisite. Attackers should be unable to predict the next number given any initial sequence of numbers from these sources. There has been a lot of effort put in to ensuring that the numbers you get from these sources are random in every sense of the word random. The only difference is that /dev/random runs out of random bytes and it makes you wait for more to be accumulated. Note that on some systems, it can block for a long time waiting for new user-generated entry to be entered into the system. So you have to use care before using /dev/random. (Perhaps the best thing to do is to use it when you're generating sensitive keying information, and you tell the user to pound on the keyboard repeatedly until you print out "OK, enough".) /dev/random is high quality entropy, generated from measuring the inter-interrupt times etc. It blocks until enough bits of random data are available. /dev/urandom is similar, but when the store of entropy is running low, it'll return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications. You might read from the devices using something like: <tscreen><verb> root# head -c 6 /dev/urandom | uuencode - </verb></tscreen> This will print six random characters on the console, suitable for password generation. See /usr/src/linux/drivers/char/random.c for a description of the algorithm. Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for helping me (Dave) with this.  <SECT> Network Security Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than physical or local, and is much more common. There are a number of good tools to assist with network security, and more and more of them are shipping with Linux distributions.  <SECT1> Packet Sniffers One of the most common ways intruders gain access to more systems on your network is by employing a packet sniffer on a already compromised host. This "sniffer" just listens on the Ethernet port for things like "password" and "login" and "su" in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear text passwords are very vulnerable to this attack. EXAMPLE: host A has been compromised. Attacker installs a sniffer. Sniffer picks up admin logging into host B from Host C. It gets the admins personal password as they login to B. Then, the admin does a 'su' to fix a problem. They now have the root password for Host B. Later the admin lets someone telnet from his account to host Z on another site. Now the attacker has a password/login on host Z. In this day and age, the attacker doesn't even need to compromise a system to do this, they could also bring a laptop or pc into a building and tap into your net. Using ssh or other encrypted password methods thwarts this attack. Things like APOP for pop accounts also prevents this attack. (Normal pop logins are very vulnerable to this, as is anything that sends clear text passwords over the wire.)  <SECT1> System services and tcp_wrappers Before you put your Linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole. There are a number of ways to disable services under Linux. You can look at your /etc/inetd.conf file and see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then sending your inetd process a SIGHUP. You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will also be unable to find the service (ie, if you remove ftp, and try and ftp to a remote site from that machine it will fail with an unknown service message). It's usually not worth the trouble to remove services, since it provides no additional security. If a local person wanted to use ftp even though you had commented it out, they would make their own client that use the common ftp port and would still work fine. Security measures belong in the server. Generally speaking, client-side security is no good. If you know you are not going to use some particular package, you can also delete it entirely. rpm -e under the Red Hat distribution will erase an entire package. Under debian dpkg likely does the same thing. Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from being started in /etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past. You should check your /etc/rc.d/rcN.d, where N is your systems run level and see if any of the servers started in that directory are not needed. The files in /etc/rc.d/rcN.d are actually symbolic links to the directory /etc/rc.d/init.d. Renaming the files in the init.d directory has the effect of disabling all the symbolic links in /etc/rc.d/rcN.d. If you only wish to disable a service for a particular runlevel, rename the appropriate file with a lower-case 's', instead of the upper-case 'S', such as in S45dhcpd. If you have BSD style rc files, you will want to check /etc/rc* for programs you don't need. Most Linux distributions ship with tcp_wrappers "wrapping" all your tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real server. tcpd then checks the host that is requesting the service and either executes the real server or denies access from that host. tcpd allows you to restrict access to your tcp services. You should make a /etc/hosts.allow and add in only those hosts that need to have access to your machines services. If you are a home dialup user, we suggest you deny ALL. tcpd also logs failed attempts to access services, so this can give you an idea that you are under attack. If you add new services, you should be sure to configure it to use tcp_wrappers TCP based. For example, a normal dial-up user can prevent outsiders from connecting to your machine, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your /etc/hosts.allow: ALL: 127. And of course /etc/hosts.deny would contain: ALL: ALL which will prevent external connections to your machine, yet still allow you from the inside to connect to servers on the Internet.  <SECT1> Verify Your DNS Information Keeping up-to-date DNS information about all hosts on your network can help to increase security. In the event of an unauthorized host becomes connected to your network, you can recognize it by its lack of a DNS entry. Many services can be configured to not accept connections from hosts that do not have valid DNS entries.  <SECT1> identd identd is a small program that typically runs out of your inetd. It keeps track of what user is running what tcp service, and then reports this to whoever requests it. Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests. Why would you want to run it then? Because it helps _you_ out, and is another data-point in tracking. If your identd is un compromised, then you know it's telling remote sites the user-name or uid of people using tcp services. If the admin at a remote site comes back to you and tells you user so and so was trying to hack into their site, you can easily take action against that user. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user. The identd that ships with most distributions is more configurable than many people think. You can disable identd for specific users (they can make a .noident file), you can log all identd requests (I recommend it), you can even have identd return a uid instead of a user name or even NO-USER.  <SECT1> SATAN , ISS, and Other Network Scanners There are a number of different software packages out there that do port and service based scanning of machines or networks. SATAN and ISS are two of the more well known ones. This software connects to the target machine (or all the target machines on a network) on all the ports it can, and tries to determine what service is running there. Based on this information, you could find out the machine is vulnerable to a specific exploit on that server. SATAN (Security Administrators Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a machine or a network of machines. It's a good idea to get SATAN and scan your machine or network, and fix the problems it finds. Make sure you get the copy of SATAN from sun-site or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. <htmlurl url="http://www.trouble.org/~zen/satan/satan.html" name="http://www.trouble.org/~zen/satan/satan.html"> ISS (Internet Security Scanner) is another port based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information. Abacus-Sentry is a commercial port scanner from www.psionic.com. Look at it's home page on the web for more information. <htmlurl url="http://www.psionic.com" name="http://www.psionic.com"> Detecting Port scans. There are some tools designed to alert you to probes by Satan and ISS and other scanning software, However liberal use of TCP wrappers and making sure to look over your log files regularly, you should be able to notice such probes. Even on the lowest setting, Satan still leaves traces in the logs on a stock Red Hat system. There are also "stealth" port scanners. A packet with the TCP ACK bit set (as is done with established connections) will likely get through a packet-filtering firewall. The returned RST packet from a port that _had no established session_ can be taken as proof of life on that port. I don't think TCP wrappers will detect this.  <SECT1> Sendmail, qmail and MTA's. One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs. If you are using sendmail it is very important to keep up on current versions. Sendmail has a long long history of security exploits. Always make sure you are running the most recent version. <htmlurl url="http://www.sendmail.org/" name="http://www.sendmail.org"> If you are tired of upgrading your version of sendmail every week, you might consider switching over to qmail. qmail was designed with security in mind from the ground up. It's fast and stable and secure. <htmlurl url="http://www.qmail.org" name="http://www.qmail.org">  <SECT1> Denial of Service Attacks A Denial of service attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your machine. Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the Linux security lists and the bugtraq list and archives for more current information. <ITEMIZE><ITEM> <bf>SYN Flooding</bf> - SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your machine or services. See the section on kernel security for proper kernel protection options. <ITEM><bf>Pentium "F00F" Bug</bf> - It was recently discovered that a series of assembly codes send to a genuine Intel Pentium processor would reboot the machine. This affects every machine with a Pentium processor (not clones, not Pentium Pro or PII), no matter what operating system it's running. Linux kernel 2.0.32 and up contain a work around for this bug, preventing it from locking your machine. Kernel 2.0.33 has an improved version of the kernel fix, and is suggested over 2.0.32. If you are running on a Pentium, you should upgrade now! <ITEM> <bf>Ping Flooding</bf> - Ping flooding is a simple brute force denial of service attack. The attacker sends a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack, called "smurfing", sends ICMP packets to a broadcast address with _your_ machines return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack at <htmlurl url="http://www.quadrunner.com/~chuegen/smurf.txt" name=" http://www.quadrunner.com/~chuegen/smurf.txt"> If you are ever under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level or by using a firewall. <ITEM> <bf>Ping o' Death</bf> - The Ping o' Death attack is a result of incoming ICMP ECHO REQUEST packets being larger than the kernel data structures that store this information can hold. Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." This one has long been fixed, and is no longer anything to worry about. <ITEM> <bf>Teardrop / New Tear</bf> - One of the most recent exploits involves a bug present in the IP fragmentation code on Linux and Windows platforms. It is fixed in kernel version 2.0.33, and does not require selecting any kernel compile-time options to utilize the fix. Linux is apparently not vulnerable to the 'newtear' exploit. </ITEMIZE> You can find most exploit code, and a more in-depth description of how they work at <htmlurl url="http://www.rootshell.com" name="http://www.rootshell.com"> using their search engine.  <SECT1> NFS (Network File System) Security. NFS is a very widely used file sharing protocol. It allows servers running nfsd and mountd to "export" entire filesystems to other machines with nfs filesystem support builtin to their kernels (or some other client support if they are non Linux machines). Mountd keeps track of mounted filesystems in /etc/mtab, and can display them with 'showmount'. Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files. There is some small amount of "security" allowed in exporting filesystems. You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote filesystems. If you must use NFS, make sure you export to only those machines that you really need to export only. Never export your entire root directory, export only directories you need to export and export read-only wherever possible. See the NFS HOWTO for more information on NFS: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NFS-HOWTO.html" name="NFS HOWTO">  <SECT1> NIS (Network Information Service) (formerly YP). Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard /etc/passwd file), among other information. NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Not only was it not intended to be secure, it also has characteristics which inherently make it insecure. Among these are: <ITEMIZE> <ITEM> Lack of access control for contents of NIS maps <ITEM> Negation of password shadowing <ITEM> Rogue servers acting as authentic ones </ITEMIZE> Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use Crack against your users passwords. If you must use NIS, make sure you are aware of the dangers. There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html">  <SECT1> Firewalls Firewalls are a means of restricting what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local lan, and the only access from your lan to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your lan. There are a number of types and methods of setting up firewalls. Linux machines make pretty good low cost firewalls. Firewall code can be built right into 2.0 and higher kernels. The ipfwadm user space tool allows you to change what types of network traffic you allow on the fly. You can also log particular types of network traffic. Firewalls are a very usefull and important technique in securing your network. It is important to realize that you should never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good Firewall-HOWTO at your latest sunsite archive for more information on firewalls and Linux. <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"> More information can also be found in the IP-Masquerade mini-howto: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html" name="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"> More information on ipfwadm (The tool that lets you change settings on your firewall, can be found at it's home page: <htmlurl url="http://www.xos.nl/linux/ipfwadm/" name="http://www.xos.nl/linux/ipfwadm/">  <SECT> Security Preparation (before you go on-line) Ok, so you have checked over your system, and determined its as secure as feasible, and are ready to put it online. There are a few things you should now do in order to be prepared in case an intrusion actually does happen, so you can quickly disable the intruder, and get back up and running.  <SECT1> Make a Full Backup of Your Machine Discussion of backup methods and storage is beyond the scope of this document, but a few words relating to backups and security: If you have less than 650mb of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time). Tapes and other re-writable media should be write protected as soon as your backup is complete and verified to prevent tampering. Make sure you store your backups in a secure off line area. A good backup will ensure that you have a known good point to restore your system from.  <SECT1> Choosing a Good Backup Schedule A six-tape cycle is an easy one to maintain. This includes four tapes for during the week, one tape for even Friday's, and one tape for odd Friday's. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particular important changes or add some important data to your system, a backup might well be in order.  <SECT1> Backup Your RPM or Debian File Database In the event of an intrusion, you can use your RPM database like you would use tripwire, but only if you can be sure it too hasn't been modified. You should copy the RPM database to a floppy, and keep this copy off-line at all times. The Debian distribution likely has something similar. Specifically, the files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single floppy. Compressed, each should fit on a seperate floppy. Now, when your system is compromised, you can use the command: <tscreen><verb> root# rpm -Va </verb></tscreen> to verify each file on the system. See the RPM man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. This means that every time a new RPM is added to the system, the RPM database will need to be rearchived. You will have to decide the advantages versus drawbacks.  <SECT1>Keep Track of Your System Accounting Data It is very important that the information that comes from syslog has not been compromised. Making the files in /var/log readable and writable by a limited number of users is a good start. Be sure to keep an eye on what gets written there, especially under the `auth' facility. Multiple login failures, for example, can indicate an attempted break-in. Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in /var/log and check messages, mail.log, and others. You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells syslogd (the system logging daemon) where to log various messages. You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the 'logrotate' package un recent Red Hat distributions. Other distributions likely have a similar process. If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things they appeared to tamper with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea. Log files are typically modified by the intruder in order to cover his tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them. You should also be sure to seperate the `auth' facility from other log data, including attempts to switch users using `su', login attempts, and other user accounting information. If possible, configure syslog to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and refer to the `@' option. Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what the look like on a normal day. Knowing this can help make unusual things stand out.  <SECT1> Apply All New System Updates. Most Linux users install from a CDROM. Due to the fast paced nature of security fixes, new (fixed) programs are always being released. Before you connect your machine to the network, it's a good idea to check with your distribution's ftp site (ftp.redhat.com for example) and get all the updated packages since you received your distribution CDROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.  <SECT> What To Do During and After a Breakin So you have followed some of the advice here (or elsewhere) and have detected a breakin? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have.  <SECT1> Security Compromise under way. Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences. If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab setting you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people. If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they are normally in from? no? Then use a non electronic means of getting in touch. For instance, call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations. If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable, if they are connected via ethernet, unplug the ethernet cable. If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like tcp_wrappers or ipfwadm to deny access from the intruders site. If you can't deny all people from the same site as the intruder, locking the users account will have to do. Note that locking an account is not an easy thing. You have to keep in mind .rhosts files, FTP access, and a host of backdoors). After you have done one of the above (disconnected network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off. You should monitor your site well for the next few minutes, as the attacker will try and get back in. Perhaps using a different account, and/or from a different network address.  <SECT1> Security Compromise has already happened So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what?  <SECT2> Closing the Hole If you are able to determine what means the attacker used to get into your system, you should try and close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version or any of the lists know of a fix. Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. You can find Caldera security fixes here <htmlurl url="http://www.caldera.com/tech-ref/security/" name="http://www.caldera.com/tech-ref/security/">. Red Hat has not yet seperated their security fixes from bugfixes, but their distribution errata is available at <htmlurl url="http://www.redhat.com/errata" name="http://www.redhat.com/errata"> Debian now has a security mailing list and web page. See: <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/"> for more information. It is very likely that if one vendor has released a security update, that most other Linux vendors will as well. There is now a linux security auditing project. They are methodically going through all the user space utilities and looking for possible security exploits and overflows. From their announcement: "We are attempting a systematic audit of Linux sources with a view to being as secure as OpenBSD. We have already uncovered (and fixed) some problems, but more help is welcome. The list is unmoderated and also a useful resource for general security discussions. The list address is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: security-audit-subscribe@ferret.lmh.ox.ac.uk" If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local machines.  <SECT2> Assessing the Damage The first thing is to assess the damage. What has been compromised? If you are running an Integrity Checker like Tripwire you can make a tripwire run and it should tell you. If not, you will have to look around at all your important data. Since Linux systems are getting easier and easier to install, you might consider saving your config files and then wiping your disk(s) and reinstalling, then restoring your user files from backups and your config files. This will insure that you have a new clean system. If you have to backup files from the compromised system, be especially cautious of any binaries that you restore as they may be trojan horses placed there by the intruder. Re-installation should be considered mandatory upon an intruder obtaining root access. Additionally, you'd like to keep any evidence there is, so having a spare disk in the safe may make sense. Then you have to worry about how long ago the compromise happened, and whether the backups hold any damaged work. More on backups later.  <SECT2> Backups, Backups, Backups! Having regular backups is a godsend for security matters. If your system is compromised, you can restore the data you need from backups. Of course some data is valuable to the attacker to, and they will not only destroy it, they will steal it and have their own copies, but at least you will still have the data. You should check several backups back into the past before restoring a file that has been tampered with. The intruder could have compromised your files long ago, and you could have made many successful backups of the compromised file!!! Of course, there are also a raft of security concerns with backups. Make sure you are storing them in a secure place. Know who has access to them. (If an attacker can get your backups, they can have access to all your data without you ever knowing it.)  <SECT2> Tracking Down the Intruder. Ok, you have locked the intruder out, and recovered your system, but you're not quite done yet. While it is unlikely that most intruders will ever be caught, you should report the attack. You should report the attack to the admin contact at the site where the attacker attacked your system. You can look up this contact with "whois" or the internic database. You might send them an email with all applicable log entries and dates and times. If you spotted anything else distinctive about your intruder, you might mention that too. After sending the email, you should (if you are so inclined) follow up with a phone call. If that admin in turn spots your attacker, they might be able to talk to the admin of the site where they are coming from and so on. Good hackers often use many intermediate systems. Some (or many) of which may not even know they have been compromised. Trying to track a cracker back to their home system can be difficult. Being polite to the admins you talk to can go a long way to getting help from them. You should also notify any security organizations you are a part of (CERT or similar), as well as your Linux system vendor.  <SECT> Security Sources There are a LOT of good sites out there for UNIX security in general and Linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative.  <SECT1> Web Sites <ITEMIZE> <ITEM> The Hacker FAQ is a FAQ about hackers: <htmlurl url="http://www.solon.com/~seebs/faqs/hacker.html" name="The Hacker FAQ"> <ITEM> The COAST archive has a large number of unix security programs and information: <htmlurl url="http://www.cs.purdue.edu/coast/" name="COAST"> <ITEM> Rootshell.com is a great site for seeing what exploits are currently being used by crackers: <htmlurl url="http://www.rootshell.com/" name="rootshell.com exploits"> <ITEM> BUGTRAQ puts out advisories on security issues: <htmlurl url="http://www.netspace.org/lsv-archive/bugtraq.html" name="BUGTRAQ archives"> <ITEM> CERT, the Computer Emergency Response Team, puts out advisories on common attacks on unix platforms: <htmlurl url="http://www.cert.org/" name="CERT home"> <ITEM> Dan Farmer is the author of SATAN and many other security tools, his home site has some interesting security survey information as well as security tools: <htmlurl url="http://www.trouble.org" name="Dan Farmers trouble.org"> <ITEM> The Linux security WWW is a good site for Linux security information: <htmlurl url="http://www.aoy.com/Linux/Security/" name="Linux Security WWW"> <ITEM> Reptile has lots of good Linux security information on his site: <htmlurl url="http://207.237.120.45/linux/" name="Reptiles Linux Security Page"> <ITEM> Infilsec has a vulnerability engine that can tell you what vunerabilities affect a specific platform: <htmlurl url="http://www.infilsec.com/vulnerabilities/" name="Infilsec vunerability engine"> <ITEM> CIAC sends out periodic security bulletins on common exploits: <htmlurl url="http://ciac.llnl.gov/cgi-bin/index/bulletins" name="CIAC bulitins"> <ITEM> A good starting point for Linux Pluggable Authentication modules can be found at <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/" name="http://www.kernel.org/pub/linux/libs/pam/">. <ITEM> The debian project has a web page for their security fixes and information. It is at <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/">. </ITEMIZE>  <SECT1> Mailing Lists Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. (see links above for archives). CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not subject) of the message put (either or both): subscribe ciac-bulletin Redhat has a number of mailing lists, the most important of which is the redhat-announce list. You can read about security (and other) fixes as soon as they come out. Send email to majordomo@redhat.com and put subscribe redhat-announce. The debian project has a security mailing list that covers their security fixes. see <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/"> for more information.  <SECT1> Books - Printed Reading Material. There are a number of good security books out there. This section lists a few of them. In addition to the security specify books, security is covered in a number of other books on system administration. Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4  <SECT> Glossary <ITEMIZE> <ITEM><bf>Host:</bf> A computer system attached to a network <ITEM><bf>Firewall:</bf> A component or set of components that restricts access between a protected network and the Internet, or between other sets of networks. <ITEM><bf>Bastion Host:</bf> A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projects on the outer walls of medieval castles. Bastions overlook critical areas of defense, usually having strongs walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers. <ITEM><bf>Dual-homed Host:</bf> A general-purpose computer system that has at least two network interfaces. <ITEM><bf>Packet:</bf> The fundamental unit of communication on the Internet. <ITEM><bf>Packet Filtering:</bf> The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice-versa). accomplish packet filtering, you set up a set of rules that specifiy what types of packets (those to or from a particular IP address or port) are to be allowed and what types are to be blocked. <ITEM><bf>Perimeter network:</bf> A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ. <ITEM><bf>Proxy server:</bf> A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests on to real servers, and relay answers back to clients. <ITEM><bf>Denial of Service:</bf> A denial of service attack is when an attacker consumes the resources on your computer for things it was not intended to be doing, thus preventing normal use of your network resources to legimite purposes. <ITEM><bf>Buffer Overflow:</bf> Common coding style is never to allocate buffers "large enough" and not checking for overflows. When such buffers are overflows, the executing program (daemon or set-uid program) can be tricked in doing some other things. Generally this works by overwriting a function's return address on the stack to point to another location. <ITEM><bf>IP Spoofing:</bf> IP-Spoofing is a complex technical attack that is made up of several components. It is a security exploit that works by tricking computers in a trust-relationship that you are someone that you really aren't. There is an extensive paper written by daemon9, route, and infinity in the Volume Seven, Issue fourty-Eight issue of Phrack Magazine. <ITEM><bf>Authentication:</bf> The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. <ITEM><bf>Non-repudiation:</bf> The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data. </ITEMIZE>  <SECT> Frequently Asked Questions <enum> <ITEM> Is it more secure to compile driver support directly into the kernel, instead of making it a module? Answer: Some people think it is better to disable the ability to load device drivers using modules, because an intruder could load a trojan module or himself load a module that could affect system security. However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module. Modules are for dynamically loading support for a particular device that may be infrequently used. On server machines, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as a server. Modules are also slower than support compiled directly in the kernel. <ITEM> Logging in as root from a remote machine always fails. Answer: See the section on Root security. This is done intentionally to prevent remote users from attempting to connect via telnet to your machine as root, which is a serious security vulnerability. Don't forget, potential intruders have time on their side, and can run automated programs to find your password. <ITEM> How do I enable shadow passwords on my Red Hat 4.2 or 5.0 Linux box? Answer: Shadow passwords is a mechanism for storing your password in a file other than the normal /etc/passwd file. This has several advantages. The first one is that the shadow file, /etc/shadow, is only readable by root, unlike /etc/passwd, which must remain readable by everyone. The other advantage is that as the administrator, you can enable or disable accounts without everyone knowing the status of other users accounts. The /etc/passwd file is then used to store user and group names, used by programs like `/bin/ls' to map the user ID to the proper username in a directory listing. The /etc/shadow file then only contains the username and his/her password, and perhaps accounting information, like when the account expires, etc. To enable shadow passwords, run 'pwconv' as root, and /etc/shadow should now exist, and be used by applications. Since you are using RH 4.2 or above, the PAM modules will automatically adapt to the change from using normal /etc/passwd to shadow passwords without any other change. Since you are interested in securing your passwords, perhaps you would also be interested in generating good passwords to begin with. For this you can use the `pam_cracklib' module, which is part of PAM. It runs your password against the Crack libraries to help you decide if it is too easily guessable by password cracking programs. <ITEM> How can I enable the Apache SSL extensions? Answer: 1.Get SSLeay 0.8.0 or later from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL 2.Build and test and install it! 3.Get Apache 1.2.5 source 4.Get Apache SSLeay extensions from <url url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz" name="here"> 5.Unpack it in the apache-1.2.5 source directory and patch Apache as per the README. 6.Configure and build it. You might also try <htmlurl url="http://www.replay.com" name="Replay Associates"> which has many pre-built packages, and is located outside of the United States. <ITEM> How can I manipulate user accounts, and still retain security? Answer: The Red Hat distribution, especially RH5.0, contains a great number of tools to change the properties of user accounts. <ITEMIZE><ITEM> The pwconv and unpwconv programs can be used to convert back and forth between shadow and non-shadowed passwords <ITEM>The pwck and grpck programs can be used to verify proper organization of the passwd and group files. <ITEM>The programs useradd, usermod, and userdel can be used to add, delete and modify user accounts. The programs groupadd, groupmod, and groupdel will do the same for groups. <ITEM>Group passwords can be created using gpasswd. </ITEMIZE> All these programs are 'shadow-aware' -- that is; if you enable shadow it will use /etc/shadow for password information, otherwise it won't. See the respective man pages for further information. <ITEM> How can I password protect specific HTML documents using Apache? I bet you didn't know about <htmlurl url="http://www.apacheweek.com" name="http://www.apacheweek.org"> did you? You can find information on User Authentication at <htmlurl url="http://www.apacheweek.com/features/userauth" name="http://www.apacheweek.com/features/userauth"> as well as other web server security tips from <htmlurl url="http://www.apache.org/docs/misc/security_tips.html" name="http://www.apache.org/docs/misc/security_tips.html"> </enum>  <SECT> Conclusion By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your machine. If you pay attention to your log files and run something like tripwire regularly, you can do even more. A reasonable level of computer security is not difficult to maintain on a home machine. More effort is required on business machines, but Linux can indeed be a secure platform. Due to the nature of Linux development, security fixes often come out much faster than they do on commercial operating systems, making Linux an ideal platform when security is a requirement.  <SECT> Thanks to Information here is collected from many sources. Thanks to the following that either indirectly or directly have contributed: <tscreen><verb> Rob Riggs <rob@DevilsThumb.com> S. Coffin <scoffin@netcom.com> Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu> Roelof Osinga <roelof@eboa.com> Kyle Hasselbacher <kyle@carefree.quux.soltec.net> "David S. Jackson" <dsj@dsj.net> "Todd G. Ruskell" <ruskell@boulder.nist.gov> Rogier Wolff <R.E.Wolff@BitWizard.nl> Antonomasia <ant@notatla.demon.co.uk> Nic Bellamy <sky@wibble.net> </verb></tscreen> <!-- - - - - - - - - - - - - - - - - - - - - - - - - - -

Linux Security HOWTO <AUTHOR>Kevin Fenzi, <tt>kevin@scrye.com</tt> &ero Dave Wreski, <tt>dave@nic.com</tt> <DATE>v0.9.16, 24 June 1998 <ABSTRACT> 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 your mail to avoid spam filters and to bring your mail to the quick attention of the authors. </ABSTRACT> <TOC>  <SECT> Introduction This document covers some of the main security 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 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 some general methods to prevent such exploits from taking place.  <SECT1> New Versions of this Document New versions of this document will be periodically posted to <it>comp.os.linux.answers</it>. They will also be added to the various anonymous FTP sites who archive such information, including: <tt> <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO" name="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO"> </tt> In addition, you should generally be able to find this document on the Linux Worldwide Web home page via: <tt> <htmlurl url="http://sunsite.unc.edu/mdw/linux.html" name="http://sunsite.unc.edu/mdw/linux.html"> </tt> Finally, the very latest version of this document should also be available in various formats from: <tt> <htmlurl url="http://scrye.com/~kevin/lsh/" name="http://scrye.com/~kevin/lsh/"> </tt>  <SECT1> Feedback All comments, error reports, additional information and criticism of all sorts should be directed to: <tt> <htmlurl url="mailto:kevin@scrye.com" name="kevin@scrye.com"> </tt> and <tt> <htmlurl url="mailto:dave@nic.com" name="dave@nic.com"> </tt> 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.  <SECT1> Disclaimer No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. Additionally, this is an early version, with many possibilities for inaccuracies and 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-like terms.  <SECT1> Copyright Information This document is copyrighted (c)1998 Kevin Fenzi and Dave Wreski, and distributed under the following terms: <ITEMIZE> <ITEM> 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. <ITEM> 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. <ITEM> If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator, at </ITEMIZE> <tt> <htmlurl url="mailto:tjbynum@sunsite.unc.edu" name="tjbynum@sunsite.unc.edu"> </tt>  <SECT> 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 foundatation before we get started.  <SECT1> Why Do We Need Security? In the ever-changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becomming 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, your data. 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 still wondering what the difference is between a "Hacker" and a "Cracker", see Eric Raymond's document, "How to Become A Hacker", available at <htmlurl url="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html" name="http://sagan.earthspace.net/~esr/faqs/hacker-howto.html">.  <SECT1> 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 is 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 <htmlurl url="http://ds.internic.net/rfc/rfc2196.txt" name="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. It is even advisable to generate a security policy for systems with more than one user.  <SECT1> 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. <ITEMIZE><ITEM> Risk is the possibility that an intruder may be successful in attempting to access your computer. Can an intruder read, write files, or execute programs that could cause damage? Can they delete critical data? 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. A single user that is allowed to login using an rhosts file, or allowing the use of an insecure service, such as tftp, you risk an intruder using this to 'get 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. <ITEM> Threat is typically from someone with motivation to gain unathorized access to your network, or computer. You must decide who you trust to have access to your system, and what threat they could impose. There are several types of intruders, and it is useful to keep the different characteristics in mind as you are securing your systems. <ITEMIZE> <ITEM><bf>The Curious</bf> - This type of intruder is basically interested in finding out what type of system and data, you have. </item> <ITEM><bf>The Malicious</bf> - This type of intruder is out to either bring down your systems, or deface your web page, or otherwise cause you time and money to recover. </item> <ITEM><bf>The High-Profile Intruder</bf> - 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. </item> <ITEM><bf>The Competition</bf> - 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. </item> </ITEMIZE><ITEM> Vulnerability describes how well protected your computer is from another network, and the potential for someone gaining unathorized access. What's at stake if someone breaks into your system? Of course the concerns of a dynamic PPP home user will be different than 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? </ITEMIZE>  <SECT1> 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: <quote><bf> "That which is not permitted is prohibited"</bf></quote> 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.  <SECT1> Means of Securing Your Site This document will discuss various means in which you can secure the assets you have worked hard for: your local machine, data, users, network, even your reputation. What would happen to your reputation if an intruder deleted some of your user's 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 several reasons an intruder may be interested in your systems, which we will discuss later.  <SECT2> Host Security Perhaps the area of most concentration on security is done with 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 of machines becomes larger.  <SECT2> Your Network Security Network security is also as necessary as local host security. With your single system, or a distributed computing network, the Internet, or hundreds, if not thousands or more computers on the same network, you can't rely on each one of those systems being secure. Making sure authorized users are the only ones permitted to use your network resources, building firewalls, using strong encryption, and ensuring there are no rogue, or 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.  <SECT2> Security Through Obscurity One type of security that must be discussed is "security through obscurity". This means that by doing something like changing the login name from 'root' to 'toor', for example, to try and obscure someone from breaking into your system as root is only a false sense of security, and will result in very unpleasant consequences. Rest assured that any system attacker will quickly see through such empty security measures. Simply because you may have a small site, or relatively low profile does not mean an intruder won't be interested in what you have. We'll discuss what your protecting in the next sections.  <SECT1> Organization of This Document This document has been segregated into a number of sections. They cover several broad kinds of security issues. The first, physical security, covers how you need to protect your physical machine from tampering. The second describes how to protect your system from tampering by local users. The third, files and filesystem security show you how to setup your filesystems and premissions on your files. The next, password security and encryption discusses how to use encryption to better secure your machine and network. Kernel security discusses what kernel options you should set or be aware of for a more secure machine. network security, describes how to better secure your Linux system from network attacks. Security preparation discusses how to prepair your machine(s) before bringing them on-line. The next discusses what to do when you detect a system compromise in progress or detect one that has recently happened. Then links to other security resources are enumerated, and finally some questions and answers and a few closing words. The two main points to realize when reading this document are: <ITEMIZE> <ITEM> Be aware of your system. Check system logs such as /var/log/messages and keep an eye on your system, and <ITEM> Keep your system up to date by making sure you have installed the current versions of software and have upgraded per security alerts, or otherwise improved the security of any suspect programs. Just doing this will help make your system markedly more secure. </ITEMIZE>  <SECT> 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 environment, 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 a 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 a good idea, but beyond the scope of this document. :)  <SECT1> Computer locks Many more 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.  <SECT1> 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. Under Linux/x86 many PC BIOSs let you set a boot password. This doesn't provide all that much security (BIOS can be reset, or removed if someone can get into the case), but might be a good deterrent (ie it will take time and leave traces of tampering). 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. Some examples are: disallow booting from floppy drives and passwords to access some bios features. On S/Linux, (Linux for SPARC(tm) processor machines) your EEPROM can be set to require a boot-up password. This might slow attackers down. NOTE: If you have a server machine, and you setup 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. ;(  <SECT1> Boot Loader Security The various Linux boot loaders also can have a boot password set. Using lilo, take a look at the "restricted" and "password" settings. "password" allows you to set a bootup password. "restricted" will let the machine boot _unless_ someone specifies options at the lilo: prompt (like 'single'). 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. This 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, as well as password-protecting your computer's BIOS. If anyone has security related information from a different boot loader, we would love to hear it. (grub, silo, milo, loadlin, etc). NOTE: If you have a server machine, and you setup 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. ;(  <SECT1> 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 vty 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 does not 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.  <SECT1> 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, a trouble light should go on. 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: <ITEMIZE> <ITEM>Short or incomplete logs. <ITEM>Logs containing strange timestamps. <ITEM>Logs with incorrect permissions or ownership. <ITEM>Records of reboots or restarting of services. <ITEM>missing logs. <ITEM>su entries or logins from strange places. </ITEMIZE> We will discuss system log data later in the HOWTO.  <SECT> 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 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.  <SECT1> 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 secretary, or another general user, with an account, you might want them to only have access to a word processor or drawing program, but be unable to delete data that is not his or hers. Several good rules of thumb when allowing other people legitimate access to your Linux machine: <ITEMIZE> <ITEM> Limit access privileges given to new uers. <ITEM> Be aware when/where they login from, or should be logging in from. <ITEM> Make sure to remove inactive accounts <ITEM> 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. <ITEM> The creation of group user-IDs should be absolutely prohibited. User accounts also provide accountability, and this is not possible with group accounts. </ITEMIZE> 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.  <SECT1> Root Security The most sought-after account on your machine is the 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. Running as root all the time is a very very very bad idea. Several tricks to avoid messing up your own box as root: <ITEMIZE> <ITEM> When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: ie, you are going to do a "rm foo*.bak", instead, 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. <ITEM> Provide your users with a default alias to the rm command to ask for confirmation for deletion of files. <ITEM> 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 <bf>sure</bf> what needs to be done by root. <ITEM> The command path for the root user is very important. The command path, or the PATH environment variable, defines the location the shell searches for programs. Try and limit the command path for the root user as much as possible, and never use '.', meaning 'the current directory', in your PATH statement. 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. <ITEM> Never use the rlogin/rsh/rexec (called the r-utilities) suite of tools as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a .rhosts file for root. <ITEM> 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 ssh or other encrypted channel), so there is no need to be able to login directly as root. <ITEM> Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type! </ITEMIZE> If you absolutely positively need to allow someone (hopefully very trusted) to have superuser 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. Sudo 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, but use sudo so you can 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 the user root access. This includes most editors, for example. Also, a program as innocous 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 yet be secure.  <SECT> Files and Filesystem Security A few minutes of preparation and planning ahead before putting your systems online can help to protect your system, and the data that is stored on them. <ITEMIZE> <ITEM> There should never be a reason for user's 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 user's home partitions, as well as /var, which prohibit execution of programs, and creation of character or block devices, which should never be necessary anyway. <ITEM> 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. <ITEM> Configure your user's file-creation umask to be as restrictive as possible. Commonly used settings are 022, 033, and the most restrictive 077, and are added to /etc/profile. The file creation mask must be set while keeping in mind the purpose of the account. Permissions that are too restrictive may cause users to start sharing accounts or passwords, or otherwise compromise security. Further information is available in the <ITEM> 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. <ITEM> 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: <tscreen><verb> @users hard core 0 @users hard nproc 50 @users hard rss 5000</verb></tscreen> This says to prohibit the creation of core files, restrict the number of processes to 50, and restrict memory usage per user to 5M. <ITEM> The /var/log/wtmp and /var/run/utmp files contain the login records for all users on your system. Its 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. <ITEM> 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: <tscreen><verb> root# find / -type f \( -perm -04000 -o -perm -02000 \) </verb></tscreen> 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 descriminitely remove the SUID or SGID permissions on a suspicious program with chmod(1), then change it back if you absolutely feel it is necessary. <ITEM> 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: <tscreen><verb> root# find / -perm -2 ! -type l -ls </verb></tscreen> 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. <ITEM> Unowned files may also be an indication an intruder has accessed your system. You can locate files on your system that do not have an owner, or belong to a group with the command: <tscreen><verb> root# find / -nouser -o -nogroup -print </verb></tscreen> <ITEM> The use of ~/.rhosts files should be absolutely prohibited. For this reason, it is recommended that /etc/inetd.conf disable their usage, thereby eliminating the threat of users creating ~/.rhosts files in their home directories. Perhaps a crontab script may still be used that searches user's home directories via /etc/passwd and removes any ~/.rhosts files. <ITEM> 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. </ITEMIZE>  <SECT1>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 inadvertantly 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: <tscreen><verb> # Set the user's default umask umask 033 </verb></tscreen> Be sure to make root's umask 077, which will disable read, write, and execute permission for other users, unless explicitly changed using chmod(1). If you are using Red Hat, and adhered 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.  <SECT1> File Permissions It's important to insure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintance. 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. <bf>Read:</bf> <ITEMIZE> <ITEM>To be able to view contents of a file <ITEM>To be able to read a directory </ITEMIZE> <bf>Write:</bf> <ITEMIZE> <ITEM>To be able to add to or change a file <ITEM>To be able to delete or move files in a directory </ITEMIZE> <bf>Execute:</bf> <ITEMIZE> <ITEM>To be able to run a binary program or shell script <ITEM>To be able to search in a directory, combined with read permission </ITEMIZE> <descrip> <tag/Save Text Attribute: (For directories)/ The sticky bit also has a different meaning when applied to directories. If the sticky bit is set on a directory, then a user may only delete files that the user 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. </descrip> <descrip> <tag/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 the owner of the file. This is the cause of many 'buffer overflow' exploits. </descrip> <descrip> <tag/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 also be executable for this to have any effect. </descrip> <descrip> <tag/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. </descrip> 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 <bf>File Example:</bf> <tscreen><verb> -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) </verb></tscreen> The following lines are examples of the minimum set of the permissions that are required to perform the access described. You may want to give more permission than what is listed here, but this should describe what these minimum permissions on files do: <tscreen><verb> -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 equal to owner --------s- Will execute with effective user ID equal to group -rw------T No update of "last modified time". Usually used for swap files ---t------ No effect. (formerly sticky bit) </verb></tscreen> <bf>Directory Example:</bf> <tscreen><verb> 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) </verb></tscreen> The following lines are examples of the minimum set of the 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: <tscreen><verb> 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 now be read by owner d-wx------ Files can now 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 </verb></tscreen> 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. <descrip> <tag /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. </descrip>  <SECT1> Integrity Checking with 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: <tscreen><verb> # set mailto MAILTO=kevin # run tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire </verb></tscreen> 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.  <SECT1> Trojan Horses A Trojan Horse is named after the fabled ploy in Homers great literary work. The idea is that you put up a program or binary that sounds great, and get other people to download it and run it as root. Then, you can compromise their system while they are not paying attention. While they think the binary they just pulled down does one thing (and it might very well), it also compromises their security. You should take care of what programs you install on your machine. redhat provides MD5 checksums, and PGP signs RPM files so you can verify you are installing the real thing. Other distributions have similar methods. You should never run any binary you don't have the source for or a well known binary as root! Few attackers are willing to release source code to public scrutiny. Although it can be complex, make sure you are getting the source for some program from it's real distribution site. If the program is going to run as root make sure either you or someone you trust has looked over the source and verified it.  <SECT> Password Security & Encryption One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent Linux distributions include password programs that do not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features. In depth discussion of encryption is beyond the scope of this document, but a introduction is in order. Encryption is very useful, possibly even necessary in this day and age. There are all sorts of methods of encrypting data, each with their own set of characteristics. Most unicies (and Linux is no exception) primarily use a one-way encryption algorithm, called DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, whatever you type in is encrypted again and compared with the entry in the file that stores your passwords. If they match, it must be the same password, and you are allowed access. Although DES is a two-way encryption algorithm (you can code and then decode a message, given the right keys), the variant that most unices use is one-way. This means that it should not be possible to reverse the encryption to get the password from the contents of /etc/passwd (or /etc/shadow). Brute force attacks, such as "Crack" or "John the Ripper" (see below) can often guess passwords unless your password is sufficently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can go to <htmlurl url="http://consult.cern.ch/writeup/security/security_3.html" name="http://consult.cern.ch/writeup/security/security_3.html"> for information on how to choose a good password.  <SECT1> PGP and Public Key Cryptography Public Key Cryptography, such as that which is used for PGP, involves cryptography that uses one key for encryption, and one key for decryption. Traditionally, cryptography involves using the same key for encryption that is used for decryption. This "secret key" must be known to both parties, and somehow transferred from one another securely. Public key encryption alleviates the need to securely transmit the key that is used for encryption by using two seperate keys, a public key and a private key. Each person's public key is available by anyone to do the encryption, while at the same time each person keeps his or her private key to decrypt messages encrypted with the correct public key. There are advantages to both public key and private key cryptography, and you can read about those differences in the RSA Cryptography FAQ, listed at the end of this section. PGP (Pretty Good Privacy) is well supported on Linux. Versions 2.6.2 and 5.0 are known to work well. For a good primer on PGP and how to use it, take a look a the PGP FAQ. <htmlurl url="http://www.pgp.com/service/export/faq/55faq.cgi" name="http://www.pgp.com/service/export/faq/55faq.cgi"> Be sure to use the version that is applicable to your country, as due to export restrictions by the US Government, strong-encryption is prohibited from being transferred in electronic form outside the country. US export controls are now managed by EAR (Export Administration Regulations). They are no longer governed by ITAR. There is also a step-by-step guide for configuring PGP on Linux available at <htmlurl url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html" name="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"> It was written for the International version of PGP, but is easily adaptable to the United States version. You may also need a patch for some of the latest versions of Linux, which is available at <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/crypto" name="ftp://sunsite.unc.edu/pub/Linux/apps/crypto">. There is a project working on a free re-implementation of pgp with open source. See the GNU Privacy Guard web page for more information: <htmlurl url="http://www.d.shuttle.de/isil/crypt/gnupg.html" name="http://www.d.shuttle.de/isil/crypt/gnupg.html">. More information on cryptography can be found in the RSA cryptography FAQ, available at <htmlurl url="http://www.rsa.com/rsalabs/newfaq/" name="http://www.rsa.com/rsalabs/newfaq/">. Here you will find information on such terms as "Diffie-Hellman", "public-key cryptography", "Digital Certificates", etc.  <SECT1> SSL, S-HTTP, HTTPS and S/MIME Often times users ask about the differences between the various security and encryption protocols, and how to use them. While this isn't an encryption document, it is a good idea to explain briefly what each are, and where to find more information. <ITEMIZE> <ITEM><bf>SSL:</bf> - SSL, or Secure Sockets Layer, is an encryption method developed by Netscape to provide security over the Internet. It supports several different encryption protocols, and provides client and server authentication. SSL operates at the transport layer, creates a secure encrypted channel of data, and thus can seamlessly encrypt data of many types. This is most commonly seen when going to a secure site to view a secure online document with Communicator, and serves as the basis for secure communications with Communicator, as well as many other Netscape Communications data encryption. More information can be found at <htmlurl url="http://www.consensus.com/security/ssl-talk-faq.html" name="http://www.consensus.com/security/ssl-talk-faq.html">. Information on Netscape's other security implementations, and a good starting point for these protocols is available at <htmlurl url="http://home.netscape.com/info/security-doc.html" name="http://home.netscape.com/info/security-doc.html">. <ITEM><bf>S-HTTP:</bf> - S-HTTP is another protocol that provides security services across the Internet. It was designed to provide confidentiality, authenticity, integrity, and non-repudiability &lsqb cannot be mistaken for someone else ] while supporting multiple key management mechanisms and cryptographic algorithms via option negotiation between the parties involved in each transaction. S-HTTP is limited to the specific software that is implementing it, and encrypts each message individually. &lsqb From RSA Cryptography FAQ, page 138] <ITEM><bf>S/MIME:</bf> - S/MIME, or Secure Multipurpose Internet Mail Extension, is an encryption standard used to encrypt electronic mail, or other types of messages on the Internet. It is an open standard developed by RSA, so it is likely we will see it on Linux one day soon. More information on S/MIME can be found at <htmlurl url="http://home.netscape.com/assist/security/smime/overview.html" name="http://home.netscape.com/assist/security/smime/overview.html">. </ITEMIZE>  <SECT1> Linux x-kernel IPSEC Implementation Along with CIPE, and other forms of data encryption, there is also an implemention of IPSEC for Linux. IPSEC is an effort by the IETF to create cryptographically secure communications at the IP network level, which also provides authentication, integrity, access control, and confidentiality. Information on IPSEC and Internet draft can be found at <htmlurl url="http://www.ietf.org/html.charters/ipsec-charter.html" name="http://www.ietf.org/html.charters/ipsec-charter.html">. You can also find links to other protocols involving key management, and an IPSEC mailing list and archives. The Linux implementation, which is being developed at the University of Arizona, uses an object-based framework for implementing network protocols called x-kernel, and can be found at <htmlurl url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html" name="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html">. Most simply, the x-kernel is a method of passing messages at the kernel level, which makes for an easier implementation. As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.  <SECT1> SSH (Secure Shell), stelnet SSH and stelnet are programs that allow you to login to remote systems and have a encrypted connection. SSH is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as for user authentication. This can be used to securely login to a remote host or copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts. The SSH home page can be found at <htmlurl url="http://www.cs.hut.fi/ssh/" name="http://www.cs.hut.fi/ssh/"> You can also use SSH from your Windows workstation to your Linux SSH server. There are several freely available Windows client implementations, including the one at <htmlurl url="http://guardian.htu.tuwien.ac.at/therapy/ssh/" name="http://guardian.htu.tuwien.ac.at/therapy/ssh/"> as well as a commercial implementation from DataFellows, at <htmlurl url="http://www.datafellows.com" name="http://www.datafellows.com">. There is also a open source project to re-implement ssh called "psst...". For more information see: <htmlutl url="http://www.net.lut.ac.uk/psst/" name="http://www.net.lut.ac.uk/psst/"> SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol, developed by Eric Young. It includes several applications, such as Secure telnet, a module for Apache, several databases, as well as several algorithms including DES, IDEA and Blowfish. Using this library, a secure telnet replacement has been created that does encryption over a telnet connection. Unlike SSH, stelnet uses SSL, the Secure Sockets Layer protocol developed by Netscape. You can find Secure telnet and Secure FTP by starting with the SSLeay FAQ, available at <htmlurl url="http://www.psy.uq.oz.au/~ftp/Crypto/" name="http://www.psy.uq.oz.au/~ftp/Crypto/">  <SECT1> PAM - Pluggable Authentication Modules Newer versions of the Red Hat Linux distribution ship with a unified authentication scheme called "PAM". PAM allows you to change on the fly your authentication methods, requirements, and encapsulate all local authentication methods without re-compiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be suer to take a look at the PAM web site for more information. <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/index.html" name="http://www.kernel.org/pub/linux/libs/pam/index.html"> Just a few of the things you can do with PAM: <ITEMIZE> <ITEM> Use a non DES encryption for your passwords. (Making them harder to brute force decode) <ITEM> Set resource limits on all your users so they can't perform denial of service attacks (number of processes, amount of memory, etc) <ITEM> Enable shadow passwords (see below) on the fly <ITEM> allow specific users to login only at specific times from specific places </ITEMIZE> Within a few hours of installing and configuring your system, you can prevent many attacks before they even occur. For example, use PAM to disable the system-wide usage of dot-rhosts files in user's home directories by adding these lines to /etc/pam.d/login: <tscreen><verb> # # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts </verb></tscreen>  <SECT1>Cryptographic IP Encapsulation (CIPE) The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet. CIPE encrypts the data at the network level. Packets travelling between hosts on the network are encrypted. The encryption engine is placed near the driver which sends and receives packets. This is unlike SSH, which encrypts the data by connection, at the socket level. A logical connection between programs running on different hosts is encrypted. CIPE can be used in tunnelling, in order to create a Virtual Private Network. Low-level encryption has the advantage that it can be made to work transparently between the two networks connected in the VPN, without any change to application software. Summarized from the CIPE documentation: The IPSEC standards define a set of protocols which can be used (among other things) to build encrypted VPNs. However, IPSEC is a rather heavyweight and complicated protocol set with a lot of options, implementations of the full protocol set are still rarely used and some issues (such as key management) are still not fully resolved. CIPE uses a simpler approach, in which many things which can be parameterized (such as the choice of the actual encryption algorithm used) are an install-time fixed choice. This limits flexibility, but allows for a simple (and therefore efficient, easy to debug...) implementation. Further information can be found at <htmlurl url="http://www.inka.de/~bigred/devel/cipe.html" name="http://www.inka.de/~bigred/devel/cipe.html"> As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.  <SECT1> Kerberos Kerberos is an authentication system developed by the Athena Project at MIT. When a user logs in, Kerberos authenticates that user (using a password), and provides the user with a way to prove her identity to other servers and hosts scattered around the network. This authentication is then used by programs such as rlogin to allow the user to login to other hosts without a password (in place of the .rhosts file). This authentication method can also used by the mail system in order to guarantee that mail is delivered to the correct person, as well as to guarantee that the sender is who he claims to be. The overall effect of installing Kerberos and the numerous other programs that go with it is to virtually eliminate the ability of users to "spoof" the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous stanard programs. You can find more information on kerberos at <htmlurl url="http://www.veritas.com/common/f/97042301.htm" name="http://www.veritas.com/common/f/97042301.htm"> and the code can be found at <htmlurl url="http://nii.isi.edu/info/kerberos/" name="http://nii.isi.edu/info/kerberos/"> [From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]  <SECT1> Shadow Passwords. Shadow passwords are a means of keeping your encrypted password information secret from normal users. Normally this encrypted password is stored in your /etc/passwd file for all to read. They can then run password guesser programs on it and attempt to determine what it is. Shadow passwords save this information to a /etc/shadow file that only privileged users can read. In order to run shadow passwords you need to make sure all your utilities that need access to password information are recompiled to support it. PAM (above) also allows you to just plug in a shadow module and doesn't require re-compilation of executables. You can refer to the Shadow-Password HOWTO for further information if necessary. It is available at <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html" name="http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"> It is rather dated now, and will not be required for distributions supporting PAM.  <SECT1> Crack and John the Ripper If for some reason your passwd program is not enforcing non easily guessable passwords, you might want to run a password cracking program and make sure your users passwords are secure. Password cracking programs work on a simple idea. They try every word in the dictionary, and then variations on those words. They encrypt each one and check it against your encrypted password. If they get a match they are in. Also, the "dictionary" may include usernames, Star Trek ships, foreign words, keyboard patterns, etc... There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" <htmlurl url="http://www.false.com/security/john/index.html" name="http://www.false.com/security/john/index.html"> . They will take up a lot of your cpu time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to get your passwd (unix /etc/passwd) file, but these are more common than you might think.  <SECT1> CFS and TCFS - Cryptographic File Systems CFS is a way of encrypting an entire directory trees and allow users to store encrypted files on them. It uses a NFS server running on the local machine. rpms are avail at <htmlurl url="http://www.replay.com/redhat/" name="http://www.replay.com/redhat/"> and more information on how it all works is at: <htmlurl url="ftp://ftp.research.att.com/dist/mab/" name="ftp://ftp.research.att.com/dist/mab/"> TCFS improves on CFS, adding more integration with the file system, so that it's transparent to any users using the file system that it's encrypted. more information at: <htmlurl url="http://edu-gw.dia.unisa.it/tcfs/" name="http://edu-gw.dia.unisa.it/tcfs/" > It also need not be used on entire filesystems. It works on directories trees as well.  <SECT1> X11, SVGA and display security  <SECT2> X11 It's important for you to secure your graphical display to prevent attackers from doing things like: grabbing your passwords as you type them without you knowing it, reading documents or information you are reading on your screen, or even using a hole to gain superuser access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system. X has a number of access control mechanisms. The simplest of them is host based. You can use xhost to specify what hosts are allowed access to your display. This is not very secure at all. If someone has access to your machine they can xhost + their machine and get in easily. When using xdm (X Display Manager) to login, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and stored in your .Xauthority file. These cookies need to be transferred in confidence, and you really don't gain anything if your home directory is shared via NFS. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide only that connection access. See the Remote-X-Apps mini-howto, available at <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html">. You can also use ssh (see ssh, below) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no un-encrypted data flows across the network. Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites you wish to run X programs off of.  <SECT2> SVGA SVGAlib programs are typically SUID-root in order to access all your Linux machine's video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.  <SECT2> GGI (Generic Graphics Interface project) The Linux GGI project is trying to solve several of the problems with video interfaces on Linux. GGI will move a small piece of the video code into the Linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console. <htmlurl url="http://synergy.caltech.edu/~ggi/" name="http://synergy.caltech.edu/~ggi/">  <SECT> Kernel Security This is a description of the kernel configuration options that relate to security, and an explanation of what they do, and how to use them. As the kernel controls your computer's networking, it is important that the kernel is very secure, and the kernel itself won't be compromised. To prevent some of the latest networkworking attacks, you should try and keep your kernel version current. You can find new kernels at ftp://ftp.kernel.org.  <SECT1> Kernel Compile Options <ITEMIZE> <ITEM>IP: Drop source routed frames (CONFIG_IP_NOSR) This option should be enabled. Source routed frames contain the entire path to their destination inside of the packet. This means that routers the packet goes thru does not need to inspect the packet, and just forwards it on. This could lead to data entering your system that may be a potential exploit. <ITEM>IP: Firewalling (CONFIG_IP_FIREWALL) This option is necessary if you are going to configure your machine as a firewall, do masquerading, or wish to protect your dial-up workstation from someone entering via your PPP dial-up interface. <ITEM>IP: forwarding/gatewaying (CONFIG_IP_FORWARD) If you enable IP forwarding, your Linux box essentially becomes a router. If your machine is on a network, you could be forwarding data from one network to another, and perhaps subverting a firewall that was put there to prevent this from happening. Normal dial-up users will want to disable this, and other users should concentrate on the security implications of doing this. Firewall machines will want this enabled, and used in conjunction with firewall software. You can enable and disable IP forwarding dynamically using the following command: <tscreen><verb> root# echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> and disable it with the command: <tscreen><verb> root# echo 0 > /proc/sys/net/ipv4/ip_forward </verb></tscreen> This file (and many other files in /proc) will always appear to be zero length, but in fact aren't. This is a newly introduced kernel feature, so be sure your using a kernel 2.0.33 or later. <ITEM>IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) This option gives you information about packets your firewall received, like sender, receipient, port, etc. <ITEM>IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) Generally this option is disabled, but if you are building a firewall or a masquerading host, you will want to enable it. When data is sent from one host to another, it does not always get sent as a single packet of data, but rather it is fragmented into several pieces. The problem with this is that the port numbers are only stored in the first fragment. This means that someone can insert information into the remaining packets for your connection that aren't supposed to be there. It could also prevent a teardrop attack against an internal host that is not yet itself patched against it. <ITEM>IP: syn cookies (CONFIG_SYN_COOKIES) SYN Attack is a denial of service (DoS) attack that consumes all the resources on your machine, forcing you to reboot. We can't think of a reason you wouldn't normally enable this. In the 2.1 kernel series this config option mearly allows syn cookies, but does not enable them. To enable them, you have to do: echo 1 > /proc/sys/net/ipv4/tcp_syncookies <ITEM>Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) This is an option that is available in the 2.1 kernel series that will sign NCP packets for stronger security. Normally you can leave it off, but it is there if you do need it. <ITEM>IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) This is a really neat option that allows you to analyze the first 128 bytes of the packets in a userspace program, to determine if you would like to accept or deny the packet, based on its validity. </ITEMIZE>  <SECT1> Kernel Devices There are a few block and character devices available on Linux that will also help you with security. The two devices /dev/random and /dev/urandom are provided by the kernel to retrieve random data at any time. Both /dev/random and /dev/urandom should be secure enough to use in generating PGP keys, SSH challenges, and other applications where secure random numbers are requisite. Attackers should be unable to predict the next number given any initial sequence of numbers from these sources. There has been a lot of effort put in to ensuring that the numbers you get from these sources are random in every sense of the word random. The only difference is that /dev/random runs out of random bytes and it makes you wait for more to be accumulated. Note that on some systems, it can block for a long time waiting for new user-generated entry to be entered into the system. So you have to use care before using /dev/random. (Perhaps the best thing to do is to use it when you're generating sensitive keying information, and you tell the user to pound on the keyboard repeatedly until you print out "OK, enough".) /dev/random is high quality entropy, generated from measuring the inter-interrupt times etc. It blocks until enough bits of random data are available. /dev/urandom is similar, but when the store of entropy is running low, it'll return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications. You might read from the devices using something like: <tscreen><verb> root# head -c 6 /dev/urandom | uuencode - </verb></tscreen> This will print six random characters on the console, suitable for password generation. See /usr/src/linux/drivers/char/random.c for a description of the algorithm. Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for helping me (Dave) with this.  <SECT> Network Security Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than physical or local, and is much more common. There are a number of good tools to assist with network security, and more and more of them are shipping with Linux distributions.  <SECT1> Packet Sniffers One of the most common ways intruders gain access to more systems on your network is by employing a packet sniffer on a already compromised host. This "sniffer" just listens on the Ethernet port for things like "password" and "login" and "su" in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear text passwords are very vulnerable to this attack. EXAMPLE: host A has been compromised. Attacker installs a sniffer. Sniffer picks up admin logging into host B from Host C. It gets the admins personal password as they login to B. Then, the admin does a 'su' to fix a problem. They now have the root password for Host B. Later the admin lets someone telnet from his account to host Z on another site. Now the attacker has a password/login on host Z. In this day and age, the attacker doesn't even need to compromise a system to do this, they could also bring a laptop or pc into a building and tap into your net. Using ssh or other encrypted password methods thwarts this attack. Things like APOP for pop accounts also prevents this attack. (Normal pop logins are very vulnerable to this, as is anything that sends clear text passwords over the wire.)  <SECT1> System services and tcp_wrappers Before you put your Linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole. There are a number of ways to disable services under Linux. You can look at your /etc/inetd.conf file and see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then sending your inetd process a SIGHUP. You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will also be unable to find the service (ie, if you remove ftp, and try and ftp to a remote site from that machine it will fail with an unknown service message). It's usually not worth the trouble to remove services, since it provides no additional security. If a local person wanted to use ftp even though you had commented it out, they would make their own client that use the common ftp port and would still work fine. Security measures belong in the server. Generally speaking, client-side security is no good. If you know you are not going to use some particular package, you can also delete it entirely. rpm -e under the Red Hat distribution will erase an entire package. Under debian dpkg likely does the same thing. Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from being started in /etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past. You should check your /etc/rc.d/rcN.d, where N is your systems run level and see if any of the servers started in that directory are not needed. The files in /etc/rc.d/rcN.d are actually symbolic links to the directory /etc/rc.d/init.d. Renaming the files in the init.d directory has the effect of disabling all the symbolic links in /etc/rc.d/rcN.d. If you only wish to disable a service for a particular runlevel, rename the appropriate file with a lower-case 's', instead of the upper-case 'S', such as in S45dhcpd. If you have BSD style rc files, you will want to check /etc/rc* for programs you don't need. Most Linux distributions ship with tcp_wrappers "wrapping" all your tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real server. tcpd then checks the host that is requesting the service and either executes the real server or denies access from that host. tcpd allows you to restrict access to your tcp services. You should make a /etc/hosts.allow and add in only those hosts that need to have access to your machines services. If you are a home dialup user, we suggest you deny ALL. tcpd also logs failed attempts to access services, so this can give you an idea that you are under attack. If you add new services, you should be sure to configure it to use tcp_wrappers TCP based. For example, a normal dial-up user can prevent outsiders from connecting to your machine, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your /etc/hosts.allow: ALL: 127. And of course /etc/hosts.deny would contain: ALL: ALL which will prevent external connections to your machine, yet still allow you from the inside to connect to servers on the Internet.  <SECT1> Verify Your DNS Information Keeping up-to-date DNS information about all hosts on your network can help to increase security. In the event of an unauthorized host becomes connected to your network, you can recognize it by its lack of a DNS entry. Many services can be configured to not accept connections from hosts that do not have valid DNS entries.  <SECT1> identd identd is a small program that typically runs out of your inetd. It keeps track of what user is running what tcp service, and then reports this to whoever requests it. Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests. Why would you want to run it then? Because it helps _you_ out, and is another data-point in tracking. If your identd is un compromised, then you know it's telling remote sites the user-name or uid of people using tcp services. If the admin at a remote site comes back to you and tells you user so and so was trying to hack into their site, you can easily take action against that user. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user. The identd that ships with most distributions is more configurable than many people think. You can disable identd for specific users (they can make a .noident file), you can log all identd requests (I recommend it), you can even have identd return a uid instead of a user name or even NO-USER.  <SECT1> SATAN , ISS, and Other Network Scanners There are a number of different software packages out there that do port and service based scanning of machines or networks. SATAN and ISS are two of the more well known ones. This software connects to the target machine (or all the target machines on a network) on all the ports it can, and tries to determine what service is running there. Based on this information, you could find out the machine is vulnerable to a specific exploit on that server. SATAN (Security Administrators Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a machine or a network of machines. It's a good idea to get SATAN and scan your machine or network, and fix the problems it finds. Make sure you get the copy of SATAN from sun-site or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. <htmlurl url="http://www.trouble.org/~zen/satan/satan.html" name="http://www.trouble.org/~zen/satan/satan.html"> ISS (Internet Security Scanner) is another port based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information. Abacus-Sentry is a commercial port scanner from www.psionic.com. Look at it's home page on the web for more information. <htmlurl url="http://www.psionic.com" name="http://www.psionic.com"> Detecting Port scans. There are some tools designed to alert you to probes by Satan and ISS and other scanning software, However liberal use of TCP wrappers and making sure to look over your log files regularly, you should be able to notice such probes. Even on the lowest setting, Satan still leaves traces in the logs on a stock Red Hat system. There are also "stealth" port scanners. A packet with the TCP ACK bit set (as is done with established connections) will likely get through a packet-filtering firewall. The returned RST packet from a port that _had no established session_ can be taken as proof of life on that port. I don't think TCP wrappers will detect this.  <SECT1> Sendmail, qmail and MTA's. One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs. If you are using sendmail it is very important to keep up on current versions. Sendmail has a long long history of security exploits. Always make sure you are running the most recent version. <htmlurl url="http://www.sendmail.org/" name="http://www.sendmail.org"> If you are tired of upgrading your version of sendmail every week, you might consider switching over to qmail. qmail was designed with security in mind from the ground up. It's fast and stable and secure. <htmlurl url="http://www.qmail.org" name="http://www.qmail.org">  <SECT1> Denial of Service Attacks A Denial of service attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your machine. Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the Linux security lists and the bugtraq list and archives for more current information. <ITEMIZE><ITEM> <bf>SYN Flooding</bf> - SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your machine or services. See the section on kernel security for proper kernel protection options. <ITEM><bf>Pentium "F00F" Bug</bf> - It was recently discovered that a series of assembly codes send to a genuine Intel Pentium processor would reboot the machine. This affects every machine with a Pentium processor (not clones, not Pentium Pro or PII), no matter what operating system it's running. Linux kernel 2.0.32 and up contain a work around for this bug, preventing it from locking your machine. Kernel 2.0.33 has an improved version of the kernel fix, and is suggested over 2.0.32. If you are running on a Pentium, you should upgrade now! <ITEM> <bf>Ping Flooding</bf> - Ping flooding is a simple brute force denial of service attack. The attacker sends a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack, called "smurfing", sends ICMP packets to a broadcast address with _your_ machines return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack at <htmlurl url="http://www.quadrunner.com/~chuegen/smurf.txt" name=" http://www.quadrunner.com/~chuegen/smurf.txt"> If you are ever under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level or by using a firewall. <ITEM> <bf>Ping o' Death</bf> - The Ping o' Death attack is a result of incoming ICMP ECHO REQUEST packets being larger than the kernel data structures that store this information can hold. Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." This one has long been fixed, and is no longer anything to worry about. <ITEM> <bf>Teardrop / New Tear</bf> - One of the most recent exploits involves a bug present in the IP fragmentation code on Linux and Windows platforms. It is fixed in kernel version 2.0.33, and does not require selecting any kernel compile-time options to utilize the fix. Linux is apparently not vulnerable to the 'newtear' exploit. </ITEMIZE> You can find most exploit code, and a more in-depth description of how they work at <htmlurl url="http://www.rootshell.com" name="http://www.rootshell.com"> using their search engine.  <SECT1> NFS (Network File System) Security. NFS is a very widely used file sharing protocol. It allows servers running nfsd and mountd to "export" entire filesystems to other machines with nfs filesystem support builtin to their kernels (or some other client support if they are non Linux machines). Mountd keeps track of mounted filesystems in /etc/mtab, and can display them with 'showmount'. Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files. There is some small amount of "security" allowed in exporting filesystems. You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote filesystems. If you must use NFS, make sure you export to only those machines that you really need to export only. Never export your entire root directory, export only directories you need to export and export read-only wherever possible. See the NFS HOWTO for more information on NFS: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NFS-HOWTO.html" name="NFS HOWTO">  <SECT1> NIS (Network Information Service) (formerly YP). Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard /etc/passwd file), among other information. NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Not only was it not intended to be secure, it also has characteristics which inherently make it insecure. Among these are: <ITEMIZE> <ITEM> Lack of access control for contents of NIS maps <ITEM> Negation of password shadowing <ITEM> Rogue servers acting as authentic ones </ITEMIZE> Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use Crack against your users passwords. If you must use NIS, make sure you are aware of the dangers. There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html">  <SECT1> Firewalls Firewalls are a means of restricting what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local lan, and the only access from your lan to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your lan. There are a number of types and methods of setting up firewalls. Linux machines make pretty good low cost firewalls. Firewall code can be built right into 2.0 and higher kernels. The ipfwadm user space tool allows you to change what types of network traffic you allow on the fly. You can also log particular types of network traffic. Firewalls are a very usefull and important technique in securing your network. It is important to realize that you should never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good Firewall-HOWTO at your latest sunsite archive for more information on firewalls and Linux. <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"> More information can also be found in the IP-Masquerade mini-howto: <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html" name="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"> More information on ipfwadm (The tool that lets you change settings on your firewall, can be found at it's home page: <htmlurl url="http://www.xos.nl/linux/ipfwadm/" name="http://www.xos.nl/linux/ipfwadm/">  <SECT> Security Preparation (before you go on-line) Ok, so you have checked over your system, and determined its as secure as feasible, and are ready to put it online. There are a few things you should now do in order to be prepared in case an intrusion actually does happen, so you can quickly disable the intruder, and get back up and running.  <SECT1> Make a Full Backup of Your Machine Discussion of backup methods and storage is beyond the scope of this document, but a few words relating to backups and security: If you have less than 650mb of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time). Tapes and other re-writable media should be write protected as soon as your backup is complete and verified to prevent tampering. Make sure you store your backups in a secure off line area. A good backup will ensure that you have a known good point to restore your system from.  <SECT1> Choosing a Good Backup Schedule A six-tape cycle is an easy one to maintain. This includes four tapes for during the week, one tape for even Friday's, and one tape for odd Friday's. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particular important changes or add some important data to your system, a backup might well be in order.  <SECT1> Backup Your RPM or Debian File Database In the event of an intrusion, you can use your RPM database like you would use tripwire, but only if you can be sure it too hasn't been modified. You should copy the RPM database to a floppy, and keep this copy off-line at all times. The Debian distribution likely has something similar. Specifically, the files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single floppy. Compressed, each should fit on a seperate floppy. Now, when your system is compromised, you can use the command: <tscreen><verb> root# rpm -Va </verb></tscreen> to verify each file on the system. See the RPM man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. This means that every time a new RPM is added to the system, the RPM database will need to be rearchived. You will have to decide the advantages versus drawbacks.  <SECT1>Keep Track of Your System Accounting Data It is very important that the information that comes from syslog has not been compromised. Making the files in /var/log readable and writable by a limited number of users is a good start. Be sure to keep an eye on what gets written there, especially under the `auth' facility. Multiple login failures, for example, can indicate an attempted break-in. Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in /var/log and check messages, mail.log, and others. You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells syslogd (the system logging daemon) where to log various messages. You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the 'logrotate' package un recent Red Hat distributions. Other distributions likely have a similar process. If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things they appeared to tamper with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea. Log files are typically modified by the intruder in order to cover his tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them. You should also be sure to seperate the `auth' facility from other log data, including attempts to switch users using `su', login attempts, and other user accounting information. If possible, configure syslog to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and refer to the `@' option. Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what the look like on a normal day. Knowing this can help make unusual things stand out.  <SECT1> Apply All New System Updates. Most Linux users install from a CDROM. Due to the fast paced nature of security fixes, new (fixed) programs are always being released. Before you connect your machine to the network, it's a good idea to check with your distribution's ftp site (ftp.redhat.com for example) and get all the updated packages since you received your distribution CDROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.  <SECT> What To Do During and After a Breakin So you have followed some of the advice here (or elsewhere) and have detected a breakin? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have.  <SECT1> Security Compromise under way. Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences. If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab setting you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people. If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they are normally in from? no? Then use a non electronic means of getting in touch. For instance, call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations. If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable, if they are connected via ethernet, unplug the ethernet cable. If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like tcp_wrappers or ipfwadm to deny access from the intruders site. If you can't deny all people from the same site as the intruder, locking the users account will have to do. Note that locking an account is not an easy thing. You have to keep in mind .rhosts files, FTP access, and a host of backdoors). After you have done one of the above (disconnected network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off. You should monitor your site well for the next few minutes, as the attacker will try and get back in. Perhaps using a different account, and/or from a different network address.  <SECT1> Security Compromise has already happened So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what?  <SECT2> Closing the Hole If you are able to determine what means the attacker used to get into your system, you should try and close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version or any of the lists know of a fix. Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. You can find Caldera security fixes here <htmlurl url="http://www.caldera.com/tech-ref/security/" name="http://www.caldera.com/tech-ref/security/">. Red Hat has not yet seperated their security fixes from bugfixes, but their distribution errata is available at <htmlurl url="http://www.redhat.com/errata" name="http://www.redhat.com/errata"> Debian now has a security mailing list and web page. See: <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/"> for more information. It is very likely that if one vendor has released a security update, that most other Linux vendors will as well. There is now a linux security auditing project. They are methodically going through all the user space utilities and looking for possible security exploits and overflows. From their announcement: "We are attempting a systematic audit of Linux sources with a view to being as secure as OpenBSD. We have already uncovered (and fixed) some problems, but more help is welcome. The list is unmoderated and also a useful resource for general security discussions. The list address is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: security-audit-subscribe@ferret.lmh.ox.ac.uk" If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local machines.  <SECT2> Assessing the Damage The first thing is to assess the damage. What has been compromised? If you are running an Integrity Checker like Tripwire you can make a tripwire run and it should tell you. If not, you will have to look around at all your important data. Since Linux systems are getting easier and easier to install, you might consider saving your config files and then wiping your disk(s) and reinstalling, then restoring your user files from backups and your config files. This will insure that you have a new clean system. If you have to backup files from the compromised system, be especially cautious of any binaries that you restore as they may be trojan horses placed there by the intruder. Re-installation should be considered mandatory upon an intruder obtaining root access. Additionally, you'd like to keep any evidence there is, so having a spare disk in the safe may make sense. Then you have to worry about how long ago the compromise happened, and whether the backups hold any damaged work. More on backups later.  <SECT2> Backups, Backups, Backups! Having regular backups is a godsend for security matters. If your system is compromised, you can restore the data you need from backups. Of course some data is valuable to the attacker to, and they will not only destroy it, they will steal it and have their own copies, but at least you will still have the data. You should check several backups back into the past before restoring a file that has been tampered with. The intruder could have compromised your files long ago, and you could have made many successful backups of the compromised file!!! Of course, there are also a raft of security concerns with backups. Make sure you are storing them in a secure place. Know who has access to them. (If an attacker can get your backups, they can have access to all your data without you ever knowing it.)  <SECT2> Tracking Down the Intruder. Ok, you have locked the intruder out, and recovered your system, but you're not quite done yet. While it is unlikely that most intruders will ever be caught, you should report the attack. You should report the attack to the admin contact at the site where the attacker attacked your system. You can look up this contact with "whois" or the internic database. You might send them an email with all applicable log entries and dates and times. If you spotted anything else distinctive about your intruder, you might mention that too. After sending the email, you should (if you are so inclined) follow up with a phone call. If that admin in turn spots your attacker, they might be able to talk to the admin of the site where they are coming from and so on. Good hackers often use many intermediate systems. Some (or many) of which may not even know they have been compromised. Trying to track a cracker back to their home system can be difficult. Being polite to the admins you talk to can go a long way to getting help from them. You should also notify any security organizations you are a part of (CERT or similar), as well as your Linux system vendor.  <SECT> Security Sources There are a LOT of good sites out there for UNIX security in general and Linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative.  <SECT1> Web Sites <ITEMIZE> <ITEM> The Hacker FAQ is a FAQ about hackers: <htmlurl url="http://www.solon.com/~seebs/faqs/hacker.html" name="The Hacker FAQ"> <ITEM> The COAST archive has a large number of unix security programs and information: <htmlurl url="http://www.cs.purdue.edu/coast/" name="COAST"> <ITEM> Rootshell.com is a great site for seeing what exploits are currently being used by crackers: <htmlurl url="http://www.rootshell.com/" name="rootshell.com exploits"> <ITEM> BUGTRAQ puts out advisories on security issues: <htmlurl url="http://www.netspace.org/lsv-archive/bugtraq.html" name="BUGTRAQ archives"> <ITEM> CERT, the Computer Emergency Response Team, puts out advisories on common attacks on unix platforms: <htmlurl url="http://www.cert.org/" name="CERT home"> <ITEM> Dan Farmer is the author of SATAN and many other security tools, his home site has some interesting security survey information as well as security tools: <htmlurl url="http://www.trouble.org" name="Dan Farmers trouble.org"> <ITEM> The Linux security WWW is a good site for Linux security information: <htmlurl url="http://www.aoy.com/Linux/Security/" name="Linux Security WWW"> <ITEM> Reptile has lots of good Linux security information on his site: <htmlurl url="http://207.237.120.45/linux/" name="Reptiles Linux Security Page"> <ITEM> Infilsec has a vulnerability engine that can tell you what vunerabilities affect a specific platform: <htmlurl url="http://www.infilsec.com/vulnerabilities/" name="Infilsec vunerability engine"> <ITEM> CIAC sends out periodic security bulletins on common exploits: <htmlurl url="http://ciac.llnl.gov/cgi-bin/index/bulletins" name="CIAC bulitins"> <ITEM> A good starting point for Linux Pluggable Authentication modules can be found at <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/" name="http://www.kernel.org/pub/linux/libs/pam/">. <ITEM> The debian project has a web page for their security fixes and information. It is at <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/">. </ITEMIZE>  <SECT1> Mailing Lists Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. (see links above for archives). CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not subject) of the message put (either or both): subscribe ciac-bulletin Redhat has a number of mailing lists, the most important of which is the redhat-announce list. You can read about security (and other) fixes as soon as they come out. Send email to majordomo@redhat.com and put subscribe redhat-announce. The debian project has a security mailing list that covers their security fixes. see <htmlurl url="http://www.debian.com/security/" name="http://www.debian.com/security/"> for more information.  <SECT1> Books - Printed Reading Material. There are a number of good security books out there. This section lists a few of them. In addition to the security specify books, security is covered in a number of other books on system administration. Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4  <SECT> Glossary <ITEMIZE> <ITEM><bf>Host:</bf> A computer system attached to a network <ITEM><bf>Firewall:</bf> A component or set of components that restricts access between a protected network and the Internet, or between other sets of networks. <ITEM><bf>Bastion Host:</bf> A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projects on the outer walls of medieval castles. Bastions overlook critical areas of defense, usually having strongs walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers. <ITEM><bf>Dual-homed Host:</bf> A general-purpose computer system that has at least two network interfaces. <ITEM><bf>Packet:</bf> The fundamental unit of communication on the Internet. <ITEM><bf>Packet Filtering:</bf> The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice-versa). accomplish packet filtering, you set up a set of rules that specifiy what types of packets (those to or from a particular IP address or port) are to be allowed and what types are to be blocked. <ITEM><bf>Perimeter network:</bf> A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ. <ITEM><bf>Proxy server:</bf> A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests on to real servers, and relay answers back to clients. <ITEM><bf>Denial of Service:</bf> A denial of service attack is when an attacker consumes the resources on your computer for things it was not intended to be doing, thus preventing normal use of your network resources to legimite purposes. <ITEM><bf>Buffer Overflow:</bf> Common coding style is never to allocate buffers "large enough" and not checking for overflows. When such buffers are overflows, the executing program (daemon or set-uid program) can be tricked in doing some other things. Generally this works by overwriting a function's return address on the stack to point to another location. <ITEM><bf>IP Spoofing:</bf> IP-Spoofing is a complex technical attack that is made up of several components. It is a security exploit that works by tricking computers in a trust-relationship that you are someone that you really aren't. There is an extensive paper written by daemon9, route, and infinity in the Volume Seven, Issue fourty-Eight issue of Phrack Magazine. <ITEM><bf>Authentication:</bf> The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. <ITEM><bf>Non-repudiation:</bf> The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data. </ITEMIZE>  <SECT> Frequently Asked Questions <enum> <ITEM> Is it more secure to compile driver support directly into the kernel, instead of making it a module? Answer: Some people think it is better to disable the ability to load device drivers using modules, because an intruder could load a trojan module or himself load a module that could affect system security. However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module. Modules are for dynamically loading support for a particular device that may be infrequently used. On server machines, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as a server. Modules are also slower than support compiled directly in the kernel. <ITEM> Logging in as root from a remote machine always fails. Answer: See the section on Root security. This is done intentionally to prevent remote users from attempting to connect via telnet to your machine as root, which is a serious security vulnerability. Don't forget, potential intruders have time on their side, and can run automated programs to find your password. <ITEM> How do I enable shadow passwords on my Red Hat 4.2 or 5.0 Linux box? Answer: Shadow passwords is a mechanism for storing your password in a file other than the normal /etc/passwd file. This has several advantages. The first one is that the shadow file, /etc/shadow, is only readable by root, unlike /etc/passwd, which must remain readable by everyone. The other advantage is that as the administrator, you can enable or disable accounts without everyone knowing the status of other users accounts. The /etc/passwd file is then used to store user and group names, used by programs like `/bin/ls' to map the user ID to the proper username in a directory listing. The /etc/shadow file then only contains the username and his/her password, and perhaps accounting information, like when the account expires, etc. To enable shadow passwords, run 'pwconv' as root, and /etc/shadow should now exist, and be used by applications. Since you are using RH 4.2 or above, the PAM modules will automatically adapt to the change from using normal /etc/passwd to shadow passwords without any other change. Since you are interested in securing your passwords, perhaps you would also be interested in generating good passwords to begin with. For this you can use the `pam_cracklib' module, which is part of PAM. It runs your password against the Crack libraries to help you decide if it is too easily guessable by password cracking programs. <ITEM> How can I enable the Apache SSL extensions? Answer: 1.Get SSLeay 0.8.0 or later from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL 2.Build and test and install it! 3.Get Apache 1.2.5 source 4.Get Apache SSLeay extensions from <url url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz" name="here"> 5.Unpack it in the apache-1.2.5 source directory and patch Apache as per the README. 6.Configure and build it. You might also try <htmlurl url="http://www.replay.com" name="Replay Associates"> which has many pre-built packages, and is located outside of the United States. <ITEM> How can I manipulate user accounts, and still retain security? Answer: The Red Hat distribution, especially RH5.0, contains a great number of tools to change the properties of user accounts. <ITEMIZE><ITEM> The pwconv and unpwconv programs can be used to convert back and forth between shadow and non-shadowed passwords <ITEM>The pwck and grpck programs can be used to verify proper organization of the passwd and group files. <ITEM>The programs useradd, usermod, and userdel can be used to add, delete and modify user accounts. The programs groupadd, groupmod, and groupdel will do the same for groups. <ITEM>Group passwords can be created using gpasswd. </ITEMIZE> All these programs are 'shadow-aware' -- that is; if you enable shadow it will use /etc/shadow for password information, otherwise it won't. See the respective man pages for further information. <ITEM> How can I password protect specific HTML documents using Apache? I bet you didn't know about <htmlurl url="http://www.apacheweek.com" name="http://www.apacheweek.org"> did you? You can find information on User Authentication at <htmlurl url="http://www.apacheweek.com/features/userauth" name="http://www.apacheweek.com/features/userauth"> as well as other web server security tips from <htmlurl url="http://www.apache.org/docs/misc/security_tips.html" name="http://www.apache.org/docs/misc/security_tips.html"> </enum>  <SECT> Conclusion By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your machine. If you pay attention to your log files and run something like tripwire regularly, you can do even more. A reasonable level of computer security is not difficult to maintain on a home machine. More effort is required on business machines, but Linux can indeed be a secure platform. Due to the nature of Linux development, security fixes often come out much faster than they do on commercial operating systems, making Linux an ideal platform when security is a requirement.  <SECT> Thanks to Information here is collected from many sources. Thanks to the following that either indirectly or directly have contributed: <tscreen><verb> Rob Riggs <rob@DevilsThumb.com> S. Coffin <scoffin@netcom.com> Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu> Roelof Osinga <roelof@eboa.com> Kyle Hasselbacher <kyle@carefree.quux.soltec.net> "David S. Jackson" <dsj@dsj.net> "Todd G. Ruskell" <ruskell@boulder.nist.gov> Rogier Wolff <R.E.Wolff@BitWizard.nl> Antonomasia <ant@notatla.demon.co.uk> Nic Bellamy <sky@wibble.net> </verb></tscreen>  </article>