diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index ecd6672faf..6ef679c12d 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -114,7 +114,9 @@ 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 + system unusable, but do not attempt to compromise the + root account (break root). + Security concerns can be split up into several categories: @@ -185,10 +187,10 @@ 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 + 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 + 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 than mess with the user's files, or crash the machine. User account compromises are very common because users tend not to @@ -200,18 +202,18 @@ 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 + 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 - a suid-root program that allows the attacker to break root once + a 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 a backdoor. Many of the root holes + a way to break root on a machine, the attacker may not have a need + to install a backdoor. Many of the root holes found and closed to date involve a considerable amount of work by the attacker to cleanup after himself, so most attackers install backdoors. A backdoor provides the attacker with a way to easily - regain root access to the system, but it also gives the smart + regain root access to the system, but it also gives the smart system administrator a convenient way to detect the intrusion. Making it impossible for an attacker to install a backdoor may actually be detrimental to your security, because it will not @@ -225,11 +227,11 @@ - Securing root and staff accounts. + Securing root and staff accounts. - Securing root – root-run servers and suid/sgid + Securing root – root-run servers and suid/sgid binaries. @@ -287,8 +289,8 @@ 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 + 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 @@ -296,47 +298,47 @@ 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 + /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 + sshd, make sure that direct root logins are disabled there as well. You can do this by editing your /etc/ssh/sshd_config file, and making sure that PermitRootLogin is set to NO. Consider every access method – - services such as FTP often fall through the cracks. Direct root + services such as FTP often fall through the cracks. Direct root logins should only be allowed via the system console. wheel - Of course, as a sysadmin you have to be able to get to root, + 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 + 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 + 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 + 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' - .k5login file in the root account to allow a - &man.ksu.1; to root without having to place anyone at all in the + an authentication method such as Kerberos, to use Kerberos' + .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 + 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 than having nothing at all, it is not necessarily the safest option. An indirect way to secure staff accounts, and ultimately - root access is to use an alternative login access method and + root access is to use an alternative login access method and do what is known as starring out the crypted password for the staff accounts. Using the &man.vipw.8; command, one can replace each instance of a crypted password @@ -358,8 +360,8 @@ *. With this done, staff members must use another mechanism to authenticate themselves such as &man.kerberos.1; or &man.ssh.1; using a public/private key - pair. When using something like kerberos, one generally must - secure the machines which run the kerberos servers and your + pair. When using something like Kerberos, one generally must + secure the machines which run the Kerberos servers and your desktop workstation. When using a public/private key pair with ssh, one must generally secure the machine used to login from (typically @@ -389,15 +391,15 @@ servers. Kerberos - Using something like kerberos also gives you the ability to + 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 machines on which the staff member may have an account. 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 + 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). @@ -435,20 +437,20 @@ 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 + 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 + be run as root. For example, the ntalk, comsat, and finger daemons can be run in special - user sandboxes. A sandbox is not perfect, + user sandboxes. A sandbox is not perfect, unless you go through 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 + 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 @@ -479,17 +481,17 @@ and others. There are alternatives to some of these, but installing them may require more work than 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 + run these servers as root and rely on other mechanisms to detect break-ins that might occur through them. - The other big potential root holes in a system are the + The other big potential root holes 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 + 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 than sorry and the prudent @@ -522,7 +524,7 @@ 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 + 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. @@ -533,9 +535,9 @@ 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 + 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 + 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. @@ -549,7 +551,7 @@ Securing the Kernel Core, Raw Devices, and Filesystems - If an attacker breaks root he can do just about anything, but + 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 @@ -781,7 +783,7 @@ 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., + 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 @@ -883,14 +885,14 @@ ssh Kerberos - There are a few issues with both kerberos and + 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 there are bugs in the kerberized telnet and rlogin applications that make them unsuitable for dealing with binary streams. Also, by default - kerberos does not encrypt a session unless you use the + Kerberos does not encrypt a session unless you use the option. ssh encrypts everything by default. @@ -901,18 +903,18 @@ 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 an attacker has broken root on the + duration of your login, and if an attacker 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 + 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 + protecting passwords via Kerberos. ssh keys should only be used for automated tasks from secure machines - (something that kerberos is unsuited to do). We also recommend that + (something that Kerberos is unsuited to do). 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 @@ -1739,7 +1741,7 @@ Password changed. Adding <command>su</command> Privileges Kerberos allows us to give each user - who needs root privileges their own + who needs root privileges their own separate su password. We could now add an id which is authorized to su to root. This is @@ -1815,7 +1817,7 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM <principal>.<instance> of the form <username>.root will allow that <username> to su to - root if the necessary entries are in the .klogin + root if the necessary entries are in the .klogin file in root's home directory: &prompt.root; cat /root/.klogin