diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index 6c5ecd3f8e..f41a708139 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,7 +1,7 @@ @@ -214,6 +214,14 @@ Securing FreeBSD + + Command vs. Protocol + Throughout this document, we will use + bold text to refer to a command or + application. This is used for instances such as ssh, since it's + a protocol as well as command. + + The sections that follow will cover the methods of securing your FreeBSD system that were mentioned in the last section of this chapter. @@ -237,9 +245,12 @@ /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 + 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 logins should only be allowed via the system console. wheel @@ -249,33 +260,33 @@ 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 + wheel group (in /etc/group). The staff members placed in the - wheel group are allowed to - su to root. You should never give staff + 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 + 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 + 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 - wheel group. This may be the better solution - since the wheel mechanism still allows an + 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 than 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 - do what is known as *'ing out the crypted + do what is known as staring out the crypted password for the staff accounts. Using the &man.vipw.8; command, one can replace each instance of a crypted password - with a single * character. This command + with a single * character. This command will update the /etc/master.passwd file and user/password database to disable password-authenticated logins. @@ -290,18 +301,18 @@ This change will prevent normal logins from occurring, since the encrypted password will never match - *. With this done, staff members must use + *. 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 desktop workstation. When using a public/private key pair - with ssh, one must generally secure + with ssh, one must generally secure the machine used to login from (typically one's workstation). An additional layer of protection can be added to the key pair by password protecting the key pair when creating it with &man.ssh-keygen.1;. Being able to - * out the passwords for staff accounts also + star out the passwords for staff accounts also guarantees that staff members can only login through secure access methods that you have setup. This forces all staff members to use secure, encrypted connections for all of their @@ -369,7 +380,7 @@ 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 + 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, @@ -450,12 +461,12 @@ 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 + star 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 + 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. @@ -465,7 +476,7 @@ Securing the Password File The only sure fire way is to * out as many - passwords as you can and use ssh or + 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 @@ -553,8 +564,8 @@ 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 key-pairs to - allow the limited-access box to ssh to + box, or by setting up ssh key-pairs to + allow the limited-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 @@ -563,8 +574,8 @@ 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 + ssh may be the better choice even with + the audit-trail tracks that ssh lays. Once you give a limited-access box, at least read access to the @@ -582,15 +593,15 @@ on system partitions such as / and /usr. - When using ssh rather than NFS, + When using ssh rather than 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 + scripts use. The ssh client on the client box may already be compromised. All in all, using - ssh may be necessary when running over + ssh may be necessary when running over unsecure links, but it is also a lot harder to deal with. A good security script will also check for changes to user and @@ -779,15 +790,15 @@ Spoofed packet attacks may also be used to overload the kernel route cache. Refer to the net.inet.ip.rtexpire, - rtminexpire, and rtmaxcache + 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 than rtminexpire. There are two + reduce the rtexpire but will never decrease it + to less than rtminexpire. There are two problems: @@ -797,14 +808,14 @@ - The rtminexpire is not low enough for + 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 + 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 @@ -817,7 +828,7 @@ Kerberos There are a few issues with both kerberos and - ssh that need to be addressed if + 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 @@ -827,29 +838,29 @@ option. ssh encrypts everything by default. - ssh works quite well in every + 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 + ssh to an unsecure machine, your keys becomes exposed. The actual keys themselves are not exposed, but - ssh installs a forwarding port for the + ssh installs a forwarding port for 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 + 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 + 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 + (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 + ssh configuration, or that you make use of the from=IP/DOMAIN option that - ssh allows in its + ssh allows in its authorized_keys file to make the key only usable to entities logging in from specific machines. @@ -1008,7 +1019,7 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a There are four programs involved in the S/Key system which we @@ -1058,7 +1069,7 @@ Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT - At the Enter secret password: prompt you + At the Enter secret password: prompt, you should enter a password or phrase. Remember, this is not the password that you will use to login with, this is used to generate your one-time login keys. The ID line gives the @@ -1315,13 +1326,13 @@ README krb.conf krb.realms You should now edit the krb.conf and krb.realms files to define your Kerberos realm. - In this case the realm will be GRONDAR.ZA and the - server is grunt.grondar.za. We edit or create + In this case the realm will be EXAMPLE.COM and the + server is grunt.example.com. We edit or create the krb.conf file: &prompt.root; cat krb.conf -GRONDAR.ZA -GRONDAR.ZA grunt.grondar.za admin server +EXAMPLE.COM +EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu @@ -1343,16 +1354,16 @@ ARC.NASA.GOV trident.arc.nasa.gov provides an administrative database server. For further explanation of these terms, please consult the Kerberos manual pages. - Now we have to add grunt.grondar.za - to the GRONDAR.ZA realm and also add an entry to - put all hosts in the .grondar.za - domain in the GRONDAR.ZA realm. The + Now we have to add grunt.example.com + to the EXAMPLE.COM realm and also add an entry to + put all hosts in the .example.com + domain in the EXAMPLE.COM realm. The krb.realms file would be updated as follows: &prompt.root; cat krb.realms -grunt.grondar.za GRONDAR.ZA -.grondar.za GRONDAR.ZA +grunt.example.com EXAMPLE.COM +.example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU @@ -1370,7 +1381,7 @@ grunt.grondar.za GRONDAR.ZA kdb_init command to do this: &prompt.root; kdb_init -Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA +Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. @@ -1465,7 +1476,7 @@ Edit O.K. on each machine. For this we use the ext_srvtab command. This will create a file which must be copied or moved by secure means to each Kerberos client's - /etc/kerberosIV directory. This file must be present on each server + /etc/kerberosIV directory. This file must be present on each server and client, and is crucial to the operation of Kerberos. @@ -1551,7 +1562,7 @@ Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 -Local realm: GRONDAR.ZA +Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a @@ -1566,7 +1577,7 @@ Master key entered. BEWARE! above: &prompt.user; kinit jane -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: @@ -1575,17 +1586,17 @@ Kerberos Initialization for "jane" &prompt.user; klist Ticket file: /tmp/tkt245 -Principal: jane@GRONDAR.ZA +Principal: jane@EXAMPLE.COM Issued Expires Principal -Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA +Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Now try changing the password using passwd to check if the kpasswd daemon can get authorization to the Kerberos database: &prompt.user; passwd -realm GRONDAR.ZA +realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password @@ -1637,7 +1648,7 @@ Edit O.K. Now try getting tokens for it to make sure it works: &prompt.root; kinit jane.root -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: @@ -1645,7 +1656,7 @@ Kerberos Initialization for "jane.root" .klogin file: &prompt.root; cat /root/.klogin -jane.root@GRONDAR.ZA +jane.root@EXAMPLE.COM Now try doing the su: @@ -1656,10 +1667,10 @@ jane.root@GRONDAR.ZA &prompt.root; klist Ticket file: /tmp/tkt_root_245 -Principal: jane.root@GRONDAR.ZA +Principal: jane.root@EXAMPLE.COM Issued Expires Principal -May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA +May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM @@ -1670,22 +1681,22 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA This was based on a user with the same name as the principal, and this is a Kerberos default; that a <principal>.<instance> of the form - <username>.root will allow + <username>.root will allow that <username> to su to root if the necessary entries are in the .klogin file in root's home directory: &prompt.root; cat /root/.klogin -jane.root@GRONDAR.ZA +jane.root@EXAMPLE.COM Likewise, if a user has in their own home directory lines of the form: &prompt.user; cat ~/.klogin -jane@GRONDAR.ZA -jack@GRONDAR.ZA +jane@EXAMPLE.COM +jack@EXAMPLE.COM - This allows anyone in the GRONDAR.ZA realm + This allows anyone in the EXAMPLE.COM realm who has authenticated themselves to jane or jack (via kinit, see above) access to rlogin to jane's @@ -1693,11 +1704,11 @@ jack@GRONDAR.ZA rlogin, rsh or rcp. - For example, Jane now logs into another system using + For example, jane now logs into another system using Kerberos: &prompt.user; kinit -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble @@ -1706,14 +1717,14 @@ Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 - Or Jack logs into Jane's account on the same machine (Jane having + Or Jack logs into Jane's account on the same machine (jane having set up the .klogin file as above, and the person in charge of Kerberos having set up principal jack with a null instance: &prompt.user; kinit &prompt.user; rlogin grunt -l jane -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 @@ -1782,7 +1793,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 mechanisms. FreeBSD comes with a kernel packet filter (known as - IPFW), which is what the rest of this + ipfw), which is what the rest of this section will concentrate on. Proxy servers can be built on FreeBSD from third party software, but there is such a variety of proxy servers available that it would be impossible to cover them in this @@ -2915,9 +2926,9 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec rc.conf file: sshd_enable="YES" - This will load the ssh daemon the next time your system + This will load the ssh daemon the next time your system initializes. Alternatively, you can simply run the - sshd daemon. + sshd daemon.