Defcon1-Header
Tool-BarfreeBSD ArticlesSearch Our SiteHOMEfreeBSD LinksContribute to FreeBSD HelpFreeBSD FilesFreeBSD Script Corner

FreeBSD Security

For a updated version of this FAQ, Please goto the original authors page at:
  www.freebsd.org/~jkb/howto.html


# This HOW-TO is maintained by Jan Koum
# Please mail me any additions, comments, suggestions, etc.
#

FreeBSD SECURITY HOW-TO



o FreeBSD Security HOW-TO Introduction

 o Is there really a need for this HOW-TO?

FreeBSD is a very secure operating system. Since source code is freely available, the OS is constantly going through the review and inspection.  While FreeBSD comes very secure OOB (Out-Of-Box), there are many features that can make it more secure for those of you who are "paranoid". This HowTo will go over some steps which will help you increase overall
security of your machine.

 o Will you cover tripwire, TCP wrappers, crack, cops, Satan, other tools?

 No I will not (except for SSH). This is FreeBSD specific HowTo. There is a lot of information for non-OS specific tools already out there. I would alike to concentrate on BSD only at this time.

 o Who should read this HOW-TO?
  
 Anyone who wants to learn more about ways to make their system more secure. This HOW-TO will cover some very basic steps and some very complex steps. If you have any questions or would like to contribute, please E-Mail the maintainer: jkb@best.com
 While this HOW-TO is FreeBSD specific most of the material covered here will also apply to other Unix OSes (especially OpenBSD and NetBSD).

 o Is this HowTo available in other languages?
 
 As far as I know it has been translated to Russian:
 http://www.etrust.ru/osa/security.html
 and Chinese:
 http://water.ite.ntnu.edu.tw/doc/cfbhow2.txt

 o TODO:

 Cover /etc/login.conf and login classes.
 Talk about running X windows.
 Convert this to .html

o Networking

 o inetd (Inet Daemon)

 Networking plays a very important role in overall system security.
 FreeBSD is based on 4.4BSD which comes with built in networking and
 actually has one of the most solid and fast TCP/IP stacks around. This
 stack provides support for protocols such as telnet, ftp, talk, rsh, and etc.
 Main configuration file for many of these services is located in /etc and
 is named inetd.conf - to edit this file type "vi /etc/inetd.conf" (I will
 use vi as in editor in these examples. You should however use an editor
 you are most comfortable with - if you want an easy way out try pico).
 If you are going to use pico, start with with -w option:

       -w     Disable word  wrap  (thus  allow  editing  of  long
              lines).

 This is very useful when editing files such as /etc/inetd.conf
 You can also use ee - it comes with FreeBSD and is actually set as an
 editor of choice by default for root, but "echo $EDITOR" to check.
 When you open the file in editor you will see plain ascii text which
 tells inetd which services to run, as what user and etc. (man 5 inetd.conf).
 Since this file is the main file which starts all the network services it
 is very important to configure it properly. To turn off a service you would
 place a "#" in front of the line. In general, placing a "#" before a line in
 any unix configuration file disables that line. A basic rule of thumb is to
 turn off the services which you unfamiliar with. If you don't know what it
 is or what it does, don't run it then. Ideally you would not run inetd at all.
 One example is if you are doing web serving only. Then you would run ssh and
 httpd only and NOTHING ELSE. More info on ssh follows below. If you decide
 not to run any of the daemons in the inetd.con file, then you can simply turn
 off inetd. To do that, edit /etc/rc.conf file and change

inetd_enable="YES"

   to

inetd_enable="NO"

 nobody will be able to telnet, rlogin or ftp into your computer.
 If you will be running inetd, consider using tcp wrappers. You can find
 more information at ftp://ftp.win.tue.nl/pub/security/index.html#software
 If you do decide to leave inetd running, then make sure to enable logging
 and to increase the number of times a service can be invoked in one minute.
 (The default is 256, I recommend 1024 - adjust it yourself as you see fit).
 If you are connecting with a slow link (a modem for example), this will
 not matter, but if you have a fast connection this "feature" can be used
 to create a DoS (Denial of Service) attack. Someone can create a simple
 shell script to invoke more then 256 connections to your computer which
 will cause your inetd service to shut down. On the other hand, if you want
 to support 1024 simultaneous connection to your box make sure you have it
 configured to support that. Or else someone can also cause DoS and crash your
 computer. Hence, the line right below

inetd_enable="YES"

 should be changed from:

inetd_flags=""

 to:

inetd_flags="-l -R 1024"

 this will turn on logging (-l switch) and increase maximum connection number
 to 1024 from the default 256. You will also need to change your syslog.conf
 file in /etc directory, but we will talk about syslogd later.

 o SSH

 I mentioned above that in some cases you will not need to run inetd at all.
 For example, if you are running a web, news or nfs only server, there
 is no need to have another services running on the machine. "How do I
 control my machine?" one might ask? This is where SSH comes in. You can login
 into the machine remotely using SSH (Secure Shell). Secure Shell was designed
 as a replacement for rsh, rlogin and other Berkeley r* commands, but people
 quickly realized how useful SSH is and started using it instead of such
 applications as telnet and ftp. SSH has many features, but it is mostly
 used for encrypting connection to prevent clear text passwords and the rest
 of the data traveling on in the clear on the wire. If you use telnet,
 your connection can be spied on. (If you think that S/Key is the solution
 there still exists the problems of data insertion and connection hijacking.)
 I hope by now you have been convinced to turn off inetd completely and
 install SSH instead. If you don't think you can live without services
 provided by inetd then at least enable logging and increase maximum allowed
 connections per minute (see above).
 One can download SSH from ftp://ftp.funet.fi/pub/unix/security/login/ssh
 If you want an easy way out:

# cd /usr/ports/security/ssh
# make install

 If you will have your users connect to you from non-Unix machines, some of the
 places to get Windows SSH clients are
 http://fox.doc.ic.ac.uk/~ci2/ssh/
 http://www.zip.com.au/~roca/ttssh.html
 SecureCRT from http://www.vandyke.com

 o Inetd (part II)


  o telnetd


 So you have decided still to use inetd. Let us look at the options inside
 of inetd.conf which can make services a little more secure.
 Every attacker at first will gather information about the network or the
 system he/she is about to attack. One of the things you can do to prevent
 this is to add "-h" switch to the telnet daemon:

telnet  stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd -h

 from the telnetd man page:

 -h      Disable the printing of host-specific information before login
         has been completed.

 While there are many other ways for someone to gather system information,
 one step here and another step there will overall produce a good result.
 If you don't want to run telnet daemon at all, then simply add "#" in the
 very beginning of the line:

#telnet stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd
 
 One of the quite extreme measures you can take is to refuse someone a
 telnet session if their IP does not resolve into a hostname. To do that,
 simply add "-U" switch to the telnet daemon:

telnet  stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd -h -U

 This will do very little, however, to increase the overall security of your
 system.


   o ftpd


 Now let's look at ftpd. FreeBSD has the ftp daemon configured to do some
 logging. You can see that because ftpd is started with "-l" switch from
 inetd.conf. However, you also need to configure your syslogd (syslog daemon)
 to provide support for the log generated by ftp daemon (ftpd).
 From the man page:

 -l      Each successful and failed ftp(1) session is logged using syslog
         with a facility of LOG_FTP.  If this option is specified twice,
         the retrieve (get), store (put), append, delete, make directory,
         remove directory and rename operations and their filename argu-
         ments are also logged.  Note: LOG_FTP messages are not displayed
         by syslogd(8) by default, and may have to be enabled in syslogd(8)'s
         configuration file.

 Let's enable ftpd logging in the syslog daemon's configuration file. This file
 is /etc/syslog.conf (also `man 5 syslog.conf`). Add the following line to
 the configuration file:
 
ftp.*                                           /var/log/ftpd

 don't forget to issue the command "touch /var/log/ftpd" since syslogd can't
 write to a file which isn't created first. Don't forget to add the file
 to which you will log ftp activity into /etc/newsyslog.conf to make sure
 it is rotated properly. See below for newsyslog(8) information.
 If you want to add more information about your ftp daemon (ftpd) to the log
 files, just add second "-l" to the ftp line in /etc/inetd.conf:

ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l -l

 If you want to make sure your users are using scp (Secure Copy, which is
 part of SSH suite), but still want to allow anonymous ftp access, start
 your ftp daemon with "-A" switch:

ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l -A

 You can then also edit /etc/ftpwelcome to say that ftpd will only allow
 incoming anonymous connections and that existing users should use scp
 instead of ftpd. If you do enable anonymous ftpd, then you can use -S
 option to log anonymous ftp transfers:

ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -A -S


   o fingerd


 Finger service comes configured as "secure" by default: it does not
 allow queries without a user name. This is a good thing (tm). Yet,
 some people are paranoid and would like not to run finger service
 at all. In that case, again, comment it out by placing "#" at the
 beginning of the line. If you would like to continue running finger
 service, enable logging by adding "-l" switch:

finger  stream  tcp     nowait  nobody  /usr/libexec/fingerd    fingerd -s -l

 Logs from fingerd will go into /var/log/messages by default. If you want to
 have finger daemon log to a specific file, add the following line to your
 /etc/syslog.conf file:

daemon.notice                                   /var/log/fingerd

/* !fingerd anyone? */

$ man 5 syslog.conf

 You really should not have anything other then ftp, telnet and finger
 daemons enabled in your /etc/inetd.conf file. I usually disable talk and
 and comsat as well as other services I personally have no need for. As I
 mentioned before: if you don't know what the service does or think you don't
 need it, disable it. Some man pages which you might find useful relating
 to the networking configuration are: inetd, ftpd, telnetd, fingerd, syslogd,
 comsat, talkd, rshd, rlogind, and inetd.conf. Make sure to look at the
 "SEE ALSO" section of the man page for related information.


   o ipfw (IP FireWall)

 IP Firewall does packet filtering: Nothing more, nothing less. However,
 you should consider compiling support for ipfw into your kernel. I usually
 compile support for ipfw on most of my machines, HOWEVER, on most my kernel
 config looks like this:

options         IPFIREWALL              #finger the net
options         IPFIREWALL_VERBOSE      #log the net
options         IPFIREWALL_DEFAULT_TO_ACCEPT
 
 first line includes basic IP Firewall support. Second line configures ipfw
 to be able to log accepted or rejected packets. Third line is very
 important. It does exactly what it says: accept any connections and packets
 from anywhere by default. If you don't do this, ifpw will deny everything
 by default. I like to have ipfw built into the kernel just in case, but I
 don't like to deny everything by default on my personal workstation or for
 example a shell server.

********** NOTE ************
 DO NO USE THIS OPTION UNLESS YOU KNOW WHAT YOU ARE DOING!!!
 This is not the correct approach to firewall configurations. Everything
 should be denied by default. DO NOT add

options         IPFIREWALL_DEFAULT_TO_ACCEPT

 if you are building a secure system or production firewall. Make
 sure everything is denied by default first and then add rules to allow
 connections/packets on a case by case bases. See /etc/rc.firewall more info.
 AGAIN: Do not use this options unless you just like to have ipfw built into
 the kernel to deny occasional DoS attacks or block certain ports/network
 temporarally.
*****************************

 One should take a closer look at /etc/rc.firewall for possible examples
 and basic firewall setup. See URL at the bottom for FreeBSD ipfw config
 page.
 
       
   o log_in_vain


 You can also change some useful kernel variables through sysctl command:

# sysctl -w net.inet.tcp.log_in_vain=1
# sysctl -w net.inet.udp.log_in_vain=1

 This will provide you with logging of attempted connections to your box
 to the port which does not have a server running to it. For example,
 if you do not have DNS server on your computer and someone would try
 to use your computer as DNS you would see a message such as:

Connection attempt to UDP yourIP:53 from otherIP:X
(where X is some high port #)

 This will be seen with "dmesg" command. dmesg displays the system's
 kernel message buffer. However, this buffer only can store limited
 amount of information and hence this also gets logged to the messages
 file in /var/log directory:

# tail -1 /var/log/messages
Jun 12 19:36:03 ugh /kernel: Connection attempt to UDP yourIP:53 from otherIP:X


   o Final notes


 Now you should in theory have your machine a little more secure than when
 you just installed it. A few things you can do now to verify that everything
 you did above worked are:

$ netstat -na | grep LISTEN

 this will tell you which ports have services waiting for a connection. The
 less you have, the better :) Also, run different port scanners (strobe, nmap)
 to find out what ports you have open.
 And also make sure syslog is actually logging everything you want it to:

# cd /var/log
# tail -10 fingerd ftpd messages

 If you don't see anything in your logs, make sure that you have restarted
 both inetd and syslogd processes:

# kill -HUP `cat /var/run/syslog.pid` `cat /var/run/inetd.pid`

o Filesystem

 Since Unix considers everything a file, it is very important to properly
 protect your filesystem. This process starts before installing the OS
 itself: you need to calculate and design your partition layout. There are
 a few main reasons for doing so. One is that you can mount different
 filesystems with different options (some examples below). Another is that
 if you want to export a filesystem, you will have a more granular control.
 If you are coming to FreeBSD from the Linux world you will notice that
 while Linux puts everything under one root partition "/", FreeBSD by default
 gives "/", "/usr" and "/var". This makes it easy to use programs like
 dump also. But there are security advantages as well. One of the things I
 usually do is try to separate partitions where users will be able to write
 so that they can be mounted "nosuid". From the mount man page:

            nosuid  Do not allow set-user-identifier or set-group-identifier
                    bits to take effect.  Note: this option is worthless if a
                    public available suid or sgid wrapper like suidperl is
                    installed on your system.

 Hence you would have one partition for user directories: /home or /usr/home
 Then you could also create separate partition for /var/tmp and then
 point your /tmp to it:

 # rm -rf /tmp
 # ln -s /var/tmp /tmp

 For example, you then could have something like:

 # cat /etc/fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/sd0s1b             none            swap    sw              0       0
/dev/sd0s1a             /               ufs     rw              1       1
/dev/sd0s1g             /usr            ufs     rw              2       2
/dev/sd0s1h             /usr/home       ufs     rw,nosuid       2       2      
/dev/sd0s1f             /var            ufs     rw              2       2
/dev/sd0s1e             /var/tmp        ufs     rw,nosuid       2       2
proc                    /proc           procfs  rw              0       0

 At this point you need to make sure all the directories where users can
 write are either mounted "-nosuid" or have been chmod'ed in such way that
 not anyone can write to them. By default FreeBSD will have only one you
 should be concerned with: /var/spool/uucppublic
 You can either mount your "/var" filesystem "-nosuid" or just issue

 # chmod o-w /var/spool/uucppublic

 If you want to find all your writable directories, issue:

 # find / -perm -0777 -type d -ls

 As the man page points out, having an suid/sgid wrapper will make mounting
 your other filesystems nosuid useless. Find out what files are installed
 on your system as suid or guid. To do that use find(1):

 # find / -perm -2000 -ls
 # find / -perm -4000 -ls

 Also, you can simply not use the "-ls" switch to get a more compact output
 One of the things you might do is to "chmod 000" binaries you will never
 ever find useful. Some examples would be uustat, uucico (even getting uid
 of uucp is not good) if you never touch uucp. Or ppp and pppd if you never
 will do anything PPP related on the system. If you will never do ANY printing
 you can safely chmod to 000 lpr, lprq, lprm. Maybe one day someone will
 implement a simple shell script which based on a series of questions will
 chmod your system for you.

 At this point you might be asking what can stop an attacker from simply
 unmounting and then mounting the filesystem without "-nosuid" flag?
 Well, nothing, unless you change securelevel.

o Securelevel

 BSD kernel has a notion of securelevel. While some argue that it is not
 as perfect as it could be, it will do the job most of the time to stop
 your average "script kiddiez". Securelevel is simply the level with which
 your kernel runs - each level implementing different protections and checks.
 This is taken from the init(8) man page:

     The kernel runs with four different levels of security.  Any superuser
     process can raise the security level, but only init can lower it.  The
     security levels are:

     -1    Permanently insecure mode - always run the system in level 0 mode.

     0     Insecure mode - immutable and append-only flags may be turned off.
           All devices may be read or written subject to their permissions.

     1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted filesystems, /dev/mem, and
           /dev/kmem may not be opened for writing.

     2     Highly secure mode - same as secure mode, plus disks may not be
           opened for writing (except by mount(2))  whether mounted or not.
           This level precludes tampering with filesystems by unmounting them,
           but also inhibits running newfs(8) while the system is multi-user.

     If the security level is initially -1, then init leaves it unchanged.
     Otherwise, init arranges to run the system in level 0 mode while single
     user and in level 1 mode while multiuser.  If level 2 mode is desired
     while running multiuser, it can be set while single user, e.g., in the
     startup script /etc/rc, using sysctl(8).

 For example, if all your system does is web serving, you can safely set
 your securelevel to 2. However, if you are running an X server, setting
 your securelevel to 1 or higher will cause you problems because X server
 needs to open /dev/mem and /dev/kmem for writing, and securelevel of 1
 prevents doing so. One way around this is to set your securelevel after
 you start your X server, but IMHO if you are running X server you already
 have other security issues to worry about then kernel securelevel.
 To find out what your current securelevel is:
 
 # sysctl kern.securelevel  To raise your securelevel:

 # sysctl -w kern.securelevel=X

 where X is 0, 1 or 2.

 You will also have problems upgrading your system with "make world" and
 when rebuilding the kernel if you are running with securelevel of 1 or
 higher. This is because by default "make install"  will install your kernel
 with the system immutable flag:

 # ls -lo /kernel
-r-xr-xr-x  1 root  wheel  schg 1061679 Jun 30 01:27 /kernel

 That "schg" is what will prevent you from installing a new kernel:
 
 nfr# id
 uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem)

 nfr# sysctl kern.securelevel
 kern.securelevel: 2

 nfr# rm -rf /kernel
 rm: /kernel: Operation not permitted

 nfr# mv /kernel /tmp/
 mv: rename /kernel to /tmp//kernel: Operation not permitted

 If you are running in securelevel of 1 or 2, this flag may not be turned off:

 # chflags noschg /kernel
 chflags: /kernel: Operation not permitted

 It should be noted however that file /boot.config can be used to change
 kernel used at system boot-up. To prevent this, one should:

 # touch /boot.config
 # chflags schg /boot.config

 By default you will also have some binaries installed with schg flag set
 on your system:

 # ls -lo /sbin | grep schg
-r-x------  1 bin   bin       schg 204800 Jul 19 20:38 init
 # ls -lo /bin | grep schg
-r-sr-xr-x  1 root  bin       schg 192512 Jul 19 20:36 rcp

 But back to locking down your system. Since we are talking about system
 immutable flags, one might consider running chflags schg on the whole
 /sbin and /bin tree. This will make it harder for someone to backdoor
 your system with a "rootkit" (considering that you are also running with
 appropriate securelevel)

 # chflags schg /bin/*
 # chflags schg /sbin/*

 Since /sbin can be moved out of the way and new /sbin can be created,
 it also makes sence to chflags both /sbin and /bin if you did the above:

 # chflags schg /bin ; chflags schg /sbin

 Doing a lot of changes to file flags is bound to and will in turn cause
 problems with "make world".                     
 
 It is best to do "make world" in single user mode anyway. For more       
 information on "make world" and reasons why see:

 http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html
 
 At this point you should have your system reasonably locked down with
 very few services running, filesystems mounted the way they should
 and with appropriate kernel securelevel.

 Man pages related to the above topics: init(8), chflags(1), sysctl(8)


o Logging

 Logging is very important. It might provide you with clues that you are
 under attack, that attempts to break in have been made or that your
 system has been broken into. Standard Unix logging is done through syslog
 daemon, syslogd(8). This daemon is started upon boot up from /etc/rc
 and then keeps on running until you shut down your system.

 $ ps -axu | grep syslogd

 Syslog daemon reads configuration from /etc/syslog.conf file when it starts.
 This file is very important as it tells syslog what to log and where.
 You will probably want to read man pages for both syslogd and syslog.conf:
 
 $ man syslogd ; man 5 syslog.conf

 Since Unix is designed around networking, syslog daemon can and will
 by default accept syslog datagrams from other systems. It in turn can itself
 send datagrams to other computers on the network also. And of course it
 can log everything locally - which is the default. Since syslog daemon
 uses UDP - datagrams can be forged. One thing you can do is to tell your
 syslog daemon NOT to listen to syslog daemon from other systems by running
 your syslog daemon in secure mode. To do so, add "-s" switch in your
 /etc/rc.conf file:


 If you need your system to accept syslog datagrams from another devices
 (such as your router, our your web server), use "-a" switch to allow
 specific hosts, domains or subnets.
 Next time you reboot your system, syslogd will be running with "-s" switch
 and when someone will send datagrams to your syslogd over the network you
 will see the following in your logs:


 If you don't want to reboot your system, simply kill -9 your syslog daemon
 and start it as root with "-s" switch.
 This is all nice and fine if all the attacks against your system fail and
 your syslog files are left uncompromised. But what if you actually were
 broken into and an attacker erased your /var/log directory? There are many
 ways to prevent this. One way is to set up a machine on your network which
 will do syslog logging for your whole network and NOTHING else. It will have
 no ports open except for UDP port 514 (syslogd). This way you can have all
 of your systems (routers, firewalls, server, workstation) send critical (or
 whatever you chose) information to this one machine. This can be an
 old 486 computer with a lot of disk space. Make sure to give correct options
 to the "-a" switch if you dedicate a system for syslogd. You can also connect
 an old line printer to your system and have syslog send certain information
 to the printer (failed logins, etc). If it is on the paper, it will be very
 hard for an attacker to erase the logs (unless she is works in the same
 place). Other options includes sending all your syslogd messages to another
 computer connected with a serial (cuaaN) or parallel (lpN) port cable.

 Everyone will have different needs as to what they want to log. However,
 one thing I usually do is to add to the syslog.conf file the following line:

auth.*                                  /var/log/authlog

 FreeBSD comes with something called newsyslog. This program will rotate
 your logs for you so they don't grow big or take all your hard drive.
 The configuration file is /etc/newsyslog.conf - please take a look at the
 man page for more information:

 % man newsyslog

 Unlike syslogd, newsyslog is not always running on your system, but is rather
 started from crontab:
 
 % grep newsyslog /etc/crontab
0       *       *       *       *       root    /usr/sbin/newsyslog
 %

 You should modify /etc/newsyslog.conf to your needs. I usually change the
 default mode of 664 for some files to 640 - the reason is that there is no
 reasons for users to read your logs. You should also (as root) do the following

 # cd /var/log
 # chmod g-w,o-r * ; chmod a+r wtmp

 This will prevent your users from reading the log files, unless they are in
 the appropriate group (such as wheel or something else). You should probably
 make all your log files owned by group wheel -- this purely for convenience:
 if you are in group wheel, most likely you can su(1) to root and read log
 files anyway - this way you just don't have to su(1) one extra time.
 You will also have to add "root.wheel" to your /etc/newsyslog.conf file:
 
 /var/log/maillog        root.wheel      640  7     100  *     Z
 /var/log/authlog        root.wheel      640  7     100  *     Z
 /var/log/messages       root.wheel      640  7     100  *     Z

 This will rotate files when they reach size of 100K, gzip them, rotate
 old files, chmod to 640 and chown to root.wheel - exactly what we want.

 There are a also a few alternatives to the standard Unix syslog:
 One is ssyslog (secure syslog) from CORE SDI and is located at:
 http://www.core-sdi.com/ENGLISH/CoreLabs/ssyslog/download.html

 Another is nsyslog (new syslog) from the people who brought you ipfilter
 and is located at: http://cheops.anu.edu.au/~avalon/nsyslog.html

 To go with any of the above (standard syslog, ssyslog or nsyslog) one
 should probably also take a look at some utilities which will analyze
 log files for you, saving you the trouble of running grep yourself.
 One is called logcheck and is available from
 http://www.psionic.com/abacus/abacus_logcheck.html
 Another similar package is called logsurfer and you can download
 it from http://www.cert.dfn.de/eng/team/wl/logsurf/

o Misc. hints and tips

 o LKM
 
 One might want to disable use of LKM's on a production system. Why? See:
 Phrack Magazine   Volume 7, Issue 51 September 01, 1997, article 09
 To disable LKMs, add the following line to your kernel:

 options        NO_LKM

 to your kernel configuration file.

 o Portmap

 By default FreeBSD comes with portmapper enabled. If you don't have a need
 for it: disable it. You will not have a need for portmap daemon if you are not
 using any programs which require RPC. To disable the portmap, edit
 /etc/rc.conf and replace:

 portmap_enable="YES"             # Run the portmapper service (or NO).

 with

 portmap_enable="NO"             # Run the portmapper service (or NO).

 o Sendmail

 By default FreeBSD ships with sendmail enabled. In the past sendmail was
 known for weak security. Lately people working on sendmail did a great job
 in cleaning up the code, but due to the size of sendmail's source it is
 no an easy thing to do. In other words: turn off sendmail also if you don't
 need it. If you do need to use sendmail, check with http://www.sendmail.org
 for patches and different hacks. Also, if you are running sendmail 8.8 please
 make sure that spammers can not use your system to relay spam.
 See http://www.sendmail.org/antispam.html for more information on anti-spam.
 To turn off sendmail in FreeBSD simply edit /etc/rc.conf (yes, again) and
 change:
 
 sendmail_enable="YES"   # Run the sendmail daemon (or NO).

 to
 
 sendmail_enable="NO"   # Run the sendmail daemon (or NO).

 o Ports and Packages

 It is best not to use ports or packages when building a secure system.
 You don't really know which ports or packages will install suid-root
 binaries on your system -- and you don't want more then what you have
 already, trust me. Even though you can give different switches to the
 pkg_add command (such as "-v" or "-n"), it is best to download the software
 in source code form and compile it yourself.

 o Filesystem quota

 If you are running a "shell" type server, you might want to consider using
 quotas on the user filesystem (such as /usr/home for example). This can
 protect you from Denial of Service attack (accidental or not) of a random
 user filling up the whole filesystem. To enable quotas, modify the line in
 /etc/rc.conf from:

check_quotas="NO"       # Check quotas (or NO).

 tocheck_quotas="YES"       # Check quotas (or NO).

 Please also take a look at the following man pages for more information
 and examples of how to use quotas: quotaon, edquota, repquota, quota
 Make sure to add "userquota" to your /etc/fstab: man 5 fstab

 o Crontab

 If you are using /etc/crontab to run jobs which can give someone extra
 information about your system, make sure to "chomd 640 /etc/crontab"

 o BPF

 BPF stands for berkeley packet filter and is required to be in the kernel
 if you want to perform network sniffing. Programs such as tcpdump or NFR
 use BPF all the time. However, program which sniff the network from BSD
 systems also use BPF. If someone does manage to get root on your system,
 having BPF in the kernel will make sniffing of your network much easier for
 them. Don't compile BPF into the kernel if you won't have a need for it. By
 default FreeBSD's kernel does not support BPF.

 o CVSup, CVS, etc.

 If you installed your system from a CD-Rom, chances are that by the time the
 code was frozen to the time you got your CD in the mail, some bugs were
 discovered. Most likely (or so we all hope), they were not security bugs.
 Yet, I would recommend upgrading your system to the latest -current (or
 -stable: whichever one you follow) source. Doing this you will know that
 you are running up-to-date OS. For more info see:

 http://www.freebsd.org/handbook/handbook264.html#508

 A very good documentation on how to "make world" after you got the latest
 source can be found at:
 http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html

 o SSH

 I can't stress enough how important it is to use SSH instead of telnet, ftp,
 rlogin, rsh, etc. For people who are on slow speed lines (dial-up, 56K frame)
 ssh has -C option: [man page quote]

      -C     Requests compression of all data (including  stdin,
              stdout,  stderr,  and  data  for  forwarded X11 and
              TCP/IP connections).  The compression algorithm  is
              the  same used by gzip, and the "level" can be con-
              trolled by the CompressionLevel option (see below).
              Compression  is  desirable on modem lines and other
              slow connections, but will only slow down things on
              fast  networks.   The default value can be set on a
              host-by-host basis in the configuration files;  see
              the Compress option below.

 This will "make your ssh connection faster" :) In other words, just use SSH.
 Please, PLEASE use ssh. If you won't, then no security will help you.
 

 o Related URLs:

 FreeBSD Hardening Project:
 http://www.watson.org/fbsd-hardening/

 FreeBSD ipfw Configuration Page:
 http://www.metronet.com/~pgilley/freebsd/ipfw

 FreeBSD Security advisories:
 ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/

 FreeBSD Security web page:
 http://www.freebsd.org/security/security.html

 Security tools in FreeBSD:
 http://www.samag.com/archive/0705/feature.html

 o Thanks!

 I would like to thank the cast of many for help with this work-in-progress.
 Your comments, support and feedback made it possible.
 Special thanks to Chris Peiffer for english grammar and spelling editing.

© 1997 - 20013 Defcon1, www.defcon1.org , Copyrights for all materials on this web site are held by the individual authors, artists, photographers or creators. Materials may not be reproduced or otherwise distributed without permission of www.defcon1.org and the content's original author.

Defcon1-Header2
Tool-Bar-2Defcon1  Webmail