diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index 85a76f9d33..60859ae9a6 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,2058 +1,2013 @@ Security + Parts rewritten and updated by &a.unfurl;, 21 March + 2000. + DES, MD5, and Crypt - Contributed by &a.wollman; 24 September - 1995. - - In order to protect the security of passwords on UN*X systems from - being easily exposed, passwords have traditionally been scrambled in - some way. Starting with Bell Labs' Seventh Edition Unix, passwords were - encrypted using what the security people call a “one-way hash - function”. That is to say, the password is transformed in such a - way that the original password cannot be regained except by brute-force - searching the space of possible passwords. Unfortunately, the only - secure method that was available to the AT&T researchers at the time - was based on DES, the Data Encryption Standard. This causes only - minimal difficulty for commercial vendors, but is a serious problem for - an operating system like FreeBSD where all the source code is freely - available, because national governments in many places like to place - restrictions on cross-border transport of DES and other encryption - software. - - So, the FreeBSD team was faced with a dilemma: how could we provide - compatibility with all those UNIX systems out there while still not - running afoul of the law? We decided to take a dual-track approach: we - would make distributions which contained only a non-regulated password - scrambler, and then provide as a separate add-on library the DES-based - password hash. The password-scrambling function was moved out of the C - library to a separate library, called libcrypt - because the name of the C function to implement it is - crypt. In FreeBSD 1.x and some pre-release 2.0 - snapshots, the non-regulated scrambler uses an insecure function written - by Nate Williams; in subsequent releases this was replaced by a - mechanism using the RSA Data Security, Inc., MD5 one-way hash function. - Because neither of these functions involve encryption, they are believed - to be exportable from the US and importable into many other - countries. - - Meanwhile, work was also underway on the DES-based password hash - function. First, a version of the crypt function - which was written outside the US was imported, thus synchronizing the US - and non-US code. Then, the library was modified and split into two; the - DES libcrypt contains only the code involved in - performing the one-way password hash, and a separate - libcipher was created with the entry points to - actually perform encryption. The code was partitioned in this way to - make it easier to get an export license for the compiled library. - + Every user on a UNIX system has a password associated with their + account, obviously these passwords need to be known only to + the user and the actual operating system. In order to keep + these passwords secret, they are encrypted with what is known + as a 'one-way hash', that is, they can only be easily encrypted + but not decrypted. The only way to get the password is by + brute force searching the 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 is not such a problem for users that live in + the US, but since the source code for DES cannot be exported + outside the US, FreeBSD had to find a way to both comply with + US law and retain compatibility with all the other UNIX + variants that still use 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 FreeBSD came to + use MD5 as it's default encryption method. + - Recognizing your <command>crypt</command> mechanism - - It is fairly easy to recognize whether a particular password - string was created using the DES- or MD5-based hash function. MD5 - password strings always begin with the characters - $1$. 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 doesn't begin with a dollar sign is very likely a DES - password. - - Determining which library is being used on your system is fairly - easy for most programs, except for those like init - which are statically linked. (For those programs, the only way is to - try them on a known password and see if it works.) Programs which use - crypt are linked against - libcrypt, which for each type of library is a - symbolic link to the appropriate implementation. For example, on a - system using the DES versions: - + Recognizing your crypt mechanism + + It is pretty easy to identify which encryption method + FreeBSD 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 with + encrypted with the DES hash and also begin with the characters + $1$. 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. + + Identifying which library is being used by the programs on + your system is easy as well. Any program that uses crypt is linked + against libcrypt which for each type of library is a symbolic link + to the appropriate implementation. For example, on a system using + the DES versions: + &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a - - On a system using the MD5-based libraries, the same links will be - present, but the target will be libscrypt rather - than libdescrypt. + + On a system using the MD5-based libraries, the same links will + be present, but the target will be libscrypt + rather than libdescrypt. - - - + S/Key - - Contributed by &a.wollman; 25 September - 1995. - - S/Key is a one-time password scheme based on a one-way hash function - (in our version, this is MD4 for compatibility; other versions have used - MD5 and DES-MAC). S/Key has been a standard part of all FreeBSD - distributions since version 1.1.5, and is also implemented on a large - and growing number of other systems. S/Key is a registered trademark of - Bell Communications Research, Inc. + + S/Key is a one-time password scheme based on a one-way hash + function. FreeBSD uses the MD4 hash for compatibility but other + systems have used MD5 and DES-MAC. S/Key has been part of the + FreeBSD base system since version 1.1.5 and is also used on a + growing number of other operating systems. S/Key is a registered + trademark of Bell Communications Research, Inc. There are three different sorts of passwords which we will talk about in the discussion 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 S/Key - key program and accepted by the - keyinit 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 key program - (and sometimes the keyinit program) which it uses to - generate one-time passwords; we will call it a “secret - password” or just unqualified “password”. - - The secret password does not necessarily have anything to do with - your UNIX password (while they can be the same, this is not - recommended). While UNIX passwords are limited to eight characters in - length, your S/Key secret password can be as long as you like; I use - seven-word phrases. In general, the S/Key system operates completely - independently of the UNIX password system. - - There are in addition two other sorts of data involved in the S/Key - system; one is called the “seed” or (confusingly) - “key”, and consists of two letters and five digits, and the - other is the “iteration count” and is a number between 100 - and 1. S/Key constructs a one-time password from these components by - concatenating the seed and the secret password, then applying a one-way - hash (the RSA Data Security, Inc., MD4 secure hash function) - iteration-count times, and turning the result into six short English - words. The login and su programs - keep 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 function is used, it is not - possible to generate future one-time passwords having overheard one - which was successfully used; the iteration count is decremented after - each successful login to keep the user and login program in sync. (When - you get the iteration count down to 1, it is time to reinitialize - S/Key.) - - There are four programs involved in the S/Key system which we will - discuss below. The key program accepts an iteration - count, a seed, and a secret password, and generates a one-time password. - The keyinit program is used to initialized S/Key, and - to change passwords, iteration counts, or seeds; it takes either a - secret password, or an iteration count, seed, and one-time password. - The keyinfo program examines the - /etc/skeykeys file and prints out the invoking - user's current iteration count and seed. Finally, the - login and su programs contain the - necessary logic to accept S/Key one-time passwords for authentication. - The login program is also capable of disallowing the - use of UNIX passwords on connections coming from specified - addresses. + Kerberos password; we will call this a “UNIX password”. + The second sort is the one-time password which is generated by the + S/Key key program and accepted by the + keyinit 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 + key program (and sometimes the + keyinit program) which it uses to generate + one-time passwords; we will call it a “secret password” + or just unqualified “password”. + + The secret password does not have anything to do with your UNIX + password; they can be the same but this is not reccomended. S/Key + secret passwords are not limted to 8 characters like UNIX passwords, + they can be as long as you like. Passwords of six or seven word + long phrases are fairly common. For the most part, the S/Key system + operates completely independently of the UNIX password + system. + + Besides the password, there are two other pieces of data that + are important to S/Key. One is what is known as the + “seed” or “key” and consists of two letters + and five digits. The other is what is called the “iteration + count” and is a number between 1 and 100. S/Key creates the + one-time password by concatenating the seed and the secret password, + then applying the MD4 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 + login and su programs keep + 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 sucessfully + used password is captured; the interation count is decremented after + each sucessfull login to keep the user and the login program in + sync. When the iteration count gets down to 1 S/Key must be + reinitialized. + + There are four programs involved in the S/Key system which we + will discuss below. The key program accepts an + iteration count, a seed, and a secret password, and generates a + one-time password. The keyinit program is used + to initialized S/Key, and to change passwords, iteration counts, or + seeds; it takes either a secret password, or an iteration count, + seed, and one-time password. The keyinfo program + examines the /etc/skeykeys file and prints out + the invoking user's current iteration count and seed. Finally, the + login and su programs contain + the necessary logic to accept S/Key one-time passwords for + authentication. The login program is also + capable of disallowing the use of UNIX passwords on connections + coming from specified addresses. There are four different sorts of operations we will cover. The first is using the keyinit program over a secure connection to set up S/Key for the first time, or to change your password or seed. The second operation is using the keyinit program over an insecure connection, in conjunction with the key program over a secure connection, to do the same. The third is using the - key program to log in over an insecure connection. - The fourth is using the key program to generate a - number of keys which can be written down or printed out to carry with - you when going to some location without secure connections to anywhere - (like at a conference). + key program to log in over an insecure + connection. The fourth is using the key program + to generate a number of keys which can be written down or printed + out to carry with you when going to some location without secure + connections to anywhere. Secure connection initialization - - To initialize S/Key, change your password, or change your seed - while logged in over a secure connection (e.g., on the console of a - machine), use the keyinit command without any - parameters while logged in as yourself: - - &prompt.user; keyinit -Updating wollman: ) these will not appear if you -Old key: ha73895 ) have not used S/Key before + + To initialize S/Key for the first time, change your password, + or change your seed while logged in over a secure connection + (e.g., on the console of a machine or via ssh), use the + keyinit command without any parameters while + logged in as yourself: + + &prompt.user; keyinit +Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. -Enter secret password: ) I typed my pass phrase here -Again secret password: ) I typed it again ID - -wollman s/key is 99 ha73896 ) discussed below SAG -HAS FONT GOUT FATE BOOM ) - - There is a lot of information here. At theEnter secret - password: prompt, you should enter some password or phrase - (I use phrases of minimum seven words) which will be needed to - generate login keys. The line starting `ID' gives the parameters of - your particular S/Key instance: your login name, the iteration count, - and seed. When logging in with S/Key, the system will remember these - parameters and present them back to you so you do not have to remember - them. The last line gives the particular one-time password which - corresponds to those parameters and your secret password; if you were - to re-login immediately, this one-time password is the one you would - use. +Enter secret password: +Again secret password: + +ID unfurl s/key is 99 to17757 +DEFY CLUB PRO NASH LACE SOFT + + 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 + parameters of your particular S/Key instance; your login name, the + iteration count, and seed. When logging in with S/Key, the system + will remember these parameters and present them back to you so you + do not have to remember them. The last line gives the particular + one-time password which corresponds to those parameters and your + secret password; if you were to re-login immediately, this + one-time password is the one you would use. - + Insecure connection initialization - To initialize S/Key or change your password or seed over an - insecure connection, you will need to already have a secure connection - to some place where you can run the key program; - this might be in the form of a desk accessory on a Macintosh, or a - shell prompt on a machine you trust (we will show the latter). You - will also need to make up an iteration count (100 is probably a good - value), and you may make up your own seed or use a randomly-generated - one. Over on the insecure connection (to the machine you are - initializing), use the keyinit -s command: - + To initialize S/Key or change your secret password over an + insecure connection, you will need to already have a secure + connection to some place where you can run the + key program; this might be in the form of a + desk accessory on a Macintosh, or a shell prompt on a machine you + trust. You will also need to make up an iteration count (100 is + probably a good value), and you may make up your own seed or use a + randomly-generated one. Over on the insecure connection (to the + machine you are initializing), use the keyinit + -s command: + &prompt.user; keyinit -s -Updating wollman: Old key: kh94741 -Reminder you need the 6 English words from the skey command. -Enter sequence count from 1 to 9999: 100 ) I typed this -Enter new key [default kh94742]: -s/key 100 kh94742 - - To accept the default seed (which the keyinit - program confusingly calls a key), press return. - Then move over to your secure connection or S/Key desk accessory, and - give it the same parameters: - - &prompt.user; key 100 kh94742 +Updating unfurl: +Old key: to17758 +Reminder you need the 6 english words from the key command. +Enter sequence count from 1 to 9999: 100 +Enter new key [default to17759]: +s/key 100 to 17759 +s/key access password: + + To accept the default seed (which the + keyinit program confusingly calls a + key), press return. Then before entering an + access password, move over to your secure connection or S/Key desk + accessory, and give it the same parameters: + + &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) I typed my secret password -HULL NAY YANG TREE TOUT VETO - +Enter secret password: <secret password> +CURE MIKE BANE HIM RACY GORE + Now switch back over to the insecure connection, and copy the one-time password generated by key over to the keyinit program: - - s/key access password: HULL NAY YANG TREE TOUT VETO -ID wollman s/key is 100 kh94742 -HULL NAY YANG TREE TOUT VETO - The rest of the description from the previous section applies here - as well. - - - - Diversion: a login prompt - - Before explaining how to generate one-time passwords, we should go - over an S/Key login prompt: - - &prompt.user; telnet himalia -Trying 18.26.0.186... -Connected to himalia.lcs.mit.edu. -Escape character is '^]'. -s/key 92 hi52030 -Password: - - Note that, before prompting for a password, the login program - prints out the iteration number and seed which you will need in order - to generate the appropriate key. You will also find a useful feature - (not shown here): if you press return at the password prompt, the - login program will turn echo on, so you can see what you are typing. - This can be extremely useful if you are attempting to type in an S/Key - by hand, such as from a printout. - - If this machine were configured to disallow UNIX passwords over a - connection from my machine, the prompt would have also included the - annotation (s/key required), indicating that only - S/Key one-time passwords will be accepted. + s/key access password:CURE MIKE BANE HIM RACY GORE +ID unfurl s/key is 100 to17759 +CURE MIKE BANE HIM RACY GORE + + The rest of the description from the previous section applies + here as well. Generating a single one-time password - - Now, to generate the one-time password needed to answer this login - prompt, we use a trusted machine and the key - program. (There are versions of the key program - from DOS and Windows machines, and there is an S/Key desk accessory - for Macintosh computers as well.) The command-line - key program takes as its parameters the iteration - count and seed; you can cut-and-paste right from the login prompt - starting at key to the end of the line. - Thus: - - &prompt.user; key 92 hi52030 ) pasted from previous section + + Once you've initialized S/Key, when you login you will be + presented with a prompt like this: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +s/key 97 fw13894 +Password: + + As a side note, the S/Key prompt has a useful feature + (not shown here): if you press return at the password prompt, the + login program will turn echo on, so you can see what you are + typing. This can be extremely useful if you are attempting to + type in an S/Key by hand, such as from a printout. Also, if this + machine were configured to disallow UNIX passwords over a + connection from my machine, the prompt would have also included + the annotation (s/key required), indicating + that only S/Key one-time passwords will be accepted. + + At this point you need to generate your one-time password to + answer this login prompt. This must be done on a trusted system + that you can run the key command on. (There + are versions of the key program from DOS, + Windows and MacOS as well.) The key program + needs both the iteration count and the seed as command line + options. You can cut-and-paste these right from the login prompt + on the machine that you are logging in to. + + On the trusted system: + + &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) I typed my secret password -ADEN BED WOLF HAW HOT STUN - - And in the other window: - - s/key 92 hi52030 ) from previous section -Password: - (turning echo on) -Password:ADEN BED WOLF HAW HOT STUN -Last login: Wed Jun 28 15:31:00 from halloran-eldar.l -[etc.] - - This is the easiest mechanism if you have a - trusted machine. There is a Java S/Key key applet, - The Java OTP - Calculator, that you can download and run locally on any +Enter secret password: +WELD LIP ACTS ENDS ME HAAG + + Now that you have your one-time password you can continue + logging in: + + login: <username> +s/key 97 fw13894 +Password: <return to enable echo> +s/key 97 fw13894 +Password [echo on]: WELD LIP ACTS ENDS ME HAAG +Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... + + This is the easiest mechanism if you have + a trusted machine. There is a Java S/Key key + applet, The Java OTP + Calculator, that you can download and run locally on any Java supporting browser. - + Generating multiple one-time passwords - - Sometimes we have to go places where no trusted machines or - connections are available. In this case, it is possible to use the - key command to generate a number of one-time - passwords in the same command; these can then be printed out. For - example: - - &prompt.user; key -n 25 57 zz99999 + + Sometimes you have have to go places where you do not have + access to a trusted machine or secure connection. In this case, + it is possible to use the key command to + generate a number of one-time passwords before hand to be printed + out and taken with you. For example: + + &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: -33: WALT THY MALI DARN NIT HEAD -34: ASK RICE BEAU GINA DOUR STAG -… -56: AMOS BOWL LUG FAT CAIN INCH -57: GROW HAYS TUN DISH CAR BALM - - The requests twenty-five keys in sequence; - the indicates the ending - iteration number; and the rest is as before. Note that these are - printed out in reverse order of eventual use. If - you are really paranoid, you might want to write the results down by - hand; otherwise you can cut-and-paste into lpr. - Note that each line shows both the iteration count and the one-time - password; you may still find it handy to scratch off passwords as you - use them. +Enter secret password: <secret password> +26: SODA RUDE LEA LIND BUDD SILT +27: JILT SPY DUTY GLOW COWL ROT +28: THEM OW COLA RUNT BONG SCOT +29: COT MASH BARR BRIM NAN FLAG +30: CAN KNEE CAST NAME FOLK BILK + + The requests five keys in sequence, the + specifies what the last iteration number + should be. Note that these are printed out in + reverse order of eventual use. If you are + really paranoid, you might want to write the results down by hand; + otherwise you can cut-and-paste into lpr. Note + that each line shows both the iteration count and the one-time + password; you may still find it handy to scratch off passwords as + you use them. - + Restricting use of UNIX passwords - - The configuration file /etc/skey.access can - be used to configure restrictions on the use of UNIX passwords based - on the host name, user name, terminal port, or IP address of a login - session. The complete format of the file is documented in the - &man.skey.access.5; manual page; there are also some security - cautions there which should be read before depending on this file for - security. - - If there is no /etc/skey.access file (which - is the default state as FreeBSD is shipped), then all users will be - allowed to use UNIX passwords. If the file exists, however, then all - users will be required to use S/Key unless explicitly permitted to do + + Restrictions can be placed on the use of UNIX passwords based + on the host name, user name, terminal port, or IP address of a + login session. These restrictions can be found in the + configuration file /etc/skey.access. The + &man.skey.access.5; manual page has more info on the complete + format of the file and also details some security cautions to be + aware of before depending on this file for security. + + If there is no /etc/skey.access file + (this is the FreeBSD default), then all users will be allowed to + use UNIX passwords. If the file exists, however, then all users + will be required to use S/Key unless explicitly permitted to do otherwise by configuration statements in the - skey.access file. In all cases, UNIX passwords - are permitted on the console. - - Here is a sample configuration file which illustrates the three - most common sorts of configuration statements: - + skey.access file. In all cases, UNIX + passwords are permitted on the console. + + Here is a sample configuration file which illustrates the + three most common sorts of configuration statements: + -permit internet 18.26.0.0 255.255.0.0 -permit user jrl +permit internet 192.168.0.0 255.255.0.0 +permit user fnord permit port ttyd0 - - The first line (permit internet) allows users - whose IP source address (which is vulnerable to spoofing) matches the - specified value and mask, to use UNIX passwords. This should not be - considered a security mechanism, but rather, a means to remind - authorized users that they are using an insecure network and need to - use S/Key for authentication. - + + The first line (permit internet) allows + users whose IP source address (which is vulnerable to spoofing) + matches the specified value and mask, to use UNIX passwords. This + should not be considered a security mechanism, but rather, a means + to remind authorized users that they are using an insecure network + and need to use S/Key for authentication. + The second line (permit user) allows the - specified user to use UNIX passwords at any time. Generally speaking, - this should only be used for people who are either unable to use the + specified username, in this case fnord, to use + UNIX passwords at any time. Generally speaking, this should only + be used for people who are either unable to use the key program, like those with dumb terminals, or those who are uneducable. - - The third line (permit port) allows all users - logging in on the specified terminal line to use UNIX passwords; this - would be used for dial-ups. + + The third line (permit port) allows all + users logging in on the specified terminal line to use UNIX + passwords; this would be used for dial-ups. - + Kerberos - + Contributed by &a.markm; (based on contribution by &a.md;). Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. Services such as remote login, remote copy, secure inter-system file copying and other high-risk tasks are made considerably safer and more controllable. The following instructions can be used as a guide on how to set up Kerberos as distributed for FreeBSD. However, you should refer to the relevant manual pages for a complete description. In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, distribution, but eBones, which had been previously ported to FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, and is thus available to system owners outside those countries. For those needing to get a legal foreign distribution of this software, please do not get it from a USA or Canada site. You will get that site in big trouble! A legal copy of this is available from ftp.internat.FreeBSD.org, which is in South Africa and an official FreeBSD mirror site. Creating the initial database This is done on the Kerberos server only. First make sure that you do not have any old Kerberos databases around. You should change to the directory /etc/kerberosIV and check that only the following files are present: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms If any additional files (such as principal.* or master_key) exist, then use the kdb_destroy command to destroy the old Kerberos database, of if Kerberos is not running, simply delete the extra files. 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 the krb.conf file: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov In this case, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to not include them for simplicity. The first line names the realm in which this system works. The other lines contain realm/host entries. The first item on a line is a realm, and the second is a host in that realm that is acting as a “key distribution centre”. The words admin server following a hosts name means that host also provides an administrative database server. For further explanation of these terms, please consult the Kerberos man 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 krb.realms file would be updated as follows: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Again, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to remove them to simplify things. The first line puts the specific system into the named realm. The rest of the lines show how to default systems of a particular subdomain to a named realm. Now we are ready to create the database. This only needs to run on the Kerberos server (or Key Distribution Centre). Issue the kdb_init command to do this: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Now we have to save the key so that servers on the local machine can pick it up. Use the kstash command to do this. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! This saves the encrypted master password in /etc/kerberosIV/master_key. Making it all run Two principals need to be added to the database for each system that will be secured with Kerberos. Their names are kpasswd and rcmd These two principals are made for each system, with the instance being the name of the individual system. These daemons, kpasswd and rcmd allow other systems to change Kerberos passwords and run commands like rcp, rlogin and rsh. Now let's add these entries: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Creating the server file We now have to extract all the instances which define the services 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 and client, and is crucial to the operation of Kerberos. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Now, this command only generates a temporary file which must be renamed to srvtab so that all the server can pick it up. Use the mv command to move it into place on the original system: &prompt.root; mv grunt-new-srvtab srvtab If the file is for a client system, and the network is not deemed safe, then copy the client-new-srvtab to removable media and transport it by secure physical means. Be sure to rename it to srvtab in the client's /etc/kerberosIV directory, and make sure it is mode 600: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Populating the database We now have to add some user entries into the database. First let's create an entry for the user jane. Use the kdb_edit command to do this: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Testing it all out First we have to start the Kerberos daemons. NOTE that if you have correctly edited your /etc/rc.conf then this will happen automatically when you reboot. This is only necessary on the Kerberos server. Kerberos clients will automagically get what they need from the /etc/kerberosIV directory. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! Now we can try using the kinit command to get a ticket for the id jane that we created above: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: Try listing the tokens using klist to see if we really have them: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA 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 Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. Adding <command>su</command> privileges Kerberos allows us to give each user who needs root privileges their own separate supassword. We could now add an id which is authorized to su to root. This is controlled by having an instance of root associated with a principal. Using kdb_edit we can create the entry jane.root in the Kerberos database: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Now try getting tokens for it to make sure it works: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: Now we need to add the user to root's .klogin file: &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA Now try doing the su: &prompt.user; su Password: and take a look at what tokens we have: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA Using other commands In an earlier example, we created a principal called jane with an instance root. 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 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 Likewise, if a user has in their own home directory lines of the form: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA This allows anyone in the GRONDAR.ZA realm who has authenticated themselves to jane or jack (via kinit, see above) access to rlogin to jane's account or files on this system (grunt) via rlogin, rsh or rcp. For example, Jane now logs into another system, using Kerberos: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: %prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. 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 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) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Firewalls Contributed by &a.gpalmer; and &a.alex;. Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the FreeBSD kernel to implement them. People often think that having a firewall between your internal network and the “Big Bad Internet” will solve all your security problems. It may help, but a poorly setup firewall system is more of a security risk than not having one at all. A firewall can add another layer of security to your systems, but it cannot stop a really determined cracker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just made the crackers job that much easier. What is a firewall? There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a packet filtering router, where the kernel on a multi-homed machine chooses whether to forward or block packets based on a set of rules. The second type, known as a proxy server, relies on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled. Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a bastion host) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms. FreeBSD comes with a kernel packet filter (known as 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 document. Packet filtering routers A router is a machine which forwards packets between two or more networks. A packet filtering router has an extra piece of code in its kernel which compares each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software has packet filtering code within it that defaults to forwarding all packets. To enable the filters, you need to define a set of rules for the filtering code so it can decide if the packet should be allowed to pass or not. To decide whether a packet should be passed on, the code looks through its set of rules for a rule which matches the contents of this packets headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a “rule chain”. The packet matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc). Proxy servers Proxy servers are machines which have had the normal system daemons (telnetd, ftpd, etc) replaced with special servers. These servers are called proxy servers as they normally only allow onward connections to be made. This enables you to run (for example) a proxy telnet server on your firewall host, and people can telnet in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out). Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including “one-shot” password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password instantly expires. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system. Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers, and often they can be set up so that you can limit which users can talk to which destination machine. Again, what facilities are available depends largely on what proxy software you choose. What does IPFW allow me to do? IPFW, the software supplied with FreeBSD, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, &man.ipfw.8;. Together, they allow you to define and query the rules currently used by the kernel in its routing decisions. There are two related parts to IPFW. The firewall section allows you to perform packet filtering. There is also an IP accounting section which allows you to track usage of your router, based on similar rules to the firewall section. This allows you to see (for example) how much traffic your router is getting from a certain machine, or how much WWW (World Wide Web) traffic it is forwarding. As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation. Enabling IPFW on FreeBSD As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See reconfiguring the kernel for more details on how to recompile your kernel. There are currently three kernel configuration options relevant to IPFW: options IPFIREWALL Compiles into the kernel the code for packet filtering. options IPFIREWALL_VERBOSE Enables code to allow logging of packets through &man.syslogd.8;. Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen. options IPFIREWALL_VERBOSE_LIMIT=10 Limits the number of packets logged through &man.syslogd.8; on a per entry basis. You may wish to use this option in hostile environments in which you want to log firewall activity, but do not want to be open to a denial of service attack via syslog flooding. When a chain entry reaches the packet limit specified, logging is turned off for that particular entry. To resume logging, you will need to reset the associated counter using the &man.ipfw.8; utility: &prompt.root; ipfw zero 4500 Where 4500 is the chain entry you wish to continue logging. Previous versions of FreeBSD contained an IPFIREWALL_ACCT option. This is now obsolete as the firewall code automatically includes accounting facilities. Configuring IPFW The configuration of the IPFW software is done through the &man.ipfw.8; utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand its structure. There are currently four different command categories used by the utility: addition/deletion, listing, flushing, and clearing. Addition/deletion is used to build the rules that control how packets are accepted, rejected, and logged. Listing is used to examine the contents of your rule set (otherwise known as the chain) and packet counters (accounting). Flushing is used to remove all entries from the chain. Clearing is used to zero out one or more accounting entries. Altering the IPFW rules The syntax for this form of the command is: ipfw -N command index action log protocol addresses options There is one valid flag when using this form of the command: -N Resolve addresses and service names in output. The command given can be shortened to the shortest unique form. The valid commands are: add Add an entry to the firewall/accounting rule list delete Delete an entry from the firewall/accounting rule list Previous versions of IPFW used separate firewall and accounting entries. The present version provides packet accounting with each firewall entry. If an index value is supplied, it used to place the entry at a specific point in the chain. Otherwise, the entry is placed at the end of the chain at an index 100 greater than the last chain entry (this does not include the default policy, rule 65535, deny). The log option causes matching rules to be output to the system console if the kernel was compiled with IPFIREWALL_VERBOSE. Valid actions are: reject Drop the packet, and send an ICMP host or port unreachable (as appropriate) packet to the source. allow Pass the packet on as normal. (aliases: pass and accept) deny Drop the packet. The source is not notified via an ICMP message (thus it appears that the packet never arrived at the destination). count Update packet counters but do not allow/deny the packet based on this rule. The search continues with the next chain entry. Each action will be recognized by the shortest unambiguous prefix. The protocols which can be specified are: all Matches any IP packet icmp Matches ICMP packets tcp Matches TCP packets udp Matches UDP packets The address specification is: from address/maskport to address/maskport via interface You can only specify port in conjunction with protocols which support ports (UDP and TCP). The is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. ed0) to match only packets coming through this interface. Interface unit numbers can be specified with an optional wildcard. For example, ppp* would match all kernel PPP interfaces. The syntax used to specify an address/mask is: address or address/mask-bits or address:mask-pattern A valid hostname may be specified in place of the IP address. is a decimal number representing how many bits in the address mask should be set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any address in a class C subnet (in this case, 192.216.222) to be matched. is an IP address which will be logically AND'ed with the address given. The keyword any may be used to specify “any IP address”. The port numbers to be blocked are specified as: port,port,port… to specify either a single port or a list of ports, or port-port to specify a range of ports. You may also combine a single range with a list, but the range must always be specified first. The options available are: frag Matches if the packet is not the first fragment of the datagram. in Matches if the packet is on the way in. out Matches if the packet is on the way out. ipoptions spec Matches if the IP header contains the comma separated list of options specified in spec. The supported list of IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a leading !. established Matches if the packet is part of an already established TCP connection (i.e. it has the RST or ACK bits set). You can optimize the performance of the firewall by placing established rules early in the chain. setup Matches if the packet is an attempt to establish a TCP connection (the SYN bit set is set but the ACK bit is not). tcpflags flags Matches if the TCP header contains the comma separated list of flags. The supported flags are fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be indicated by a leading !. icmptypes types Matches if the ICMP type is present in the list types. The list may be specified as any combination of ranges and/or individual types separated by commas. Commonly used ICMP types are: 0 echo reply (ping reply), 3 destination unreachable, 5 redirect, 8 echo request (ping request), and 11 time exceeded (used to indicate TTL expiration as with &man.traceroute.8;). Listing the IPFW rules The syntax for this form of the command is: ipfw -a -t -N l There are three valid flags when using this form of the command: -a While listing, show counter values. This option is the only way to see accounting counters. -t Display the last match times for each chain entry. The time listing is incompatible with the input syntax used by the &man.ipfw.8; utility. -N Attempt to resolve given addresses and service names. Flushing the IPFW rules The syntax for flushing the chain is: ipfw flush This causes all entries in the firewall chain to be removed except the fixed default policy enforced by the kernel (index 65535). Use caution when flushing rules, the default deny policy will leave your system cut off from the network until allow entries are added to the chain. Clearing the IPFW packet counters The syntax for clearing one or more packet counters is: ipfw zero index When used without an index argument, all packet counters are cleared. If an index is supplied, the clearing operation only affects a specific chain entry. Example commands for ipfw This command will deny all packets from the host evil.crackers.org to the telnet port of the host nice.people.org by being forwarded by the router: &prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23 The next example denies and logs any TCP traffic from the entire crackers.org network (a class C) to the nice.people.org machine (any port). &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup To see the accounting records: &prompt.root; ipfw -a list or in the short form &prompt.root; ipfw -a l You can also see the last time a chain entry was matched with: &prompt.root; ipfw -at l Building a packet filtering firewall The following suggestions are just that: suggestions. The requirements of each firewall are different and I cannot tell you how to build a firewall to meet your particular requirements. When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, I strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for of `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter. If you use the logging versions of the accept command, it can generate large amounts of log data as one log line will be generated for every packet that passes through the firewall, so large ftp/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. syslogd with also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on. You should enable your firewall from /etc/rc.conf.local or /etc/rc.conf. The associated manpage explains which knobs to fiddle and lists some preset firewall configurations. If you do not use a preset configuration, ipfw list will output the current ruleset into a file that you can pass to rc.conf. If you do not use /etc/rc.conf.local or /etc/rc.conf to enable your firewall, it is important to make sure your firewall is enabled before any IP interfaces are configured. The next problem is what your firewall should actually do! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are: Block all incoming access to ports below 1024 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet. Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you'll have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing xhost + on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063. Check what ports any internal servers use (e.g. SQL servers, etc). It is probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above. Another checklist for firewall configuration is available from CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filtering As I said above, these are only guidelines. You will have to decide what filter rules you want to use on your firewall yourself. I cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above. OpenSSL As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base system. OpenSSL provides a general-purpose cryptography library, as well as the Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols. However, some of the algorithms (specifically, RSA and IDEA) included in OpenSSL are protected by patents in the USA and elsewhere, and are not available for unrestricted use (in particular, IDEA is not available at all in FreeBSD's version of OpenSSL). As a result, FreeBSD has available two different versions of the OpenSSL RSA libraries depending on geographical location (USA/non-USA). Source Code Installations OpenSSL is part of the src-crypto and src-securecvsup collections. See the Obtaining FreeBSD section for more information about obtaining and updating FreeBSD source code. International (Non-USA) Users People who are located outside the USA, and who obtain their crypto sources from internat.FreeBSD.org (the International Crypto Repository) or an international mirror site, will build a version of OpenSSL which includes the “native” OpenSSL implementation of RSA, but does not include IDEA, because the latter is restricted in certain locations elsewhere in the world. In the future a more flexible geographical identification system may allow building of IDEA in countries for which it is not restricted. Please be aware of any local restrictions on the import, use and redistribution of cryptography which may exist in your country. USA Users As noted above, RSA is patented in the USA, with terms preventing general use without an appropriate license. Therefore the standard OpenSSL RSA code may not be used in the USA, and has been removed from the version of OpenSSL carried on USA mirror sites. The RSA patent is due to expire on September 20, 2000, at which time it is intended to add the “full” RSA code back to the USA version of OpenSSL. However (and fortunately), the RSA patent holder (RSA Security, has provided a “RSA reference implementation” toolkit (RSAREF) which is available for certain classes of use, including non-commercial use (see the RSAREF license for their definition of non-commercial). If you meet the conditions of the RSAREF license and wish to use it in conjunction with OpenSSL to provide RSA support, you can install the rsaref port, which is located in /usr/ports/security/rsaref, or the rsaref-2.0 package. The OpenSSL library will then automatically detect and use the RSAREF libraries. Please obtain legal advice if you are unsure of your compliance with the license terms. The RSAREF implementation is inferior to the “native&rdquo OpenSSL implementation (it is much slower, and cannot be used with keys larger than 1024 bits). If you are not located in the USA then you are doing yourself a disadvantage by using RSAREF. Users who have purchased an appropriate RSA source code license from RSA Security may use the International version of OpenSSL described above to obtain native RSA support. IDEA code is also removed from the USA version of OpenSSL for patent reasons. Binary Installations If your FreeBSD installation was a binary installation (e.g., installed from the Walnut Creek CDROM, or from a snapshot downloaded from ftp.FreeBSD.org) and you selected to install the crypto collection, then the sysinstall utility will automatically select the correct version to install during the installation process. If the international version was selected but could not be installed during sysinstall (e.g. you have not configured network access, and the version must be downloaded from a FTP site) then you can add the international RSA library after installation as a package. The librsaintl package contains the RSA code for International (non-USA) users. This is not legal for use in the USA, but international users should use this version because the RSA implementation is faster and more flexible. It is available from ftp.internat.FreeBSD.org and does not require RSAREF. IPsec Contributed by &a.shin;, 5 March 2000. IPsec mechanism provides secure communication either for IP layer and socket layer communication. This section should explain how to use them. About IPsec implementation, please refer section 23.5.4. The current IPsec implementation supports both transport mode and tunnel mode. However, tunnel mode comes with some restrictions. http://www.kame.net/newsletter/ has more comprehensive examples. Transport mode example with IPv4 Let's setup security association to deploy a secure channel between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little complicated example. From HOST A to HOST B, only old AH is used. From HOST B to HOST A, new AH and new ESP are combined. Now we should choose algorithm to be used corresponding to "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. OK, let's 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. (1) HOST A ------> HOST B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) HOST A <------ HOST B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 Now, let's setup security association. Execute &man.setkey.8; on both HOST A and B: &prompt.root; setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D Actually, IPsec communication doesn't process until security policy entries will be defined. In this case, you must setup each host. At A: &prompt.root; setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D At B: &prompt.root; setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D HOST A --------------------------------------> HOST E 10.2.3.4 10.6.7.8 | | ========== old AH keyed-md5 ==========> <========= new AH hmac-sha1 =========== <========= new ESP des-cbc ============ Transport mode example with IPv6 Another example using IPv6. ESP transport mode is recommended for TCP port number 110 between Host-A and Host-B. ============ ESP ============ | | Host-A Host-B 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: &prompt.root; setkey -c <<EOF spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec esp/transport/fec0::10-fec0::11/use ; spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec esp/transport/fec0::11-fec0::10/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF and at Host-B: &prompt.root; setkey -c <<EOF spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec esp/transport/fec0::11-fec0::10/use ; spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec esp/transport/fec0::10-fec0::11/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF Note the direction of SP. Tunnel mode example with IPv4 Tunnel mode between two security gateways Security protocol is old AH tunnel mode, i.e. specified by RFC1826, with keyed-md5 whose key is "this is the test" as authentication algorithm. ======= AH ======= | | Network-A Gateway-A Gateway-B Network-B 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 Configuration at Gateway-A: &prompt.root; setkey -c <<EOF spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF If port number field is omitted such 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: &prompt.root; setkey -c <<EOF spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF Making SA bundle between two security gateways AH transport mode and ESP tunnel mode is required between Gateway-A and Gateway-B. In this case, ESP tunnel mode is applied first, and AH transport mode is next. ========== AH ========= | ======= ESP ===== | | | | | Network-A Gateway-A Gateway-B Network-B fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 Tunnel mode example with IPv6 Encryption algorithm is 3des-cbc, and authentication algorithm for ESP is hmac-sha1. Authentication algorithm for AH is hmac-md5. Configuration at Gateway-A: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; EOF Making SAs with the different end ESP tunnel mode is required between Host-A and Gateway-A. Encryption algorithm is cast128-cbc, and authentication algorithm for ESP is hmac-sha1. ESP transport mode is recommended between Host-A and Host-B. Encryption algorithm is rc5-cbc, and authentication algorithm for ESP is hmac-md5. ================== ESP ================= | ======= ESP ======= | | | | | Host-A Gateway-A Host-B fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 Configuration at Host-A: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; EOF diff --git a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml index 85a76f9d33..60859ae9a6 100644 --- a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml @@ -1,2058 +1,2013 @@ Security + Parts rewritten and updated by &a.unfurl;, 21 March + 2000. + DES, MD5, and Crypt - Contributed by &a.wollman; 24 September - 1995. - - In order to protect the security of passwords on UN*X systems from - being easily exposed, passwords have traditionally been scrambled in - some way. Starting with Bell Labs' Seventh Edition Unix, passwords were - encrypted using what the security people call a “one-way hash - function”. That is to say, the password is transformed in such a - way that the original password cannot be regained except by brute-force - searching the space of possible passwords. Unfortunately, the only - secure method that was available to the AT&T researchers at the time - was based on DES, the Data Encryption Standard. This causes only - minimal difficulty for commercial vendors, but is a serious problem for - an operating system like FreeBSD where all the source code is freely - available, because national governments in many places like to place - restrictions on cross-border transport of DES and other encryption - software. - - So, the FreeBSD team was faced with a dilemma: how could we provide - compatibility with all those UNIX systems out there while still not - running afoul of the law? We decided to take a dual-track approach: we - would make distributions which contained only a non-regulated password - scrambler, and then provide as a separate add-on library the DES-based - password hash. The password-scrambling function was moved out of the C - library to a separate library, called libcrypt - because the name of the C function to implement it is - crypt. In FreeBSD 1.x and some pre-release 2.0 - snapshots, the non-regulated scrambler uses an insecure function written - by Nate Williams; in subsequent releases this was replaced by a - mechanism using the RSA Data Security, Inc., MD5 one-way hash function. - Because neither of these functions involve encryption, they are believed - to be exportable from the US and importable into many other - countries. - - Meanwhile, work was also underway on the DES-based password hash - function. First, a version of the crypt function - which was written outside the US was imported, thus synchronizing the US - and non-US code. Then, the library was modified and split into two; the - DES libcrypt contains only the code involved in - performing the one-way password hash, and a separate - libcipher was created with the entry points to - actually perform encryption. The code was partitioned in this way to - make it easier to get an export license for the compiled library. - + Every user on a UNIX system has a password associated with their + account, obviously these passwords need to be known only to + the user and the actual operating system. In order to keep + these passwords secret, they are encrypted with what is known + as a 'one-way hash', that is, they can only be easily encrypted + but not decrypted. The only way to get the password is by + brute force searching the 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 is not such a problem for users that live in + the US, but since the source code for DES cannot be exported + outside the US, FreeBSD had to find a way to both comply with + US law and retain compatibility with all the other UNIX + variants that still use 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 FreeBSD came to + use MD5 as it's default encryption method. + - Recognizing your <command>crypt</command> mechanism - - It is fairly easy to recognize whether a particular password - string was created using the DES- or MD5-based hash function. MD5 - password strings always begin with the characters - $1$. 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 doesn't begin with a dollar sign is very likely a DES - password. - - Determining which library is being used on your system is fairly - easy for most programs, except for those like init - which are statically linked. (For those programs, the only way is to - try them on a known password and see if it works.) Programs which use - crypt are linked against - libcrypt, which for each type of library is a - symbolic link to the appropriate implementation. For example, on a - system using the DES versions: - + Recognizing your crypt mechanism + + It is pretty easy to identify which encryption method + FreeBSD 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 with + encrypted with the DES hash and also begin with the characters + $1$. 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. + + Identifying which library is being used by the programs on + your system is easy as well. Any program that uses crypt is linked + against libcrypt which for each type of library is a symbolic link + to the appropriate implementation. For example, on a system using + the DES versions: + &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a - - On a system using the MD5-based libraries, the same links will be - present, but the target will be libscrypt rather - than libdescrypt. + + On a system using the MD5-based libraries, the same links will + be present, but the target will be libscrypt + rather than libdescrypt. - - - + S/Key - - Contributed by &a.wollman; 25 September - 1995. - - S/Key is a one-time password scheme based on a one-way hash function - (in our version, this is MD4 for compatibility; other versions have used - MD5 and DES-MAC). S/Key has been a standard part of all FreeBSD - distributions since version 1.1.5, and is also implemented on a large - and growing number of other systems. S/Key is a registered trademark of - Bell Communications Research, Inc. + + S/Key is a one-time password scheme based on a one-way hash + function. FreeBSD uses the MD4 hash for compatibility but other + systems have used MD5 and DES-MAC. S/Key has been part of the + FreeBSD base system since version 1.1.5 and is also used on a + growing number of other operating systems. S/Key is a registered + trademark of Bell Communications Research, Inc. There are three different sorts of passwords which we will talk about in the discussion 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 S/Key - key program and accepted by the - keyinit 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 key program - (and sometimes the keyinit program) which it uses to - generate one-time passwords; we will call it a “secret - password” or just unqualified “password”. - - The secret password does not necessarily have anything to do with - your UNIX password (while they can be the same, this is not - recommended). While UNIX passwords are limited to eight characters in - length, your S/Key secret password can be as long as you like; I use - seven-word phrases. In general, the S/Key system operates completely - independently of the UNIX password system. - - There are in addition two other sorts of data involved in the S/Key - system; one is called the “seed” or (confusingly) - “key”, and consists of two letters and five digits, and the - other is the “iteration count” and is a number between 100 - and 1. S/Key constructs a one-time password from these components by - concatenating the seed and the secret password, then applying a one-way - hash (the RSA Data Security, Inc., MD4 secure hash function) - iteration-count times, and turning the result into six short English - words. The login and su programs - keep 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 function is used, it is not - possible to generate future one-time passwords having overheard one - which was successfully used; the iteration count is decremented after - each successful login to keep the user and login program in sync. (When - you get the iteration count down to 1, it is time to reinitialize - S/Key.) - - There are four programs involved in the S/Key system which we will - discuss below. The key program accepts an iteration - count, a seed, and a secret password, and generates a one-time password. - The keyinit program is used to initialized S/Key, and - to change passwords, iteration counts, or seeds; it takes either a - secret password, or an iteration count, seed, and one-time password. - The keyinfo program examines the - /etc/skeykeys file and prints out the invoking - user's current iteration count and seed. Finally, the - login and su programs contain the - necessary logic to accept S/Key one-time passwords for authentication. - The login program is also capable of disallowing the - use of UNIX passwords on connections coming from specified - addresses. + Kerberos password; we will call this a “UNIX password”. + The second sort is the one-time password which is generated by the + S/Key key program and accepted by the + keyinit 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 + key program (and sometimes the + keyinit program) which it uses to generate + one-time passwords; we will call it a “secret password” + or just unqualified “password”. + + The secret password does not have anything to do with your UNIX + password; they can be the same but this is not reccomended. S/Key + secret passwords are not limted to 8 characters like UNIX passwords, + they can be as long as you like. Passwords of six or seven word + long phrases are fairly common. For the most part, the S/Key system + operates completely independently of the UNIX password + system. + + Besides the password, there are two other pieces of data that + are important to S/Key. One is what is known as the + “seed” or “key” and consists of two letters + and five digits. The other is what is called the “iteration + count” and is a number between 1 and 100. S/Key creates the + one-time password by concatenating the seed and the secret password, + then applying the MD4 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 + login and su programs keep + 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 sucessfully + used password is captured; the interation count is decremented after + each sucessfull login to keep the user and the login program in + sync. When the iteration count gets down to 1 S/Key must be + reinitialized. + + There are four programs involved in the S/Key system which we + will discuss below. The key program accepts an + iteration count, a seed, and a secret password, and generates a + one-time password. The keyinit program is used + to initialized S/Key, and to change passwords, iteration counts, or + seeds; it takes either a secret password, or an iteration count, + seed, and one-time password. The keyinfo program + examines the /etc/skeykeys file and prints out + the invoking user's current iteration count and seed. Finally, the + login and su programs contain + the necessary logic to accept S/Key one-time passwords for + authentication. The login program is also + capable of disallowing the use of UNIX passwords on connections + coming from specified addresses. There are four different sorts of operations we will cover. The first is using the keyinit program over a secure connection to set up S/Key for the first time, or to change your password or seed. The second operation is using the keyinit program over an insecure connection, in conjunction with the key program over a secure connection, to do the same. The third is using the - key program to log in over an insecure connection. - The fourth is using the key program to generate a - number of keys which can be written down or printed out to carry with - you when going to some location without secure connections to anywhere - (like at a conference). + key program to log in over an insecure + connection. The fourth is using the key program + to generate a number of keys which can be written down or printed + out to carry with you when going to some location without secure + connections to anywhere. Secure connection initialization - - To initialize S/Key, change your password, or change your seed - while logged in over a secure connection (e.g., on the console of a - machine), use the keyinit command without any - parameters while logged in as yourself: - - &prompt.user; keyinit -Updating wollman: ) these will not appear if you -Old key: ha73895 ) have not used S/Key before + + To initialize S/Key for the first time, change your password, + or change your seed while logged in over a secure connection + (e.g., on the console of a machine or via ssh), use the + keyinit command without any parameters while + logged in as yourself: + + &prompt.user; keyinit +Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. -Enter secret password: ) I typed my pass phrase here -Again secret password: ) I typed it again ID - -wollman s/key is 99 ha73896 ) discussed below SAG -HAS FONT GOUT FATE BOOM ) - - There is a lot of information here. At theEnter secret - password: prompt, you should enter some password or phrase - (I use phrases of minimum seven words) which will be needed to - generate login keys. The line starting `ID' gives the parameters of - your particular S/Key instance: your login name, the iteration count, - and seed. When logging in with S/Key, the system will remember these - parameters and present them back to you so you do not have to remember - them. The last line gives the particular one-time password which - corresponds to those parameters and your secret password; if you were - to re-login immediately, this one-time password is the one you would - use. +Enter secret password: +Again secret password: + +ID unfurl s/key is 99 to17757 +DEFY CLUB PRO NASH LACE SOFT + + 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 + parameters of your particular S/Key instance; your login name, the + iteration count, and seed. When logging in with S/Key, the system + will remember these parameters and present them back to you so you + do not have to remember them. The last line gives the particular + one-time password which corresponds to those parameters and your + secret password; if you were to re-login immediately, this + one-time password is the one you would use. - + Insecure connection initialization - To initialize S/Key or change your password or seed over an - insecure connection, you will need to already have a secure connection - to some place where you can run the key program; - this might be in the form of a desk accessory on a Macintosh, or a - shell prompt on a machine you trust (we will show the latter). You - will also need to make up an iteration count (100 is probably a good - value), and you may make up your own seed or use a randomly-generated - one. Over on the insecure connection (to the machine you are - initializing), use the keyinit -s command: - + To initialize S/Key or change your secret password over an + insecure connection, you will need to already have a secure + connection to some place where you can run the + key program; this might be in the form of a + desk accessory on a Macintosh, or a shell prompt on a machine you + trust. You will also need to make up an iteration count (100 is + probably a good value), and you may make up your own seed or use a + randomly-generated one. Over on the insecure connection (to the + machine you are initializing), use the keyinit + -s command: + &prompt.user; keyinit -s -Updating wollman: Old key: kh94741 -Reminder you need the 6 English words from the skey command. -Enter sequence count from 1 to 9999: 100 ) I typed this -Enter new key [default kh94742]: -s/key 100 kh94742 - - To accept the default seed (which the keyinit - program confusingly calls a key), press return. - Then move over to your secure connection or S/Key desk accessory, and - give it the same parameters: - - &prompt.user; key 100 kh94742 +Updating unfurl: +Old key: to17758 +Reminder you need the 6 english words from the key command. +Enter sequence count from 1 to 9999: 100 +Enter new key [default to17759]: +s/key 100 to 17759 +s/key access password: + + To accept the default seed (which the + keyinit program confusingly calls a + key), press return. Then before entering an + access password, move over to your secure connection or S/Key desk + accessory, and give it the same parameters: + + &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) I typed my secret password -HULL NAY YANG TREE TOUT VETO - +Enter secret password: <secret password> +CURE MIKE BANE HIM RACY GORE + Now switch back over to the insecure connection, and copy the one-time password generated by key over to the keyinit program: - - s/key access password: HULL NAY YANG TREE TOUT VETO -ID wollman s/key is 100 kh94742 -HULL NAY YANG TREE TOUT VETO - The rest of the description from the previous section applies here - as well. - - - - Diversion: a login prompt - - Before explaining how to generate one-time passwords, we should go - over an S/Key login prompt: - - &prompt.user; telnet himalia -Trying 18.26.0.186... -Connected to himalia.lcs.mit.edu. -Escape character is '^]'. -s/key 92 hi52030 -Password: - - Note that, before prompting for a password, the login program - prints out the iteration number and seed which you will need in order - to generate the appropriate key. You will also find a useful feature - (not shown here): if you press return at the password prompt, the - login program will turn echo on, so you can see what you are typing. - This can be extremely useful if you are attempting to type in an S/Key - by hand, such as from a printout. - - If this machine were configured to disallow UNIX passwords over a - connection from my machine, the prompt would have also included the - annotation (s/key required), indicating that only - S/Key one-time passwords will be accepted. + s/key access password:CURE MIKE BANE HIM RACY GORE +ID unfurl s/key is 100 to17759 +CURE MIKE BANE HIM RACY GORE + + The rest of the description from the previous section applies + here as well. Generating a single one-time password - - Now, to generate the one-time password needed to answer this login - prompt, we use a trusted machine and the key - program. (There are versions of the key program - from DOS and Windows machines, and there is an S/Key desk accessory - for Macintosh computers as well.) The command-line - key program takes as its parameters the iteration - count and seed; you can cut-and-paste right from the login prompt - starting at key to the end of the line. - Thus: - - &prompt.user; key 92 hi52030 ) pasted from previous section + + Once you've initialized S/Key, when you login you will be + presented with a prompt like this: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +s/key 97 fw13894 +Password: + + As a side note, the S/Key prompt has a useful feature + (not shown here): if you press return at the password prompt, the + login program will turn echo on, so you can see what you are + typing. This can be extremely useful if you are attempting to + type in an S/Key by hand, such as from a printout. Also, if this + machine were configured to disallow UNIX passwords over a + connection from my machine, the prompt would have also included + the annotation (s/key required), indicating + that only S/Key one-time passwords will be accepted. + + At this point you need to generate your one-time password to + answer this login prompt. This must be done on a trusted system + that you can run the key command on. (There + are versions of the key program from DOS, + Windows and MacOS as well.) The key program + needs both the iteration count and the seed as command line + options. You can cut-and-paste these right from the login prompt + on the machine that you are logging in to. + + On the trusted system: + + &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) I typed my secret password -ADEN BED WOLF HAW HOT STUN - - And in the other window: - - s/key 92 hi52030 ) from previous section -Password: - (turning echo on) -Password:ADEN BED WOLF HAW HOT STUN -Last login: Wed Jun 28 15:31:00 from halloran-eldar.l -[etc.] - - This is the easiest mechanism if you have a - trusted machine. There is a Java S/Key key applet, - The Java OTP - Calculator, that you can download and run locally on any +Enter secret password: +WELD LIP ACTS ENDS ME HAAG + + Now that you have your one-time password you can continue + logging in: + + login: <username> +s/key 97 fw13894 +Password: <return to enable echo> +s/key 97 fw13894 +Password [echo on]: WELD LIP ACTS ENDS ME HAAG +Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... + + This is the easiest mechanism if you have + a trusted machine. There is a Java S/Key key + applet, The Java OTP + Calculator, that you can download and run locally on any Java supporting browser. - + Generating multiple one-time passwords - - Sometimes we have to go places where no trusted machines or - connections are available. In this case, it is possible to use the - key command to generate a number of one-time - passwords in the same command; these can then be printed out. For - example: - - &prompt.user; key -n 25 57 zz99999 + + Sometimes you have have to go places where you do not have + access to a trusted machine or secure connection. In this case, + it is possible to use the key command to + generate a number of one-time passwords before hand to be printed + out and taken with you. For example: + + &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: -33: WALT THY MALI DARN NIT HEAD -34: ASK RICE BEAU GINA DOUR STAG -… -56: AMOS BOWL LUG FAT CAIN INCH -57: GROW HAYS TUN DISH CAR BALM - - The requests twenty-five keys in sequence; - the indicates the ending - iteration number; and the rest is as before. Note that these are - printed out in reverse order of eventual use. If - you are really paranoid, you might want to write the results down by - hand; otherwise you can cut-and-paste into lpr. - Note that each line shows both the iteration count and the one-time - password; you may still find it handy to scratch off passwords as you - use them. +Enter secret password: <secret password> +26: SODA RUDE LEA LIND BUDD SILT +27: JILT SPY DUTY GLOW COWL ROT +28: THEM OW COLA RUNT BONG SCOT +29: COT MASH BARR BRIM NAN FLAG +30: CAN KNEE CAST NAME FOLK BILK + + The requests five keys in sequence, the + specifies what the last iteration number + should be. Note that these are printed out in + reverse order of eventual use. If you are + really paranoid, you might want to write the results down by hand; + otherwise you can cut-and-paste into lpr. Note + that each line shows both the iteration count and the one-time + password; you may still find it handy to scratch off passwords as + you use them. - + Restricting use of UNIX passwords - - The configuration file /etc/skey.access can - be used to configure restrictions on the use of UNIX passwords based - on the host name, user name, terminal port, or IP address of a login - session. The complete format of the file is documented in the - &man.skey.access.5; manual page; there are also some security - cautions there which should be read before depending on this file for - security. - - If there is no /etc/skey.access file (which - is the default state as FreeBSD is shipped), then all users will be - allowed to use UNIX passwords. If the file exists, however, then all - users will be required to use S/Key unless explicitly permitted to do + + Restrictions can be placed on the use of UNIX passwords based + on the host name, user name, terminal port, or IP address of a + login session. These restrictions can be found in the + configuration file /etc/skey.access. The + &man.skey.access.5; manual page has more info on the complete + format of the file and also details some security cautions to be + aware of before depending on this file for security. + + If there is no /etc/skey.access file + (this is the FreeBSD default), then all users will be allowed to + use UNIX passwords. If the file exists, however, then all users + will be required to use S/Key unless explicitly permitted to do otherwise by configuration statements in the - skey.access file. In all cases, UNIX passwords - are permitted on the console. - - Here is a sample configuration file which illustrates the three - most common sorts of configuration statements: - + skey.access file. In all cases, UNIX + passwords are permitted on the console. + + Here is a sample configuration file which illustrates the + three most common sorts of configuration statements: + -permit internet 18.26.0.0 255.255.0.0 -permit user jrl +permit internet 192.168.0.0 255.255.0.0 +permit user fnord permit port ttyd0 - - The first line (permit internet) allows users - whose IP source address (which is vulnerable to spoofing) matches the - specified value and mask, to use UNIX passwords. This should not be - considered a security mechanism, but rather, a means to remind - authorized users that they are using an insecure network and need to - use S/Key for authentication. - + + The first line (permit internet) allows + users whose IP source address (which is vulnerable to spoofing) + matches the specified value and mask, to use UNIX passwords. This + should not be considered a security mechanism, but rather, a means + to remind authorized users that they are using an insecure network + and need to use S/Key for authentication. + The second line (permit user) allows the - specified user to use UNIX passwords at any time. Generally speaking, - this should only be used for people who are either unable to use the + specified username, in this case fnord, to use + UNIX passwords at any time. Generally speaking, this should only + be used for people who are either unable to use the key program, like those with dumb terminals, or those who are uneducable. - - The third line (permit port) allows all users - logging in on the specified terminal line to use UNIX passwords; this - would be used for dial-ups. + + The third line (permit port) allows all + users logging in on the specified terminal line to use UNIX + passwords; this would be used for dial-ups. - + Kerberos - + Contributed by &a.markm; (based on contribution by &a.md;). Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. Services such as remote login, remote copy, secure inter-system file copying and other high-risk tasks are made considerably safer and more controllable. The following instructions can be used as a guide on how to set up Kerberos as distributed for FreeBSD. However, you should refer to the relevant manual pages for a complete description. In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, distribution, but eBones, which had been previously ported to FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, and is thus available to system owners outside those countries. For those needing to get a legal foreign distribution of this software, please do not get it from a USA or Canada site. You will get that site in big trouble! A legal copy of this is available from ftp.internat.FreeBSD.org, which is in South Africa and an official FreeBSD mirror site. Creating the initial database This is done on the Kerberos server only. First make sure that you do not have any old Kerberos databases around. You should change to the directory /etc/kerberosIV and check that only the following files are present: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms If any additional files (such as principal.* or master_key) exist, then use the kdb_destroy command to destroy the old Kerberos database, of if Kerberos is not running, simply delete the extra files. 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 the krb.conf file: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov In this case, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to not include them for simplicity. The first line names the realm in which this system works. The other lines contain realm/host entries. The first item on a line is a realm, and the second is a host in that realm that is acting as a “key distribution centre”. The words admin server following a hosts name means that host also provides an administrative database server. For further explanation of these terms, please consult the Kerberos man 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 krb.realms file would be updated as follows: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Again, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to remove them to simplify things. The first line puts the specific system into the named realm. The rest of the lines show how to default systems of a particular subdomain to a named realm. Now we are ready to create the database. This only needs to run on the Kerberos server (or Key Distribution Centre). Issue the kdb_init command to do this: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Now we have to save the key so that servers on the local machine can pick it up. Use the kstash command to do this. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! This saves the encrypted master password in /etc/kerberosIV/master_key. Making it all run Two principals need to be added to the database for each system that will be secured with Kerberos. Their names are kpasswd and rcmd These two principals are made for each system, with the instance being the name of the individual system. These daemons, kpasswd and rcmd allow other systems to change Kerberos passwords and run commands like rcp, rlogin and rsh. Now let's add these entries: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Creating the server file We now have to extract all the instances which define the services 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 and client, and is crucial to the operation of Kerberos. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Now, this command only generates a temporary file which must be renamed to srvtab so that all the server can pick it up. Use the mv command to move it into place on the original system: &prompt.root; mv grunt-new-srvtab srvtab If the file is for a client system, and the network is not deemed safe, then copy the client-new-srvtab to removable media and transport it by secure physical means. Be sure to rename it to srvtab in the client's /etc/kerberosIV directory, and make sure it is mode 600: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Populating the database We now have to add some user entries into the database. First let's create an entry for the user jane. Use the kdb_edit command to do this: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Testing it all out First we have to start the Kerberos daemons. NOTE that if you have correctly edited your /etc/rc.conf then this will happen automatically when you reboot. This is only necessary on the Kerberos server. Kerberos clients will automagically get what they need from the /etc/kerberosIV directory. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! Now we can try using the kinit command to get a ticket for the id jane that we created above: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: Try listing the tokens using klist to see if we really have them: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA 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 Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. Adding <command>su</command> privileges Kerberos allows us to give each user who needs root privileges their own separate supassword. We could now add an id which is authorized to su to root. This is controlled by having an instance of root associated with a principal. Using kdb_edit we can create the entry jane.root in the Kerberos database: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Now try getting tokens for it to make sure it works: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: Now we need to add the user to root's .klogin file: &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA Now try doing the su: &prompt.user; su Password: and take a look at what tokens we have: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA Using other commands In an earlier example, we created a principal called jane with an instance root. 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 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 Likewise, if a user has in their own home directory lines of the form: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA This allows anyone in the GRONDAR.ZA realm who has authenticated themselves to jane or jack (via kinit, see above) access to rlogin to jane's account or files on this system (grunt) via rlogin, rsh or rcp. For example, Jane now logs into another system, using Kerberos: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: %prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. 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 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) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Firewalls Contributed by &a.gpalmer; and &a.alex;. Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the FreeBSD kernel to implement them. People often think that having a firewall between your internal network and the “Big Bad Internet” will solve all your security problems. It may help, but a poorly setup firewall system is more of a security risk than not having one at all. A firewall can add another layer of security to your systems, but it cannot stop a really determined cracker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just made the crackers job that much easier. What is a firewall? There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a packet filtering router, where the kernel on a multi-homed machine chooses whether to forward or block packets based on a set of rules. The second type, known as a proxy server, relies on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled. Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a bastion host) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms. FreeBSD comes with a kernel packet filter (known as 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 document. Packet filtering routers A router is a machine which forwards packets between two or more networks. A packet filtering router has an extra piece of code in its kernel which compares each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software has packet filtering code within it that defaults to forwarding all packets. To enable the filters, you need to define a set of rules for the filtering code so it can decide if the packet should be allowed to pass or not. To decide whether a packet should be passed on, the code looks through its set of rules for a rule which matches the contents of this packets headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a “rule chain”. The packet matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc). Proxy servers Proxy servers are machines which have had the normal system daemons (telnetd, ftpd, etc) replaced with special servers. These servers are called proxy servers as they normally only allow onward connections to be made. This enables you to run (for example) a proxy telnet server on your firewall host, and people can telnet in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out). Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including “one-shot” password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password instantly expires. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system. Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers, and often they can be set up so that you can limit which users can talk to which destination machine. Again, what facilities are available depends largely on what proxy software you choose. What does IPFW allow me to do? IPFW, the software supplied with FreeBSD, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, &man.ipfw.8;. Together, they allow you to define and query the rules currently used by the kernel in its routing decisions. There are two related parts to IPFW. The firewall section allows you to perform packet filtering. There is also an IP accounting section which allows you to track usage of your router, based on similar rules to the firewall section. This allows you to see (for example) how much traffic your router is getting from a certain machine, or how much WWW (World Wide Web) traffic it is forwarding. As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation. Enabling IPFW on FreeBSD As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See reconfiguring the kernel for more details on how to recompile your kernel. There are currently three kernel configuration options relevant to IPFW: options IPFIREWALL Compiles into the kernel the code for packet filtering. options IPFIREWALL_VERBOSE Enables code to allow logging of packets through &man.syslogd.8;. Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen. options IPFIREWALL_VERBOSE_LIMIT=10 Limits the number of packets logged through &man.syslogd.8; on a per entry basis. You may wish to use this option in hostile environments in which you want to log firewall activity, but do not want to be open to a denial of service attack via syslog flooding. When a chain entry reaches the packet limit specified, logging is turned off for that particular entry. To resume logging, you will need to reset the associated counter using the &man.ipfw.8; utility: &prompt.root; ipfw zero 4500 Where 4500 is the chain entry you wish to continue logging. Previous versions of FreeBSD contained an IPFIREWALL_ACCT option. This is now obsolete as the firewall code automatically includes accounting facilities. Configuring IPFW The configuration of the IPFW software is done through the &man.ipfw.8; utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand its structure. There are currently four different command categories used by the utility: addition/deletion, listing, flushing, and clearing. Addition/deletion is used to build the rules that control how packets are accepted, rejected, and logged. Listing is used to examine the contents of your rule set (otherwise known as the chain) and packet counters (accounting). Flushing is used to remove all entries from the chain. Clearing is used to zero out one or more accounting entries. Altering the IPFW rules The syntax for this form of the command is: ipfw -N command index action log protocol addresses options There is one valid flag when using this form of the command: -N Resolve addresses and service names in output. The command given can be shortened to the shortest unique form. The valid commands are: add Add an entry to the firewall/accounting rule list delete Delete an entry from the firewall/accounting rule list Previous versions of IPFW used separate firewall and accounting entries. The present version provides packet accounting with each firewall entry. If an index value is supplied, it used to place the entry at a specific point in the chain. Otherwise, the entry is placed at the end of the chain at an index 100 greater than the last chain entry (this does not include the default policy, rule 65535, deny). The log option causes matching rules to be output to the system console if the kernel was compiled with IPFIREWALL_VERBOSE. Valid actions are: reject Drop the packet, and send an ICMP host or port unreachable (as appropriate) packet to the source. allow Pass the packet on as normal. (aliases: pass and accept) deny Drop the packet. The source is not notified via an ICMP message (thus it appears that the packet never arrived at the destination). count Update packet counters but do not allow/deny the packet based on this rule. The search continues with the next chain entry. Each action will be recognized by the shortest unambiguous prefix. The protocols which can be specified are: all Matches any IP packet icmp Matches ICMP packets tcp Matches TCP packets udp Matches UDP packets The address specification is: from address/maskport to address/maskport via interface You can only specify port in conjunction with protocols which support ports (UDP and TCP). The is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. ed0) to match only packets coming through this interface. Interface unit numbers can be specified with an optional wildcard. For example, ppp* would match all kernel PPP interfaces. The syntax used to specify an address/mask is: address or address/mask-bits or address:mask-pattern A valid hostname may be specified in place of the IP address. is a decimal number representing how many bits in the address mask should be set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any address in a class C subnet (in this case, 192.216.222) to be matched. is an IP address which will be logically AND'ed with the address given. The keyword any may be used to specify “any IP address”. The port numbers to be blocked are specified as: port,port,port… to specify either a single port or a list of ports, or port-port to specify a range of ports. You may also combine a single range with a list, but the range must always be specified first. The options available are: frag Matches if the packet is not the first fragment of the datagram. in Matches if the packet is on the way in. out Matches if the packet is on the way out. ipoptions spec Matches if the IP header contains the comma separated list of options specified in spec. The supported list of IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a leading !. established Matches if the packet is part of an already established TCP connection (i.e. it has the RST or ACK bits set). You can optimize the performance of the firewall by placing established rules early in the chain. setup Matches if the packet is an attempt to establish a TCP connection (the SYN bit set is set but the ACK bit is not). tcpflags flags Matches if the TCP header contains the comma separated list of flags. The supported flags are fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be indicated by a leading !. icmptypes types Matches if the ICMP type is present in the list types. The list may be specified as any combination of ranges and/or individual types separated by commas. Commonly used ICMP types are: 0 echo reply (ping reply), 3 destination unreachable, 5 redirect, 8 echo request (ping request), and 11 time exceeded (used to indicate TTL expiration as with &man.traceroute.8;). Listing the IPFW rules The syntax for this form of the command is: ipfw -a -t -N l There are three valid flags when using this form of the command: -a While listing, show counter values. This option is the only way to see accounting counters. -t Display the last match times for each chain entry. The time listing is incompatible with the input syntax used by the &man.ipfw.8; utility. -N Attempt to resolve given addresses and service names. Flushing the IPFW rules The syntax for flushing the chain is: ipfw flush This causes all entries in the firewall chain to be removed except the fixed default policy enforced by the kernel (index 65535). Use caution when flushing rules, the default deny policy will leave your system cut off from the network until allow entries are added to the chain. Clearing the IPFW packet counters The syntax for clearing one or more packet counters is: ipfw zero index When used without an index argument, all packet counters are cleared. If an index is supplied, the clearing operation only affects a specific chain entry. Example commands for ipfw This command will deny all packets from the host evil.crackers.org to the telnet port of the host nice.people.org by being forwarded by the router: &prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23 The next example denies and logs any TCP traffic from the entire crackers.org network (a class C) to the nice.people.org machine (any port). &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup To see the accounting records: &prompt.root; ipfw -a list or in the short form &prompt.root; ipfw -a l You can also see the last time a chain entry was matched with: &prompt.root; ipfw -at l Building a packet filtering firewall The following suggestions are just that: suggestions. The requirements of each firewall are different and I cannot tell you how to build a firewall to meet your particular requirements. When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, I strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for of `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter. If you use the logging versions of the accept command, it can generate large amounts of log data as one log line will be generated for every packet that passes through the firewall, so large ftp/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. syslogd with also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on. You should enable your firewall from /etc/rc.conf.local or /etc/rc.conf. The associated manpage explains which knobs to fiddle and lists some preset firewall configurations. If you do not use a preset configuration, ipfw list will output the current ruleset into a file that you can pass to rc.conf. If you do not use /etc/rc.conf.local or /etc/rc.conf to enable your firewall, it is important to make sure your firewall is enabled before any IP interfaces are configured. The next problem is what your firewall should actually do! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are: Block all incoming access to ports below 1024 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet. Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you'll have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing xhost + on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063. Check what ports any internal servers use (e.g. SQL servers, etc). It is probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above. Another checklist for firewall configuration is available from CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filtering As I said above, these are only guidelines. You will have to decide what filter rules you want to use on your firewall yourself. I cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above. OpenSSL As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base system. OpenSSL provides a general-purpose cryptography library, as well as the Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols. However, some of the algorithms (specifically, RSA and IDEA) included in OpenSSL are protected by patents in the USA and elsewhere, and are not available for unrestricted use (in particular, IDEA is not available at all in FreeBSD's version of OpenSSL). As a result, FreeBSD has available two different versions of the OpenSSL RSA libraries depending on geographical location (USA/non-USA). Source Code Installations OpenSSL is part of the src-crypto and src-securecvsup collections. See the Obtaining FreeBSD section for more information about obtaining and updating FreeBSD source code. International (Non-USA) Users People who are located outside the USA, and who obtain their crypto sources from internat.FreeBSD.org (the International Crypto Repository) or an international mirror site, will build a version of OpenSSL which includes the “native” OpenSSL implementation of RSA, but does not include IDEA, because the latter is restricted in certain locations elsewhere in the world. In the future a more flexible geographical identification system may allow building of IDEA in countries for which it is not restricted. Please be aware of any local restrictions on the import, use and redistribution of cryptography which may exist in your country. USA Users As noted above, RSA is patented in the USA, with terms preventing general use without an appropriate license. Therefore the standard OpenSSL RSA code may not be used in the USA, and has been removed from the version of OpenSSL carried on USA mirror sites. The RSA patent is due to expire on September 20, 2000, at which time it is intended to add the “full” RSA code back to the USA version of OpenSSL. However (and fortunately), the RSA patent holder (RSA Security, has provided a “RSA reference implementation” toolkit (RSAREF) which is available for certain classes of use, including non-commercial use (see the RSAREF license for their definition of non-commercial). If you meet the conditions of the RSAREF license and wish to use it in conjunction with OpenSSL to provide RSA support, you can install the rsaref port, which is located in /usr/ports/security/rsaref, or the rsaref-2.0 package. The OpenSSL library will then automatically detect and use the RSAREF libraries. Please obtain legal advice if you are unsure of your compliance with the license terms. The RSAREF implementation is inferior to the “native&rdquo OpenSSL implementation (it is much slower, and cannot be used with keys larger than 1024 bits). If you are not located in the USA then you are doing yourself a disadvantage by using RSAREF. Users who have purchased an appropriate RSA source code license from RSA Security may use the International version of OpenSSL described above to obtain native RSA support. IDEA code is also removed from the USA version of OpenSSL for patent reasons. Binary Installations If your FreeBSD installation was a binary installation (e.g., installed from the Walnut Creek CDROM, or from a snapshot downloaded from ftp.FreeBSD.org) and you selected to install the crypto collection, then the sysinstall utility will automatically select the correct version to install during the installation process. If the international version was selected but could not be installed during sysinstall (e.g. you have not configured network access, and the version must be downloaded from a FTP site) then you can add the international RSA library after installation as a package. The librsaintl package contains the RSA code for International (non-USA) users. This is not legal for use in the USA, but international users should use this version because the RSA implementation is faster and more flexible. It is available from ftp.internat.FreeBSD.org and does not require RSAREF. IPsec Contributed by &a.shin;, 5 March 2000. IPsec mechanism provides secure communication either for IP layer and socket layer communication. This section should explain how to use them. About IPsec implementation, please refer section 23.5.4. The current IPsec implementation supports both transport mode and tunnel mode. However, tunnel mode comes with some restrictions. http://www.kame.net/newsletter/ has more comprehensive examples. Transport mode example with IPv4 Let's setup security association to deploy a secure channel between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little complicated example. From HOST A to HOST B, only old AH is used. From HOST B to HOST A, new AH and new ESP are combined. Now we should choose algorithm to be used corresponding to "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. OK, let's 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. (1) HOST A ------> HOST B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) HOST A <------ HOST B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 Now, let's setup security association. Execute &man.setkey.8; on both HOST A and B: &prompt.root; setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D Actually, IPsec communication doesn't process until security policy entries will be defined. In this case, you must setup each host. At A: &prompt.root; setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D At B: &prompt.root; setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D HOST A --------------------------------------> HOST E 10.2.3.4 10.6.7.8 | | ========== old AH keyed-md5 ==========> <========= new AH hmac-sha1 =========== <========= new ESP des-cbc ============ Transport mode example with IPv6 Another example using IPv6. ESP transport mode is recommended for TCP port number 110 between Host-A and Host-B. ============ ESP ============ | | Host-A Host-B 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: &prompt.root; setkey -c <<EOF spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec esp/transport/fec0::10-fec0::11/use ; spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec esp/transport/fec0::11-fec0::10/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF and at Host-B: &prompt.root; setkey -c <<EOF spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec esp/transport/fec0::11-fec0::10/use ; spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec esp/transport/fec0::10-fec0::11/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF Note the direction of SP. Tunnel mode example with IPv4 Tunnel mode between two security gateways Security protocol is old AH tunnel mode, i.e. specified by RFC1826, with keyed-md5 whose key is "this is the test" as authentication algorithm. ======= AH ======= | | Network-A Gateway-A Gateway-B Network-B 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 Configuration at Gateway-A: &prompt.root; setkey -c <<EOF spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF If port number field is omitted such 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: &prompt.root; setkey -c <<EOF spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF Making SA bundle between two security gateways AH transport mode and ESP tunnel mode is required between Gateway-A and Gateway-B. In this case, ESP tunnel mode is applied first, and AH transport mode is next. ========== AH ========= | ======= ESP ===== | | | | | Network-A Gateway-A Gateway-B Network-B fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 Tunnel mode example with IPv6 Encryption algorithm is 3des-cbc, and authentication algorithm for ESP is hmac-sha1. Authentication algorithm for AH is hmac-md5. Configuration at Gateway-A: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; EOF Making SAs with the different end ESP tunnel mode is required between Host-A and Gateway-A. Encryption algorithm is cast128-cbc, and authentication algorithm for ESP is hmac-sha1. ESP transport mode is recommended between Host-A and Host-B. Encryption algorithm is rc5-cbc, and authentication algorithm for ESP is hmac-md5. ================== ESP ================= | ======= ESP ======= | | | | | Host-A Gateway-A Host-B fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 Configuration at Host-A: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; EOF