This document provides instructions for installing, securing, and maintaining FreeBSD servers. It discusses pre-installation planning including partitioning, software selection, and kernel customization. Post-installation tasks covered include rebuilding the operating system to incorporate updates, installing software via packages and ports, and preparing for automated upgrades. The goal is to provide a secure, optimized system tailored to the server's purpose through careful configuration and removal of unnecessary components.

1. Installing, Securing and Maintaining FreeBSD Servers
by Dru Lavigne
dru@isecom.org
Edition for meetBSD 2005
Krakow, June 18, 2005

2. Introduction
FreeBSD is renowned for providing a secure and stable server platform. FreeBSD
system administrators have several tools available to them for patching their systems
and keeping any applications and the operating system itself secure and up- to- date.
The actual techniques used to configure a secure FreeBSD server will vary according to
the administrator and the server being setup. It is, however, always interesting to peek
into another administrator's techniques and learn new tips and tricks to try on ones
own systems.
This tutorial covers some of the tools available to the FreeBSD systems administrator
and offers some solutions for automating the maintenance of FreeBSD servers. It
includes scripts which will work "out- of-the- box"; note that they are intended to be a
starting point for the administrator to add his own customizations. This tutorial does
not pretend to be comprehensive and to cover all the options available for securing a
server operating sytem.
This tutorial will cover:
•
determining the partitioning and RAID schemes for the server
•
deciding what to install
•
editing make.conf
•
rebuilding world to incorporate all changes since the operating system was last
released
•
the whys and hows of compiling a stripped down kernel
•
deciding which applications to install via packages and which via ports
•
using make options
•
creating a software upgrade scheme using portupgrade and porteasy
•
creating a backup mechanism using scponly
•
general hardening tips

3. Pre- installation Planning
Careful planning before the operating system install can greatly ease the maintenance
of the resulting server system. Questions that should be answered before the install
are:
1. Will this server be using hardware or software RAID and what type of RAID (1, 5 or
10)?
2. What is the purpose of the server? For example, will it be a web server, mail server,
FTP server, file server, VPN device, firewall?
3. Which operating system components need to be installed?
4. Which applications need to be installed on the system?
Partitioning Scheme:
While it is convenient to take advantage of the default partitioning scheme available
with the FreeBSD installer, the defaults are suitable for a workstation- -not for a server.
Here is an example of pressing "a" to create the default partition sizes; I've added the
mount points for clarity:
FreeBSD Disklabel Editor
Disk: ad0
Part
---ad0s1a
ad0s1b
ad0s1d
ad0s1e
ad0s1f
Partition name: ad0s1 Free: 0 blocks (0MB)
Mount
----<none>
swap
<none>
<none>
<none>
Size
Newfs Part
----------256MB *
614MB SWAP
256MB *
256MB *
13269MB *
Mount
----/
Size Newfs
---- -----
/var
/tmp
/usr
Notice that /var is way too small. You won't be fitting too many logs into that
partition. You do have lots of room in /usr, though, and should recreate those two
partitions manually to more appropriate sizes.
What sizes are appropriate? That depends upon the purpose of the server, or the
answer to question number 2 above.
-1-

4. For example, a webserver without user directories doesn't need that much room in
/us r. Calculate the space you'll need for /usr/bin and /usr/local , your existing HTML
content, leave some room for growth and add a few hundred MB for good measure.
The balance of the space should go to /var to leave lots of room for logging.
A server with shell accounts will need a larger /usr . When doing your calculations,
estimate the number of users and decide upon how much disk space to allocate each
user. You may wish to enforce quotas; see the quota section of the FreeBSD handbook
(http://www.freebsd.org/doc/en_US.ISO8859- 1/books/handbook/quotas.htm ) for
configuration details.
If you're setting up a public FTP server, you should carefully choose the size of /usr as
part of your security considerations to prevent your site from becoming a warez site
(http://www.eits.uga.edu/wsg/security/FTP/anonymous_ftp_abuses.html ).
Finally, keep in mind that you can never have too much space dedicated to logs. If
you're storing logs locally, consider dedicating a separate drive to /var. An alternative
is to configure syslog to log to another system.
What to Install:
When creating a server, especially an Internet- facing server, the less you install, the
better. Choosing Minimal from the installation menu will install a working operating
system.
You don't need the overhead of the entire ports collection in order to keep your ports
up- to- date, so don't install it. However, you will want src so you can recompile your
kernel and incorporate any changes to the operating system since it was released. If
your Internet connection is slow, you may prefer to choose Custom and select src -installing the src package is quicker than using cvsup to download each and every src
file.
Note: depending upon your security requirements, you may choose to remove src
from the system as part of the hardening process. You can still keep your system
patched if you have another system available with source code for when you need to
recompile a system binary or a kernel.
Since I usually ssh into my servers from a FreeBSD system, I don't install any docs or
manpages on the servers themselves.
X is not appropriate on a server system due to its overhead and inherent security risks.
Fortunately, any FreeBSD administrative task can be performed at the command line.
I recomme nd using a shell you are comfortable with and customizing your shell
configuration file to ensure effectiveness at the command line. If you really must do
some administrative tasks from a GUI, install webmin (http://www.webmin.com ) on
your workstation and restrict and monitor webmin access to the server.
-2-

5. Post- installation Preparation
After you reboot into the new operating system, your next tasks are to:
1. rebuild world to incorporate any changes since the operating system was released
2. compile a custom kernel
Rebuilding world:
Unless you happen to install the operating system the same day it is released, there
will be changes and security fixes that you'll need to incorporate. After a fresh install,
rebuilding world is an efficient way to incorporate those changes and ensure the
operating system is current to today's date.
Start by creating a cvsup file similar to this example:
# more /root/.bin/.cvs- supfile
*default host=cvsup.pl.freebsd.org
*default base=/usr /local/etc /cvsup
*default prefix=/usr
*default tag=RELENG_5_4
*default release=cvs delete use- rel- suffix compress
src- all
Using this default tag will incorporate all of the fixes and security advisories that effect
any release starting with 5.4.
You'll need to install cvsup- without- gui before you can download or sync your src:
# pkg_add -r cvsup- without- gui
# rehash
Then, create the cvsup directory and run cvsup :
# mkdir /usr/local/etc/cvsup
# cvsup -L 2 /root/.bin/.cvs- supfile
If you have already installed src, only the changes since the operating system was
released will be downloaded. If you haven't installed src yet, this will download the
latest src.
-3-

6. Once src is downloaded, create a custom /etc/make.conf before rebuilding world:
# cp /usr/share/examples/make.conf /etc/make.conf
In your edits, don't forget to find and uncom men t these 2 lines:
CFLAGS= -O -pipe
NOPROFILE= true
# Avoid compiling profiled libraries
You'll also want to review this section and determine which portions of the system you
don't want to build:
# To avoid building various parts of the base system:
#NO_ACPI= true # do not build acpiconf(8) and related programs
#NO_BOOT= true # do not build boot blocks and loader
#NO_CVS=
true # do not build CVS
#NO_CXX=
true # do not build C++ and friends
#NO_BLUETOOTH= true # do not build Bluetooth related stuff
<snip>
I like to keep a backup copy of /etc/make.conf so I don't have to re- edit on each
system I setup.
Once you're finished your edits, you're ready to update the operating system:
# cd /usr/src
# make buildworld
# make buildkernel
# make installkernel
# shutdown now
# make installworld
# shutdown -r now
Note that dropping to single- user mode (shutdown now ) isn't technically required on
a server that you're still setting up and noone else is attached to. It is a good habit to
get into, though, if you also rebuild world on production systems.
-4-

7. Customizing the Kernel:
I'm always amazed that many administrators are reluctant to recompile a kernel and
only do so when the handbook indicates they must in order to configure a certain
functionality.
Just as the default partitioning scheme isn't suited for a server, neither is the default
kernel. Go in and take a close look at /usr/src/sys/i386/conf/GENERIC and ask
yourself the following questions:
•
•
•
•
•
•
•
•
does this system really need IPv6 support?
do I really want NFS (and its inherent security risks) on an Internet facing server?
should I be loading filesystems I'll never use? (e.g. DOS, CD9660)
do I need SCSI drivers on a non- SCSI system?
do I need hardware RAID drivers if I'm using software RAID?
do I really need to load dozens of NIC drivers if I always buy the same brand of NIC?
do I need PCMCIA or wireless support on a non- laptop system?
will I be using USB or Firewire?
When building a server, you want to strip out the functionality you don't need for two
primary reasons:
1. performance: since the kernel is loaded into memory, unused filesystems and
drivers waste RAM that could be better used elsewhere. This is particularly true for
memory using servers such as HTTP.
2. security: you can't exploit something that doesn't exist. As an example, why subject
a server to a potential IPv6 vulnerability when the server doesn't even need IPv6
functionality?
Besides stripping the kernel of unneeded functionality, you may also wish to add
options that aren't present in the default kernel. On a 5.x system, take a read through
/ usr/src/sys/i386/conf/NOTES to see what applies to your specific hardware and your
server's security and performance needs.
Once you have an idea of what you wish to take out and add to the default kernel
configuration file:
# cd /usr/src/sys/i386/conf
# cp GENERIC CUSTOM
and customize CUSTOM to your server's needs.
-5-

8. For each of my servers, I like to create a record of the modifications and store a copy
on my workstation:
# diff -l GENERIC CUSTOM > `hostname`_kernel_changes.`date +%d.%m.%y`
Once you have saved your changes, build and install the customized kernel and reboot
into it:
# cd /usr/src
# make buildkernel KERNCONF=CUSTOM
# make installkernel KERNCONF=CUSTOM
# shutdown -r now
-6-

9. Software Installation
Remember the sysadmin's second mantra: document, document, document. You
want to know exactly what software is required on a server and exactly how and when
it was installed. This is especially important if you want to successfully keep that
software patched and up- to- date without breaking anything during that process.
First determine which software is required on the system and make a list. Often with
server software you'll want to research which application versions are available and
which version is appropriate for that particular server's needs. For example, when
setting up a webserver, research the pros/co ns between using Apache 1.x and Apache
2.x. If setting up an SMTP server, take a look at the pros/cons of using Sendmail,
Postfix, Qmail or other MTAs.
Pre-compiled binary or port?
Once you've settled on the applications and which versions, research each
application's website to see if there are any make options you wish to incorporate into
your binary . Do record the make options you will need. You and any future sysadmins
will thank you for your diligence.
For the software that doesn't require specific make options, it makes sense to use
pkg_add to install the pre- compiled binary. Don't worry if that binary is out- of-date,
you'll be upgrading all software before putting the server into operation.
Preparing the system for future software upgrades:
Before installing anything, prepare the system for a minimal ports tree. This is needed
in order to see which applications need to be upgraded and to successfully use
portupgrade to upgrade them. However, there are techniques you can use to ensure
portupgrade only has the port skeletons you need without having to maintain the
entire ports collection.
First, edit /root/.cshrc and add this line to the environmental variable section to set
the CVSROOT:
setenv CVSROOT :pserver:anoncvs@anoncvs.at.FreeBSD.org/home/ncvs
then inform the shell of the change:
# source /root/.chsrc
Then, use cvs to install the minimu m required ports tools:
# touch /root/.cvspass
# cd /usr
-7-

10. # cvs login
Logging in to :pserver:anoncvs@anoncvs.at.freebsd.org:2401/ho me / ncvs
CVS Password: anoncvs
# cvs checkout -A -P ports/Mk
cvs server: Updating ports/Mk
U ports/Mk/bsd.autotools.Mk
U ports/Mk/bsd.emacks.mk
U ports/Mk/bsd.gcc.mk
U ports/Mk/bsd.gnome.mk
U ports/Mk/bsd.gnustep.Mk
<snip>
# cvs checkout -A -P ports/Templates
cvs server: Updating ports/Templates
U ports/Templates/README.category
U ports/Templates/README.port
U ports/Templates/README.top
U ports/Templates/config.guess
U ports/Templates/config.sub
# cvs checkout -A -P ports/Tools
cvs server: Updating ports/Tools
U ports/Tools/ make_index
U ports/Tools/ make_readmes
cvs server: Updating ports/Tools/portb uild
U ports/Tools/portbuild/README
<snip>
# cvs checkout -A -P ports/Makefile
U ports/Makefile
Next, install porteasy. This utility downloads the required port skeletons, including
dependencies for any application you wish to install and keep up- to- date.
# pkg_add -r porteasy
Once porteasy is installed, use it to download its own port skeleton. You'll also want to
download the port skeleton for cvsup- without- gui, which is the only other application
currently installed:
-8-

11. # pwd
/usr
# porteasy -u misc/porteasy
U .cvsignore
U CHANGES
U LEGAL
U MOVED
U README
U UPDATING
U misc/Makefile
U porteasy/Makefile
U porteasy/pkg- descr
U porteasy/pkg- plist
U porteasy/src/ porteasy.8
U porteasy/porteasy.pl
U lang/Makefile
U perl5.8/Makefile
<snip>
# porteasy -u net/cvsup- without- gui
U net/Makefile
U cvsup- without- gui/Makefile
<snip>
U ezm3/Makefile
<snip>
U devel/Makefile
U gmake/Makefile
<snip>
U gettext/Makefile
<snip>
U converters/Makefile
U libiconv/Makefile
<snip>
U libtool15/Makefile
Notice how porteasy downloads all of the dependencies as well as the ports
subdirectories (e.g. net, devel, converters) required by those dependencies.
-9-

12. Installing Packages:
Now you have a routine. For each application you wish to install, use pkg_add -r to
install it, followed by porteasy -u to download its port skeleton which will be used to
see if the binary is out- of-date, and if so, to upgrade it to the latest version.
Note that porteasy requires the location of the application within the ports structure.
If you don't know the path, run this command after using pkg_add -r:
# pkg_info -ox cvsup- without- gui
Information for cvsup- without- gui- 16.1h_2:
Origin:
net/cvsup- without- gui
One application you will want to build is portupgrade:
# pkg_add -r portupgrade
# porteasy -u sysutils/portupgrade
U sysutils/Makefile
U portupgrade /Makefile
<snip>
U databases/Makefile
U ruby18/Makefile
<snip>
-10-

13. Preserving make Options:
If you have any applications that require make options, first download the required
ports skeletons. Here is an example for Apache2:
# porteasy -u www/apache2
U www/Makefile
U apache2/Makefile
<snip>
The Apache2 port is particularly complex as it supports many make options organized
into categories. You'll want to work your way through the three make targets:
# cd /usr/ports/www/apache2
# make show- options|more
Available knobs:
By default, modules are compiled as dynamically loadable (DSO) modules:
Modules knobs philosophy:
Modules are split in categoreies, "make show- categories" shows you
which modules they contain. You can enable/disable/customize a category:
- To enable a category: WITH_<CATEGORY>MODULES=yes
[WITH_PROXY_MODULES=yes]
- To disable a category: WITHOUT_<CATEGORY>_MODULES=yes
[WITHOUT_DAV_MODULES=yes]
- To customize a category: WITH_CUSTOM_<CATEGORY>
<snip>
Available make targets:
show- options:
show- modules:
show- categories:
<snip>
prints this message
prints list of available modules
prints list of modules sorted by category
To see which modules are enabled/disabled by default:
# make show- modules|more
access: enabled (shared)
auth: enabled (shared)
auth_anon: enabled (shared)
auth_dbm: enabled (shared)
auth_digest: enabled (shared)
dav: enabled (shared)
dav_fs: enabled (shared)
bucketeer: disabled
<snip>
-11-

14. And to view the possible categories:
# make show- categories|more
AUTH contains these modules:
access auth auth_anon auth_dbm auth_digest
DAV contains these modules:
dav dav_fs
<snip>
Here is an example where Apache2 will be compiled with the PROXY module (which is
disabled by default) and with a customized AUTH module that only includes access,
auth and auth_anon:
# make -DWITH_PROXY_MODULES WITH_CUSTOM_AUTH="access auth
auth_anon" install clean
To enable a module category: WITH_<CATEGORY>MODULES
To disable a module category: WITHOUT_<CATEGORY>_MODULES
Per default categories are:
AUTH DAV MISC
Categories available:
AUTH DAV EXPERIMENTAL LDAP MISC PROXY SSL SUEXEC THREADS
To see all available knobs, type make show- options
To see all modules in different categories, type make show- categories
You can check your modules configuration by using make show- modules
To save apache.org bandwidth, please use the closest
mirror. Hit Ctrl+C now and do a make print- closest- mirrors.
To automatically update /etc/ make.conf do:
make print- closest- mirrors >> /etc/ m ake.conf
=> httpd- 2.0.54.tar.bz2 doesn't seem to exist in /usr/p orts/ distfiles/apache2.
=> Attempting to fetch from http:/ /www.apache.org/dist/ httpd.
<snip>
Note how I specified my make options. It is equally correct to use either
-DWITH_PROXY_MODULES or WITH_PROXY_MODULES=yes . However, since
WITH_CUSTOM_AUTH="access auth auth_anon"includes an equals sign, you can't
start that option with -D .
While your customized binary is compiling, edit /usr/local/etc/pkgtools.conf . If you
don't, you will lose your make options when portupgrade upgrades your binary.
If this file isn't on your system, copy over the sample file:
# cp usr/local/etc/pkgtools.conf.sample /usr/local/etc/pkgtools.conf
Open up the file in your favourite editor and search for the MAKE_ARGS section:
-12-

15. # MAKE_ARGS: hash
#
# This is a hash of ports glob or package glob => arguments mapping.
# portupgrade(1) and portinstall(1) look it up to pick comman d line
# arguments to pass to make(1). You can use wildcards ("ports glob"
# or "package glob"). If a port/package matches multiple entries,
# all the arguments are joined using the space as separator.
#
# cf. -m/- -make- args of portupgrade(1), ports_glob(1)
#
# You can alternatively specify a procedure instead of a string if
# you want to specify arguments which can vary depending on the port.
# The procedure is called with a port origin as an argument.
#
# e.g.:
# MAKE_ARGS = {
# 'databases/ mysql323- *' => 'WITH_CHARSET=ujis',
# 'ruby18- *' => 'RUBY_VER=1.8',
# 'ruby16- *' => 'RUBY_VER=1.6',
# }
#
# To specify multiple arguments for each port, use one of the
# following:
#
# MAKE_ARGS = {
# # a) Separate them with the space
# 'databases/ mysql41- *' => 'WITH_LINUXTHREADS=1 SKIP_DNS_CHECK=1',
#
# # b) Specify them using an array
# 'databases/ mysql41- *' => [
#
'WITH_LINUXTHREADS=1',
#
'SKIP_DNS_CHECK=1',
# ],
# }
Those comments are meant to get you started. Your customizations belong in this
section which immediately follows the comments:
MAKE_ARGS = {
}
-13-

16. For the preceding Apache2 example, this would be the modification:
MAKE_ARGS = {
'www/apache2- *' => [
' WITH_PROXY_MODULES=yes',
'WITH_CUSTOM_AUTH=access auth auth_anon',
],
}
You should check this file for syntax errors by running portversion -l "<". If you do
have a syntax error, it will be marked with the ^ marker as in this example where I
forgot to include a comma at the end of the WITH_PROXY_MODULES line. Notice
that the marker is at the character after the missing comma:
# portversion -l "<"
** Error occured reading /usr/local/etc / pkgtools.conf:
/usr/local/etc / pkgtools.conf:313: syntax error
'WITH_CUSTOM_AUTH=access auth auth_anon',
^
/usr/local/etc / pkgtoosl.conf:313: syntax error
It's always a good idea to keep a copy of each server's customized pkgtools.conf on
your administrative workstation.
/var/db/ports:
Some ports present you with an ncurses menu which allows you to pick and choose
your make options. Use the make config target to determine if this is the case.
For example:
# cd /usr/ports/www/apache2
# make config
===> No options to configure
This port doesn't offer a menu to choose options which is why we went to the trouble
of researching the various modules and categories. However, this port does:
-14-

17. # cd /usr/ports/ftp/pure- ftpd
# make config
The nice thing about these ports is that they save your selection to /var/db/ports to be
available the next time the binary is recompiled (say, during an upgrade):
# more /var/db/ports/pure- ftpd/options
# This file is auto- generated by 'make config'.
# No user- servicable parts inside!
# Options for pure- ftpd- 1.0.20_3
_OPTIONS_READ=pure- ftpd- 1.0.20_3
WITHOUT_LDAP=true
WITHOUT_MYSQL=true
WITH_PAM=true
WITHOUT_PGSQL=true
WITHOUT_PRIVSEP=true
WITHOUT_PERUSERLIMITS=true
WITHOUT_THROTTLING=true
WITH_BANNER=true
-15-

18. Upgrading Software
Now that your software is installed, create some simple scripts to assist you in keeping
the applications up- to- date.
Here is an example that will notify you if any software needs upgrading, but still
requires manual intervention to do the actual upgrade:
# more /root/.bin/.check_upgrades
#!/bin/sh
# check to see if /src has changed
cvsup -L2 /root/.bin /.cvs- supfile
# download latest port index and incorporate into database of installed software
cd /usr /ports
make fetchindex
portsdb -u
# report on which applications are out- of-date
echo "The following ports need upgrading"
portversion -l "<"
This script is very light- weight, runs very quickly and gets the job done. You can either
instruct cron to run the script and email the contents to root or run the script
manually as part of your administrative routine. I prefer to use the results of the script
to help me identify an upgrade path. Depending upon the software that needs
upgrading, I may decide to schedule the upgrade for a time that will least impact users
and can research if there have been any configuration changes I need to be aware of in
the new version of the software.
Note: don't forget the importance of reading /usr/ ports /UPDATING.
Remember, when you do decide to upgrade a program, first use porteasy to download
the required port skeletons. Once you have the port skeletons, remember to inform
portupgrade to also upgrade any dependencies. For example:
# cd /usr
# porteasy -u net/cvsup- without- gui
# portupgrade -rR cvsup- without- gui
-16-

19. On some systems I also like to use portaudit to inform me of any existing
vulnerabilities:
# cd /usr
# porteasy -u security/portaudit
# pkg_add -r portaudit
===> To check your installed ports for known vulnerabilities now, do:
/usr/local/sbin / portaudit -Fda
# rehash
# portaudit -Fda
auditfile.tbz
100% of 24 kB 58 kBps
New database installed.
Database created: Thu May 26 15:10:09 EDT 2005
0 problem(s) in your installed packages found.
Adding that line to your check- upgrades script will keep you informed of any new
security vulnerabilities. Sometimes there will be a time lag between when a
vulnerability is found and a patch or a new version of the application that addresses
the vulnerability is released. Using the results of your script, you can determine the
best course of action until the vulnerability is addressed.
-17-

20. Creating a Backup Solution
If document, document, document is the sysadmin's second mantra, backup, backup,
backup is the first. The backup solution you implement will vary from scenario to
scenario. Some questions to ask yourself:
•
what will I be backing up to? tape, another drive on the local system, another
system on the same or a different network, etc.
•
what files or filesystems do I want to backup?
•
do I have the storage space to handle full backups or should I do incremental?
•
how time sensitive are the backups? Should I sync two systems, or can I afford a
time lag between backups?
There are many tools available to create a custom backup solution, ranging from the
built- in FreeBSD utilities to third- party software applications available through the
ports collection. In a more complex scenario you may wish to investigate:
•
•
•
bacula
rsnapshot
boxbackup
http://www.bacula.org
http://www.rsnapshot.org
http://www.fluffy.co.uk/boxbackup/
Homegrown Solution Using scponly:
In a simpler scenario where backups aren't time sensitive and you wish to backup to
another system, consider creating your own script. Choose your favourite archiver
(tar, cpio, pax) and use scp to protect the backup while it traverses the network. In
addition, use scponly (http:/ /www.sublimation.org/scponly/) to protect the backup
account by ensuring it is only used for scp .
On the system that is to receive the backups:
# pkg_add -r scponly
Fetching ftp://ftp.freebsd.org/pub /FreeBSD/ports /i386/packages- 5.4-release/Latest/
scponly.tbz...Done
Updating /etc/shells
On the system to receive the backups, create a backup user, giving it a shell of
/usr/local/bin/ sc ponly. Become that user and create this directory:
# su -l bkp
$ mkdir .ssh
-18-

21. On the system you are backing up, create the same backup user and su to that account
in order to generate a public/private key with an empty passphrase:
# su -l bkp
$ ssh- keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home / bkp /.ssh /id_rsa):
Created directory '/home / bkp /.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home / bkp /.ssh /id_rsa.
Your public key has been saved in /home / bkp /.ssh /i d_rsa.pub.
The key fingerprint is:
20:42:b9:e6:41:73:c6:28:57:5a:cc:d8:cb:49:12:80 bkp@server.domain.org
Then, copy over the public key to the system which will be receiving the backups:
$ scp .ssh/id_rsa.pub 1.1.1.1:/usr/home/bkp/.ssh/authorized_keys
Password:
id_rsa.pub
100% 231
0.2KB/s
00:00
Verify that public key authentication is working by ssh ing to the system to receive the
backups:
$ ssh 1.1.1.1
$ exit
Once it is, change the shell to /sbin / n ologin for the bkp account on the system being
backed up.
A Simple Backup Script:
Next, on the system you wish to backup, create your script. Here is a simple example
to get you started:
# more /root/.bin/.backup
#!/bin/sh
cd /usr /backups
tar czvf etc_backup.`date +%d.%m.%y`.tgz /usr/local/etc/
scp etc_backup.`date +%d.%m.%y`.tgz bkp@1.1.1.1:/usr/ ho me / bk p /
rm /usr/backups / etc_backup.`date +%d.%m.%y`.tgz
-19-

22. Don't forget to create the /usr/backups directory as a temporary holding place for the
backup until it is scp 'd over to the backup host. This particular tar statement makes a
compressed archive of /usr/local/etc saved with a datestamp in the filename. Note
that when you use scponly , the backup is meant to be placed in the home directory of
the user account running the scponly shell. This script then removes the temporary
backup from /usr/backups once the file has been copied over to the backup host. A
more sophisticated script would include checks to ensure the scp was successful.
Finally, note that this script is owned by root so it is able to backup any files you
specify; however the scp is executed by the restricted bkp shell.
Once you have a script, test it at the comman d line to ensure it works and your scp is
successful. Then, use cron to schedule your backup script.
-20-

23. General Hardening Tips
A FreeBSD server with a minimal install running the minimu m required applications
with a mechanism to keep the operating system and applications up- to- date is well on
its way to becoming a secure system. Besides protecting the system itself with firewall
rules and monitoring applications, there are other tweakables available on the system
itself.
Consider:
•
restricting ssh access using the AllowUsers keyword in / etc/ssh/sshd_config
•
using chflags to set the schg flag on system binaries and configuration files that
don't require modifications
•
implementing a file integrity checking system such as tripwire
(http:/ /www.tripwire.com), aide (http:/ /www.cs.tut.fi/~ram mer / aide.html)or
implementing your own using mtree
•
changing /etc/motd , adding an ssh banner, and removing the COPYRIGHT notice
•
subscribing to the FreeBSD security advisories mailing list
(http:/ /lists.freebsd.org/mailman /listinfo/freebsd- security- notifications)
•
reviewing mount(8) to see if any options are applicable to your filesystems
•
reviewing your sysctl(8) settings; http:/ /sysctl.enderunix.org/ provides some
helpful descriptions
•
reviewing your rc.conf(5) settings
Finally, do:
•
read root's emails daily and have a log review action plan
-21-