From owner-freebsd-doc@FreeBSD.ORG Tue Nov 7 21:20:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C26916A417 for ; Tue, 7 Nov 2006 21:20:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 359CF43D4C for ; Tue, 7 Nov 2006 21:20:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kA7LKI96015130 for ; Tue, 7 Nov 2006 21:20:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kA7LKIlB015129; Tue, 7 Nov 2006 21:20:18 GMT (envelope-from gnats) Resent-Date: Tue, 7 Nov 2006 21:20:18 GMT Resent-Message-Id: <200611072120.kA7LKIlB015129@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D115316A40F for ; Tue, 7 Nov 2006 21:13:02 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80FE443D82 for ; Tue, 7 Nov 2006 21:13:01 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id kA7LD0VO047932 for ; Tue, 7 Nov 2006 21:13:00 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id kA7LD0TO047931; Tue, 7 Nov 2006 21:13:00 GMT (envelope-from nobody) Message-Id: <200611072113.kA7LD0TO047931@www.freebsd.org> Date: Tue, 7 Nov 2006 21:13:00 GMT From: Niclas Zeising To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: docs/105256: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 21:20:19 -0000 >Number: 105256 >Category: docs >Synopsis: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook >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: Tue Nov 07 21:20:17 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: 7.0-CURRENT >Organization: >Environment: >Description: I was reading through the "Securing FreeBSD" chapter of the handbook (section 14.3) and found some wording choices which I found wrong or hard to comprehend, along with some spelling mistakes. The attached patch changes the wording and spelling in a way I find appropriate. Feel free to do whatever you like with the patch. >How-To-Repeat: Read Section 14.3 of the handbook >Fix: Apply the whole patch, or the parts you find good. (Note, I had to add the ".txt" extension to the patch so the browser would report it as text/*) Patch attached with submission follows: --- doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml.orig 2006-11-07 18:30:54.000000000 +0100 +++ doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml 2006-11-07 21:02:16.000000000 +0100 @@ -559,7 +559,7 @@ Securing User Accounts User accounts are usually the most difficult to secure. While - you can impose Draconian access restrictions on your staff and + you can impose draconian access restrictions on your staff and 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 @@ -568,13 +568,13 @@ 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. + encrypted password file. Securing the Password File - The only sure fire way is to * out as many + The only sure fire way is to star out as many passwords as you can and use ssh or Kerberos for access to those accounts. Even though the encrypted password file (/etc/spwd.db) can only be read @@ -631,7 +631,7 @@ 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 + It should be noted that being too draconian in what you attempt to protect may prevent the all-important detection of an intrusion. @@ -650,12 +650,11 @@ 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 + security) if you cannot detect potential intrusions. Half the job of the onion is to slow down the attacker, rather than stop him, in - order to give the detection side of the equation a chance to catch - him in the act. + order to be able to catch him in the act. - The best way to detect an incursion is to look for modified, + The best way to detect an intrusion 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 @@ -678,7 +677,7 @@ the audit-trail tracks that ssh lays. - Once you give a limited-access box, at least read access to the + Once you have given a limited-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 @@ -707,7 +706,7 @@ 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… + .ssh/authorized_keys and so forth, files that might fall outside the purview of the MD5 check. @@ -718,24 +717,23 @@ nosuid options (see &man.mount.8;) are what you want to look into. You should probably 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. + attempt, whether or not the attempt succeds. Process accounting (see &man.accton.8;) is a relatively low-overhead feature of the operating system which might help 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. + a system, assuming the file is still intact after the break-in has + occured. 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 + will try 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. + information to a secure machine monitoring the consoles. @@ -759,7 +757,7 @@ 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. + cannot take down your servers by: @@ -772,13 +770,14 @@ - Kernel Route Cache. + Overloading the 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 + A common DoS attack scenario is attacking a forking server and + making it spawning so many child processes that the host system + eventually runs out of memory, file descriptors, etc. and then + grinds to a halt. 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 @@ -857,7 +856,7 @@ 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 + stomp on ping packets 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 @@ -868,7 +867,7 @@ 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 + memory, especially if the server cannot drain the ICMP responses it generates fast enough. Use the sysctl variable net.inet.icmp.icmplim to limit these attacks. @@ -927,7 +926,7 @@ 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 + you intend to use them. Kerberos 5 is an excellent authentication protocol, but there are bugs in the kerberized telnet and rlogin applications that make them @@ -936,7 +935,7 @@ 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 @@ -950,10 +949,10 @@ We recommend that you use ssh in combination with Kerberos whenever possible for staff logins. - ssh can be compiled with Kerberos + Ssh can be compiled with Kerberos support. This reduces your reliance on potentially exposed 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 you either turn off key-forwarding in the >Release-Note: >Audit-Trail: >Unformatted: