Chapter 1. General Security Knowledge 1.1 Superuser By default, on FreeBSD, the superuser account is root. The root account is all powerful. It can create, destroy, edit, break and control. It has complete control over the computer. One of the best things you can do to enhance your security is to only use root when absolutely necessary. When doing normal work, use your own, unprivileged account. When you're root, never run a binary that wasn't built from source code unless your absolutely sure it's safe. Only run programs that need to be run as root; you can use your own account for running other programs. 1.2 su You should never be able to login as root unless connecting through a secure protocol, such as SSH, and even then it isn't a very good idea. Instead, you should login as your username, then su to root. Besides limiting casual password attacks on your root login, this gives you a measure of accountability when tracking down problems. You can see who logged in, and who su'ed, instead of having a relatively anonymous root login message. Only the usernames in the wheel group will be able to su to root, so make sure your username is in there before continuing. You can add your user name by editing /etc/group so that the first line looks like: wheel:*:0:root,your_username Make sure you don't put any spaces in that line and to separate the usernames with commas. If you for some reason need to disable direct login via root, you will need to edit the lines below in /etc/ttys: console none unknown off secure # ttyv0 "/usr/libexec/getty PC" cons25 on secure ttyv1 "/usr/libexec/getty PC" cons25 on secure [...] To disable direct logging in via root, change all occurrences of secure to insecure. You will no longer be able to directly login as root on any of the virtual terminals. Note that since none of the pseudo-terminals are labeled secure, root logins are disabled on those terminals. In practical terms, this means that you cannot login as root through a telnet session. 1.3 Using SSH2 Key Authentication Although using SSH2 greatly improves your privacy over telnet, it still theoretically can be decrypted. If we encrypt our data being sent across the network to a public key on the remote machine, we increase our privacy even more. Here is an example of setting up ssh2 key authentication with unix. Install ssh2 on your local machine. You can find it at ftp.cis.fed.gov/pub/ssh/ssh-2.4.0.tar.gz, or you can simply use the port in /usr/ports/security/ssh2. Run ssh-keygen2 markus@fluidenterprises:~$ ssh-keygen2 Generating 1024-bit dsa key pair 1 oOo.oOo.oKey generated. 1024-bit dsa, markus@fluidenterprises, Mon Dec 25 2000 00:13:43 +0200 Passphrase : *********** Again : ********** Private key saved to /home/markus/.ssh2/id_dsa_1024_a Public key saved to /home/markus/.ssh2/id_dsa_1024_a.pub Create an identification file for yourself. markus@fluidenterprises:~$ echo "IdKey id_dsa_1024_a" > ~/.ssh2/identification Copy your public key to your remote host and put it in your .ssh2 directory. Create an authorization file on your remote host. fluid@watchtower:~/.ssh2$ echo "Key id_dsa_1024_a.pub" >> authorization Go back to your local machine and try logging in, it should look like: markus@fluidenterprises:~$ ssh2 -l fluid remote_host Passphrase for key "/home/markus/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, markus@fluidenterprises.net, Sat Dec 16 2000 02:56:47": Enter your pass phrase, voila. How to use secure ftp 2. markus@fluidenterprises:~$ sftp2 fluid@remote_host Passphrase for key "/home/markus/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, markus@fluidenterprises.net, Sat Dec 16 2000 02:56:47": sftp> Commands for sftp2 are pretty much identical as ftp Now that we have a secure public key authorization system going, test it out a couple times, and when your comfortable, * out your passwd in the passwd file. If everyone authenticates themselves via public key authorization, our security will raise greatly. Make sure to not upload id_dsa_1024_a, this is your private key and you don't want anyone to access it. --------------------------------------------------------------------------------- Chapter 2. Keep your source updated 2.1 Stay Updated The best way to stay secure is to stay updated. I strongly recommend subscribing to freebsd-security@freebsd.org. Whenever there happens to be a vulnerability, you can run cvsup to update your source, then use make buildworld and make installworld. This process is explained in this chapter. 2.2 CVSup "CVSup is a software package for distributing and updating collections of files across a network. It can efficiently and accurately mirror all types of files, including sources, binaries, hard links, symbolic links, and even device nodes. CVSup's streaming communication protocol and multithreaded architecture make it most likely the fastest mirroring tool in existence today. In addition to being a great general-purpose mirroring tool, CVSup includes special features and optimizations specifically tailored to CVS repositories." (from /usr/ports/net/cvsup/pkg-descr). In other words, CVSup connects to the main FreeBSD source code database and updates your source files that have changed. If you have the ports collection installed, you can install CVSup by typing cd /usr/ports/net/cvsup;make install as root. This will download, patch, compile and install CVSup. (Editor's note: the build of CVSup requires a lot of disk space and resources - you may find it easier to use the cvsup-bin port, /usr/ports/net/cvsup-bin, if you will only be using cvsup to keep your source and ports trees updated.) You will now need to create a "supfile" so cvsup knows what files to download and where to put them. Here is an example of a cvsup supfile: *default host=cvsup2.ca.freebsd.org *default base=/usr *default prefix=/usr *default release=cvs *default delete use-rel-suffix *default compress *default tag=RELENG_4 src-all ports-all tag=. The above code would keep your /usr/ports and /usr/src updated to the most recent version of the FreeBSD 4.x source files. If this file was called "supfile", you could upgrade your sources by running the command cvsup supfile as root. If you have cvsup installed, you can find examples of supfiles in /usr/share/examples/cvsup. For a complete guide to setting up cvsup for FreeBSD updating, check out the CVSUP section of the FreeBSD Handbook (http//www.freebsd.org/handbook/cvsup.html). 2.3 Compiling and Installing Once you have your new source code, you're going to have to do something with it. This is where make buildworld and make installworld come into play. The make buildworld command builds all your sources, and make installworld installs your newly compiled operating system. Both of these commands are found in /usr/src (or where ever you've decided to keep your source files). Before you update your system, it's good practice to backup your system or at least your important files. It is not likely something will go wrong, but better safe then sorry. It is suggested that you do the install in single user mode, for it's safer and faster. If you would like to drop to single user mode, issue shutdown now as root. Note that networking is not enabled in single-user mode, so you'll have to be at your console to use it. Before compiling, you should remove your old object files. To do this, type cd /usr/obj;chflags -R noschg *;rm -rf * as root. This will remove everything under /usr/obj. You will now be ready to recompile your operating system. To compile, run the command cd /usr/src;make buildworld as root. Once that has been completed without any errors, run the command cd /usr/src;make installworld as root. After this has completed successfully, your operating system will be updated. For detailed instructions, check out the FreeBSD Handbook (http://www.freebsd.org/handbook/makeworld.html). It's good practice to recompile your kernel after a make installworld. If you don't, certain tools (like ps and top) may not work correctly. If you're using a GENERIC kernel (if you don't know, you probably are), you can recompile it by running cd /usr/src; make buildkernel KERNEL=GENERIC; make installkernel KERNEL=GENERIC as root. Now reboot; you will have your updated operating system! --------------------------------------------------------------------------------- Chapter 3. Using a Firewall 3.1 Intro to IPFW FreeBSD comes with a very lovely kernel firewall, IPFW. IPFW is a packet filtering and accounting system which is built into the kernel. IPFW has two parts, a packet filtering part and an accounting system that allows you to track the usage on your router. We will be looking at the packet filtering half. In order to use IPFW, you have to recompile your kernel with a couple of new options. If you haven't made a custom kernel yet, the next section shall quickly go over it. If you already have a custom kernel, feel free to skip this next section. 3.2 Customizing your Kernel If you've never customized your kernel before then you should be running GENERIC. GENERIC is the default config file that comes with FreeBSD. All your kernel config files should be kept in /sys/i386/conf. You should copy GENERIC to your kernel's name and edit it. Here is a quick way of creating a customized kernel with ipfw support. # cd /usr/src/sys/i386/conf # cp GENERIC KERNEL_NAME # echo "options IPFIREWALL" >> KERNEL_NAME # echo "options IPFIREWALL_VERBOSE" >> KERNEL_NAME # echo "options IPFIREWALL_VERBOSE_LIMIT=200" >> KERNEL_NAME # echo "options IPFIREWALL_DEFAULT_TO_ACCEPT" >> KERNEL_NAME (Note: Include the above line if you want to accept all packets by default) # cd /usr/src # make buildkernel KERNEL=KERNEL_NAME # make installkernel KERNEL=KERNEL_NAME The above commands would make a copy of GENERIC as your kernel's name, then add the firewall options, then compile and install the new kernel. I suggest reading through your new kernel config file. For complete coverage on Kernel Customization, see the FreeBSD Handbook (http://www.freebsd.org/handbook/kernelconfig.html). 3.3 Setting up your Firewall Once you're more comfortable with firewall rules and operation, then you probably shouldn't use the IPFIREWALL_DEFAULT_TO_ACCEPT option. You'll want to deny everything and work your way from there. 3.4 Using IPFW IPFW looks quite complicated from a first glance, but it gets easier. To enable your firewall rules in /etc/rc.firewall when your computer boots, add firewall_enable=YES to /etc/rc.conf. You can also add firewall_logging_enable="YES" to enable logging and firewall_quiet="YES" to make it quiet while it's setting the rules on boot up. You can now open /etc/rc.firewall and look for the lines that has: # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. You can add rules to rc.firewall right above the example above. The syntax for IPFW is ipfw [-N] command [index] action [log] protocol addresses [options]. To add a rule you start with {$fwcmd}, which is the same thing as ipfw but is used with that command in rc.firewall. For command you put add because we are adding a rule. For action, you can use reject, which drops the packet but informs the source address via icmp that the packet has been dropped, or you could use allow, which allows the packet to carry on happily, or you could use deny, which denies the packet right there and does not notify the source address. For protocol, you can use tcp, udp, icmp or all. The syntax for addresses is from source_address [port,[port-port]] to destination_address [port,[port-port]]. Instead of putting in a hostname or ip for an address, you can use any. The examples below are recommended for people who are concerned about security and do not run a server. # ipfw add deny tcp from any to localhost 1-1024 setup (The above line will block all incoming traffic to ports 1-1024, which is a good idea if you don't want anyone using your services. Note that this is only useful if you don't ever want to initiate connections to this machine from the outside world.) # ipfw add deny tcp from any to localhost 6000-6063 (The above line will deny outside traffic from using your X windows. ) The above are just a few examples to get you started. A properly setup firewall can greatly raise your security, but it will not make you invincible. For more information on IPFW, see the FreeBSD Handbook (http://www.freebsd.org/handbook/firewalls.html). --------------------------------------------------------------------------------- Chapter 4. Services 4.1 INETD Inetd is a daemon that starts many of your systems services, including telnet, ftp, sendmail and so on. The configuration file for inetd is kept in /etc/inetd.conf. That file has entries in it that look like: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l telnet stream tcp nowait root /usr/libexec/telnetd telnetd #shell stream tcp nowait root /usr/libexec/rshd rshd As a general rule of thumb, we put a '#' sign in front of a line that we don't want. If we don't want any of the services, change the line inetd_enable="YES" to inetd_enable="NO" to greatly increase our security. If you just want to be able to get a shell from your computer, I would suggest turning off inetd then installing ssh2 from /usr/ports/security. If you decide to keep telnetd on, there's a few flags you may want to add, two of which are -h and -U. The flag -h prevents users from seeing host specific information until they are completely logged in and -U denies ips that don't transform into hostnames. telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h -U If you look at the ftp line, you may notice it already comes with the -l option. That option allows for logging, but you also have to enable ftp logging in syslogd. To do this add this following line to /etc/syslog.conf: ftp.* /var/log/ftpd For additional ftpd logging, you can add a second -l. 4.2 Standalone Daemons You may prefer not to use INETD but instead run a standalone daemon. You can disable INETD by editing the line below in your /etc/rc.conf inetd_enable="YES" change it to inetd_enable="NO" INETD will not run next time you reboot. If you want to kill it now, you can do: killall inetd You may now start adding daemons to the bottom of rc.network. One program I stress that you should run as a standalone daemon rather then INETD, is sshd2. It is considerably faster running standalone. --------------------------------------------------------------------------------- Chapter 5. DES vs MD5 5.1 Password Scheme Prior to 4.2-RELEASE, FreeBSD came with DES installed as the default system password encryption method. Currently, MD5 is the default. FreeBSD was switched to MD5 due to US export laws regulating DES. MD5 is believed to be more secure then DES, so using it puts you at no loss. DES is there strictly for backward compatibility. It is quite easy to recognize which password scheme you are using. For one, if you look in the /etc/master.passwd file, you will notice all the MD5 password begin with $1$ and their strings are much longer than DES. To identify which password scheme your system is using, check where your libcrypt* points to by doing ls -l /usr/lib/libcrypt* If the symbolic links point to libdescrypt*, you're using DES, if it points to libmd5crypt*, you're using MD5. Example of a system using DES bash# ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Dec 6 22:18 /usr/lib/libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 14 Dec 6 22:18 /usr/lib/libcrypt.so -> libdescrypt.so lrwxr-xr-x 1 root wheel 16 Dec 6 22:18 /usr/lib/libcrypt.so.2 -> libdescrypt.so.2 lrwxr-xr-x 1 root wheel 15 Dec 6 22:18 /usr/lib/libcrypt_p.a -> libdescrypt_p.a -r--r--r-- 1 root wheel 1259976 Dec 6 22:38 /usr/lib/libcrypto.a lrwxr-xr-x 1 root wheel 14 Dec 6 22:38 /usr/lib/libcrypto.so -> libcrypto.so.1 -r--r--r-- 1 root wheel 782240 Dec 6 22:38 /usr/lib/libcrypto.so.1 -r--r--r-- 1 root wheel 1341942 Dec 6 22:38 /usr/lib/libcrypto_p.a bash# --------------------------------------------------------------------------------- Chapter 6. Conclusion 6.1 Rules to Remember By following the above steps, you have created a fairly secure FreeBSD box. The main things to keep in mind is that new vulnerabilities are constantly coming out. This means that you have to keep your source code current and I highly suggest subscribing to freebsd-security@freebsd.org. The main things to remember are: Keep your source updated Don't install unnecessary suid-root programs Keep your firewall rules updated Use common sense - don't run programs without source 6.2 References FreeBSD Handbook