From owner-freebsd-doc Sun Nov 18 15:20:26 2001 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6B1F537B419 for ; Sun, 18 Nov 2001 15:20:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id fAINK1I04371; Sun, 18 Nov 2001 15:20:01 -0800 (PST) (envelope-from gnats) Received: from Kain.sumuk.de (Kain.sumuk.de [213.221.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 6B63137B405 for ; Sun, 18 Nov 2001 15:15:18 -0800 (PST) Received: (from vincent@localhost) by Kain.sumuk.de (8.11.5/8.11.5) id fAINFAf01968; Mon, 19 Nov 2001 00:15:10 +0100 (CET) (envelope-from vincent) Message-Id: <200111182315.fAINFAf01968@Kain.sumuk.de> Date: Mon, 19 Nov 2001 00:15:10 +0100 (CET) From: Martin Heinen Reply-To: Martin Heinen To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: docs/32094: Whitespace changes for chapter Security Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 32094 >Category: docs >Synopsis: Whitespace changes for chapter Security >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 18 15:20:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Martin Heinen >Release: FreeBSD 4.4-PRERELEASE i386 >Organization: >Environment: System: FreeBSD Kain.sumuk.de 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE #11: Thu Sep 27 18:54:33 CEST 2001 toor@Kain.earth.sol:/usr/obj/usr/src/sys/KAIN i386 >Description: fixed line breakings, moved closing to the end of a paragraph, indented tags spreading across lines >How-To-Repeat: read the Security chapter >Fix: Index: chapter.sgml =================================================================== RCS file: /u/cvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v retrieving revision 1.98 diff -u -r1.98 chapter.sgml --- chapter.sgml 2001/11/16 12:07:18 1.98 +++ chapter.sgml 2001/11/18 22:57:14 @@ -187,10 +187,11 @@ 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 + 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 than mess with the user's files, or crash the machine. User account compromises are very common because users tend not to @@ -202,19 +203,22 @@ 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 - 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 + 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 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 - system administrator a convenient way to detect the intrusion. + 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 close off the hole the attacker found to break in the first @@ -231,8 +235,8 @@ - Securing root – root-run servers and suid/sgid - binaries. + Securing root – root-run servers + and suid/sgid binaries. @@ -280,17 +284,19 @@ The sections that follow will cover the methods of securing your FreeBSD system that were mentioned in the last section of this chapter. + linkend="security-intro">last section of this chapter. - Securing the <username>root</username> Account and Staff Accounts + Securing the <username>root</username> Account and + Staff Accounts su 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 @@ -298,53 +304,62 @@ 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 - logins are disabled there as well. You can do this by editing + 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. + 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, - so we open up a few holes. But we make sure these holes require - additional password verification to operate. One way to make 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 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 + .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 - with a single * character. This command - will update the /etc/master.passwd file - and user/password database to disable password-authenticated + with a single * character. + This command will update the /etc/master.passwd + file and user/password database to disable password-authenticated logins. A staff account entry such as: @@ -357,7 +372,8 @@ 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 @@ -437,10 +453,10 @@ 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, + 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 is not perfect, @@ -450,8 +466,8 @@ 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 + 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 @@ -481,17 +497,19 @@ 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 - break-ins that might occur through them. + 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 @@ -537,13 +555,13 @@ 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. + 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 the Checking file integrity section + linkend="security-integrity">Checking file integrity section below). @@ -551,7 +569,8 @@ 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 @@ -765,8 +784,7 @@ 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. - + that sendmail to prevent cascade failures. Syslogd can be attacked directly and it is strongly recommended that you use the @@ -783,7 +801,8 @@ 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 @@ -903,7 +922,8 @@ 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. @@ -1445,8 +1465,8 @@ You should now edit the krb.conf and krb.realms files to define your Kerberos realm. In this case the realm will be EXAMPLE.COM and the - server is grunt.example.com. We edit or create - the krb.conf file: + server is grunt.example.com. We edit + or create the krb.conf file: &prompt.root; cat krb.conf EXAMPLE.COM @@ -1804,8 +1824,9 @@ <principal>.<instance> of the form <username>.root will allow that <username> to su to - root if the necessary entries are in the .klogin - file in root's home directory: + root if the necessary entries are in the + .klogin file in root's + home directory: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM @@ -1838,7 +1859,8 @@ 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: @@ -2640,7 +2662,8 @@ elsewhere, and is not available for unrestricted use. IDEA is included in the OpenSSL sources in FreeBSD, but it is not built by default. If you wish to use it, and you comply with the - license terms, enable the MAKE_IDEA switch in /etc/make.conf and + license terms, enable the MAKE_IDEA switch in + /etc/make.conf and rebuild your sources using make world. Today, the RSA algorithm is free for use in USA and other @@ -2726,21 +2749,23 @@ From HOST B to HOST A, new AH and new ESP are combined. Now we should choose an algorithm to be used corresponding to - AH/new AH/ESP/new ESP. Please refer to the &man.setkey.8; man + AH/new AH/ESP/ + new ESP. Please refer to the &man.setkey.8; man page to know algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1 for new AH, and new-DES-expIV with 8 byte IV for new ESP. Key length highly depends on each algorithm. For example, key length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1, and 8 for new-DES-expIV. Now we choose MYSECRETMYSECRET, - KAMEKAMEKAMEKAMEKAME, PASSWORD, respectively. + KAMEKAMEKAMEKAMEKAME, PASSWORD, + respectively. OK, let us assign SPI (Security Parameter Index) for each protocol. Please note that we need 3 SPIs for this secure channel since three security headers are produced (one for from HOST A to HOST B, two for from HOST B to HOST A). Please also note that SPI MUST be greater - than or equal to 256. We choose, 1000, 2000, and 3000, respectively. - + than or equal to 256. We choose, 1000, 2000, and 3000, + respectively. (1) @@ -2827,9 +2852,10 @@ fec0::10 -------------------- fec0::11 - Encryption algorithm is blowfish-cbc whose key is kamekame, and - authentication algorithm is hmac-sha1 whose key is this is the test - key. Configuration at Host-A: + Encryption algorithm is blowfish-cbc whose key is + kamekame, and authentication algorithm is hmac-sha1 + whose key is this is the test key. + Configuration at Host-A: &prompt.root; setkey -c <<EOF @@ -2899,10 +2925,11 @@ EOF - If the port number field is omitted such as above then [any] is - employed. -m specifies the mode of SA to be used. -m any means - wild-card of mode of security protocol. You can use this SA for both - tunnel and transport mode. + If the port number field is omitted such as above then + [any] is employed. -m + specifies the mode of SA to be used. -m any means + wild-card of mode of security protocol. You can use this SA for both + tunnel and transport mode. and at Gateway-B: @@ -3062,12 +3089,11 @@ Be sure to make the following additions to your - rc.conf file: - + rc.conf file: sshd_enable="YES" - This will load the ssh daemon the next time your system - initializes. Alternatively, you can simply run the - sshd daemon. + This will load the ssh daemon + the next time your system initializes. Alternatively, you can + simply run the sshd daemon. @@ -3090,7 +3116,8 @@ created using rlogin or telnet. SSH utilizes a key fingerprint system for verifying the authenticity of the server when the - client connects. The user is prompted to enter yes only when + client connects. The user is prompted to enter + yes only when connecting for the first time. Future attempts to login are all verified against the saved fingerprint key. The SSH client will alert you if the saved fingerprint differs from the @@ -3117,9 +3144,9 @@ scp - The scp command works similarly to rcp; - it copies a file to or from a remote machine, except in a - secure fashion. + The scp command works similarly to + rcp; it copies a file to or from a remote machine, + except in a secure fashion. &prompt.root scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: @@ -3128,8 +3155,7 @@ &prompt.root Since the fingerprint was already saved for this host in the previous example, it is verified when using scp - here. - + here. The arguments passed to scp are similar to cp, with the file or files in the first @@ -3278,19 +3304,20 @@ - An SSH tunnel works by creating a listen socket on localhost - on the specified port. It then forwards any connection received + An SSH tunnel works by creating a listen socket on + localhost on the specified port. + It then forwards any connection received on the local host/port via the SSH connection to the specified remote host and port. In the example, port 5023 on localhost is being forwarded to port - 23 on localhost of the remote - machine. Since 23 is telnet, this - would create a secure telnet session through an SSH tunnel. + 23 on localhost + of the remote machine. Since 23 is telnet, + this would create a secure telnet session through an SSH tunnel. - This can be used to wrap any number of insecure TCP protocols - such as smtp, pop3, ftp, etc. + This can be used to wrap any number of insecure TCP protocols + such as smtp, pop3, ftp, etc. A typical SSH Tunnel &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message