From ea469c10fa49bc94f6a3ca8942bc85a22850a151 Mon Sep 17 00:00:00 2001 From: Jim Mock Date: Sat, 25 Mar 2000 00:19:02 +0000 Subject: [PATCH] DocBook-ify the security(7) man page and add it to the chapter since it contains useful general security information. Suggested by: unfurl --- .../books/handbook/security/chapter.sgml | 737 +++++++++++++++++- .../books/handbook/security/chapter.sgml | 737 +++++++++++++++++- 2 files changed, 1466 insertions(+), 8 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index 60859ae9a6..6cc393ebe3 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,18 +1,747 @@ Security - - Parts rewritten and updated by &a.unfurl;, 21 March - 2000. + + Much of this chapter has been taken from the + &man.security.7; man page, originally written by + &a.dillon;. + + + Synopsis + + The following chapter will provide a basic introduction to + system security concepts, some general good rules of thumb, and some + advanced topics such as S/Key, OpenSSL, Kerberos, and others. + + + + Introduction + + Security is a function that begins and ends with the system + administrator. While all BSD UNIX multi-user systems have some + inherent security, the job of building and maintaining additional + security mechanisms to keep those users “honest” is + probably one of the single largest undertakings of the sysadmin. + Machines are only as secure as you make them, and security concerns + are ever competing with the human necessity for convenience. UNIX + systems, in general, are capable of running a huge number of + simultaneous processes and many of these processes operate as + servers – meaning that external entities can connect and talk + to them. As yesterday's mini-computers and mainframes become + today's desktops, and as computers become networked and + internetworked, security becomes an ever bigger issue. + + Security is best implemented through a layered + “onion” approach. In a nutshell, what you want to do is + to create as many layers of security as are convenient and then + carefully monitor the system for intrusions. You do not want to + overbuild your security or you will interefere with the detection + side, and detection is one of the single most important aspects of + any security mechanism. For example, it makes little sense to set + the schg flags (see &man.chflags.1;) on every system binary because + while this may temporarily protect the binaries, it prevents a + hacker who has broken in from making an easily detectable change + that may result in your security mechanisms not detecting the hacker + at all. + + System security also pertains to dealing with various forms of + attack, including attacks that attempt to crash or otherwise make a + system unusable but do not attempt to break root. Security concerns + can be split up into several categories: + + + + Denial of service attacks. + + + + User account compromises. + + + + Root compromise through accessible servers. + + + + Root compromise via user accounts. + + + + Backdoor creation. + + + + A denial of service attack is an action that deprives the + machine of needed resources. Typically, D.O.S. attacks are + brute-force mechanisms that attempt to crash or otherwise make a + machine unusable by overwhelming its servers or network stack. Some + D.O.S. attacks try to take advantages of bugs in the networking + stack to crash a machine with a single packet. The latter can only + be fixed by applying a bug fix to the kernel. Attacks on servers + can often be fixed by properly specifying options to limit the load + the servers incur on the system under adverse conditions. + Brute-force network attacks are harder to deal with. A + spoofed-packet attack, for example, is nearly impossible to stop + short of cutting your system off from the internet. It may not be + able to take your machine down, but it can fill up internet + pipe. + + A user account compromise is even more common then a D.O.S. + attack. Many sysadmins still run standard telnetd, rlogind, rshd, + and ftpd servers on their machines. These servers, by default, do + not operate over encrypted connections. The result is that if you + have any moderate-sized user base, one or more of your users logging + into your system from a remote location (which is the most common + and convenient way to login to a system) will have his or her + password sniffed. The attentive system admin will analyze his + remote access logs looking for suspicious source addresses even for + successful logins. + + One must always assume that once an attacker has access to a + user account, the attacker can break root. However, the reality is + that in a well secured and maintained system, access to a user + account does not necessarily give the attacker access to root. The + distinction is important because without access to root the attacker + cannot generally hide his tracks and may, at best, be able to do + nothing more then mess with the user's files or crash the machine. + User account compromises are very common because users tend not to + take the precautions that sysadmins take. + + System administrators must keep in mind that there are + potentially many ways to break root on a machine. The attacker may + know the root password, the attacker may find a bug in a root-run + server and be able to break root over a network connection to that + server, or the attacker may know of a bug in an suid-root program + that allows the attacker to break root once he has broken into a + user's account. If an attacker has found a way to break root on a + machine, the attacker may not have a need to install Many of the + root holes found and closed to date involve a considerable amount of + work by the hacker to cleanup after himself, so most hackers do + install backdoors. This gives you a convienient way to detect the + hacker. Making it impossible for a hacker to install a backdoor may + actually be detrimental to your security because it will not close + off the hole the hacker found to break in in the first place. + + Security remedies should always be implemented with a + multi-layered “onion peel” approach and can be + categorized as follows: + + + + Securing root and staff accounts. + + + + Securing root – root-run servers and suid/sgid + binaries. + + + + Securing user accounts. + + + + Securing the password file. + + + + Securing the kernel core, raw devices, and + filesystems. + + + + Quick detection of inappropriate changes made to the + system. + + + + Paranoia. + + + + The next section of this chapter will cover the above bullet + items in greater depth. + + + + Securing FreeBSD + + The sections that follow will cover the methods of securing your + FreeBSD system that were mentioned in the last section of this chapter. + + + Securing the root account and staff accounts + + First off, do not bother securing staff accounts if you have + not secured the root account. Most systems have a password + assigned to the root account. The first thing you do is assume + that the password is always compromised. + This does not mean that you should remove the password. The + password is almost always necessary for console access to the + machine. What it does mean is that you should not make it + possible to use the password outside of the console or possibly + even with the &man.su.1; command. For example, make sure that + your pty's are specified as being unsecure in the + /etc/ttys file so that direct root logins + via telnet or rlogin are + disallowed. If using other login services such as + sshd, make sure that direct root logins + are disabled there as well. Consider every access method – + services such as ftp often fall through the cracks. Direct root + logins should only be allowed via the system console. + + Of course, as a sysadmin you have to be able to get to root, + so we open up a few holes. But we make sure these holes require + additional password verification to operate. One way to make root + accessible is to add appropriate staff accounts to the + wheel group (in + /etc/group). The staff members placed in the + wheel group are allowed to + su to root. You should never give staff + members native wheel access by putting them in the + wheel group in their password entry. Staff + accounts should be placed in a staff group, and + then added to the wheel group via the + /etc/group file. Only those staff members + who actually need to have root access should be placed in the + wheel group. It is also possible, when using + an authentication method such as kerberos, to use kerberos's + .k5login file in the root account to allow a + &man.ksu.1; to root without having to place anyone at all in the + wheel group. This may be the better solution + since the wheel mechanism still allows an + intruder to break root if the intruder has gotten hold of your + password file and can break into a staff account. While having + the wheel mechanism is better then having + nothing at all, it is not necessarily the safest option. + + An indirect way to secure the root account is to secure your + staff accounts by using an alternative login access method and + *'ing out the crypted password for the staff + accounts. This way an intruder may be able to steal the password + file but will not be able to break into any staff accounts (or, + indirectly, root, even if root has a crypted password associated + with it). Staff members get into their staff accounts through a + secure login mechanism such as &man.kerberos.1; or &man.ssh.1; + using a private/public key pair. When you use something like + kerberos, you generally must secure the machines which run the + kerberos servers and your desktop workstation. When you use a + public/private key pair with ssh, you + must generally secure the machine you are logging in + from (typically your workstation), but you + can also add an additional layer of protection to the key pair by + password protecting the keypair when you create it with + &man.ssh-keygen.1;. Being able to * out the + passwords for staff accounts also guarantees that staff members can + only login through secure access methods that you have setup. You + can thus force all staff members to use secure, encrypted + connections for all of their sessions which closes an important + hole used by many intruders: That of sniffing the network from an + unrelated, less secure machine. + + The more indirect security mechanisms also assume that you are + logging in from a more restrictive server to a less restrictive + server. For example, if your main box is running all sorts of + servers, your workstation should not be running any. In order for + your workstation to be reasonably secure you should run as few + servers as possible, up to and including no servers at all, and + you should run a password-protected screen blanker. Of course, + given physical access to a workstation an attacker can break any + sort of security you put on it. This is definitely a problem that + you should consider but you should also consider the fact that the + vast majority of break-ins occur remotely, over a network, from + people who do not have physical access to your workstation or + servers. + + Using something like kerberos also gives you the ability to + disable or change the password for a staff account in one place + and have it immediately effect all the machine the staff member + may have an account on. If a staff member's account gets + compromised, the ability to instantly change his password on all + machines should not be underrated. With discrete passwords, + changing a password on N machines can be a mess. You can also + impose re-passwording restrictions with kerberos: not only can a + kerberos ticket be made to timeout after a while, but the kerberos + system can require that the user choose a new password after a + certain period of time (say, once a month). + + + + Securing Root-run Servers and SUID/SGID Binaries + + The prudent sysadmin only runs the servers he needs to, no + more, no less. Be aware that third party servers are often the + most bug-prone. For example, running an old version of imapd or + popper is like giving a universal root ticket out to the entire + world. Never run a server that you have not checked out + carefully. Many servers do not need to be run as root. For + example, the ntalk, + comsat, and + finger daemons can be run in special + user sandboxes. A sandbox isn't perfect unless + you go to a large amount of trouble, but the onion approach to + security still stands: If someone is able to break in through + a server running in a sandbox, they still have to break out of the + sandbox. The more layers the attacker must break through, the + lower the likelihood of his success. Root holes have historically + been found in virtually every server ever run as root, including + basic system servers. If you are running a machine through which + people only login via sshd and never + login via telnetd or + rshd or + rlogind, then turn off those + services! + + FreeBSD now defaults to running + ntalkd, + comsat, and + finger in a sandbox. Another program + which may be a candidate for running in a sandbox is &man.named.8;. + The default rc.conf includes the arguments + necessary to run namedin a sandbox in a + commented-out form. Depending on whether you are installing a new + system or upgrading an existing system, the special user accounts + used by these sandboxes may not be installed. The prudent + sysadmin would research and implement sandboxes for servers + whenever possible. + + There are a number of other servers that typically do not run + in sandboxes: sendmail, + popper, + imapd, ftpd, + and others. There are alternatives to some of these, but + installing them may require more work then you are willing to + perform (the convenience factor strikes again). You may have to + run these servers as root and rely on other mechanisms to detect + break-ins that might occur through them. + + The other big potential root hole in a system are the + suid-root and sgid binaries installed on the system. Most of + these binaries, such as rlogin, reside + in /bin, /sbin, + /usr/bin, or /usr/sbin. + While nothing is 100% safe, the system-default suid and sgid + binaries can be considered reasonably safe. Still, root holes are + occasionally found in these binaries. A root hole was found in + Xlib in 1998 that made + xterm (which is typically suid) + vulnerable. It is better to be safe then sorry and the prudent + sysadmin will restrict suid binaries that only staff should run to + a special group that only staff can access, and get rid of + (chmod 000) any suid binaries that nobody uses. + A server with no display generally does not need an + xterm binary. Sgid binaries can be + almost as dangerous. If an intruder can break an sgid-kmem binary + the intruder might be able to read /dev/kmem + and thus read the crypted password file, potentially compromising + any passworded account. Alternatively an intruder who breaks + group kmem can monitor keystrokes sent through + pty's, including pty's used by users who login through secure + methods. An intruder that breaks the tty group can write to + almost any user's tty. If a user is running a terminal program or + emulator with a keyboard-simulation feature, the intruder can + potentially generate a data stream that causes the user's terminal + to echo a command, which is then run as that user. + + + + Securing User Accounts + + User accounts are usually the most difficult to secure. While + you can impose Draconian access restrictions on your staff and + * out their passwords, you may not be able to + do so with any general user accounts you might have. If you do + have sufficient control then you may win out and be able to secure + the user accounts properly. If not, you simply have to be more + vigilant in your monitoring of those accounts. Use of + ssh and kerberos for user accounts is + more problematic due to the extra administration and technical + support required, but still a very good solution compared to a + crypted password file. + + + + Securing the Password File + + The only sure fire way is to * out as many + passwords as you can and use ssh or + kerberos for access to those accounts. Even though the crypted + password file (/etc/spwd.db) can only be read + by root, it may be possible for an intruder to obtain read access + to that file even if the attacker cannot obtain root-write + access. + + Your security scripts should always check for and report + changes to the password file (see Checking file integrity + below). + + + + Securing the Kernel Core, Raw Devices, and + Filesystems + + If an attacker breaks root he can do just about anything, but + there are certain conveniences. For example, most modern kernels + have a packet sniffing device driver built in. Under FreeBSD it + is called the bpf device. An intruder + will commonly attempt to run a packet sniffer on a compromised + machine. You do not need to give the intruder the capability and + most systems should not have the bpf device compiled in. + + But even if you turn off the bpf device, you still have + /dev/mem and /dev/kmem + to worry about. For that matter, the intruder can still write to + raw disk devices. Also, there is another kernel feature called + the module loader, &man.kldload.8;. An enterprising intruder can + use a KLD module to install his own bpf device or other sniffing + device on a running kernel. To avoid these problems you have to + run the kernel at a higher secure level, at least securelevel 1. + The securelevel can be set with a sysctl on + the kern.securelevel variable. Once you have + set the securelevel to 1, write access to raw devices will be + denied and special chflags flags, such as schg, + will be enforced. You must also ensure that the + schg flag is set on critical startup binaries, + directories, and script files – everything that gets run up + to the point where the securelevel is set. This might be overdoing + it, and upgrading the system is much more difficult when you + operate at a higher secure level. You may compromise and run the + system at a higher secure level but not set the + schg flag for every system file and directory + under the sun. Another possibility is to simply mount + / and /usr read-only. + It should be noted that being too draconian in what you attempt to + protect may prevent the all-important detection of an + intrusion. + + + + Checking File Integrity: Binaires, Configuration Files, + Etc. + + When it comes right down to it, you can only protect your core + system configuration and control files so much before the + convenience factor rears its ugly head. For example, using + chflags to set the schg bit + on most of the files in / and + /usr is probably counterproductive because + while it may protect the files, it also closes a detection window. + The last layer of your security onion is perhaps the most + important – detection. The rest of your security is pretty + much useless (or, worse, presents you with a false sense of + safety) if you cannot detect potential incursions. Half the job + of the onion is to slow down the attacker rather then stop him in + order to give the detection side of the equation a chance to catch + him in the act. + + The best way to detect an incursion is to look for modified, + missing, or unexpected files. The best way to look for modified + files is from another (often centralized) limited-access system. + Writing your security scripts on the extra-secure limited-access + system makes them mostly invisible to potential hackers, and this + is important. In order to take maximum advantage you generally + have to give the limited-access box significant access to the + other machines in the business, usually either by doing a + read-only NFS export of the other machines to the limited-access + box, or by setting up ssh keypairs to + allow the limit-access box to ssh to + the other machines. Except for its network traffic, NFS is the + least visible method – allowing you to monitor the + filesystems on each client box virtually undetected. If your + limited-access server is connected to the client boxes through a + switch, the NFS method is often the better choice. If your + limited-access server is connected to the client boxes through a + hub or through several layers of routing, the NFS method may be + too insecure (network-wise) and using + ssh may be the better choice even with + the audit-trail tracks that ssh + lays. + + Once you give a limit-access box at least read access to the + client systems it is supposed to monitor, you must write scripts + to do the actual monitoring. Given an NFS mount, you can write + scripts out of simple system utilities such as &man.find.1; and + &man.md5.1;. It is best to physically md5 the client-box files + boxes at least once a day, and to test control files such as those + found in /etc and + /usr/local/etc even more often. When + mismatches are found relative to the base md5 information the + limited-access machine knows is valid, it should scream at a + sysadmin to go check it out. A good security script will also + check for inappropriate suid binaries and for new or deleted files + on system partitions such as / and + /usr. + + When using ssh rather then NFS, + writing the security script is much more difficult. You + essentially have to scp the scripts to the client box in order to + run them, making them visible, and for safety you also need to + scp the binaries (such as find) that those + scripts use. The ssh daemon on the + client box may already be compromised. All in all, using + ssh may be necessary when running over + unsecure links, but it's also a lot harder to deal with. + + A good security script will also check for changes to user and + staff members access configuration files: + .rhosts, .shosts, + .ssh/authorized_keys and so forth… + files that might fall outside the purview of the + MD5 check. + + If you have a huge amount of user disk space it may take too + long to run through every file on those partitions. In this case, + setting mount flags to disallow suid binaries and devices on those + partitions is a good idea. The nodev and + nosuid options (see &man.mount.8;) are what you + want to look into. I would scan them anyway at least once a week, + since the object of this layer is to detect a break-in whether or + not the break-in is effective. + + Process accounting (see &man.accton.8;) is a relatively + low-overhead feature of the operating system which I recommend + using as a post-break-in evaluation mechanism. It is especially + useful in tracking down how an intruder has actually broken into + a system, assuming the file is still intact after the break-in + occurs. + + Finally, security scripts should process the log files and the + logs themselves should be generated in as secure a manner as + possible – remote syslog can be very useful. An intruder + tries to cover his tracks, and log files are critical to the + sysadmin trying to track down the time and method of the initial + break-in. One way to keep a permanent record of the log files is + to run the system console to a serial port and collect the + information on a continuing basis through a secure machine + monitoring the consoles. + + + + Paranoia + + A little paranoia never hurts. As a rule, a sysadmin can add + any number of security features as long as they do not effect + convenience, and can add security features that do effect + convenience with some added thought. Even more importantly, a + security administrator should mix it up a bit – if you use + recommendations such as those given by this document verbatim, you + give away your methodologies to the prospective hacker who also + has access to this document. + + + + Denial of Service Attacks + + This section covers Denial of Service attacks. A DOS attack + is typically a packet attack. While there is not much you can do + about modern spoofed packet attacks that saturate your network, + you can generally limit the damage by ensuring that the attacks + cannot take down your servers. + + + + Limiting server forks. + + + + Limiting springboard attacks (ICMP response attacks, ping + broadcast, etc.). + + + + Kernel Route Cache. + + + + A common DOS attack is against a forking server that attempts + to cause the server to eat processes, file descriptors, and memory + until the machine dies. Inetd (see &man.inetd.8;) has several + options to limit this sort of attack. It should be noted that + while it is possible to prevent a machine from going down it is + not generally possible to prevent a service from being disrupted + by the attack. Read the inetd manual page carefully and pay + specific attention to the , , + and options. Note that spoofed-IP attacks + will circumvent the option to inetd, so + typically a combination of options must be used. Some standalone + servers have self-fork-limitation parameters. + + Sendmail has its + option which tends to work + much better than trying to use sendmail's load limiting options + due to the load lag. You should specify a + MaxDaemonChildren parameter when you start + sendmail high enough to handle your + expected load but no so high that the computer cannot handle that + number of sendmails without falling on + its face. It is also prudent to run sendmail in queued mode + () and to run the daemon + (sendmail -bd) separate from the queue-runs + (sendmail -q15m). If you still want realtime + delivery you can run the queue at a much lower interval, such as + , but be sure to specify a reasonable + MaxDaemonChildren option for that sendmail to + prevent cascade failures. + + Syslogd can be attacked directly + and it is strongly recommended that you use the + option whenever possible, and the option + otherwise. + + You should also be fairly careful with connect-back services + such as tcpwrapper's reverse-identd, + which can be attacked directly. You generally do not want to use + the reverse-ident feature of + tcpwrappers for this reason. + + It is a very good idea to protect internal services from + external access by firewalling them off at your border routers. + The idea here is to prevent saturation attacks from outside your + LAN, not so much to protect internal services from network-based + root compromise. Always configure an exclusive firewall, i.e., + “firewall everything except ports A, B, + C, D, and M-Z”. This way you can firewall off all of your + low ports except for certain specific services such as + named (if you are primary for a zone), + ntalkd, + sendmail, and other internet-accessible + services. If you try to configure the firewall the other way + – as an inclusive or permissive firewall, there is a good + chance that you will forget to “close” a couple of + services or that you will add a new internal service and forget + to update the firewall. You can still open up the high-numbered + port range on the firewall to allow permissive-like operation + without compromising your low ports. Also take note that FreeBSD + allows you to control the range of port numbers used for dynamic + binding via the various net.inet.ip.portrange + sysctl's (sysctl -a | fgrep + portrange), which can also ease the complexity of your + firewall's configuration. I usually use a normal first/last range + of 4000 to 5000, and a hiport range of 49152 to 65535, then block + everything under 4000 off in my firewall (except for certain + specific internet-accessible ports, of course). + + Another common DOS attack is called a springboard attack + – to attack a server in a manner that causes the server to + generate responses which then overload the server, the local + network, or some other machine. The most common attack of this + nature is the ICMP ping broadcast attack. + The attacker spoofs ping packets sent to your LAN's broadcast + address with the source IP address set to the actual machine they + wish to attack. If your border routers are not configured to + stomp on ping's to broadcast addresses, your LAN winds up + generating sufficient responses to the spoofed source address to + saturate the victim, especially when the attacker uses the same + trick on several dozen broadcast addresses over several dozen + different networks at once. Broadcast attacks of over a hundred + and twenty megabits have been measured. A second common + springboard attack is against the ICMP error reporting system. + By constructing packets that generate ICMP error responses, an + attacker can saturate a server's incoming network and cause the + server to saturate its outgoing network with ICMP responses. This + type of attack can also crash the server by running it out of + mbuf's, especially if the server cannot drain the ICMP responses + it generates fast enough. The FreeBSD kernel has a new kernel + compile option called ICMP_BANDLIM which limits the effectiveness + of these sorts of attacks. The last major class of springboard + attacks is related to certain internal inetd services such as the + udp echo service. An attacker simply spoofs a UDP packet with the + source address being server A's echo port, and the destination + address being server B's echo port, where server A and B are both + on your LAN. The two servers then bounce this one packet back and + forth between each other. The attacker can overload both servers + and their LANs simply by injecting a few packets in this manner. + Similar problems exist with the internal chargen port. A + competent sysadmin will turn off all of these inetd-internal test + services. + + Spoofed packet attacks may also be used to overload the kernel + route cache. Refer to the net.inet.ip.rtexpire, + rtminexpire, and rtmaxcache + sysctl parameters. A spoofed packet attack + that uses a random source IP will cause the kernel to generate a + temporary cached route in the route table, viewable with + netstat -rna | fgrep W3. These routes + typically timeout in 1600 seconds or so. If the kernel detects + that the cached route table has gotten too big it will dynamically + reduce the rtexpire but will never decrease it to less then + rtminexpire. There are two problems: + + + + The kernel does not react quickly enough when a lightly + loaded server is suddenly attacked. + + + + The rtminexpire is not low enough for + the kernel to survive a sustained attack. + + + + If your servers are connected to the internet via a T3 or + better it may be prudent to manually override both + rtexpire and rtminexpire + via &man.sysctl.8;. Never set either parameter to zero (unless + you want to crash the machine :-). Setting both + parameters to 2 seconds should be sufficient to protect the route + table from attack. + + + + Access Issues with Kerberos and SSH + + There are a few issues with both kerberos and + ssh that need to be addressed if you + intend to use them. Kerberos V is an excellent authentication + protocol but the kerberized telnet and + rlogin suck rocks. There are bugs that + make them unsuitable for dealing with binary streams. Also, by + default kerberos does not encrypt a session unless you use the + option. ssh + encrypts everything by default. + + ssh works quite well in every + respect except that it forwards encryption keys by default. What + this means is that if you have a secure workstation holding keys + that give you access to the rest of the system, and you + ssh to an unsecure machine, your keys + becomes exposed. The actual keys themselves are not exposed, but + ssh installs a forwarding port for the + duration of your login and if a hacker has broken root on the + unsecure machine he can utilize that port to use your keys to gain + access to any other machine that your keys unlock. + + We recommend that you use ssh in + combination with kerberos whenever possible for staff logins. + ssh can be compiled with kerberos + support. This reduces your reliance on potentially exposable + ssh keys while at the same time + protecting passwords via kerberos. ssh + keys should only be used for automated tasks from secure machines + (something that kerberos is unsuited to). We also recommend that + you either turn off key-forwarding in the + ssh configuration, or that you make use + of the from=IP/DOMAIN option that + ssh allows in its + authorized_keys file to make the key only + useable to entities logging in from specific machines. + + DES, MD5, and Crypt + Parts rewritten and updated by &a.unfurl;, 21 March + 2000. + Every user on a UNIX system has a password associated with their account, obviously these passwords need to be known only to the user and the actual operating system. In order to keep diff --git a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml index 60859ae9a6..6cc393ebe3 100644 --- a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml @@ -1,18 +1,747 @@ Security - - Parts rewritten and updated by &a.unfurl;, 21 March - 2000. + + Much of this chapter has been taken from the + &man.security.7; man page, originally written by + &a.dillon;. + + + Synopsis + + The following chapter will provide a basic introduction to + system security concepts, some general good rules of thumb, and some + advanced topics such as S/Key, OpenSSL, Kerberos, and others. + + + + Introduction + + Security is a function that begins and ends with the system + administrator. While all BSD UNIX multi-user systems have some + inherent security, the job of building and maintaining additional + security mechanisms to keep those users “honest” is + probably one of the single largest undertakings of the sysadmin. + Machines are only as secure as you make them, and security concerns + are ever competing with the human necessity for convenience. UNIX + systems, in general, are capable of running a huge number of + simultaneous processes and many of these processes operate as + servers – meaning that external entities can connect and talk + to them. As yesterday's mini-computers and mainframes become + today's desktops, and as computers become networked and + internetworked, security becomes an ever bigger issue. + + Security is best implemented through a layered + “onion” approach. In a nutshell, what you want to do is + to create as many layers of security as are convenient and then + carefully monitor the system for intrusions. You do not want to + overbuild your security or you will interefere with the detection + side, and detection is one of the single most important aspects of + any security mechanism. For example, it makes little sense to set + the schg flags (see &man.chflags.1;) on every system binary because + while this may temporarily protect the binaries, it prevents a + hacker who has broken in from making an easily detectable change + that may result in your security mechanisms not detecting the hacker + at all. + + System security also pertains to dealing with various forms of + attack, including attacks that attempt to crash or otherwise make a + system unusable but do not attempt to break root. Security concerns + can be split up into several categories: + + + + Denial of service attacks. + + + + User account compromises. + + + + Root compromise through accessible servers. + + + + Root compromise via user accounts. + + + + Backdoor creation. + + + + A denial of service attack is an action that deprives the + machine of needed resources. Typically, D.O.S. attacks are + brute-force mechanisms that attempt to crash or otherwise make a + machine unusable by overwhelming its servers or network stack. Some + D.O.S. attacks try to take advantages of bugs in the networking + stack to crash a machine with a single packet. The latter can only + be fixed by applying a bug fix to the kernel. Attacks on servers + can often be fixed by properly specifying options to limit the load + the servers incur on the system under adverse conditions. + Brute-force network attacks are harder to deal with. A + spoofed-packet attack, for example, is nearly impossible to stop + short of cutting your system off from the internet. It may not be + able to take your machine down, but it can fill up internet + pipe. + + A user account compromise is even more common then a D.O.S. + attack. Many sysadmins still run standard telnetd, rlogind, rshd, + and ftpd servers on their machines. These servers, by default, do + not operate over encrypted connections. The result is that if you + have any moderate-sized user base, one or more of your users logging + into your system from a remote location (which is the most common + and convenient way to login to a system) will have his or her + password sniffed. The attentive system admin will analyze his + remote access logs looking for suspicious source addresses even for + successful logins. + + One must always assume that once an attacker has access to a + user account, the attacker can break root. However, the reality is + that in a well secured and maintained system, access to a user + account does not necessarily give the attacker access to root. The + distinction is important because without access to root the attacker + cannot generally hide his tracks and may, at best, be able to do + nothing more then mess with the user's files or crash the machine. + User account compromises are very common because users tend not to + take the precautions that sysadmins take. + + System administrators must keep in mind that there are + potentially many ways to break root on a machine. The attacker may + know the root password, the attacker may find a bug in a root-run + server and be able to break root over a network connection to that + server, or the attacker may know of a bug in an suid-root program + that allows the attacker to break root once he has broken into a + user's account. If an attacker has found a way to break root on a + machine, the attacker may not have a need to install Many of the + root holes found and closed to date involve a considerable amount of + work by the hacker to cleanup after himself, so most hackers do + install backdoors. This gives you a convienient way to detect the + hacker. Making it impossible for a hacker to install a backdoor may + actually be detrimental to your security because it will not close + off the hole the hacker found to break in in the first place. + + Security remedies should always be implemented with a + multi-layered “onion peel” approach and can be + categorized as follows: + + + + Securing root and staff accounts. + + + + Securing root – root-run servers and suid/sgid + binaries. + + + + Securing user accounts. + + + + Securing the password file. + + + + Securing the kernel core, raw devices, and + filesystems. + + + + Quick detection of inappropriate changes made to the + system. + + + + Paranoia. + + + + The next section of this chapter will cover the above bullet + items in greater depth. + + + + Securing FreeBSD + + The sections that follow will cover the methods of securing your + FreeBSD system that were mentioned in the last section of this chapter. + + + Securing the root account and staff accounts + + First off, do not bother securing staff accounts if you have + not secured the root account. Most systems have a password + assigned to the root account. The first thing you do is assume + that the password is always compromised. + This does not mean that you should remove the password. The + password is almost always necessary for console access to the + machine. What it does mean is that you should not make it + possible to use the password outside of the console or possibly + even with the &man.su.1; command. For example, make sure that + your pty's are specified as being unsecure in the + /etc/ttys file so that direct root logins + via telnet or rlogin are + disallowed. If using other login services such as + sshd, make sure that direct root logins + are disabled there as well. Consider every access method – + services such as ftp often fall through the cracks. Direct root + logins should only be allowed via the system console. + + Of course, as a sysadmin you have to be able to get to root, + so we open up a few holes. But we make sure these holes require + additional password verification to operate. One way to make root + accessible is to add appropriate staff accounts to the + wheel group (in + /etc/group). The staff members placed in the + wheel group are allowed to + su to root. You should never give staff + members native wheel access by putting them in the + wheel group in their password entry. Staff + accounts should be placed in a staff group, and + then added to the wheel group via the + /etc/group file. Only those staff members + who actually need to have root access should be placed in the + wheel group. It is also possible, when using + an authentication method such as kerberos, to use kerberos's + .k5login file in the root account to allow a + &man.ksu.1; to root without having to place anyone at all in the + wheel group. This may be the better solution + since the wheel mechanism still allows an + intruder to break root if the intruder has gotten hold of your + password file and can break into a staff account. While having + the wheel mechanism is better then having + nothing at all, it is not necessarily the safest option. + + An indirect way to secure the root account is to secure your + staff accounts by using an alternative login access method and + *'ing out the crypted password for the staff + accounts. This way an intruder may be able to steal the password + file but will not be able to break into any staff accounts (or, + indirectly, root, even if root has a crypted password associated + with it). Staff members get into their staff accounts through a + secure login mechanism such as &man.kerberos.1; or &man.ssh.1; + using a private/public key pair. When you use something like + kerberos, you generally must secure the machines which run the + kerberos servers and your desktop workstation. When you use a + public/private key pair with ssh, you + must generally secure the machine you are logging in + from (typically your workstation), but you + can also add an additional layer of protection to the key pair by + password protecting the keypair when you create it with + &man.ssh-keygen.1;. Being able to * out the + passwords for staff accounts also guarantees that staff members can + only login through secure access methods that you have setup. You + can thus force all staff members to use secure, encrypted + connections for all of their sessions which closes an important + hole used by many intruders: That of sniffing the network from an + unrelated, less secure machine. + + The more indirect security mechanisms also assume that you are + logging in from a more restrictive server to a less restrictive + server. For example, if your main box is running all sorts of + servers, your workstation should not be running any. In order for + your workstation to be reasonably secure you should run as few + servers as possible, up to and including no servers at all, and + you should run a password-protected screen blanker. Of course, + given physical access to a workstation an attacker can break any + sort of security you put on it. This is definitely a problem that + you should consider but you should also consider the fact that the + vast majority of break-ins occur remotely, over a network, from + people who do not have physical access to your workstation or + servers. + + Using something like kerberos also gives you the ability to + disable or change the password for a staff account in one place + and have it immediately effect all the machine the staff member + may have an account on. If a staff member's account gets + compromised, the ability to instantly change his password on all + machines should not be underrated. With discrete passwords, + changing a password on N machines can be a mess. You can also + impose re-passwording restrictions with kerberos: not only can a + kerberos ticket be made to timeout after a while, but the kerberos + system can require that the user choose a new password after a + certain period of time (say, once a month). + + + + Securing Root-run Servers and SUID/SGID Binaries + + The prudent sysadmin only runs the servers he needs to, no + more, no less. Be aware that third party servers are often the + most bug-prone. For example, running an old version of imapd or + popper is like giving a universal root ticket out to the entire + world. Never run a server that you have not checked out + carefully. Many servers do not need to be run as root. For + example, the ntalk, + comsat, and + finger daemons can be run in special + user sandboxes. A sandbox isn't perfect unless + you go to a large amount of trouble, but the onion approach to + security still stands: If someone is able to break in through + a server running in a sandbox, they still have to break out of the + sandbox. The more layers the attacker must break through, the + lower the likelihood of his success. Root holes have historically + been found in virtually every server ever run as root, including + basic system servers. If you are running a machine through which + people only login via sshd and never + login via telnetd or + rshd or + rlogind, then turn off those + services! + + FreeBSD now defaults to running + ntalkd, + comsat, and + finger in a sandbox. Another program + which may be a candidate for running in a sandbox is &man.named.8;. + The default rc.conf includes the arguments + necessary to run namedin a sandbox in a + commented-out form. Depending on whether you are installing a new + system or upgrading an existing system, the special user accounts + used by these sandboxes may not be installed. The prudent + sysadmin would research and implement sandboxes for servers + whenever possible. + + There are a number of other servers that typically do not run + in sandboxes: sendmail, + popper, + imapd, ftpd, + and others. There are alternatives to some of these, but + installing them may require more work then you are willing to + perform (the convenience factor strikes again). You may have to + run these servers as root and rely on other mechanisms to detect + break-ins that might occur through them. + + The other big potential root hole in a system are the + suid-root and sgid binaries installed on the system. Most of + these binaries, such as rlogin, reside + in /bin, /sbin, + /usr/bin, or /usr/sbin. + While nothing is 100% safe, the system-default suid and sgid + binaries can be considered reasonably safe. Still, root holes are + occasionally found in these binaries. A root hole was found in + Xlib in 1998 that made + xterm (which is typically suid) + vulnerable. It is better to be safe then sorry and the prudent + sysadmin will restrict suid binaries that only staff should run to + a special group that only staff can access, and get rid of + (chmod 000) any suid binaries that nobody uses. + A server with no display generally does not need an + xterm binary. Sgid binaries can be + almost as dangerous. If an intruder can break an sgid-kmem binary + the intruder might be able to read /dev/kmem + and thus read the crypted password file, potentially compromising + any passworded account. Alternatively an intruder who breaks + group kmem can monitor keystrokes sent through + pty's, including pty's used by users who login through secure + methods. An intruder that breaks the tty group can write to + almost any user's tty. If a user is running a terminal program or + emulator with a keyboard-simulation feature, the intruder can + potentially generate a data stream that causes the user's terminal + to echo a command, which is then run as that user. + + + + Securing User Accounts + + User accounts are usually the most difficult to secure. While + you can impose Draconian access restrictions on your staff and + * out their passwords, you may not be able to + do so with any general user accounts you might have. If you do + have sufficient control then you may win out and be able to secure + the user accounts properly. If not, you simply have to be more + vigilant in your monitoring of those accounts. Use of + ssh and kerberos for user accounts is + more problematic due to the extra administration and technical + support required, but still a very good solution compared to a + crypted password file. + + + + Securing the Password File + + The only sure fire way is to * out as many + passwords as you can and use ssh or + kerberos for access to those accounts. Even though the crypted + password file (/etc/spwd.db) can only be read + by root, it may be possible for an intruder to obtain read access + to that file even if the attacker cannot obtain root-write + access. + + Your security scripts should always check for and report + changes to the password file (see Checking file integrity + below). + + + + Securing the Kernel Core, Raw Devices, and + Filesystems + + If an attacker breaks root he can do just about anything, but + there are certain conveniences. For example, most modern kernels + have a packet sniffing device driver built in. Under FreeBSD it + is called the bpf device. An intruder + will commonly attempt to run a packet sniffer on a compromised + machine. You do not need to give the intruder the capability and + most systems should not have the bpf device compiled in. + + But even if you turn off the bpf device, you still have + /dev/mem and /dev/kmem + to worry about. For that matter, the intruder can still write to + raw disk devices. Also, there is another kernel feature called + the module loader, &man.kldload.8;. An enterprising intruder can + use a KLD module to install his own bpf device or other sniffing + device on a running kernel. To avoid these problems you have to + run the kernel at a higher secure level, at least securelevel 1. + The securelevel can be set with a sysctl on + the kern.securelevel variable. Once you have + set the securelevel to 1, write access to raw devices will be + denied and special chflags flags, such as schg, + will be enforced. You must also ensure that the + schg flag is set on critical startup binaries, + directories, and script files – everything that gets run up + to the point where the securelevel is set. This might be overdoing + it, and upgrading the system is much more difficult when you + operate at a higher secure level. You may compromise and run the + system at a higher secure level but not set the + schg flag for every system file and directory + under the sun. Another possibility is to simply mount + / and /usr read-only. + It should be noted that being too draconian in what you attempt to + protect may prevent the all-important detection of an + intrusion. + + + + Checking File Integrity: Binaires, Configuration Files, + Etc. + + When it comes right down to it, you can only protect your core + system configuration and control files so much before the + convenience factor rears its ugly head. For example, using + chflags to set the schg bit + on most of the files in / and + /usr is probably counterproductive because + while it may protect the files, it also closes a detection window. + The last layer of your security onion is perhaps the most + important – detection. The rest of your security is pretty + much useless (or, worse, presents you with a false sense of + safety) if you cannot detect potential incursions. Half the job + of the onion is to slow down the attacker rather then stop him in + order to give the detection side of the equation a chance to catch + him in the act. + + The best way to detect an incursion is to look for modified, + missing, or unexpected files. The best way to look for modified + files is from another (often centralized) limited-access system. + Writing your security scripts on the extra-secure limited-access + system makes them mostly invisible to potential hackers, and this + is important. In order to take maximum advantage you generally + have to give the limited-access box significant access to the + other machines in the business, usually either by doing a + read-only NFS export of the other machines to the limited-access + box, or by setting up ssh keypairs to + allow the limit-access box to ssh to + the other machines. Except for its network traffic, NFS is the + least visible method – allowing you to monitor the + filesystems on each client box virtually undetected. If your + limited-access server is connected to the client boxes through a + switch, the NFS method is often the better choice. If your + limited-access server is connected to the client boxes through a + hub or through several layers of routing, the NFS method may be + too insecure (network-wise) and using + ssh may be the better choice even with + the audit-trail tracks that ssh + lays. + + Once you give a limit-access box at least read access to the + client systems it is supposed to monitor, you must write scripts + to do the actual monitoring. Given an NFS mount, you can write + scripts out of simple system utilities such as &man.find.1; and + &man.md5.1;. It is best to physically md5 the client-box files + boxes at least once a day, and to test control files such as those + found in /etc and + /usr/local/etc even more often. When + mismatches are found relative to the base md5 information the + limited-access machine knows is valid, it should scream at a + sysadmin to go check it out. A good security script will also + check for inappropriate suid binaries and for new or deleted files + on system partitions such as / and + /usr. + + When using ssh rather then NFS, + writing the security script is much more difficult. You + essentially have to scp the scripts to the client box in order to + run them, making them visible, and for safety you also need to + scp the binaries (such as find) that those + scripts use. The ssh daemon on the + client box may already be compromised. All in all, using + ssh may be necessary when running over + unsecure links, but it's also a lot harder to deal with. + + A good security script will also check for changes to user and + staff members access configuration files: + .rhosts, .shosts, + .ssh/authorized_keys and so forth… + files that might fall outside the purview of the + MD5 check. + + If you have a huge amount of user disk space it may take too + long to run through every file on those partitions. In this case, + setting mount flags to disallow suid binaries and devices on those + partitions is a good idea. The nodev and + nosuid options (see &man.mount.8;) are what you + want to look into. I would scan them anyway at least once a week, + since the object of this layer is to detect a break-in whether or + not the break-in is effective. + + Process accounting (see &man.accton.8;) is a relatively + low-overhead feature of the operating system which I recommend + using as a post-break-in evaluation mechanism. It is especially + useful in tracking down how an intruder has actually broken into + a system, assuming the file is still intact after the break-in + occurs. + + Finally, security scripts should process the log files and the + logs themselves should be generated in as secure a manner as + possible – remote syslog can be very useful. An intruder + tries to cover his tracks, and log files are critical to the + sysadmin trying to track down the time and method of the initial + break-in. One way to keep a permanent record of the log files is + to run the system console to a serial port and collect the + information on a continuing basis through a secure machine + monitoring the consoles. + + + + Paranoia + + A little paranoia never hurts. As a rule, a sysadmin can add + any number of security features as long as they do not effect + convenience, and can add security features that do effect + convenience with some added thought. Even more importantly, a + security administrator should mix it up a bit – if you use + recommendations such as those given by this document verbatim, you + give away your methodologies to the prospective hacker who also + has access to this document. + + + + Denial of Service Attacks + + This section covers Denial of Service attacks. A DOS attack + is typically a packet attack. While there is not much you can do + about modern spoofed packet attacks that saturate your network, + you can generally limit the damage by ensuring that the attacks + cannot take down your servers. + + + + Limiting server forks. + + + + Limiting springboard attacks (ICMP response attacks, ping + broadcast, etc.). + + + + Kernel Route Cache. + + + + A common DOS attack is against a forking server that attempts + to cause the server to eat processes, file descriptors, and memory + until the machine dies. Inetd (see &man.inetd.8;) has several + options to limit this sort of attack. It should be noted that + while it is possible to prevent a machine from going down it is + not generally possible to prevent a service from being disrupted + by the attack. Read the inetd manual page carefully and pay + specific attention to the , , + and options. Note that spoofed-IP attacks + will circumvent the option to inetd, so + typically a combination of options must be used. Some standalone + servers have self-fork-limitation parameters. + + Sendmail has its + option which tends to work + much better than trying to use sendmail's load limiting options + due to the load lag. You should specify a + MaxDaemonChildren parameter when you start + sendmail high enough to handle your + expected load but no so high that the computer cannot handle that + number of sendmails without falling on + its face. It is also prudent to run sendmail in queued mode + () and to run the daemon + (sendmail -bd) separate from the queue-runs + (sendmail -q15m). If you still want realtime + delivery you can run the queue at a much lower interval, such as + , but be sure to specify a reasonable + MaxDaemonChildren option for that sendmail to + prevent cascade failures. + + Syslogd can be attacked directly + and it is strongly recommended that you use the + option whenever possible, and the option + otherwise. + + You should also be fairly careful with connect-back services + such as tcpwrapper's reverse-identd, + which can be attacked directly. You generally do not want to use + the reverse-ident feature of + tcpwrappers for this reason. + + It is a very good idea to protect internal services from + external access by firewalling them off at your border routers. + The idea here is to prevent saturation attacks from outside your + LAN, not so much to protect internal services from network-based + root compromise. Always configure an exclusive firewall, i.e., + “firewall everything except ports A, B, + C, D, and M-Z”. This way you can firewall off all of your + low ports except for certain specific services such as + named (if you are primary for a zone), + ntalkd, + sendmail, and other internet-accessible + services. If you try to configure the firewall the other way + – as an inclusive or permissive firewall, there is a good + chance that you will forget to “close” a couple of + services or that you will add a new internal service and forget + to update the firewall. You can still open up the high-numbered + port range on the firewall to allow permissive-like operation + without compromising your low ports. Also take note that FreeBSD + allows you to control the range of port numbers used for dynamic + binding via the various net.inet.ip.portrange + sysctl's (sysctl -a | fgrep + portrange), which can also ease the complexity of your + firewall's configuration. I usually use a normal first/last range + of 4000 to 5000, and a hiport range of 49152 to 65535, then block + everything under 4000 off in my firewall (except for certain + specific internet-accessible ports, of course). + + Another common DOS attack is called a springboard attack + – to attack a server in a manner that causes the server to + generate responses which then overload the server, the local + network, or some other machine. The most common attack of this + nature is the ICMP ping broadcast attack. + The attacker spoofs ping packets sent to your LAN's broadcast + address with the source IP address set to the actual machine they + wish to attack. If your border routers are not configured to + stomp on ping's to broadcast addresses, your LAN winds up + generating sufficient responses to the spoofed source address to + saturate the victim, especially when the attacker uses the same + trick on several dozen broadcast addresses over several dozen + different networks at once. Broadcast attacks of over a hundred + and twenty megabits have been measured. A second common + springboard attack is against the ICMP error reporting system. + By constructing packets that generate ICMP error responses, an + attacker can saturate a server's incoming network and cause the + server to saturate its outgoing network with ICMP responses. This + type of attack can also crash the server by running it out of + mbuf's, especially if the server cannot drain the ICMP responses + it generates fast enough. The FreeBSD kernel has a new kernel + compile option called ICMP_BANDLIM which limits the effectiveness + of these sorts of attacks. The last major class of springboard + attacks is related to certain internal inetd services such as the + udp echo service. An attacker simply spoofs a UDP packet with the + source address being server A's echo port, and the destination + address being server B's echo port, where server A and B are both + on your LAN. The two servers then bounce this one packet back and + forth between each other. The attacker can overload both servers + and their LANs simply by injecting a few packets in this manner. + Similar problems exist with the internal chargen port. A + competent sysadmin will turn off all of these inetd-internal test + services. + + Spoofed packet attacks may also be used to overload the kernel + route cache. Refer to the net.inet.ip.rtexpire, + rtminexpire, and rtmaxcache + sysctl parameters. A spoofed packet attack + that uses a random source IP will cause the kernel to generate a + temporary cached route in the route table, viewable with + netstat -rna | fgrep W3. These routes + typically timeout in 1600 seconds or so. If the kernel detects + that the cached route table has gotten too big it will dynamically + reduce the rtexpire but will never decrease it to less then + rtminexpire. There are two problems: + + + + The kernel does not react quickly enough when a lightly + loaded server is suddenly attacked. + + + + The rtminexpire is not low enough for + the kernel to survive a sustained attack. + + + + If your servers are connected to the internet via a T3 or + better it may be prudent to manually override both + rtexpire and rtminexpire + via &man.sysctl.8;. Never set either parameter to zero (unless + you want to crash the machine :-). Setting both + parameters to 2 seconds should be sufficient to protect the route + table from attack. + + + + Access Issues with Kerberos and SSH + + There are a few issues with both kerberos and + ssh that need to be addressed if you + intend to use them. Kerberos V is an excellent authentication + protocol but the kerberized telnet and + rlogin suck rocks. There are bugs that + make them unsuitable for dealing with binary streams. Also, by + default kerberos does not encrypt a session unless you use the + option. ssh + encrypts everything by default. + + ssh works quite well in every + respect except that it forwards encryption keys by default. What + this means is that if you have a secure workstation holding keys + that give you access to the rest of the system, and you + ssh to an unsecure machine, your keys + becomes exposed. The actual keys themselves are not exposed, but + ssh installs a forwarding port for the + duration of your login and if a hacker has broken root on the + unsecure machine he can utilize that port to use your keys to gain + access to any other machine that your keys unlock. + + We recommend that you use ssh in + combination with kerberos whenever possible for staff logins. + ssh can be compiled with kerberos + support. This reduces your reliance on potentially exposable + ssh keys while at the same time + protecting passwords via kerberos. ssh + keys should only be used for automated tasks from secure machines + (something that kerberos is unsuited to). We also recommend that + you either turn off key-forwarding in the + ssh configuration, or that you make use + of the from=IP/DOMAIN option that + ssh allows in its + authorized_keys file to make the key only + useable to entities logging in from specific machines. + + DES, MD5, and Crypt + Parts rewritten and updated by &a.unfurl;, 21 March + 2000. + Every user on a UNIX system has a password associated with their account, obviously these passwords need to be known only to the user and the actual operating system. In order to keep