FreeBSD installed. Your Next Five Moves Should be…..

The answer to the question in the title is not to break it.  Although that can very will be number six.  Instead make these next five changes to secure it.  I like the warm and fuzzy feeling of snug blankets and a secure computer. So all of these suggestions are related to security.  I would recommend these to anyone that is playing around with a FreeBSD install which will connect to the internet.

image

#1 Put locks on the doors

In order for the server to be useful, you need to be able to use it. So the first order of business is to enable SSH and also secure it.  SSH is a protocol that allows you to connect to your FreeBSD installation from a remote computer.  In this example, I’ll show you how to enable it to start on boot and allow only key based access. There are many more tweaks you can make to SSH and I suggest using Google to read up on them.

The first order of business, is to secure SSH against attempted password brute force attempts as best we can.  To do this, I prefer allowing ONLY key based login attempts. 

There is a lot of magic and moving parts to public key encryption.  But the short explanation goes something like this.  A user generates a pair of keys by using the command ssh-keygen. Basically, these keys are two files with a bunch of text garble in them.  One key is a public key, which you may share with the world and the other key is a private key which you guard tightly.  These keys are a mathematically related, which allows a certain algorithm to decipher that one key is related to the other. 

From the remote host you generated your keys on, transfer only the public key file to this new FreeBSD installation.  Put the public key file in your home directory as the file ~/.ssh/authorized_keys. You will now be able to use SSH to login from the remote host by using the key pair.  For more detailed information on how to setup and use public/private keys I again suggest Google.

To allow this, you will need to make some edits to the SSH configuration file on your new FreeBSD computer.  Use your favorite editor and change these settings in /etc/ssh/sshd_config

Disable password based login attempts

ChallengeResponseAuthentication no
PasswordAuthentication no

Enable Public Key Encryption Logins:

PubkeyAuthentication yes

Next make sure SSH is running and starts after reboot.  I run the command in bold to start the SSHD daemon.

root@demios:/etc/ssh # service sshd start

Add the line in bold to /etc/rc.conf.  This will allow SSHD to start on reboot.

sshd_enable=”YES”

#2 Oil Changes

In order to keep your car running the oil needs to be changed regularly.  Otherwise, the engine will go boom and will be competing for shotgun with your other careless buddy.  Operating systems need maintenance as well.  When you install any new operating systems one of the very first things you should do is check for updates and recheck thereafter on a regular basis. 

FreeBSD provides quite a useful command to do this, named freebsd-update.  The command allows you to fetch updates to the base operating system from a pool of servers and install them.  The pools of servers, the local location of temporarily stored update files and much more are defined in /etc/freebsd-update.conf.  

To fetch and install the updates run the following commands:

root@demios:freebsd-update fetch
root@demios:freebsd-update install

After your initial install I would highly suggest automating the fetch command via cron.  This command will send the output to the e-mail address you specify.

0 3 * * * freebsd-update -t twisteddaemon@gmail.com cron

 #3 Babysitting the Children

FreeBSD incorporates a really neat and convenient way of installing software through was is known as the Ports systems.  However, FreeBSD itself, compared to third party software, does not have many vulnerabilities.  So it’s fairly critical you keeps tabs on all the software you let play on your server.

There are two ways of utilizing the ports system to install software.  You may install a pre-compiled binary with pkg or from the ports tree which, compiles the software on your system.  Both the package and ports method eventually share the same tracking database located by default in /var/db/pkg.

Using pkg

Aside from installing, you can use the pkg command to check for vulnerabilities whether you used  a packaged or ports install.  Here is how to check for known vulnerabilities.

Running pkg for the first time, requires it to be updated to the new pkgng format.  The bootstrap should happen automatically but you can force it to update with the following command.

root@demios:pkg bootstrap -f
root@demios:pkg2ng

root@demios:pkg update -f

Run the the pkg command with ‘audit -F’.  This command will audit all installed packages/ports.  The -F flag will enable the pkg command to download the latest database maintained by the security team.

root@demios:pkg audit -F
Vulnxml file up-to-date.
0 problem(s) in the installed packages found.

In this case I do not have any packages with known vulnerabilities, if I did they would be listed.  I can also check to see if there are any newer versions of packages or ports that I am running.

root@demios:pkg version
bash-4.3.18_2                      =
rsnapshot-1.3.1_1                  =
rsync-3.1.0_3                      <
sudo-1.8.10.p3                     =
cstrzelc@europa:~ %

The ‘less then’ symbol means there are newer versions of the software.  I can upgrade the software like so.

root@demios:pkg install rsync
Updating repository catalog
The following 1 packages will be installed:

 Upgrading rsync: 3.1.0_3 -> 3.1.1_2

Using Ports

The pkg command will update packages which were compiled from the ports tree, however, ports maybe update directory from the ports tree as well.  Before doing so you should always update your ports tree to the latest copy:

root@demios:portsnap fetch
root@demios:portsnap update

To check and update individual installed ports, I recommend portmaster. 

root@demios:pkg install portmaster

Once installed the -a flag will ask portmaster to check for any outdated ports and update them as well as their dependencies.  You can also use -f to always rebuild the port(s) on update.

root@demios:portmaster -a
===»> Gathering distinfo list for installed ports
===»> Starting check of installed ports for available updates
===»> All ports are up to date

Finally, you can always get ports news and updates from FreshPorts.  The site will even let you follow your favorite ports.

#4 Close The Windows

When you want to keep your mother-in-law out of the house you close and lock the door. If she happens to be really feisty you may have to do the same to the windows. The same is true for keeping bad guys from entering your computer.  The doors and windows are called network ports.  There are two basic ways to secure the network ports on your system.  You could run a local firewall which, is akin to having a 350lbs bouncer named Bruno at every door.  FreeBSD supports three firewalls all of which can be easily loaded in as kernel modules. 

If you have a need to run a arge number of services and your server resembles Swiss Cheese, I would suggest running a firewall.  Otherwise, I suggest to run as little as possible.  You may determine which ports are open and listening on your server with netstat.


root@demios: netstat -na | grep ‘^tcp4\|^udp4’
tcp4       0     64 10.0.1.101.22          10.0.1.3.60697         ESTABLISHED
tcp4       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
udp4       0      0 *.514                  *.*

The netstat command above will output the TCP and UDP listening ports on all IPv4 interfaces.  This output tells me the current server is listening on TCP port 22, which is SSH.  This I want, so I leave that alone. 

The next listening port is TCP port 25 (mail).  However, this port is listening only on the 127.0.0.1 address.  Whenever something is listening on this address it means it’s only listening to itself and no connections coming from the external network can speak with it.  In this case port 25 is mail, and the mail service will allow this local host to connect to it in order to send mail.  This is fine. 

The third listening port is port 514, and it’s listening on the UDP protocol.  A quick check of /etc/services tells me UDP port 514 is the syslog logging daemon.  In my case I don’t plan on doing any logging from remote machines or to remote machines.  Hence, I’ll choose to  disable this listening port. 

A quick check of the man page tells me that specifying the “-ss” flag in rc.conf will prohibit syslogd from opening a network socket.  So I enter the following in /etc/rc.conf

syslogd_flags=”-ss”

Then restart syslogd

root@demios:~ # service syslogd restart

A quick recheck of netstat now shows I only have one service (SSHD) listening to the external network for connections.

root@demios:~ # netstat -na | grep ‘^tcp4\|^udp4’
tcp4       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN

#5 Keeping Tabs

Keeping your systems secure is a tireless task which never ends.  Yeah that truly does suck.  But there are some resources at your disposal provided by the great folks of the FreeBSD community

The FreeBSD Security Page…. Check it often and browse the recent vulnerabilities.  When you don’t trust yourself to remember, have the information come to you by subscribing to the FreeBSD mailing lists.  There are many, and they will produce a decent amount of chatter. But you will be in the know, learn lots and maybe even contribute.  I suggest FreeBSD-security, FreeBSD-security-notifications and FreeBSD-ports-bugs if you’re only looking for security related material.

————

I have been wrong before.  If you spot incorrect information in this article please report it to me without calling me more than three obscene names and I will correct it as soon as possible.

Tags: freebsd