Maintaining FreeBSD Servers

For users utilizing FreeBSD, a number of useful points are made here to ease administration. The following also applies to FreeBSD jail(8) users.

Keeping Ports Updated

Besides the normal route of weak user names and passwords, another common gateway for malicious entry into your server is application vulnerabilities. It is critical that you watch any vulnerabilities, and plan to patch them on a regular basis.

The simple shell script ports.sh is located in your home directory. This merely updates the ports tree in /usr/ports with the most current data, confirms the package database and finally proceeds to update all ports.

An additional shell script is available entited test_ports_updating.sh which follows the above path, but concludes with only detailing which ports could be updated if ports.sh is run. This is a useful script to run before running ports.sh, as the output should be compared to /usr/ports/UPDATING for any upgrading details that could cause issues. The only difference in the script is that it runs "portupgrade -Fva" instead of "portupgrade -va", with the "-F" indicating that it will only pre-fetch the source necessary for upgrading without actually upgrading.

The most common method of staying abreast of vulnerabilities is by using Portaudit located in the ports tree under ports-mgmt. Setup a daily cron job running "portaudit -Fda", which will update the vulnerability database, plus run an audit of your installed applications against that database.

SSHD

The first "law" of running an sshd server is to use public and private keys with passwords. This measure strongly raises the security bar.

For Windows computers, we recommend you download and install the ssh client of OpenSSH for Windows, to avoid the conversion of keys. To generate your ssh keypair on a Unix, Unix-like or Apple OS X computer, at the command line or terminal, type:

# ssh-keygen -b (bits) -t (type)

"bits" indicate the bit size of the keys, which we recommend to be at least 1024 or even 2048. "type" can be either rsa or dsa. It's an endless and often pointless debate which type is preferable, so take your pick.

The command will prompt the following options:

Enter file in which to save the key (/home/username/.ssh/id_(rsa or dsa):

Hit enter for the default answer, which saves the keys to .ssh.

Enter passphrase (empty for no passphrase): As mentioned, providing a password for your ssh private key is extremely important. If a computer which has your private key is compromised, that computer becomes an unrestricted gateway to all hosts on which your public ssh key resides.

You will be prompted again to confirm the password. The password will not echo.

Two files will be created, id_rsa or id_dsa and id_rsa.pub or id_dsa.pub. The first file is your private key. Keep this file save and secure. Back it up on a USB device. Keep it offline. The second file is your public key. Rename the file to authorized_keys and place in your remote account's .ssh directory.

The simplest metaphor by which to understand private and public keys is the physical world's lock and key system. Everyone has access to the lock. It is public and available to all. Your key, on the other hand, is your possession. So do not hesitate to provide your public ssh key when necessary. You are nly providing a lock. It is your private ssh key that you should never provide.

By default, sshd listens on port 22/tcp. However, to minimize CPU load caused by brute force zombie attacks, we recommend an alternate port. This measure in no way improves security, but rather is a method to eliminate a potentially taxing of resources. On line 19 of /etc/ssh/sshd_config, remove the hash in from of "Port 22" and change the port to the chosen alternate.

You may also consider creating a specific group for users who can access sshd remotely. This will prevent user names not in the appropriate group from even talking with your server's ssh daemon.

The last line of the /etc/ssh/sshd_config file should read something like:

AllowGroups sshdusers

And an appropriate "sshdusers" group should be added to /etc/group.

An additional method is to utilize tcp wrappers by editing the /etc/hosts.allow file. You can restrict sshd access to certain IP addresses, or block whole net blocks, countries or continents if access from there is not necessary. See "man 5 hosts_options" for more details, but keep in mind that the last line must read "ALL: ALL: ALLOW" for non-blocked TCP traffic to be allowed.

Finally, note that for FreeBSD jail users, in the file /etc/ssh/sshd_config, line 24 reads:

ListenAddress x.x.x.x

x.x.x.x is the IP alias address assigned to your jail. This is a crucial line that enables sshd to listen on the appropriate aliased IP address for your jail. Without this line, sshd will not listen for incoming traffic.

Dailies

One of the most useful automated routines of FreeBSD is its daily emails to root.

By default root email is received locally on the server or jail, and can be accessed while logged in as root, or by typing "sudo mail."

However, to receive dailies remotely, to an external email account, provide an email address for the root user as follows:

# sudo vi /etc/aliases

Then add the appropriate email address at line 20 and remove the hash symbol. In this example two users are receiving root email remotely:

root: user@domain.com,other@another.com

After you edit /etc/aliases, be sure to run:

# newaliases

For many server administrators, receiving large quantities of dailies becomes tedious, as some of the information is not relevant and other, more useful information, may not be provided.

This problem can be alleviated by editing the contents of dailies. In the directory "/etc/periodic/daily" is a full listing of the scripts that populate the daily email. More information can be found by typing "man 8 periodic."