Dru lavigne servers-tutorial
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Dru lavigne servers-tutorial

on

  • 235 views

Presentation, MeetBSD 2005

Presentation, MeetBSD 2005

Statistics

Views

Total Views
235
Views on SlideShare
235
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Dru lavigne servers-tutorial Document Transcript

  • 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-