From owner-freebsd-doc@FreeBSD.ORG Wed Dec 6 22:02:44 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 [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FE8B16A71A for ; Wed, 6 Dec 2006 22:02:44 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id A37C243D8A for ; Wed, 6 Dec 2006 21:49:30 +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 kB6Lo4EZ053178 for ; Wed, 6 Dec 2006 21:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kB6Lo4Df053177; Wed, 6 Dec 2006 21:50:04 GMT (envelope-from gnats) Resent-Date: Wed, 6 Dec 2006 21:50:04 GMT Resent-Message-Id: <200612062150.kB6Lo4Df053177@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 [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1FD916A50D for ; Wed, 6 Dec 2006 21:40:33 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A20944498 for ; Wed, 6 Dec 2006 21:13:48 +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 kB6LEVYB022467 for ; Wed, 6 Dec 2006 21:14:31 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id kB6LEURu022466; Wed, 6 Dec 2006 21:14:30 GMT (envelope-from nobody) Message-Id: <200612062114.kB6LEURu022466@www.freebsd.org> Date: Wed, 6 Dec 2006 21:14:30 GMT From: Niclas Zeising To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: docs/106425: [PATCH] add a HARDWARE-section to ata(4) 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: Wed, 06 Dec 2006 22:02:45 -0000 >Number: 106425 >Category: docs >Synopsis: [PATCH] add a HARDWARE-section to ata(4) >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: Wed Dec 06 21:50:03 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: 7-CURRENT >Organization: >Environment: >Description: The ata(4) manual page lacks a HARDWARE section which make the auto-generation of harware notes fail, or rather, no chip sets supported bu ata(4) shows up in the hardware notes. There was a pr complaining about this last week, unfortunately I can't find it at the moment, so I'll file a new pr. >How-To-Repeat: man 4 ata >Fix: The attached patch tries to add a proper hardware section based on the chip sets already listed in ata(4). The list is rather long, and can maybe be tweaked so it becomes shorter. If you find a way to do so, feel free. Patch attached with submission follows: --- doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml.orig 2006-11-12 11:13:08.000000000 +0100 +++ doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml 2006-11-12 19:10:20.000000000 +0100 @@ -66,17 +66,20 @@ - How to configure IPsec and create a VPN between - &os;/&windows; machines. + How to configure IPsec and create a + VPN between + &os;/&windows; machines. - How to configure and use OpenSSH, &os;'s SSH - implementation. + How to configure and use OpenSSH + , &os;'s SSH implementation. + - What file system ACLs are and how to use them. + What file system ACLs + are and how to use them. @@ -128,15 +131,14 @@ inter-networked, security becomes an even bigger issue. System security also pertains to dealing with various forms of - attack, including attacks that attempt to crash, or otherwise make a + attacks, including attacks that attempt to crash, or otherwise make a system unusable, but do not attempt to compromise the root account (break root). - Security concerns - can be split up into several categories: + Security concerns can be split up into several categories: - Denial of service attacks. + Denial of service (DoS) attacks. @@ -168,14 +170,14 @@ Denial of Service (DoS) A denial of service attack is an action that deprives the - machine of needed resources. Typically, DoS attacks are - brute-force mechanisms that attempt to crash or otherwise make a + machine of needed resources. Typically, DoS attacks + are brute-force mechanisms that attempt to crash or otherwise make a machine unusable by overwhelming its servers or network stack. Some - DoS attacks try to take advantage 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. + DoS attacks try to take advantage 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 @@ -187,8 +189,8 @@ account compromises - A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard + A user account compromise is even more common than a + DoS attack. Many sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their machines. @@ -226,7 +228,7 @@ 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 + on a machine, the attacker may have the 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 @@ -294,9 +296,8 @@ bold text to refer to an application, and a monospaced font to refer to specific commands. Protocols will use a normal font. This - typographical distinction is useful for instances such as ssh, - since it is - a protocol as well as command. + typographical distinction is useful for instances such as SSH, + since it is a protocol as well as command. The sections that follow will cover the methods of securing your @@ -348,8 +349,8 @@ 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 + 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 @@ -565,7 +566,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 encrypted password file. @@ -575,7 +576,7 @@ Securing the Password File The only sure fire way is to star 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 encrypted password file (/etc/spwd.db) can only be read by root, it may be possible for an intruder @@ -663,9 +664,9 @@ 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 - the other machines. Except for its network traffic, NFS is the + box, or by setting up SSH key-pairs to + allow the limited-access box to use ssh to + access the other machines. Except for its network traffic, NFS is the least visible method — allowing you to monitor the file systems on each client box virtually undetected. If your limited-access server is connected to the client boxes through a @@ -674,8 +675,7 @@ 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. + the audit-trail tracks that SSH lays. 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 @@ -694,13 +694,13 @@ When using ssh rather than NFS, writing the security script is much more difficult. You - essentially have to scp the scripts to the client + 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 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 insecure links, but it is also a lot harder to deal with. A good security script will also check for changes to user and @@ -753,8 +753,9 @@ Denial of Service Attacks Denial of Service (DoS) - This section covers Denial of Service attacks. A DoS attack - is typically a packet attack. While there is not much you can do + 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 by: @@ -774,16 +775,16 @@ - 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 + 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. The inetd + application (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 + page &man.inetd.8; carefully and pay specific attention to the , , and options. Note that spoofed-IP attacks will circumvent the option to @@ -822,8 +823,8 @@ 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. + 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 @@ -840,7 +841,7 @@ without compromising your low ports. Also take note that &os; 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 + sysctls (sysctl -a | fgrep portrange), which can also ease the complexity of your firewall's configuration. For example, you might use a normal first/last range of 4000 to 5000, and a hiport range of 49152 to @@ -848,9 +849,9 @@ (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 overloads the server, the local + Another common DoS attack is called a + springboard attack — to attack a server in a manner that causes + the server to generate responses which overloads 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 @@ -862,13 +863,14 @@ 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 - memory, especially if the server cannot drain the ICMP responses - it generates fast enough. + 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 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. The last major class of springboard @@ -889,12 +891,12 @@ 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 + that uses a random source IP address 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 + reduce the rtexpire but will never decrease it to less than rtminexpire. There are two problems: @@ -925,17 +927,16 @@ KerberosIV 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 5 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 - option. ssh - encrypts everything by default. + 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 @@ -948,17 +949,16 @@ 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 exposed - ssh keys while at the same time - protecting passwords via Kerberos. Ssh - keys should only be used for automated tasks from secure machines + combination with Kerberos whenever possible for staff logins. The + ssh client and server 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 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 - 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. @@ -1000,48 +1000,52 @@ space of possible passwords. Unfortunately the only secure way to encrypt passwords when - &unix; came into being was based on DES, the Data Encryption - Standard. This was not such a problem for users resident in - the US, but since the source code for DES could not be exported - outside the US, &os; had to find a way to both comply with + &unix; came into being was based on + DES, the Data + Encryption Standard. This was not such a problem for users resident in + the US, but since the source code for DES could not be + exported outside the US, &os; had to find a way to both comply with US law and retain compatibility with all the other &unix; - variants that still used DES. + variants that still used DES. The solution was to divide up the encryption libraries - so that US users could install the DES libraries and use - DES but international users still had an encryption method - that could be exported abroad. This is how &os; came to - use MD5 as its default encryption method. MD5 is believed to - be more secure than DES, so installing DES is offered primarily - for compatibility reasons. + so that US users could install the DES libraries and + use DES but international users still had an + encryption method that could be exported abroad. This is how &os; came + to use MD5 as its default + encryption method. MD5 is believed to be more secure + than DES, so installing DES is + offered primarily for compatibility reasons. Recognizing Your Crypt Mechanism - Currently the library supports DES, MD5 and Blowfish hash - functions. By default &os; uses MD5 to encrypt + Currently the library supports DES, + MD5 and Blowfish hash + functions. By default &os; uses MD5 to encrypt passwords. It is pretty easy to identify which encryption method &os; is set up to use. Examining the encrypted passwords in the /etc/master.passwd file is one way. - Passwords encrypted with the MD5 hash are longer than those - encrypted with the DES hash and also begin with the characters - $1$. Passwords starting with - $2a$ are encrypted with the - Blowfish hash function. DES password strings do not - have any particular identifying characteristics, but they are - shorter than MD5 passwords, and are coded in a 64-character - alphabet which does not include the $ - character, so a relatively short string which does not begin with - a dollar sign is very likely a DES password. + Passwords encrypted with the MD5 hash are longer + than those encrypted with the DES hash and also + begin with the characters $1$. + Passwords starting with $2a$ are + encrypted with the Blowfish hash function. DES + password strings do not have any particular identifying characteristics, + but they are shorter than MD5 passwords, and are + coded in a 64-character alphabet which does not include the + $ character, so a relatively short string + which does not begin with a dollar sign is very likely a + DES password. The password format used for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, md5 or blf. See the &man.login.conf.5; manual page - for more information about login capabilities. + for more information on login capabilities. @@ -1054,16 +1058,17 @@ one-time passwords - By default, &os; includes support for OPIE (One-time Passwords - In Everything), which uses the MD5 hash by default. + By default, &os; includes support for + OPIE + (One-time Passwords In Everything), which uses the + MD5 hash by default. There are three different sorts of passwords which we will discuss below. The first is your usual &unix; style or Kerberos password; we will call this a &unix; password. - The second sort is the one-time password which is generated by the OPIE - &man.opiekey.1; program and accepted by the - &man.opiepasswd.1; program - and the login prompt; we will + The second sort is the one-time password which is generated by the + OPIE &man.opiekey.1; program and accepted by the + &man.opiepasswd.1; program and the login prompt; we will call this a one-time password. The final sort of password is the secret password which you give to the opiekey program (and @@ -1075,32 +1080,33 @@ The secret password does not have anything to do with your &unix; password; they can be the same but this is not recommended. - OPIE secret passwords are not limited to 8 characters like old - &unix; passwordsUnder &os; the standard login + OPIE secret passwords are not limited to 8 characters + like old &unix; passwordsUnder &os; the standard login password may be up to 128 characters in length., they can be as long as you like. Passwords of six or seven word long phrases are fairly common. For the most part, the - OPIE system operates completely independently of the &unix; - password system. + OPIE system operates completely independently of the + &unix; password system. Besides the password, there are two other pieces of data that - are important to OPIE. One is what is known as the + are important to OPIE. One is what is known as the seed or key, consisting of two letters and five digits. The other is what is called the iteration - count, a number between 1 and 100. OPIE creates the - one-time password by concatenating the seed and the secret password, - then applying the MD5 hash as many times as specified by the - iteration count and turning the result into six short English words. - These six English words are your one-time password. The - authentication system (primarily PAM) keeps - track of the last one-time password used, and the user is + count, a number between 1 and 100. OPIE + creates the one-time password by concatenating the seed and the secret + password, then applying the MD5 hash as many times as + specified by the iteration count and turning the result into six short + English words. These six English words are your one-time password. The + authentication system (primarily + PAM) + keeps track of the last one-time password used, and the user is authenticated if the hash of the user-provided password is equal to the previous password. Because a one-way hash is used it is impossible to generate future one-time passwords if a successfully used password is captured; the iteration count is decremented after each successful login to keep the user and the login program in - sync. When the iteration count gets down to 1, OPIE must be - reinitialized. + sync. When the iteration count gets down to 1, OPIE + must be reinitialized. There are a few programs involved in each system which we will discuss below. The @@ -1108,7 +1114,7 @@ count, a seed, and a secret password, and generates a one-time password or a consecutive list of one-time passwords. The opiepasswd - program is used to initialize OPIE, + program is used to initialize OPIE, and to change passwords, iteration counts, or seeds; it takes either a secret passphrase, or an iteration count, seed, and a one-time password. The @@ -1133,8 +1139,8 @@ Secure Connection Initialization - To initialize OPIE for the first time, execute the - opiepasswd command: + To initialize OPIE for the first time, execute + the opiepasswd command: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c @@ -1210,7 +1216,7 @@ Generating a Single One-time Password - Once you have initialized OPIE and login, you will be + Once you have initialized OPIE and login, you will be presented with a prompt like this: &prompt.user; telnet example.com @@ -1224,8 +1230,8 @@ otp-md5 498 gr4269 ext Password: - As a side note, the OPIE prompts have a useful feature - (not shown here): if you press Return + As a side note, the OPIE prompts have a useful + feature (not shown here): if you press Return at the password prompt, the prompter will turn echo on, so you can see what you are typing. This can be extremely useful if you are attempting to @@ -1290,8 +1296,8 @@ Restricting Use of &unix; Passwords - OPIE can restrict the use of &unix; passwords based on the IP - address of a login session. The relevant file + OPIE can restrict the use of &unix; passwords + based on the IP address of a login session. The relevant file is /etc/opieaccess, which is present by default. Please check &man.opieaccess.5; for more information on this file and which security considerations @@ -1327,7 +1333,8 @@ TCP Wrappers Anyone familiar with &man.inetd.8; has probably heard - of TCP Wrappers at some point. But few + of TCP + Wrappers at some point. But few individuals seem to fully comprehend its usefulness in a network environment. It seems that everyone wants to install a firewall to handle network connections. While a @@ -1591,8 +1598,9 @@ during the era of restrictive export controls on cryptographic code from the USA. - Alternatively, the MIT implementation of Kerberos is - available from the Ports Collection as + Alternatively, the + MIT + implementation of Kerberos is available from the Ports Collection as security/krb5. @@ -1889,7 +1897,7 @@ Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Now try changing the password using &man.passwd.1; to - check if the kpasswd daemon can get + check if the kpasswd daemon can get authorization to the Kerberos database: &prompt.user; passwd @@ -2133,7 +2141,7 @@ programs that implement the program (Kerberos telnet, for example). The current version of the protocol is version 5, described in - RFC 1510. + RFC 1510. Several free implementations of this protocol are available, covering a wide range of operating systems. The Massachusetts @@ -2168,7 +2176,8 @@ Key Distribution Center - The Key Distribution Center (KDC) is the + The Key Distribution Center + KDC) is the centralized authentication service that Kerberos provides — it is the computer that issues Kerberos tickets. @@ -2580,8 +2589,9 @@ immediately upon running kinit — even before you type your password! The explanation is that the Kerberos server freely - transmits a TGT (Ticket Granting - Ticket) to any unauthorized request; however, every + transmits a + TGT (Ticket + Granting Ticket) to any unauthorized request; however, every TGT is encrypted in a key derived from the user's password. Therefore, when a user types their password it is not being sent to the KDC, @@ -2726,7 +2736,7 @@ - The KDC is a single point of failure + The <acronym>KDC</acronym> is a single point of failure By design, the KDC must be as secure as the master password database is contained on it. The @@ -2783,7 +2793,8 @@ - The Kerberos FAQ + The Kerberos FAQ + @@ -2792,9 +2803,10 @@ - RFC 1510, - The Kerberos Network Authentication Service - (V5) + + RFC 1510, The Kerberos + Network Authentication Service (V5) @@ -2850,9 +2862,12 @@ The version of OpenSSL included - in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3), - Transport Layer Security v1 (TLSv1) network security protocols - and can be used as a general cryptographic library. + in &os; supports Secure Sockets Layer v2/v3 ( + SSLv2/ + SSLv3), Transport Layer Security v1 + (TLSv1) network + security protocols and can be used as a general cryptographic library. + While OpenSSL supports the @@ -2869,8 +2884,9 @@ that the credentials of the company or individual are valid and not fraudulent. If the certificate in question has not been verified by one of the several Certificate Authorities, - or CAs, a warning is usually produced. A - Certificate Authority is a company, such as VeriSign, which will + or CAs, a warning is + usually produced. A Certificate Authority is a company, such as + VeriSign, which will sign certificates in order to validate credentials of individuals or companies. This process has a cost associated with it and is definitely not a requirement for using certificates; however, @@ -2961,9 +2977,9 @@ So what can these files do? A good use would be to encrypt connections to the Sendmail - MTA. This would dissolve the use of clear - text authentication for users who send mail via the local - MTA. + MTA. This would + dissolve the use of clear text authentication for users who send + mail via the local MTA. This is not the best use in the world as some @@ -3047,7 +3063,8 @@ VPN over IPsec - Creating a VPN between two networks, separated by the + Creating a VPN + between two networks, separated by the Internet, using FreeBSD gateways. @@ -3067,30 +3084,33 @@ Understanding IPsec This section will guide you through the process of setting - up IPsec, and to use it in an environment which consists of + up IPsec, and to use it in an + environment which consists of FreeBSD and µsoft.windows; 2000/XP machines, to make them communicate securely. In order to set up - IPsec, it is necessary that you are familiar with the concepts - of building a custom kernel (see + IPsec, it is necessary that you are familiar with + the concepts of building a custom kernel (see ). IPsec is a protocol which sits on top - of the Internet Protocol (IP) layer. It allows two or more - hosts to communicate in a secure manner (hence the name). The - FreeBSD IPsec network stack is based on the - KAME implementation, - which has support for both protocol families, IPv4 and - IPv6. + of the Internet Protocol + () layer. It allows two + or more hosts to communicate in a secure manner (hence the name). The + FreeBSD IPsec network stack is based + on the KAME implementation, + which has support for both protocol families, IPv4 and IPv6. FreeBSD contains a hardware - accelerated IPsec stack, known as Fast - IPsec, that was obtained from OpenBSD. It employs + accelerated IPsec stack, known as + Fast IPsec, that was obtained from OpenBSD. It employs cryptographic hardware (whenever possible) via the - &man.crypto.4; subsystem to optimize the performance of IPsec. + &man.crypto.4; subsystem to optimize the performance of + IPsec. This subsystem is new, and does not support all the features - that are available in the KAME version of IPsec. However, in - order to enable hardware-accelerated IPsec, the following + that are available in the KAME version of IPsec. + However, in order to enable hardware-accelerated + IPsec, the following kernel option has to be added to your kernel configuration file: @@ -3105,8 +3125,8 @@ Note, that it is not currently possible to use the Fast IPsec subsystem in lieu of the KAME - implementation of IPsec. Consult the &man.fast.ipsec.4; - manual page for more information. + implementation of IPsec. Consult the + &man.fast.ipsec.4; manual page for more information. @@ -3130,23 +3150,25 @@ AH - IPsec consists of two sub-protocols: + IPsec consists of two sub-protocols: Encapsulated Security Payload - (ESP), protects the IP packet data from third - party interference, by encrypting the contents using + (ESP) + , protects the IP packet data from + third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, - 3DES). + 3DES). - Authentication Header (AH), - protects the IP packet header from third party interference - and spoofing, by computing a cryptographic checksum and - hashing the IP packet header fields with a secure hashing - function. This is then followed by an additional header - that contains the hash, to allow the information in the + Authentication Header + (AH), + protects the IP packet header from third party + interference and spoofing, by computing a cryptographic checksum + and hashing the IP packet header fields with a + secure hashing function. This is then followed by an additional + header that contains the hash, to allow the information in the packet to be authenticated. @@ -3164,18 +3186,19 @@ VPN - IPsec can either be used to directly encrypt the traffic - between two hosts (known as Transport - Mode); or to build virtual tunnels + IPsec can either be used to directly encrypt + the traffic between two hosts (known as Transport + Mode); or to build virtual tunnels between two subnets, which could be used for secure communication between two corporate networks (known as Tunnel Mode). The latter is more commonly - known as a Virtual Private Network (VPN). - The &man.ipsec.4; manual page should be consulted for detailed - information on the IPsec subsystem in FreeBSD. + known as a Virtual Private Network (VPN) + . The &man.ipsec.4; manual page should be consulted for + detailed information on the IPsec subsystem in + &os;. - To add IPsec support to your kernel, add the following - options to your kernel configuration file: + To add IPsec support to your kernel, add the + following options to your kernel configuration file: kernel options @@ -3208,11 +3231,12 @@ The Problem - There is no standard for what constitutes a VPN. VPNs can - be implemented using a number of different technologies, each of + There is no standard for what constitutes a VPN. + VPNs can be implemented using a number of different + technologies, each of which have their own strengths and weaknesses. This section presents a scenario, and the strategies used for implementing a - VPN for this scenario. + VPN for this scenario. @@ -3231,33 +3255,36 @@ You have at least two sites - Both sites are using IP internally + Both sites are using IP internally Both sites are connected to the Internet, through a gateway that is running FreeBSD. - The gateway on each network has at least one public IP - address. + The gateway on each network has at least one public + IPaddress. The internal addresses of the two networks can be - public or private IP addresses, it does not matter. You can - be running NAT on the gateway machine if necessary. + public or private IP addresses, it does not + matter. You can be running + NAT on the + gateway machine if necessary. - The internal IP addresses of the two networks - do not collide. While I expect it is - theoretically possible to use a combination of VPN - technology and NAT to get this to work, I expect it to be a + The internal IP addresses of the two + networks do not collide. While I expect it + is theoretically possible to use a combination of + VPN technology and NAT + to get this to work, I expect it to be a configuration nightmare. If you find that you are trying to connect two networks, - both of which, internally, use the same private IP address range - (e.g. both of them use IP + address range (e.g. both of them use 192.168.1.x), then one of the networks will have to be renumbered. @@ -3293,14 +3320,16 @@ - Notice the two public IP addresses. I will use the letters to + Notice the two public IP addresses. I will use + the letters to refer to them in the rest of this article. Anywhere you see those letters in this article, replace them with your own public IP addresses. Note also that internally, the two gateway - machines have .1 IP addresses, and that the two networks have - different private IP addresses (192.168.1.x and 192.168.2.x respectively). All the + machines have .1 IP + addresses, and that the two networks have different private + IP addresses + (192.168.1.x and + 192.168.2.x respectively). All the machines on the private networks have been configured to use the .1 machine as their default gateway. @@ -3323,8 +3352,8 @@ And the whole thing has to be secure. This means that traffic between the two networks has to be encrypted. - Creating a VPN between these two networks is a multi-step - process. The stages are as follows: + Creating a VPN between these two networks is a + multi-step process. The stages are as follows: @@ -3343,7 +3372,7 @@ Configure additional software on the FreeBSD gateways, to allow &windows; machines to see one another across the - VPN. + VPN. @@ -3400,9 +3429,9 @@ the public IP addresses, and two for the private IP addresses. - Support for the gif device must be compiled in to the - &os; kernel on both machines. You can do this by adding the - line: + Support for the gif device must be + compiled in to the &os; kernel on both machines. You can do this by + adding the line: device gif @@ -3410,8 +3439,9 @@ then compile, install, and reboot as normal. Configuring the tunnel is a two step process. First the - tunnel must be told what the outside (or public) IP addresses - are, using &man.ifconfig.8;. Then the private IP addresses must be + tunnel must be told what the outside (or public) IP + addresses are, using &man.ifconfig.8;. Then the private + IP addresses must be configured using &man.ifconfig.8;. On the gateway machine on network #1 you would run the @@ -3423,7 +3453,8 @@ On the other gateway machine you run the same commands, - but with the order of the IP addresses reversed. + but with the order of the IP addresses reversed. + &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D @@ -3471,15 +3502,16 @@ shortly. It is likely that you are running a firewall on both - machines. This will need to be circumvented for your VPN - traffic. You might want to allow all traffic between both - networks, or you might want to include firewall rules that - protect both ends of the VPN from one another. + machines. This will need to be circumvented for your + VPN traffic. You might want to allow all traffic + between both networks, or you might want to include firewall rules + that protect both ends of the VPN from one + another. It greatly simplifies testing if you configure the - firewall to allow all traffic through the VPN. You can always - tighten things up later. If you are using &man.ipfw.8; on the - gateway machines then a command like + firewall to allow all traffic through the VPN. + You can always tighten things up later. If you are using &man.ipfw.8; + on the gateway machines then a command like ipfw add 1 allow ip from any to any via gif0 @@ -3487,9 +3519,10 @@ VPN, without affecting your other firewall rules. Obviously you will need to run this command on both gateway hosts. - This is sufficient to allow each gateway machine to ping - the other. On 192.168.1.1, you - should be able to run + This is sufficient to allow each gateway machine to + ping the other. On + 192.168.1.1, you should be able to run + ping 192.168.2.1 @@ -3497,7 +3530,7 @@ thing on the other gateway machine. However, you will not be able to reach internal machines - on either network yet. This is because of the routing -- + on either network yet. This is because of the routing — although the gateway machines know how to reach one another, they do not know how to reach the network behind each one. @@ -3516,12 +3549,12 @@ 192.168.1.x addresses instead. - IP traffic from hosts on one network will now be able to - reach hosts on the other network. + IP traffic from hosts on one network will now + be able to reach hosts on the other network. - That has now created two thirds of a VPN between the two - networks, in as much as it is virtual and it is a - network. It is not private yet. You can test + That has now created two thirds of a VPN between + the two networks, in as much as it is virtual and it is + a network. It is not private yet. You can test this using &man.ping.8; and &man.tcpdump.1;. Log in to the gateway host and run @@ -3542,10 +3575,10 @@ 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply - As you can see, the ICMP messages are going back and forth - unencrypted. If you had used the parameter to - &man.tcpdump.1; to grab more bytes of data from the packets you - would see more information. + As you can see, the ICMP messages are going + back and forth unencrypted. If you had used the + parameter to &man.tcpdump.1; to grab more bytes of data from the + packets you would see more information. Obviously this is unacceptable. The next section will discuss securing the link between the two networks so that it @@ -3586,7 +3619,8 @@ Step 2: Securing the link - To secure the link we will be using IPsec. IPsec provides + To secure the link we will be using IPsec. + IPsec provides a mechanism for two hosts to agree on an encryption key, and to then use this key in order to encrypt data between the two hosts. @@ -3603,10 +3637,10 @@ There must be a mechanism for specifying which traffic should be encrypted. Obviously, you do not want to encrypt - all your outgoing traffic -- you only want to encrypt the - traffic that is part of the VPN. The rules that you put in - place to determine what traffic will be encrypted are called - security policies. + all your outgoing traffic — you only want to encrypt the + traffic that is part of the VPN. The rules + that you put in place to determine what traffic will be encrypted + are called security policies. @@ -3614,7 +3648,8 @@ maintained by the kernel, and can be modified by userland programs. However, before you can do this you must configure the kernel to support IPsec and the Encapsulated Security Payload - (ESP) protocol. This is done by configuring a kernel with: + (ESP) protocol. This is done by configuring a + kernel with: kernel options @@ -3637,7 +3672,9 @@ associations. You can configure them by hand between two hosts, which entails choosing the encryption algorithm, encryption keys, and so forth, or you can use daemons that implement the Internet - Key Exchange protocol (IKE) to do this for you. + Key Exchange protocol + (IKE) to do this + for you. I recommend the latter. Apart from anything else, it is easier to set up. @@ -3662,26 +3699,28 @@ There are a number of choices for daemons to manage security associations with FreeBSD. This article will describe how to use one of these, racoon — which is available from - security/ipsec-tools in the &os; Ports - collection. + security/ipsec-tools in the &os; + Ports Collection. racoon - The racoon software must be run on both gateway hosts. On each host it - is configured with the IP address of the other end of the VPN, - and a secret key (which you choose, and must be the same on both - gateways). + The racoon software must be run on + both gateway hosts. On each host it is configured with the + IP address of the other end of the + VPN, and a secret key (which you choose, and + must be the same on both gateways). The two daemons then contact one another, confirm that they are who they say they are (by using the secret key that you configured). The daemons then generate a new secret key, and use - this to encrypt the traffic over the VPN. They periodically + this to encrypt the traffic over the VPN. They + periodically change this secret, so that even if an attacker were to crack one of the keys (which is as theoretically close to unfeasible as it - gets) it will not do them much good -- by the time they have cracked - the key the two daemons have chosen another one. + gets) it will not do them much good — by the time they have + cracked the key the two daemons have chosen another one. The configuration file for racoon is stored in ${PREFIX}/etc/racoon. You should find a @@ -3691,9 +3730,10 @@ key. The default racoon configuration expects to find this in - the file ${PREFIX}/etc/racoon/psk.txt. It is important to note - that the pre-shared key is not the key that will be used to - encrypt your traffic across the VPN link, it is simply a token + the file ${PREFIX}/etc/racoon/psk.txt. It is + important to note that the pre-shared key is not + the key that will be used to encrypt your traffic across the + VPN link, it is simply a token that allows the key management daemons to trust one another. psk.txt contains a line for each @@ -3705,23 +3745,28 @@ W.X.Y.Z secret - That is, the public IP address of the remote end, - whitespace, and a text string that provides the secret. - Obviously, you should not use secret as your key -- the normal + That is, the public IP + address of the remote end, whitespace, and a text string that + provides the secret. Obviously, you should not use + secret as your key — the normal rules for choosing a password apply. On gateway host #2 the line would look like this A.B.C.D secret - That is, the public IP address of the remote end, and the + That is, the public IP address of the remote + end, and the same secret key. psk.txt must be mode 0600 (i.e., only read/write to root) before racoon will run. You must run racoon on both gateway machines. You will - also need to add some firewall rules to allow the IKE traffic, - which is carried over UDP to the ISAKMP (Internet Security Association + also need to add some firewall rules to allow the + IKE traffic, + which is carried over UDP to the + ISAKMP (Internet Security Association Key Management Protocol) port. Again, this should be fairly early in your firewall ruleset. @@ -3732,7 +3777,7 @@ Once racoon is running you can try pinging one gateway host from the other. The connection is still not encrypted, but racoon will then set up the security associations between the two - hosts -- this might take a moment, and you may see this as a + hosts — this might take a moment, and you may see this as a short delay before the ping commands start responding. Once the security association has been set up you can @@ -3750,12 +3795,14 @@ link. Each IP packet that you send out has a header that contains - data about the packet. The header includes the IP addresses of - both the source and destination. As we already know, private IP + data about the packet. The header includes the + IP addresses of both the source and destination. + As we already know, private IP addresses, such as the 192.168.x.y range are not supposed to appear on the public Internet. Instead, they must first be encapsulated inside another packet. - This packet must have the public source and destination IP + This packet must have the public source and destination + IP addresses substituted for the private addresses. So if your outgoing packet started looking like this: @@ -3805,11 +3852,13 @@ This encapsulation is carried out by the gif device. As - you can see, the packet now has real IP addresses on the outside, + you can see, the packet now has real IP addresses + on the outside, and our original packet has been wrapped up as data inside the packet that will be put out on the Internet. - Obviously, we want all traffic between the VPNs to be + Obviously, we want all traffic between the + VPNs to be encrypted. You might try putting this in to words, as: If a packet leaves from The configuration on gateway host #1 (which has the public - IP address A.B.C.D) to force all - outbound traffic to W.X.Y.Z to be - encrypted is: + IP address A.B.C.D) + to force all outbound traffic to W.X.Y.Z + to be encrypted is: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; @@ -3865,7 +3914,8 @@ to add a rule to the secure policy database. The rest of this line specifies which packets will match this policy. A.B.C.D/32 and W.X.Y.Z/32 are the IP addresses and + role="ipaddr">W.X.Y.Z/32 are the IP + addresses and netmasks that identify the network or hosts that this policy will apply to. In this case, we want it to apply to traffic between these two hosts. tells the kernel that @@ -3893,15 +3943,16 @@ in this case, and the necessary reversal of the IP addresses. - The other gateway host (which has the public IP address - W.X.Y.Z) will need similar rules. + The other gateway host (which has the public + IP address W.X.Y.Z) + will need similar rules. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; - Finally, you need to add firewall rules to allow ESP and - IPENCAP packets back and forth. These rules will need to be - added to both hosts. + Finally, you need to add firewall rules to allow + ESP and IPENCAP packets back + and forth. These rules will need to be added to both hosts. ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D @@ -3944,7 +3995,8 @@ - When they are received by the far end of the VPN they will + When they are received by the far end of the + VPN they will first be decrypted (using the security associations that have been negotiated by racoon). Then they will enter the gif interface, which will unwrap @@ -3966,12 +4018,13 @@ XXX tcpdump output - Now, as you can see, &man.tcpdump.1; shows the ESP packets. If + Now, as you can see, &man.tcpdump.1; shows the + ESP packets. If you try to examine them with the option you will see (apparently) gibberish, because of the encryption. - Congratulations. You have just set up a VPN between two - remote sites. + Congratulations. You have just set up a VPN + between two remote sites. Summary @@ -3986,7 +4039,8 @@ Install security/ipsec-tools. Edit ${PREFIX}/etc/racoon/psk.txt on both - gateway hosts, adding an entry for the remote host's IP + gateway hosts, adding an entry for the remote host's + IP address and a secret key that they both know. Make sure this file is mode 0600. @@ -4020,7 +4074,8 @@ - Add firewall rules to allow IKE, ESP, and IPENCAP + Add firewall rules to allow IKE, + ESP, and IPENCAP traffic to both hosts: @@ -4034,10 +4089,11 @@ - The previous two steps should suffice to get the VPN up and + The previous two steps should suffice to get the + VPN up and running. Machines on each network will be able to refer to one - another using IP addresses, and all traffic across the link will - be automatically and securely encrypted. + another using IP addresses, and all traffic across + the link will be automatically and securely encrypted. @@ -4065,14 +4121,16 @@ access remote machines securely. It can be used as a direct replacement for rlogin, rsh, rcp, and - telnet. Additionally, TCP/IP - connections can be tunneled/forwarded securely through SSH. + telnet. Additionally, TCP/IP + connections can be tunneled/forwarded securely through SSH. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. - OpenSSH is maintained by the OpenBSD project, and is based + OpenSSH is maintained by the OpenBSD + project, and is based upon SSH v1.2.12 with all the recent bug fixes and updates. It - is compatible with both SSH protocols 1 and 2. + is compatible with both SSH protocols 1 and 2. Advantages of Using OpenSSH @@ -4124,12 +4182,13 @@ The login will continue just as it would have if a session was 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 + 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 connecting for the first time. Future attempts to login are all - verified against the saved fingerprint key. The SSH client + verified against the saved fingerprint key. The + SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts, or @@ -4137,7 +4196,8 @@ fingerprints. By default, recent versions of the - OpenSSH servers only accept SSH v2 + OpenSSH servers only accept + SSHv2 connections. The client will use version 2 if possible and will fall back to version 1. The client can also be forced to use one or the other by passing it the or @@ -4170,8 +4230,8 @@ The arguments passed to &man.scp.1; are similar to &man.cp.1;, with the file or files in the first argument, and the destination in the second. Since the file is - fetched over the network, through SSH, one or more of the file - arguments takes on the form + fetched over the network, through SSH, one or + more of the file arguments takes on the form . @@ -4201,7 +4261,8 @@ ssh-keygen Instead of using passwords, &man.ssh-keygen.1; can - be used to generate DSA or RSA keys to authenticate a user: + be used to generate DSA or RSA + keys to authenticate a user: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. @@ -4223,12 +4284,12 @@ ~/.ssh/id_rsa.pub, respectively for DSA and RSA key types. The public key must be placed in ~/.ssh/authorized_keys of the remote - machine in order for the setup to work. Similarly, RSA version - 1 public keys should be placed in + machine in order for the setup to work. Similarly, + RSA version 1 public keys should be placed in ~/.ssh/authorized_keys. This will allow connection to the remote machine based upon - SSH keys instead of passwords. + SSH keys instead of passwords. If a passphrase is used in &man.ssh-keygen.1;, the user will be prompted for a password each time in order to use the @@ -4246,7 +4307,7 @@ ssh-agent and ssh-add The &man.ssh-agent.1; and &man.ssh-add.1; utilities provide - methods for SSH keys to be loaded + methods for ssh keys to be loaded into memory for use, without needing to type the passphrase each time. @@ -4283,7 +4344,7 @@ launch XFCE, every time X11 starts. Then once that is done and X11 has been restarted so that the changes can take effect, simply run &man.ssh-add.1; to load - all of your SSH keys. + all of your SSH keys. @@ -4312,7 +4373,7 @@ Forces ssh to use version 2 of the protocol. (Do not use if you are working with older - SSH servers) + SSH servers) @@ -4349,29 +4410,33 @@ - The remote SSH server. + The remote SSH server. - An SSH tunnel works by creating a listen socket on - localhost on the specified port. + A SSH tunnel works by creating a listen socket + om 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. + 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. - - This can be used to wrap any number of insecure TCP - protocols such as SMTP, POP3, FTP, etc. + 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. - Using SSH to Create a Secure Tunnel for SMTP + Using <acronym>SSH</acronym> to Create a Secure Tunnel for + <acronym>SMTP</acronym> &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** @@ -4383,52 +4448,55 @@ This can be used in conjunction with an &man.ssh-keygen.1; and additional user accounts to create a - more seamless/hassle-free SSH tunneling environment. Keys - can be used in place of typing a password, and the tunnels - can be run as a separate user. + more seamless/hassle-free SSH tunneling + environment. Keys can be used in place of typing a password, an + the tunnels can be run as a separate user. - Practical SSH Tunneling Examples + Practical <acronym>SSH</acronym> Tunneling Examples - Secure Access of a POP3 Server + Secure Access of a <acronym>POP3</acronym> Server - At work, there is an SSH server that accepts + At work, there is an SSH server that accepts connections from the outside. On the same office network - resides a mail server running a POP3 server. The network, + resides a mail server running a POP3 server. + The network, or network path between your home and office may or may not be completely trustable. Because of this, you need to check your e-mail in a secure manner. The solution is to create - an SSH connection to your office's SSH server, and tunnel + an ssh connection to your office's + SSH server, and tunnel through to the mail server. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** When the tunnel is up and running, you can point your - mail client to send POP3 requests to localhost + mail client to send POP3 requests to + localhost port 2110. A connection here will be forwarded securely across the tunnel to mail.example.com. - Bypassing a Draconian Firewall + Bypassing a draconian Firewall Some network administrators impose extremely draconian firewall rules, filtering not only incoming connections, but outgoing connections. You may be only given access - to contact remote machines on ports 22 and 80 for SSH - and web surfing. + to contact remote machines on ports 22 and 80 for + SSH and web surfing. You may wish to access another (perhaps non-work related) service, such as an Ogg Vorbis server to stream music. If this Ogg Vorbis server is streaming on some other port than 22 or 80, you will not be able to access it. - The solution is to create an SSH connection to a machine - outside of your network's firewall, and use it to tunnel to - the Ogg Vorbis server. + The solution is to create an SSH connection + to a machine outside of your network's firewall, and use it to + tunnel to the Ogg Vorbis server. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* @@ -4501,7 +4569,7 @@ In conjunction with file system enhancements like snapshots, FreeBSD 5.0 and later offers the security of File System Access Control Lists - (ACLs). + (ACLs). Access Control Lists extend the standard &unix; permission model in a highly compatible (&posix;.1e) way. This feature >Release-Note: >Audit-Trail: >Unformatted: