FreeBSD  Release  8.0  Installer  Guide

Home______________________________________________________________________

 

The FBSD operating system itself has security options which control the processing of network packets and access to authorizing changes to the running kernel. These options are enabled from different places from within FBSD, like from the kernel source, the rc.conf boot start up file, and the internal sysctl MIB control file, sysctl.conf.

The first line of defense in protecting your system is your firewall software application. Its general purpose is to only allow the starting of outbound or inbound session conversations for services that you have explicitly authorized using stateful rules. Stateful rules will monitor the bi-directional exchange of the packets of the session conversation so no fraudulent packets can be inserted into the conversation by attackers or attacks based on mass amounts of invalid packets. Whatever firewall software application you use, you must code stateful firewall filter rules or you defeat the purpose of the firewall. The importance of stateful rules cannot be over-emphasized.

The second line of defense is to take due diligence. This means to spend some time to enable the network security options scattered around FBSD to make it even harder for an attacker to penetrate your system and then be able to move around and or change things. This is detailed in the network packet options section.

FBSD provides a third line of defense to restrict system file changes and a way to compartmentalize processes in jails. User data can use GEOM Based Disk Encryption (gbde) to transparently encrypt entire file systems. No clear text ever touches the hard drive's platter. The options in this category can be considered paranoia overkill for the normal home user. Their covered in detail in the security paranoia section.

For additional info see FREEBSD SECURITY & HARDENING GUIDE

 

FBSD has some options that can be used to control how some kinds of attacking packets are handled by the basic FBSD operating system. For some unknown reason this version of FBSD has more than one way of implementing the network packet options. Some are only changeable in sysctl.conf, others only in rc.conf and still others in the kernel source options.

There is no FBSD documentation that says that these network packet options are still active if an application software firewall is being used. Now on the other hand, using the network packet options have shown to cause no problems when used with an application software firewall, so I recommend enabling them wherever they are enabled from as a fail safe precaution. You should not rely on these network packet options as your sole means of protecting your network environment.

 

I chose to enable and document the network packet options which are enabled in sysctl even if they can also be enabled in rc.conf. The network packet options I enable in rc.conf has to happen there, because that is the only place these particular options can be enabled.

Add the following statements to the /etc/sysctl.conf file. You can drop the comments, but I always find them helpful later when I am looking for a problem.

 

####################################################################
#
# The sysctl.conf file contains MIB's to change the default setting
# of internal options of the kernel at boot up time. These MIB's
# control how network packets are handled after the IPFW or IPFILTER
# software application firewalls return the packet to the kernel.
# Some of these MIB's may seem like they are doing the same thing,
# but because there is no FBSD provided documentation on the order
# these MIB's get control, they all get enabled here and we let the
# kernel do its thing.
#
# NOTE: Some of these MIB's can also be set in rc.conf and/or the
# kernel source. This will not hurt anything.
#
####################################################################

####################################################################
# Redirect attacks are the purposeful mass issuing of ICMP type 5 packets.
# In a normal network, redirects to the end stations should not be required.
# To defend against this type of attack both the sending and accepting of
# redirect should be disabled. The first statement below enables the MIB
# to drop all inbound icmp redirect packets without returning any response.
# The second statement turns off the logging of redirect packets because
# there in no limit and this could fill up your logs consuming your whole
# hard drive. But there is no information about where the redirect packets
# get logged. The last statement changes the FBSD default about allowing
# redirects to be sent from this system to the Internet from yes to no.
# This option is ignored unless the host is routing IP packets, and
# should normally be enabled (=1) on all systems
# man icmp(4) and inet(4) and man ip(4) do not contain info about these MIBs.
# man sysctl(3) does have info on ip.redirect

net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=0
net.inet.ip.redirect=0


####################################################################
# Source routing is another way for an attacker to try to reach non-routable
# addresses behind your box. It can also be used to probe for information
# about your internal networks. These functions come enabled as part of the
# standard FBSD core system. The following will disable them.
# man inet(4) and man ip(4) do not contain any information on these MIBs.

net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0


####################################################################
# This MIB only drops ICMP echo requests which have a destination of your
# broadcast address. For example, if your network is 10.10.0.1/24,
# (making your subnet mask 255.255.255.0) then your network broadcast address
# is 10.10.0.255. When a host on your network needs to send a message to all
# other hosts on the subnet (which happens more often than you may think) it
# uses this address. Everyone listens on it. Hosts outside your network have
# no reason to be sending packets to your broadcast address. This MIB rejects
# all of the broadcast echo traffic from the outside world to your network
# broadcast address. If this host is a firewall or gateway, it should not
# propagate directed broadcasts originating from outside your private network.
# The following statement sets the default to no, rejecting all external
# broadcasts requests.
# man sysctl(3) has some info.
# man inet(4) and man icmp(4) do not contain any information on these MIBs.

net.inet.icmp.bmcastecho=0


####################################################################
# This changes the system behavior when connection requests are received
# on TCP or UDP ports where there is no socket listening. The normal
# behavior, when a TCP SYN segment is received on a port where there
# is no socket accepting connections is for the system to return a
# RST segment and drop the connection. The requesting system will
# see this as a "Connection reset by peer".
#
# By turning the TCP black hole MIB on with a numeric value of one, the
# incoming SYN segment is merely dropped, and no RST is sent, making
# the system appear as a blackhole.
#
# By setting the MIB value to two, any segment arriving on a closed
# port is dropped without returning a RST.
# This provides some degree of protection against stealth port scans.
# The following enables this MIB. man tcp(4) and man udp(4) blackhole(4)
# contain a little information on these MIBs.

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


####################################################################
# The log_in_vain MIB will provide you with logging of attempted
# connections to your box on any port which does not have a service
# running on it. For example, if you do not have DNS server on your
# computer and someone would try to access your computer through DNS
# port 53, you would see a message such as: Connection attempt to
# UDP yourIP:53 from otherIP:X (where X is some high port #) displayed
# on the root console screen. This message also gets posted to
# /var/log/messages & /var/log/security.log.
# The following statements enable this function.
# man tcp(4) and man udp(4) contain a little information on these MIBs.

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


####################################################################
# To defend against SYN attacks more commonly known as SYNFLOOD attacks,
# the two queues which are targeted by this type of attack should
# have their size increased so that the queues can withstand an attack
# of low to moderate intensity with little to no effect on the stability
# or availability of the system. FBSD maintains separate queues for
# inbound socket connection requests. One queue is for half-open sockets
# (SYN received, SYN|ACK sent), and the other queue for fully-open sockets
# awaiting an accept() call from the application.
# The following statement increases the queue size from 128.

 kern.ipc.somaxconn=1024


####################################################################
# By allowing aged ARP entries to remain cached or lying around
# allows for the possibility of a hacker to create a resource
# exhaustion or performance degradation by filling the IP route cache
# with bogus ARP entries. This in turn can be used as a Denial of
# Service attack. To prevent this sort of problem, the following
# statement shortens the amount of time an ARP will be cached
# from 1200 to 600 seconds.

net.link.ether.inet.max_age=600

###################### end of sysctl ####################################

 

Delivered as part of the FBSD core system is a non-secure FTP server and Telnet server. They are labeled non-secure because, when logging into these servers the account ID and password are transmitted as clear text. Now for LAN users behind your firewall this is not a security problem, but if you allow access to these servers from the public Internet, an attacker can capture packets on the public Internet looking for the plain text ID and password. This is considered a security risk. Program SSH provides secure encrypted communications between two un-trusted hosts over an insecure network. SSH has a built in FTP and telnet servers and should be the only way used to gain access to FTP and or Telnet from the public Internet. Secure and non-secure FTP and Telnet are covered in the FBSD Administration Section.

The automatic starting of the non-secure FTP and Telnet services is controlled by the "Internet super-server" inetd. Do a ‘ps ax’ command and review the active task list to see if inetd is running. If it’s running and you are not using it, add this statement to /etc/rc.conf to disable it.

inetd_enable="NO"

 

The following rc.conf statements activate knobs which can also be activated in sysctl.conf, which we already did. I list them here just so you can recognize them.

#log_in_vain="YES"
#icmp_drop_redirect="YES"
#icmp_log_redirect="YES"
#icmp_bmcastecho="NO"

 

The system logs default to being able to bind to an internal socket which allows them to be sent to some other system for recording. If you are not doing that on purpose then this option should be disabled using this statement.

syslogd_flags="-ss"

SSHD which provides secure logins defaults to no. If you want to use this function, then you have to enable it with the following statement.

sshd_enable=YES

 

All new users of FBSD start with the GENERIC kernel source to copy and name as their own customized kernel source. See COMPILING KERNEL for instructions. The following are things you can do in the kernel source to tighten up security even more. You can prefix statements with # to make it a comment to disable it or delete the statement all together.

Make these changes.

At the top the file is the following statement.

#options INET6 # IPv6 communications protocols

Ipv6 is a developmental protocol, if you are not testing this protocol on purpose, it should be disabled.

A few lines down are the network filesystem options

#options NFS # Network filesystem
#options NFS_ROOT # NFS usable as root device

Comment these out to disable them

Disable the following options because Kernel PPP has been replaced and you disabled Ipv6 earlier. You will never have use for these. They're located at the end of the kernel source statements.

#pseudo-device sl 1     # Kernel slip no longer used
#pseudo-device ppp 2    # Kernel PPP replaced by user ppp
#pseudo-device faith 4  #IPv6-to-IPv4 relaying (translation

You should have your IPFILTER or IPFIREWALL (IPFW) enabling statements already in your kernel source. Just to keep all the security options grouped together, place these by them.

options TCP_DROP_SYNFIN       # Adds support for ignoring TCP packets
                              # with SYN+FIN. This prevents nmap from
                              # identifying the TCP/IP stack, but
                              # breaks support for RFC1644 extensions
                              # & is not recommended for web servers
                              # behind the firewall.

The comments with this option are from the LINT kernel source word for word. I have an Apache web server running on my gateway/firewall box, and I use this option and can not see anything wrong happening.

 

options ICMP_BANDLIM    # Enables icmp error response bandwidth
                        # limiting. This will help protect from
                        # D.O.S. packet attacks.

options RANDOM_IP_ID    # Causes the ID field in IP packets to be
                        # randomized instead of incremented by 1 with
                        # each packet generated. This closes a minor
                        # information leak which allows remote
                        # observers to determine the rate of packet
                        # generation on the machine by watching the
                        # counter.

options NO_LKM          # disable FBSD ability to dynamically load
                        # kernel modules. If you are using the IPFILTER
                        # load module don’t do this

If you do not have a printer cabled off the parallel port of this PC then disable these options.

# Parallel port
#device ppc0 at isa? irq 7
#device ppbus            # Parallel port bus (required)
#device lpt              # Printer
#device plip             # TCP/IP over parallel
#device ppi              # Parallel port interface device

 

If you are not copying this system to other PCs with expansion cards from different manufacturers, then besides the security benefit you can also reduce the time it takes to compile the kernel by removing all unused device drivers. Review your /var/run/dmesg.boot log messages to see which devices you are really using  and only keep those. Comment out all the others. Do not delete the following device; it is used by most NICs but does not show up in dmesg as used.

device miibus # NICs that use MII bus support

 

It's very important that you completely understand the impact of activating the following options will have on your ability to make changes to your system.

The simplest thing you can do is set the immutable flag on all system binaries and /etc config files with:

chflags schg /bin/*(*) /sbin/*(*) /usr/bin/*(*) /usr/sbin/*(*) /etc/*(*)

Setting the immutable flag on means the files are marked as being protected from being written over. Once you execute the above command, no process can overwrite those files, thus increasing the level of difficulty for the attacker and increasing the odds in your favor of the attacker leaving error messages in the system log. On the other hand, you as the root user can not make any changes to those files so marked either. Every time you want to make changes you have to issue the command to turn off the immutable flag on all the same files. Use this command to do that:

chflags noschg /bin/*(*) /sbin/*(*) /usr/bin/*(*) /usr/sbin/*(*) /etc/*(*)

You can use "ls -lo" command to see the immutable flags of existing files.

 

The Jail Facility and the rc.conf securelevel options provide the maximum in security paranoia overkill available utilizing the built in facilities of FBSD.

Installer Note: There are two free public software applications for the seriously paranoid users. The CERB Reality project at http://cerber.sourceforge.net/ provides a additional level of overkill based on securing FBSD’s heritage dependences on the Unix permissions structure, and the very sophisticated port mapper for security auditing your system (see http://www.insecure.org/nmap/ )

Check out http://www.nagios.org/about/  for a free host and service monitor which will inform you of network problems before your clients, end-users or managers do. The monitoring daemon runs intermittent checks on hosts and services you specify using external "plugins" which return status information to Nagios. When problems are encountered, the daemon can send notifications out to administrative contacts in a variety of different ways (email, instant message, SMS, etc.). Current status information, historical logs, and reports can all be accessed via a web browser.

 

The jail facility is the creation of a special purpose jail directory tree containing an entire FreeBSD distribution. Any processes run are confined to the jail directory tree, because the parent directory of the jail is chrooted.

For details, see ‘man jail’ or online at: http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html

http://subwiki.honeypot.net/cgi-bin/view/Freebsd/JailAdmin

http://docs.freebsd.org/44doc/papers/jail/jail.html

 

The kernel runs with five different levels of security. Any super-user process can raise the security level, but no process can lower it. The security levels are:

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

This is the default initial value.

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 file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4) may not be loaded or unloaded.

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 file systems 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.

If the security level is initially nonzero, then init leaves it unchanged. Otherwise, init raises the level to 1 before going multi-user for the first time. Since the level cannot be reduced, it will be at least 1 for subsequent operation, even on return to single-user. If a level higher than 1 is desired while running multi-user, it can be set before going multi-user, (IE: by the startup script rc(8), or using sysctl(8)) to set the 'kern.securelevel' variable to the required security level.

Setting the security level above 1 too early in the boot sequence can prevent fsck(8) from repairing inconsistent file systems. The preferred location to set the security level is at the end of /etc/rc.conf after all multi-user startup actions are complete.

The securelevel option is intended for a production machine whose configuration is fixed and does not evolve anymore. This one option not only makes it very difficult for the attacker, but if you forget you have it turned on, or someone new takes over administrating the system and doesn't know about this, they will find themselves locked out of the system just like an attacker. You are forewarned.

In /etc/rc.conf as the last statements in the file add these statements:

# enable kernel security levels
kern_securelevel_enable=YES     # turn on kernel security levels
kern_securelevel=3              # turn on max kernel security level

 

Sensitive user data segregated into private partitions can have all the files  transparently encrypted so no clear text data ever touches the hard drive's platter by using GEOM Based Disk Encryption (gbde). See the official handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html

 

Previous Page                                        Next Page         

This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.