This is Info file Security-HOWTO.info, produced by Makeinfo version 1.68 from the input file /tmp/sgmltmp.Security-HOWTO26383.info.2. \input texinfo  File: Security-HOWTO.info, Node: Trojan Horses, Prev: Integrity Checking with Tripwire `Tripwire', Up: Files and Filesystem Security Trojan Horses ============= "Trojan Horses" are named after the fabled ploy in Homer's "Iliad". The idea is that a cracker distributes a program or binary that sounds great, and encourages other people to download it and run it as root. Then the program 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 signatures on it's RPM files so you can verify you are installing the real thing. Other distributions have similar methods. You should never run any unfamiliar binary, for which you don't have the source, 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 a program from its 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.  File: Security-HOWTO.info, Node: Password Security and Encryption, Next: Kernel Security, Prev: Files and Filesystem Security, Up: Top Password Security and 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 `passwd' 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 an 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 its own set of characteristics. Most Unixes (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, the password 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 *Note "Crack" and "John the Ripper":: ) can often guess passwords unless your password is sufficiently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can go to http://consult.cern.ch/writeup/security/security_3.html for information on how to choose a good password. * Menu: * PGP and Public-Key Cryptography:: * SSL S-HTTP HTTPS and S/MIME:: * Linux x-kernel IPSEC Implementation:: * `ssh' (Secure Shell) and `stelnet':: * PAM - Pluggable Authentication Modules:: * Cryptographic IP Encapsulation (CIPE):: * Kerberos:: * Shadow Passwords-:: * "Crack" and "John the Ripper":: * CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System:: * X11 SVGA and display security::  File: Security-HOWTO.info, Node: PGP and Public-Key Cryptography, Next: SSL S-HTTP HTTPS and S/MIME, Up: Password Security and Encryption PGP and Public-Key Cryptography =============================== Public-key cryptography, such as that used for PGP, uses one key for encryption, and one key for decryption. Traditional cryptography, however, uses the same key for encryption and decryption; this key must be known to both parties, and thus somehow transferred from one to the other securely. To alleviate the need to securely transmit the encryption key, public-key encryption uses two separate 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 (http://www.rsa.com/rsalabs/newfaq/), 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 at the PGP FAQ: 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 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; the patch is available at ftp://metalab.unc.edu/pub/Linux/apps/crypto. There is a project working on a free re-implementation of pgp with open source. GnuPG is a complete and free replacement for PGP. Because it does not use IDEA or RSA it can be used without any restrictions. GnuPG is nearly in compliance with RFC2440 (OpenPGP). See the GNU Privacy Guard web page for more information: http://www.gpg.org/. More information on cryptography can be found in the RSA cryptography FAQ, available at http://www.rsa.com/rsalabs/newfaq/. Here you will find information on such terms as "Diffie-Hellman", "public-key cryptography", "digital certificates", etc.  File: Security-HOWTO.info, Node: SSL S-HTTP HTTPS and S/MIME, Next: Linux x-kernel IPSEC Implementation, Prev: PGP and Public-Key Cryptography, Up: Password Security and Encryption SSL S-HTTP HTTPS and S/MIME =========================== Often 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 protocol is, and where to find more information. * `SSL:' - 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 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 http://home.netscape.com/info/security-doc.html. * `S-HTTP:' - S-HTTP is another protocol that provides security services across the Internet. It was designed to provide confidentiality, authentication, 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] * `S/MIME:' - S/MIME, or Secure Multipurpose Internet Mail Extension, is an encryption standard used to encrypt electronic mail and 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 http://home.netscape.com/assist/security/smime/overview.html.  File: Security-HOWTO.info, Node: Linux x-kernel IPSEC Implementation, Next: `ssh' (Secure Shell) and `stelnet', Prev: SSL S-HTTP HTTPS and S/MIME, Up: Password Security and Encryption Linux x-kernel IPSEC Implementation =================================== Along with CIPE, and other forms of data encryption, there is also an implementation of IPSEC for Linux. IPSEC is an effort by the IETF to create cryptographically-secure communications at the IP network level, and to provide authentication, integrity, access control, and confidentiality. Information on IPSEC and Internet draft can be found at 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 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.  File: Security-HOWTO.info, Node: `ssh' (Secure Shell) and `stelnet', Next: PAM - Pluggable Authentication Modules, Prev: Linux x-kernel IPSEC Implementation, Up: Password Security and Encryption `ssh' (Secure Shell) and `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 to authenticate users. It 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 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 http://guardian.htu.tuwien.ac.at/therapy/ssh/ as well as a commercial implementation from DataFellows, at http://www.datafellows.com. There is also a open source project to re-implement ssh called "psst...". For more information see: 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 http://www.psy.uq.oz.au/~ftp/Crypto/. SRP is another secure telnet/ftp implementation. From their web page: "The SRP project is developing secure Internet software for free worldwide use. Starting with a fully-secure Telnet and FTP distribution, we hope to supplant weak networked authentication systems with strong replacements that do not sacrifice user-friendliness for security. Security should be the default, not an option!" For more information, go to SRP's home page.  File: Security-HOWTO.info, Node: PAM - Pluggable Authentication Modules, Next: Cryptographic IP Encapsulation (CIPE), Prev: `ssh' (Secure Shell) and `stelnet', Up: Password Security and Encryption 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 your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be sure to take a look at the PAM web site for more information. http://www.kernel.org/pub/linux/libs/pam/index.html. Just a few of the things you can do with PAM: * Use encryption other than DES for your passwords. (Making them harder to brute-force decode) * Set resource limits on all your users so they can't perform denial-of-service attacks (number of processes, amount of memory, etc) * Enable shadow passwords (see below) on the fly * allow specific users to login only at specific times from specific places 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 `.rhosts' files in user's home directories by adding these lines to `/etc/pam.d/rlogin': # # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts  File: Security-HOWTO.info, Node: Cryptographic IP Encapsulation (CIPE), Next: Kerberos, Prev: PAM - Pluggable Authentication Modules, Up: Password Security and Encryption 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 traveling 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 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.  File: Security-HOWTO.info, Node: Kerberos, Next: Shadow Passwords-, Prev: Cryptographic IP Encapsulation (CIPE), Up: Password Security and Encryption 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. Kerberos and the other programs that come with it, prevent users from "spoofing" the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous standard programs. You can find more information about kerberos by looking at the kerberos FAQ, and the code can be found at http://nii.isi.edu/info/kerberos/. [lsqb ]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.]  File: Security-HOWTO.info, Node: Shadow Passwords-, Next: "Crack" and "John the Ripper", Prev: Kerberos, Up: Password Security and Encryption Shadow Passwords- ================= Shadow passwords are a means of keeping your encrypted password information secret from normal users. Normally, this encrypted passwords are stored in `/etc/passwd' file for all to read. Anyone can then run password guesser programs on them and attempt to determine what they are. Shadow passwords, by contrast, are saved in `/etc/shadow', which only privileged users can read. In order to use shadow passwords, you need to make sure all your utilities that need access to password information are recompiled to support them. PAM (above) also allows you to just plug in a shadow module; it doesn't require re-compilation of executables. You can refer to the Shadow-Password HOWTO for further information if necessary. It is available at http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html It is rather dated now, and will not be required for distributions supporting PAM.  File: Security-HOWTO.info, Node: "Crack" and "John the Ripper", Next: CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System, Prev: Shadow Passwords-, Up: Password Security and Encryption "Crack" and "John the Ripper" ============================= If for some reason your `passwd' program is not enforcing hard-to-guess 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, encrypting each one and checking it against your encrypted password. If they get a match they know what your password is. There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" (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 read your `/etc/passwd' file, but such holes are more common than you might think.  File: Security-HOWTO.info, Node: CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System, Next: X11 SVGA and display security, Prev: "Crack" and "John the Ripper", Up: Password Security and Encryption CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System ================================================================================ CFS is a way of encrypting an entire directory trees and allowing users to store encrypted files on them. It uses a NFS server running on the local machine. RPMS are available at http://www.replay.com/redhat/, and more information on how it all works is at ftp://ftp.research.att.com/dist/mab/. TCFS improves on CFS by adding more integration with the file system, so that it's transparent to users that the file system that is encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/. It also need not be used on entire filesystems. It works on directories trees as well.  File: Security-HOWTO.info, Node: X11 SVGA and display security, Prev: CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System, Up: Password Security and Encryption X11 SVGA and display security ============================= * Menu: * X11:: * SVGA:: * GGI (Generic Graphics Interface project)::  File: Security-HOWTO.info, Node: X11, Next: SVGA, Up: X11 SVGA and display security X11 --- It's important for you to secure your graphical display to prevent attackers from grabbing your passwords as you type them, reading documents or information you are reading on your screen, or even using a hole to gain root 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 use `xhost' to specify what hosts are allowed access to your display. This is not very secure at all, because if someone has access to your machine, they can `xhost + `their machine" and get in easily. Also, if you have to allow access from an untrusted machine, anyone there can compromise your display. When using `xdm' (X Display Manager) to log in, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and stored in your `.Xauthority' file. 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 access to only that connection. See the Remote-X-Apps mini-howto, available at http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html. You can also use `ssh' (see *Note `ssh' (Secure Shell) and `stelnet':: , above) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no unencrypted 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 on which you with to run X programs.  File: Security-HOWTO.info, Node: SVGA, Next: GGI (Generic Graphics Interface project), Prev: X11, Up: X11 SVGA and display security 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.  File: Security-HOWTO.info, Node: GGI (Generic Graphics Interface project), Prev: SVGA, Up: X11 SVGA and display security 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. http://synergy.caltech.edu/~ggi/  File: Security-HOWTO.info, Node: Kernel Security, Next: Network Security, Prev: Password Security and Encryption, Up: Top 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 it be very secure, and not be compromised. To prevent some of the latest networking attacks, you should try to keep your kernel version current. You can find new kernels at urlnam (ftp://ftp.kernel.org). There is also a international group providing a single unified crypto patch to the mainstream linux kernel. This patch provides support for a number of cyrptographic subsystems and things that cannot be included in the mainstream kernel due to export restrictions. For more information, visit their web page at: http://www.kerneli.org * Menu: * Kernel Compile Options:: * Kernel Devices::  File: Security-HOWTO.info, Node: Kernel Compile Options, Next: Kernel Devices, Up: Kernel Security Kernel Compile Options ====================== For 2.0.x kernels, the following options apply. You should see these when you are doing a 'make config' , a 'make menuconfig' or a 'make xconfig'. * IP: Drop source routed frames (CONFIG[lowbar]IP[lowbar]NOSR) This option should be enabled. Source routed frames contain the entire path to their destination inside of the packet. This means that routers through which the packet goes do not need to inspect it, and just forward it on. This could lead to data entering your system that may be a potential exploit. * IP: Firewalling (CONFIG[lowbar]IP[lowbar]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. * IP: forwarding/gatewaying (CONFIG[lowbar]IP[lowbar]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: root# echo 1 > /proc/sys/net/ipv4/ip_forward and disable it with the command: root# echo 0 > /proc/sys/net/ipv4/ip_forward 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 you're using kernel 2.0.33 or later. * IP: firewall packet logging (CONFIG[lowbar]IP[lowbar]FIREWALL[lowbar]VERBOSE) This option gives you information about packets your firewall received, like sender, recipient, port, etc. * IP: always defragment (CONFIG[lowbar]IP[lowbar]ALWAYS[lowbar]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 that isn't supposed to be there. It could also prevent a teardrop attack against an internal host that is not yet itself patched against it. * IP: syn cookies (CONFIG[lowbar]SYN[lowbar]COOKIES) a "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[lowbar]syncookies * Packet Signatures (CONFIG[lowbar]NCPFS[lowbar]PACKET[lowbar]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. * IP: Firewall packet netlink device (CONFIG[lowbar]IP[lowbar]FIREWALL[lowbar]NETLINK) This is a really neat option that allows you to analyze the first 128 bytes of the packets in a user-space program, to determine if you would like to accept or deny the packet, based on its validity. For 2.2.x kernels, many of the options are the same, but a few new ones have poped up. * Network Firewalls (CONFIG[lowbar]FIREWALL) This option should be on if you intend to run any firewalling or masquerading on your linux machine. If it's just going to be a regular client machine, it's safe to say no. * Socket Filtering (CONFIG[lowbar]FILTER) For most people, it's safe to say no to this option. This option allows you to connect a userspace filter to any socket and determine if packets should be allowed or denied. Unless you have a very specific need and are capable of programming such a filter, you should say no. Also note that as of this writing, all protocols were supported except TCP.  File: Security-HOWTO.info, Node: Kernel Devices, Prev: Kernel Compile Options, Up: Kernel Security 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 provide 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. 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: root# head -c 6 /dev/urandom | uuencode - 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.  File: Security-HOWTO.info, Node: Network Security, Next: Security Preparation (before you go on-line), Prev: Kernel Security, Up: Top 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 compromising 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. * Menu: * Packet Sniffers:: * System services and tcp[lowbar]wrappers:: * Verify Your DNS Information:: * `identd':: * SATAN ISS and Other Network Scanners:: * `sendmail' `qmail' and MTA's:: * Denial of Service Attacks:: * NFS (Network File System) Security-:: * NIS (Network Information Service) (formerly YP)-:: * Firewalls:: * VPN's - Virtual Private Networks::  File: Security-HOWTO.info, Node: Packet Sniffers, Next: System services and tcp[lowbar]wrappers, Up: Network Security 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 admin's 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 network.)  File: Security-HOWTO.info, Node: System services and tcp[lowbar]wrappers, Next: Verify Your DNS Information, Prev: Packet Sniffers, Up: Network Security System services and tcp[lowbar]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 (`[num ]' 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 (i.e., 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. Some of the services you might want to leave enabled are: * `ftp' * `telnet' (or `ssh') * mail, such as `pop-3' or `imap' * `identd' If you know you are not going to use some particular package, you can also delete it entirely. `rpm -e `packagename" under the Red Hat distribution will erase an entire package. Under debian `dpkg -remove' 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 run level, rename the appropriate file by replacing the upper-case `S' with a lower-case `s', like this: root# cd /etc/rc6.d root# mv S45dhcpd 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[lowbar]wrappers "wrapping" all your TCP services. A tcp[lowbar]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 machine's 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 alert you if you are under attack. If you add new services, you should be sure to configure them to use tcp[lowbar]wrappers if they are TCP based. For example, a normal dial-up user can prevent outsiders from connecting to his 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.  File: Security-HOWTO.info, Node: Verify Your DNS Information, Next: `identd', Prev: System services and tcp[lowbar]wrappers, Up: Network Security Verify Your DNS Information =========================== Keeping up-to-date DNS information about all hosts on your network can help to increase security. If 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.  File: Security-HOWTO.info, Node: `identd', Next: SATAN ISS and Other Network Scanners, Prev: Verify Your DNS Information, Up: Network Security `identd' ======== `identd' is a small program that typically runs out of your `inetd' server. 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 it for specific users (they can make a `.noident' file), you can log all `identd' requests (We recommend it), you can even have identd return a uid instead of a user name or even NO-USER.  File: Security-HOWTO.info, Node: SATAN ISS and Other Network Scanners, Next: `sendmail' `qmail' and MTA's, Prev: `identd', Up: Network Security 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, ISS, SAINT, and Nessus are some 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 they can, and try to determine what service is running there. Based on this information, you can tell if the machine is vulnerable to a specific exploit on that server. SATAN (Security Administrator's 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 metalab (http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/) or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. http://www.trouble.org/~zen/satan/satan.html. Note that SATAN has not been updated in quite a while, and some of the other tools below might do a better job. 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 is a suite of tools to provide host based security and intrusion detection. look at it's home page on the web for more information. http://www.psionic.com/abacus/ SAINT is a updated version of SATAN. It is web based and has many more up to date tests than SATAN. You can find out more about it at: http://www.wwdsi.com/~saint Nessus is a free security scanner. It has a GTK graphical interface for ease of use. It is also designed with a very nice plugin setup for new port scanning tests. For more information, take a look at: http://www.nessus.org * Menu: * Detecting Port scans-::  File: Security-HOWTO.info, Node: Detecting Port scans-, Up: SATAN ISS and Other Network Scanners Detecting Port scans- --------------------- There are some tools designed to alert you to probes by SATAN and ISS and other scanning software. However liberally use tcp[lowbar]wrappers, and make 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 `[lowbar]had no established session[lowbar]' can be taken as proof of life on that port. I don't think TCP wrappers will detect this.  File: Security-HOWTO.info, Node: `sendmail' `qmail' and MTA's, Next: Denial of Service Attacks, Prev: SATAN ISS and Other Network Scanners, Up: Network Security `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 from 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, stable, and secure. http://www.qmail.org  File: Security-HOWTO.info, Node: Denial of Service Attacks, Next: NFS (Network File System) Security-, Prev: `sendmail' `qmail' and MTA's, Up: Network Security Denial of Service Attacks ========================= A "Denial of service" (DoS) 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. * `SYN Flooding' - 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 *Note Kernel Security:: for proper kernel protection options. * `Pentium "F00F" Bug' - It was recently discovered that a series of assembly codes sent 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 kernels 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! * `Ping Flooding' - 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 host with `your' machine's return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack at 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. * `Ping o' Death' - The Ping o' Death attack sends ICMP ECHO REQUEST packets that are too large to fit in the kernel data structures intended to store them. 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. * `Teardrop / New Tear' - 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. You can find code for most exploits, and a more in-depth description of how they work, at http://www.rootshell.com using their search engine.  File: Security-HOWTO.info, Node: NFS (Network File System) Security-, Next: NIS (Network Information Service) (formerly YP)-, Prev: Denial of Service Attacks, Up: Network Security 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 using NFS filesystem support built in to their kernels (or some other client support if they are not 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 root user 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. Never export your entire root directory; export only directories you need to export. See the NFS HOWTO for more information on NFS: NFS HOWTO