DALnet Security Evaluation - FreeBSD
# $Id: testnet-seceval-fbsd.txt,v 1.10 2002/05/26 04:14:01 tbaur Exp $

===========================================================================
Security HOW-TO, FreeBSD 4.x-STABLE

	DALnet Security Evaluation
===========================================================================
 
Prepared by: 	Tim Baur 
Based on: 	A basic guide to securing FreeBSD 4.x-STABLE 
          	written by Marc Silver 

  ==> Document Status: 	PUBLIC - release (v1.10)

	The DALnet IRC Network

INSTRUCTIONS:

Review this document. I suggest you read it once (or twice if need be) in
its entirety, then go back and start making changes to your system. If,
while in the process of following this guideline, you run into questions,
please feel free to contact either testnet@dal.net or the person in charge
of doing the evaluation on your server. When you have completed these
changes to your server, send an email to testnet@dal.net, a meeting will
be scheduled with the staff member responsible for your evaluation.

===========================================================================


Table of Contents:

  ==> Overview

  ==> The Foundation for a secure system
      -> File System Layout

  ==> Post Installation
      -> System Secure Levels
      -> Removal of the toor user
      -> Shut down services that you dont need/want
         -> syslogd
         -> portmap
         -> telnetd
         -> sshd
         -> inetd
         -> ftpd
      -> suid/sgid Binaries
      -> Log in vain
      -> Blackhole
      -> Route Cache
      -> Crontabs
      -> Secure the console
      -> Process accounting
      -> IP Filtering
      -> Mail aliases
      -> DNS / DNS Resolver
      -> Network Time Protocol

  ==> Kernel/sysctl changes
      -> Disable bpf if you dont need it
      -> Network Limits
      -> kern.maxfiles
      -> kern.ipc.somaxconn
      -> net.inet.tcp.*space
      -> net.inet.tcp.always_keepalive
      -> Disable Ctrl-Alt-Del
      -> Quota Support

  ==> Managing user accounts
      -> User quotas
      -> Home directory permissions
      -> Hiding processes
      -> Disabling procfs
      -> login.conf(5)

  ==> Stay up to date
      -> Keep your packages current
      -> Keep your OS current

  ==> Be Vigilant

  ==> Other documents about FreeBSD Security

  ==> Thanks


Overview
========

The word security means different things to different people. While this
document covers various aspects and suggests things that can be done to
secure default installations of FreeBSD, it is is by no means an
authoritive guide to securing FreeBSD. It merely discusses a model that
DALnet requires be used on machines that are linked to the network and one
that we have had great success with.

For a broader look at security on FreeBSD and as a primer to this
document, I would suggest that everyone read the man page for security(7)
on their FreeBSD system.


The Foundation for a secure system
==================================

A system should be set up to be secure from the very beginning. There are
a number of things that can be done during the FreeBSD installation that
can save you serious headaches later. In my opinion, file system setup can
make a big difference in cases where you can (and must) assume that the
attacker already has a local login on the machine.

o  File System Layout

   The file system layout below may be used as a guideline for any
   system. Obviously, disk layout can/will differ from machine to
   machine based on the function of the machine but this should serve
   as a basic guide.

   You may adapt this to suit your own needs.

   Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
   /dev/ad0s1a    128990    31390    87282    26%    /
   /dev/ad0s1f     49583    27879    17738    61%    /tmp
   /dev/ad0s1d  12348393  2563101  8797421    23%    /usr
   /dev/ad0s1h   4065262    97983  3642059     3%    /home
   /dev/ad0s1g   2032623     6026  1863988     0%    /var
   procfs              4        4        0   100%    /proc

   Now, let's look at the output from the mount(8) command:

   /dev/ad0s1a on / (ufs, local)
   /dev/ad0s1f on /tmp (ufs, local, nodev, nosuid, soft-updates)
   /dev/ad0s1d on /usr (ufs, local, soft-updates)
   /dev/ad0s1h on /home (ufs, local, nosuid, with quotas, soft-updates)
   /dev/ad0s1g on /var (ufs, local, soft-updates)
   procfs on /proc (procfs, local)

   Now, let's discuss why I've set things up this way.

   The root partition (/) is a reasonable 128MB, (as recommended in the
   tuning(7) man page) and is home to the kernel as well as KLD's and
   various other fairly important directories which are linked directly
   off it (/sbin is just one that comes to mind). With this in mind,
   it's possible at a later stage to mount the root partition as
   read-only by editing the flags for this partition in the fstab(5)
   file.

   Temporary files are stored in /tmp, and since this directory is
   usually world writeable, it's important to not allow certain files to
   be used from this directory. Using the fstab(5) file (also see
   mount(8)) you should add the NOSUID and NODEV flags for /tmp which
   disables suid programs and stops character or block special devices
   on the filesystem. You may also want to add the NOEXEC flag for
   /tmp, but this is severely restrictive and may begin to make things
   difficult for your users. NOEXEC will also cause problems when you
   'make installworld', since a fairly normal /tmp is required for this.
   Enabling NOEXEC may also limit your ability to find an intruder.
   It's important to note that you should symlink /usr/tmp and /var/tmp
   to this /tmp partition, else you're still giving users a tmp
   directory with no restrictions.

   User specific directories are kept in /home and on this partition
   it's a good idea to add the NOSUID flag, as well as adding QUOTA
   support to limit the amount of disk space that your users may use.

   Both /usr and /var are standard partitions with soft-updates enabled.

   You may choose to also disable procfs.  See 'Disabling procfs' for
   more information.

   This model can obviously be changed to suit your needs, and you can
   be even more anal if you wish. This however, is intended to strike a
   happy medium between security and usability.


Post Installation
=================

Once your FreeBSD system has been installed there are a number of things
that can be done to help harden the machine.

o  System Secure Levels

   Security levels are at the core of FreeBSD security. They are
   extremely powerful and are essential in securing FreeBSD.

   For most machines there is absolutely no reason to run in securelevel
   -1, unless you wish to run X-Windows on the machine. You're not
   running X-Windows, you're running an IRC server. You fail the security 
   evaluation if you are running in securelevel 0 or -1.

   -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.
 
   3	Network secure mode - same as highly secure mode, plus IP packet  
	filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and
	dummynet(4) configuration cannot be adjusted.
         
   DALnet recommends servers run in at least securelevel 1.

   sysctl kern.securelevel=1

   To make this change more permanent, add the following to
   /etc/rc.conf:

   kern_securelevel_enable="YES"
   kern_securelevel="1"

o  Removal of the toor user

   By default, FreeBSD ships with an additional user that has a UID of 0.
   This user is known as toor (root backwards), and is intended as a
   backup user, so that if you mistakenly broke (for eg) root's shell, you
   could log in using this user and fix things. The account is disabled
   (passwordless) by default, and hence of no use UNLESS you change it's
   password. You may either choose to set a password for it, or remove it.
   DALnet suggests you remove this account.

   It should be noted that the rmuser(8) command will not allow the
   deletion of an account with a UID of 0, so you will need to use
   vipw(8) to remove this account.

o  Shut down services that you dont need/want

   It's important to not have any non-essential services running on the
   machine, or any services that you dont recognise. The best thing to
   do is kill all the services running on your machine and then
   explicitly enable those that you want running. This way you know for
   sure what's running on your machine. You can tell what TCP ports are
   open on your machine by using the netstat(1) command.  eg:

   secure-me (1) :  netstat -na | grep LIST
   tcp4       0      0  *.80                   *.* LISTEN
   tcp4       0      0  *.25                   *.* LISTEN
   tcp4       0      0  *.22                   *.* LISTEN

   This shows that ports TCP ports 22 (ssh), 25 (smtp), and 80 (http)
   are listening on this machine and are bound to all IP's. If you have
   a process listening and you're unsure of what process is keeping that
   port open you may use sockstat(1) to list open sockets and provide
   you with the relevant information.

   Use rc.conf(5) to easily configure which services start up by
   default, as well as local package init scripts which can be found in
   /usr/local/etc/rc.d

   Similarly you may wish to see if you have anything listening via UDP.
   You can also get this information via netstat(1):

   secure-me (2) :  netstat -na | grep -i udp
   udp4       0      0  *.514                  *.*

   Here, you see that syslogd is listening on port 514 (UDP).

   I will now discuss some common services and what you can do to better
   secure them.
   
   - syslogd ::
     syslogd will by default bind itself to UDP 514, but you can prevent
     this from happening by adding a second '-s' flag to syslogd's
     command line on startup. This prevents syslogd from using network
     sockets and can be done by simply adding the following line to
     /etc/rc.conf :

     syslogd_flags="-ss"
   
     See the syslogd(8) man page for more information.

   - portmap ::
     portmap is used for remote procedure calls and its most common
     application in FreeBSD is for use with NFS. To disable portmap add
     the following line in your /etc/rc.conf:

     portmap_enable="NO"

   - telnetd ::
     This service should be avoided at all costs. While telnet is
     useful, there is just no excuse to use it anymore. All data
     transferred across a telnet session is transmitted in clear text
     (including usernames and passwords). This should be disabled,
     either by killing inetd(8) completely, or by removing the telnetd
     line from /etc/inetd.conf. If you MUST run this service, then look
     at using something like login.access(5) or ipfw(8) to limit where
     connections to this service may come from.

     FreeBSD comes standard with sshd(8), a drop-in replacement for
     telnetd with far superior security built in.

   - sshd ::
     FreeBSD (since 4.1.1) now comes with OpenSSH as part of the base
     system, and sshd(8) is a perfect drop in replacement for telnetd,
     while remaining more secure by using encryption to protect your
     session. The protocol also allows for stronger encryption with the
     use of RSA/DSA keys.

     The use of OpenSSH is required by DALnet. The most current upto date
     version must be installed. Access to the SSH port must be firewalled.
   
     It should be noted that the most current versions of OpenSSH now
     use SSH protocol version 2, protocol version 1 should be disabled.
     This can be done by making sure the following line exists in
     /etc/ssh/sshd_config:

     Protocol 2

     This will tell the sshd that it should only allow incoming SSH2
     connections - and it will not fallback to version 1. Please note
     that you may need to restart the sshd in order for this change to
     take effect.  
   
     Similarly, you should also make sure that all outbound SSH
     connections are using SSH2 by default, and then failing back to
     SSH1. This can be done by editing /etc/ssh/ssh_config

     For more information on OpenSSH, and how to used it effectively,
     please visit http://www.openssh.com/

   - inetd ::
     inetd is designed to listen for connections on certain sockets. It
     is used for popular applications like telnetd(8), qpopper and
     ftpd(8). Since you won't be running any inetd applications, disable 
     the daemon by adding the following line to /etc/rc.conf :

     inetd_enable="NO"

     ftpd ::
     You should not be running ftpd either via inetd or standalone. 

     smtp ::
     You should not be running an smtp server. Sendmail should be disabled 
     by adding the following line to /etc/rc.conf :

     sendmail_enable="NO"

o  suid/sgid Binaries

   On an IRC server, you won't have a real need for suid/sgid bins. It is
   highly suggested one of the things you might do is to "chmod 000"
   binaries you will never ever find useful. Some examples would be
   uustat, uucico or ppp and pppd. They are not needed. There is a utility
   suidcontrol which will help you to set a system wide suid/sgid policy.
   Those binaries you expect to use (like ping or traceroute) can have
   their suid/sgid bit removed via "chmod a-s" or "chmod o-rwx" to allow
   only users in the wheel group access. Run the following commands to 
   find suid/sgid binaries on your system:

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

   NOTE: A list of suid/sgid binaries will be asked for during the 
   security evaluation.

o  Log in vain

   Even though you've now disabled many services, you should log
   connection attempts to ports without listeners/daemons. To do this
   simply add the following line to /etc/rc.conf:

   log_in_vain="YES"

   To change this without rebooting your server issue the following
   commands:

   sysctl net.inet.tcp.log_in_vain=1 
   sysctl net.inet.udp.log_in_vain=1

   Now, failed connection attempts to ports without listeners will be
   recorded to /var/log/messages.

o  Blackhole 

   FreeBSD also allows you the option to blackhole any TCP/UDP traffic
   that is bound for ports without daemons/listeners. Instead of
   logging the connection like 'log in vain' does, it ignores the
   packet, thereby creating a blackhole into which packets dissapear.
   The man page for this feature also states that this could potentially
   slow down DoS attacks aimed at your system. The Blackhole MIB can be
   easily enabled by issuing the following commands:

   sysctl net.inet.tcp.blackhole=2
   sysctl net.inet.udp.blackhole=1
   
   It should be noted that enabling blackhole for UDP will prevent
   people from being able to traceroute(8) to your system. The TCP
   value may also be increased to 2. For more information, please see
   the blackhole(4) manpage.

   To make these changes permanent, add the following lines to
   /etc/sysctl.conf:

   net.inet.tcp.blackhole=2
   net.inet.udp.blackhole=1

   It should also be noted that this is NOT a replacement for ipfw/ipf.

o  Route Cache

   Spoofed packet attacks may also be used to overload the kernel route
   cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache
   sysctl parameters. A spoofed packet attack that uses a random source IP
   will cause the kernel to generate a temporary cached route in the route
   table, viewable with netstat -rna | fgrep W3. These routes typically
   timeout in 1600 seconds or so. If the kernel detects that the cached
   route table has gotten too big it will dynamically reduce the rtexpire
   but will never decrease it to less than rtminexpire. There are two
   problems:
         
	1. The kernel does not react quickly enough when a lightly loaded
	server is suddenly attacked.
	2. The rtminexpire is not low enough for the kernel to survive a
	sustained attack.
 
   sysctl net.inet.ip.rtexpire=2 
   sysctl net.inet.ip.rtminexpire=2 
 
   To make these changes permanent, add the following lines to
   /etc/sysctl.conf:

   net.inet.ip.rtexpire=2 
   net.inet.ip.rtminexpire=2 

   Never set either parameter to zero (unless you want to crash the
   machine). Setting both parameters to 2 seconds should be sufficient to
   protect the route table from attack.

o  Crontabs

   Firstly, there are certain files which you may generally not want
   users looking at. The crontab of the root user is a perfect example.
   You can safely chmod /etc/crontab to 0640 so that only root and users
   in the wheel group can see it. Your users do not need to know what
   jobs are started by cron.

   At the same time, you may not want to allow users to use crontab(1)
   at all. You can easily stop them by creating /var/cron/deny and
   adding a list of users to that file. Those users will then be told:

   crontab: you (marcs) are not allowed to use this program

   Similarly, you may also create a /var/cron/allow and only add users
   that should be allowed to use crontab to that file. For more 
   information, please see the crontab(1) man page.

o  Secure the console

   Many people are concerned that a malicious user with physical access
   could simply reboot into single user mode and change the root
   password. While it's quite clear that if an attacker has physical
   access to your machine, NOTHING you do can keep it safe, you can
   prevent people from simply changing the root password in single user
   mode by performing one simple step. This can be done by editing
   /etc/ttys and changing the the word 'secure' on the 'console' line to
   'insecure'. This will require you to enter the root password when
   dropping into single user mode. Your line will then look like this:

   console none                            unknown off insecure

   You should also be aware that if you do this, and you somehow lose
   the root password, you will have to use a fixit floppy to reset the
   password, because dropping into single user mode will NOT allow you
   to change the password.  

o  Process accounting

   It's nice to know exactly what's happening on your machine and to
   this end I would suggest enabling process accounting on any machine
   that you run. This enables you to see what commands users are
   executing, and it can also be useful when debugging certain problems.
   It does add some slight overhead, but generally you shouldn't notice
   degraded performance. To enable, merely execute the following
   commands:

   secure-me (1) :  touch /var/account/acct
   secure-me (2) :  accton /var/account/acct

   To make this change more permanent, add the following line to
   /etc/rc.conf:

   accounting_enable="YES"

   Once accounting is enabled, you can then use the lastcomm(1) and
   sa(8) commands to get meaningful statistics from the process
   accounting database.

o  IP Firewalling (packet filter)
 
   There are two packages which can be used under FreeBSD. IP Filter and
   IP Firewall. Both handle packet filtering: Nothing more, nothing less.
 
   While it is beyond the scope of this document to outline how to fully
   configure each application, you may wish to secure the machine further
   as well as gain information on attack patterns on your machine using
   IP Filter or IP Firewall. There will come a time when you'll want to
   filter something on the machine as a quick fix to a more perm solution.
   
   We'll try to provide a quick outline..
 
   Once you decide which packet filter to use, support must be compiled
   into your kernel. I usually compile support for IP Filter on most of my
   machines, kernel config looks like this:
 
   options         IPFILTER                #ipfilter support 
   options         IPFILTER_LOG            #ipfilter logging
 
   For IP Firewall: 
 
   options         IPFIREWALL              #firewall 
   options         IPFIREWALL_VERBOSE      #firewall logging 
   options         IPFIREWALL_VERBOSE_LIMIT=100    #limit verbosity

   Local packet filtering =may= not required, depending on the network
   filtering. However, if nothing eles it should be compiled in, default
   to accept. 

   Under IP Filter, I also suggest including the following in your default
   configuration:
 
        block in log all with frag 
        block in log proto tcp all with short
        block in log all with ipopts
        block in quick all with opt lsrr
        block in quick all with opt ssrr 
 
   A similar config would also exist for IP Firewall. Each packet filter
   can be enabled via /etc/rc.conf:
 
   IP Filter: 

	ipfilter_enable="YES"
	ipfilter_program="/sbin/ipf"
	ipfilter_rules="/etc/ipf.conf"
	ipfilter_flags=""
	ipmon_enable="YES"
	ipmon_program="/sbin/ipmon"
	ipmon_flags="-D /var/log/ipflog"

   IP Firewall: 
 
	firewall_enable="YES"
	firewall_script="/etc/rc.firewall"
	firewall_type="client"
	firewall_quiet="NO"
	firewall_logging="YES"
	firewall_flags=""
 
   NOTE: A review of the IP Filter or IP Firewall rulesets will be
   requested.

o  Mail aliases

   It's important to make sure that you're being notified of anything
   that's happening on your system. FreeBSD has many scripts that are
   triggered on a daily/weekly/monthly basis (see the man page for
   periodic(8) and take a look at /etc/periodic for more information)
   that contain information about your system such as SUID program
   changes, kernel messages and other useful information. For this
   reason it is important to get these mails. The output of these
   scripts are sent to the root account, but you may choose to send the
   output to multiple addresses. To do this, edit /etc/mail/aliases and
   add a line similar to this:

   root:   localuser, remoteuser@yourdomain.com

   This means that not only is the local administrator getting a copy,
   but you're also mailing the output to a (hopefully anyway) seperate
   mail server where it is theoretically out of harms way.

   PLEASE NOTE: The sendmail daemon does NOT have to be enabled for daily 
   runs to be delivered locally or remotely. There is no need for a local
   smtp daemon on the IRC server.

o  DNS / DNS Resolver

   There have been cases of DoS/DDoS against DNS servers which are used by
   the IRC servers. This causes the IRC daemon to be unable to resolve DNS
   which also slows down client connections. While you are free to use the
   resolver of your choice (with the assumption it is running current code
   (this is =your= responsibility)), hosting a local resolver on the box
   bound to 127.0.0.1 is strongly advised. There is some overhead
   involved, mainly ram as the cache builds, but there are benefits.
 
   This is an issue that can be addressed on a case to case basis durning
   the security evaluation.

o  Network Time Protocol

   The use of ntpd is required on all DALnet servers. Each server must
   have properly synched time. ntpd is an operating system daemon which
   sets and maintains the system time-of-day in synchronism with Internet
   standard time servers. Ordinarily, ntpd reads the ntp.conf(5)
   configuration file at startup time in order to determine the
   synchronization sources and operating modes.

   In edition to running ntpd, you will also want to get the correct
   time-of-day before starting ntpd. This is done by running ntpdate.

   To enable ntpdate add the following line in your /etc/rc.conf:

   ntpdate_enable="YES"
   ntpdate_program="/usr/sbin/ntpdate"
   ntpdate_flags="time.verio.net"

   To enable ntpd add the following line in your /etc/rc.conf:

   xntpd_enable="YES"
   xntpd_program="/usr/sbin/ntpd"
   xntpd_flags="-p /var/run/ntpd.pid"

   An example of a minimum configuration, /etc/ntp.conf:

   server  129.250.35.250  prefer  # time.verio.net
   server  143.232.55.13           # ntp.nasa.gov
   peer    132.239.1.1             # ucsd.ucsd.edu
   peer    18.72.0.3               # bitsy.mit.edu
   peer    129.7.1.66              # tick.uh.edu
 
   driftfile       /etc/ntp.drift


Kernel changes
==============

o  Disable bpf if you dont need it

   One of the first things I do when I install a FreeBSD machine is
   recompile the kernel. One of the options that I like to disable in
   the kernel is the bpf device, since this would stop an attacker from
   putting the network card of the machine into promiscious mode. This
   is useful should the machine itself is compromised. Simply comment
   out the following line in your kernel file:

   #pseudo-device   bpf             #Berkeley packet filter

   You may also want to add in the options for ipfw, ipfilter, and add
   quota support at the same time.

o  Network Limits 
 
   The NMBCLUSTERS kernel configuration option dictates the amount of
   network mbufs available to the system. A heavily-trafficked server with
   a low number of MBUFs will hinder FreeBSD's ability. Each cluster
   represents approximately 2K of memory, so a value of 1024 represents 2
   megabytes of kernel memory reserved for network buffers. A simple
   calculation can be done to figure out how many are needed. If you have
   a web server which maxes out at 1000 simultaneous connections, and each
   connection eats a 16K receive and 16K send buffer, you need
   approximately 32MB worth of network buffers to cover the irc server. A
   good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768.
 
   options	   NMBCLUSTERS=81920

o kern.maxfiles 
 
   kern.maxfiles can be raised or lowered based upon your system
   requirements. This variable indicates the maximum number of file
   descriptors on your system. When the file descriptor table is full,
   ``file: table is full'' will show up repeatedly in the system message
   buffer, which can be viewed with the dmesg command.
         
   Each open file, socket, or fifo uses one file descriptor. A large-scale
   production server may easily require many thousands of file
   descriptors, depending on the kind and number of services running
   concurrently. kern.maxfile's default value is dictated by the MAXUSERS
   option in your kernel configuration file. kern.maxfiles grows
   proportionally to the value of MAXUSERS. From this number, the kernel
   is given most of its pre-defined limits.
 
   maxusers	  512

   Example, if you wanted to hold 30,000 clients, you would compile 
   maxusers at 512, update NMBCLUSTERS and add the following into
   /etc/sysctl.conf:

   kern.maxfiles=32768
   kern.maxfilesperproc=32768

o  kern.ipc.somaxconn

   The kern.ipc.somaxconn sysctl limits the size of the listen queue for
   accepting new tcp connections. The default value of 128 is typically
   too low for robust handling of new connections in a heavily loaded web
   server environment. For such environments, we recommend increasing 
   this value to 1024 or higher. The service daemon may itself limit the 
   listen queue size (e.g. sendmail, apache) but will often have a 
   directive in its configuration file to adjust the queue size up.  
   Larger listen queues also do a better job of fending off denial of
   service attacks.

   kern.ipc.somaxconn=1024

o  net.inet.tcp.*space

   The net.inet.tcp.sendspace and net.inet.tcp.recvspace sysctls are of
   particular interest if you are running network intensive applications.  
   This controls the amount of send and receive buffer space allowed for
   any given TCP connection. The default is 16K. You can often improve
   bandwidth utilization by increasing the default at the cost of eating
   up more kernel memory for each connection. We do not recommend
   increasing the defaults because you are serving thousands of
   simultaneous connections. It is possible to quickly run the system out 
   of memory due to stalled connections building up. But if you need high
   bandwidth over a fewer number of connections, especially if you have
   gigabit ethernet, increasing these defaults can make a huge difference.
   You can adjust the buffer size for incoming and outgoing data
   separately.

   We recommend the following:

   net.inet.tcp.sendspace=8192
   net.inet.tcp.recvspace=16384

   In extreme cases you may have to turn on the net.inet.tcp.rfc1323 
   sysctl and increase the buffer size to values greater then 65535.

   Generally this will not be required. Use at your own discretion.

   net.inet.tcp.rfc1323=1

o net.inet.tcp.always_keepalive 

   We recommend that you turn on net.inet.tcp.always_keepalive. This
   introduces a small amount of additional network bandwidth but 
   guarantees that dead tcp connections will eventually be recognized and
   cleared. Dead tcp connections are a particular problem on systems
   accessed by users operating over dialups, because users often
   disconnect their modems without properly closing active connections.

   net.inet.tcp.always_keepalive=1

o kern.ipc.maxsockets

   We recommend you increase both kern.ipc.maxsockets and maxsockbuf. 
   This increases the number of sockets available and increases the socket
   buffer size. On large client servers the default limits are to low and 
   you will run into problems.

   kern.ipc.maxsockets=163840
   kern.ipc.maxsockbuf=2097152

o  Disable Ctrl-Alt-Del

   You can stop users with physical access from using the Ctrl-Alt-Del
   combination to reboot your machine. Simple add the following line to
   your kernel to disable this:

   options         SC_DISABLE_REBOOT       # disable reboot key sequence

   You should be aware that all this will really prevent is users from
   rebooting your machine. If you've also marked your console as
   insecure it'll stop people from rebooting to change the root
   password. That said, if someone has physical access and they want to
   do something malicious, you're already in more serious trouble...

o  Quota Support

   In order to enable Quota support for your filesystems, you will need
   to enable this option in your kernel. This can be done with the
   following option:

   options         QUOTA                   #enable disk quotas


Managing user accounts
======================

o  User quotas

   By enforcing user quotas on certain filesystems you can limit the
   damage that an attacker who wants to consume disk space can do.
   Enforce quotas wherever possible to prevent users from filling your
   disks. This also gives you the added advantage of being able to
   manage your disk usage more effectively.

   Quota's can only be used if you have compiled support for them in the
   kernel.  Once you've done this, you will need to add the following
   lines in /etc/rc.conf:

   enable_quotas="YES"
   check_quotas="YES"

   You may then use edquota(8), quotacheck(8), quotaon(8), quotaoff(8)
   and repquota(8) to manage quota filesystems.

o  Home directory permissions

   You should be aware of what it is your users can see. Just as you
   dont want users to be able to see what is in root's crontab you may
   also not want them to view what is in root's directory. A quick
   'chmod 0750 /root' will make sure that they can't see the contents
   unless they're in the wheel group.

   To that end, you may also want to restrict user home directories by
   setting their permissions to 0700 by default. This way users will
   have to explicitly change their directory permissions in order for
   other users to view their directory contents.

o  Hiding processes

   You can also limit what processes a user can see when using the ps(1)
   command. By default, FreeBSD will allow users to see all processes
   on the system, including those that do not belong to them. You may
   wish to only allow the user to see processes owned by them. To do
   this, you may use the kern.ps_showallprocs sysctl variable. You can
   change this while the system is running by issuing the following
   command:

   sysctl kern.ps_showallprocs=0

   To make this change permanent, insert the following line into
   /etc/sysctl.conf:

   kern.ps_showallprocs=0

   The root user is not affected by kern.ps_showallprocs and can always
   see all processes.

   While this method is effective for limiting what output ps(1) gives,
   it will not stop an attacker from traversing /proc to find out what
   processes are running. See 'Disabling procfs' for more information.

o  Disabling procfs

   procfs can be used to gather information on running processes. It is
   required for the complete operation of programs such as ps(1), w(1)
   and truss(1). Due to the amount of information that procfs may yield
   many administrators feel that it is advantageous to disable this
   filesystem.

   This step is ENTIRELY voluntary. You do not need to disable this if
   you do not want to.

   To disable procfs, add the NOAUTO option to /etc/fstab for this
   filesystem. You may then mount it manually if needed.

o  login.conf(5)

   FreeBSD allows you to add users to 'login classes', where you can
   control (for example) how much CPU/memory each user can use. This
   can be very effective in limiting local DoS attacks, whether
   intentional or by accident. Since the use of login.conf would most
   likely require a document of it's own, you are encouraged to read
   the man page - login.conf(5) - for more information.


Stay up to date
===============

o  Keep your packages current

   When you're running daemons that are worldly visible and accessible
   it's important to make sure (and it's common sense) that your
   packages are always up to date. If you see a new version of a
   package you have installed, then update it via the ports tree to make
   sure that you've always got the latest version. It only takes a few
   minutes in most cases, but it's worth the effort if you're saving the
   machine from being compromised. It'll help to watch lists like
   bugtraq for security advisories.

   For more information on keeping your packages current, please see the
   FreeBSD HandBook:

   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

o  Keep your OS current

   Similarly, it's important to keep FreeBSD itself up to date. Keep
   your source tree up to date, and 'make world' if/when new security
   patches are made available. It'll help to watch lists like bugtraq
   for security advisories.

   For more information on keeping your OS current, please see the
   FreeBSD HandBook:

   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

   You should also subscribe to the FreeBSD Security Advisories mailing
   list. See:

   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html

   for more information on subscribing.


Be Vigilant
===========

You should always be on the look out for strange behaviour as it is very
often the first sign that something is wrong. You should especially be on
the lookout for:

o  A machine that has recently rebooted.

   If your machine has rebooted (and you didn't do it) check to see if
   anything serious has been changed. You should be especially watchful
   of system securelevel's, since these will need to be changed for the
   attacker to change things like the kernel, KLM's etc and afford an
   opportunity to bypass system immutable and system append-only flags.

o  Changes in SUID files.

   The daily reports that get run contain information about any changes
   in SUID files. Pay important attention to these.

o  Changes in critical system files.
   
   Watch out for changes in critical system files, like /kernel.  When
   you install FreeBSD, you should take MD5 values of these files and
   store them somewhere safe (not on the machine). Compare these values
   from time to time. If they dont match (for reasons you cant explain)
   then investigate. You can use something like
   /usr/ports/security/tripwire for this, though there are also other
   alternatives.


Other documents about FreeBSD Security
======================================

o  The following sites also contain information on securing FreeBSD:

   - http://www.freebsd.org/security/
   - http://www.freebsd.org/~jkb/howto.html
   - http://www.subterrain.net/presentations


Thanks
======

I would like to extend a thanks to Marc Silver  for
writting "A basic guide to securing FreeBSD 4.x-STABLE".
Latest News
User Account Login
Chat Now
:
:
Thanks for flying DALnet!
Tip of the day
Do not share your password with anyone. DALnet staff will not ask for your password