802.11 Security

Chapter 4. FreeBSD Station Security

This chapter demonstrates how to lock down FreeBSD workstations for use on a wireless network. It will explain required and recommended kernel tuning, secure configuration of the wireless card, locking down the operating system, and adding third-party software to further enhance the security of the machine. Many of the security practices documented in this chapter are general best practices that should be applied to any workstation (but rarely are). However, without mechanisms geared for wireless security, standard wired network best practices alone are not enough.

FreeBSD Client Setup

FreeBSD has a long history of wireless networking support. FreeBSD had robust support for the original 802.11 cards and has continued to support 802.11b cards. As of this writing, several 802.11a cards have experimental support under FreeBSD-current. Unless otherwise noted, the examples given in this chapter are for FreeBSD 4.5-RELEASE. For information regarding this release or for questions on FreeBSD in general, please see http://www.freebsd.org/.

As in any other discussion of setting up a secure platform, the steps outlined below are governed by the Principle of Least Privilege. The Principle of Least Privilege means that a user or system should be given only the required amount of privilege to perform the required tasks. This principle can be extended to configuring an operating system. Only required services, kernel configuration options, users, and files should be installed. By having unneeded interfaces on a machine (such as ppp0) or leaving unnecessary services running, you provide an attacker potential vectors for compromising your machine.

Wireless Kernel Configuration

In order to use wireless NICs, the kernel must be configured to support the networking card. Complete instructions for compiling a kernel are outside the scope of this book. The information below is meant to supplement a normal kernel configuration. For information on compiling a new kernel, see /usr/share/doc/en/books/handbook/kernelconfig.html on your FreeBSD system, or go to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html.

Before adding wireless and security options to your kernel, first remove all extraneous entries in your kernel configuration file. The GENERIC kernel that ships with FreeBSD contains many options that are not required for operation of most workstations. For example, if your workstation does not have any SCSI devices, remove all the SCSI devices and options from your kernel. Usually a configuration file for a workstation can be reduced to less than 100 lines. Once you have reached a minimal configuration, build a kernel and boot it. Verify that all devices are working as expected before adding the options specified in this section. The kernel parameters documented in this section are meant to supplement an existing kernel configuration file, not serve as a stand-alone kernel configuration.

In most cases, wireless NICs are connected via a PCMCIA (aka, PC-card) interface. For PCMCIA support, add the following to your kernel configuration file:

device          pcic0 at isa?
device          pcic1 at isa?
device          card

In order to get cards working after resuming a suspended laptop, you may also have to add this:

options         PCIC_RESUME_RESET

Once you have PC-card support, the kernel needs to be configured to use your wireless card. Card support is based on the internal chipset that the card runs on. Unfortunately, this information is not usually stamped on the outside of the card (or even in the documentation). In order to determine which chipset is in your card, you can search the Internet (including the vendor’s web site) or simply compile all the drivers into the kernel. When the machine boots, you will be able to determine which driver is in use by the card. The other drivers can be removed from the kernel configuration at that point. The following list introduces the most common wireless interface driver types:

device awi

This device is for legacy Prism I chipsets. Very few cards were sold using this chipset, so it is unlikely you will require this device.

device wi

This device is for cards based on several chipsets including the Prism II chipset and Hermes chipset. Both of these are very common chipsets that have sold millions of units. Cards that use these chipsets include the D-Link DWL650, Orinoco Silver and Gold, and NetGear MA401.

device an

This device is for Cisco Aironet cards. This includes both the Cisco 340 and 350 series cards.

device ray

This device is for Raylink-based cards. The most common card based on this chipset is the Webgear Aviator.

You may also want to add the following options to your kernel:

options         WLCACHE
options         WLDEBUG

WLCACHE enables the wireless signal strength cache. The cache stores signal strength for every known MAC address on the network. Applications can then use the cache to determine the status of connections to other hosts. WLDEBUG allows for verbose wireless debugging. Low-level debugging can be useful when difficulty occurs while configuring a wireless card. Once enabled in the kernel, you can turn on debugging using ifconfig <interface> debug.

Security Kernel Configuration

After you get the wireless devices configured properly in the kernel, there is still more kernel tweaking to do. The FreeBSD kernel provides many security-specific options that help protect a machine and its users. These security parameters are the foundation for the host’s security.

FreeBSD provides a kernel-level firewall that is controlled via the userland program ipfw. A firewall is critical piece to controlling the security of a wireless client. Your station and other stations associated to the same access point are in the same broadcast domain. There are no layer 3 or higher protection mechanisms between two stations in the same broadcast domain. A malicious user associated to the same access point as you has a “clear shot” at your machine. A host-based firewall running on your station can shut down IP-based attacks attackers may launch against you:

options         IPFIREWALL

This option enables the kernel-level firewall:

options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=100

These options enable verbose logging for the firewall. This allows you to create a firewall ruleset that logs information about interesting packets to syslog. This logging leaves an audit trail that allows you to examine network activity on your machine. Setting a verbosity limit in the kernel keeps an attacker from filling up your filesystem with data about what packets are being dropped. Assume you have a firewall rule that denies and logs all inbound HTTP traffic (port 80). An attacker then sends millions of packets to port 80 on your machine. Without a logging limit, each one of these packets would be sent to syslog and written to disk. Eventually, the filesystem containing your log files would fill up, and your machine would, in all likelihood, crash:

options IPFIREWALL_DEFAULT_TO_ACCEPT

Normally, the firewall denies all packets by default. This option allows you to accept packets by default. Allowing packets by default is a bad security practice. If the firewall rules are accidentally cleared or there is a mistake in your rules, a default policy of allowing traffic will leave you with an open system. This option should only be set if you have a pressing need to have the firewall “fail-open.”

FreeBSD also allows for changing the default behavior of various network protocols. Most of these changes enhance the host’s protection against denial-of-service attacks.

options RANDOM_IP_ID

The RANDOM_IP_ID option changes the ID field in IP packets randomly rather than sequentially. This prevents third parties from guessing the rate at which the host is sending packets. It is also good practice when using link-level encryption such as WEP. Cryptoanalytic attacks can be launched against some ciphers when portions of the plaintext are known. By having a sequentially changing ID field, part of the plaintext is known by the attacker. While a small field like the IP ID may not be the key that allows a cryptographic protocol to be broken, it is still guessable data that will make a cryptographic attack a little bit easier.

options TCP_DROP_SYNFIN

The TCP_DROP_SYNFIN causes the kernel to discard packets that have both the SYN and FIN bits set. Unless the hosts are utilizing the experimental TCP extensions outlined in RFC 1644, this should not cause any problems. Portscanning software such as nmap (available at http://insecure.org) will set both the SYN and FIN bits in an effort to avoid detection and determine what operating system the host is running. This option will make the OS determination more difficult.

options ICMP_BANDLIM

This option limits the rate the host will respond to ICMP requests. This will help minimize the effects of denial-of-service attacks.

pseudo-device bpf

This is the Berkeley Packet Filter, which allows the root user to set a network interface into promiscuous mode. An interface in promiscuous mode will not only listen to frames destined for itself, but will pick up packets addressed for other hosts on the network. Normally, an interface will only process frames destined to that interface.

BPF is a double-edged sword. It can be a powerful troubleshooting tool for network and security problems. However, in the wrong hands, a BPF-enabled host is a liability to the security of a network. A malicious user can use a promiscuous mode interface to find user credentials and other sensitive data that is traversing a network. BPF is required for some monitoring tools, such as Arpwatch, which is discussed later in this chapter.

Startup Configuration

Several startup files need to be modified for your workstation to be fully functional at boot time. First, you must enable the PC-card services, which allows the system to use PCMCIA cards. (Some PCI wireless cards in desktop machines may not need to use PC card.) Then, the wireless network card needs to be configured for your particular wireless environment.

Tip

FreeBSD stores most of the startup directives in a file called /etc/defaults/rc.conf. In order to change a value specified in /etc/defaults/rc.conf DO NOT edit that file directly. Put any line that needs to be changed into /etc/rc.conf. At boot time, FreeBSD will override the defaults with values specified in /etc/rc.conf.

Enable PC-card services by adding the following to /etc/rc.conf:

pccard_enable="YES"

There are several ways to configure the wireless networking at startup. We prefer to have one file control all wireless networking activities. This allows a single point to manipulate all wireless parameters and generally simplifies administration of the machine. Create the following /usr/local/etc/rc.d/wireless.sh:

#!/bin/sh
# This script will configure wireless network cards for FreeBSD
case "$1" in
start)

# Configure the Interface

   echo -n ' wireless network'
   ifconfig wi0 down
   ifconfig wi0 inet <your_ip_address> netmask <your_netmask> \
       ssid <your_ssid> wepmode <your_wepmode> wepkey \
       <your_wepkey> up
   # if you are going to use DHCP replace the above line with:
   # ifconfig wi0 ssid <your_ssid> wepmode <your_wepmode> wepkey \
   #    <your_wepkey<
   # dhclient wi0
   
# Set up default route

   route add default <your_default_gateway>

# Reset the firewall rules 

   [ -x /etc/rc.firewall ] && sh /etc/rc.firewall && echo -n  \
        ' resetting firewall'
   ;;

stop)

# Take down the interface so no traffic can pass

   echo 'stopping wireless card'
   ifconfig wi0 down
   ;;
*)

# Standard usage statement
 
   echo "Usage: `basename $0` {start|stop}" >&2
   ;;
esac

exit 0

Make sure the file is executable by performing:

chmod 755 /usr/local/etc/rc.d/wireless.sh

At start time, this file will be executed during normal loading procedures with a start directive. If you need to reconfigure your card after boot time, you can execute this script by hand:

/usr/local/etc/rc.d/wireless.sh start

This script uses the command ifconfig to set both IP and wireless parameters. For more information on ifconfig, see the next section, Section 4.1.4.

Card Configuration

The functionality of the wireless network card can be controlled by the ifconfig utility. Versions of FreeBSD prior to 4.5 used separate utilities to control wireless parameters. For Prism-based cards, configuration was performed via wicontrol. Cisco cards were controlled via ancontrol. The functionality of both utilities has been merged into ifconfig for the sake of consistency. As of 4.5, both wicontrol and ancontrol still exist for the sake of compatibility.

ifconfig usage includes the following parameters:

interface

The name of the wireless interface to be managed.

ssid ssid

The Service Set Identifier of the preferred access point. By setting this value to ANY the station will associate to the access point with the strongest signal. This is not recommended, since a nearby attacker can cause your station to associate by providing a stronger signal.

stationname name

The name of the station the wireless card is installed in. This is not a required parameter.

channel number

The number of the channel the STA is to use. Under 802.11b networks governed by FCC regulations, this is a number between 1 and 11.

authmode mode

This is the mode the STA is to use when connecting to an infrastructure-based network. Values are none, open, and shared.

wepmode mode

This parameter indicates the method WEP will use for forming associations. off will allow the STA to be connected only to networks without WEP protection. on forces the STA to use WEP for associations. When set to on, the STA will not form an association unless the access point allows only WEP associations. mixed mode allows the STA to form non-WEP associations, but it will prefer WEP associations if they are available.

weptxkey index

The index is a value between 1-4 to indicate which WEP key is to be used for transmissions with the AP.

wepkey key| index:key

This specifies the value of the stored WEP keys. Four different keys can be stored by using index values between 1 and 4. The WEP key is specified as either an ASCII string or a hex value preceded by 0x.

There are other parameters that can be passed to ifconfig. They primarily deal with power-saving configuration to help extend the life of battery-operated devices.

For example, if you are connecting to the closed Example network using a WEP key of secrt, the following command would set up that association:

ifconfig wi0 ssid Example wepkey secrt wepmode on

ifconfig can also be used to query the state of the wireless NIC by passing the name of the interface as the only parameter. The previous example would result in the following:

bash-2.05# ifconfig wi0
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 fe80::230:abff:fe0e:2e81%wi0 prefixlen 64 scopeid 0x6
        ether 00:30:ab:0e:2e:81
        media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
        status: associated
        ssid Example
        stationname "FreeBSD WaveLAN/IEEE node"
        channel 1 authmode NONE powersavemode OFF powersavesleep 100
        wepmode ON weptxkey 1
        wepkey 1:64-bit

OS Protection

A machine on a wireless network is in a hostile environment. With no physical security, any nearby host can launch an attack against a client with little or no protection offered by the network. Hosts must protect themselves via operating system configuration in order to be resilient to attack.

Firewall configuration

The first line of defense for hosts on a wireless network is a properly configured firewall. In general, most workstations will not be running any services, so configuring the firewall is relatively simple. Only outbound connections should be allowed in this case; all inbound connections should be dropped. If you do have services running on your workstation, you should configure your firewall appropriately.

The firewall configuration is stored in /etc/rc.firewall. The file contains ipfw commands to configure the firewall based on parameters in /etc/rc.conf. From the default FreeBSD rc.firewall:

#   open     - will allow anyone in
#   client   - will try to protect just this machine
#   simple   - will try to protect a whole network
#   closed   - totally disables IP services except via lo0 interface
#   UNKNOWN  - disables the loading of firewall rules.
#   filename - will load the rules in the given filename (full path required)

For a workstation setup, your rc.conf should contain:

firewall_enable="YES"
firewall_type="CLIENT"
firewall_logging="YES"

Here is an example rc.firewall that should serve as a starting point for wireless clients. These commands should replace the commands in the “client” section of rc.firewall:

# Setup variables to allow for portable rulesets
net="<yoursubnet>"
mask="<yournetmask>"
ip="<youripaddress>"

# Allow active TCP sessions through.  The majority of the packets passed by
# the firewall will be handled by this rule, so it should be at the top of 
# your ruleset.  Any active connections outbound from your workstation will
# be processed by this rule
${fwcmd} add pass tcp from any to any established

# Allow setup of outgoing TCP connections only
${fwcmd} add pass tcp from ${ip} to any setup

# Disallow and log setup of all other TCP connections
${fwcmd} add deny tcp from any to any setup log

# Allow DNS queries out in the world.  The "keep-state" parameter will cause
# the return DNS response to pass through the firewall.
${fwcmd} add pass udp from ${ip} to any 53 keep-state

# Silently drop local Windows queries.  They will quickly reach your log
# limit if you do not.
${fwcmd} add deny tcp from ${net}:${mask} to ${ip} 137-139
${fwcmd} add deny udp from ${net}:${mask} to ${ip} 137-139

# Log and deny connections from the local network.  There should never be
# any connections from the local network in a "hostile" wireless network.
${fwcmd} add deny ip from ${net}:${mask} to ${ip} log

# Log and deny everything else
${fwcmd} add deny ip from any to any log

You can examine the state of the firewall rulesets by executing the command ipfw show. The counters maintained by ipfw can be zeroed out by running ipfw zero.

The ipfw man page has information regarding further features that your firewall can utilize. Chapter 12 has a more complete discussion of creating gateway firewalls with FreeBSD to protect the wireless network.

Disable unneeded services

Unneeded services running on a host are one of the primary vectors for attackers to use to exploit machines. At the time of release for an operating system, there are generally no known security vulnerabilities in the default services. However, as time passes, security holes can be discovered in services and exploits can then be successfully written and executed against a vulnerable host.

If you are running services that are never actually used, you may very well forget that they exist. When a security vulnerability is found, you may not know to patch the service or you may simply not have time to patch the service before you are exploited. There is no need to run a service that provides no value and a large amount of risk.

In general, services are started in four places in FreeBSD: /etc/ined.conf, /etc/rc.conf, /etc/rc.d, and /usr/local/etc/rc.d. For services in /etc/rc.conf, comment out the entry for the service that you don’t want to start with a hash mark (#). Typically services started in rc.conf are sshd and nfsd. For services started out of inetd.conf, comment the service out with a hash mark (#). Services typically started out of inetd.conf are telnet and ftp. For services in the two rc.d directories, either remove the executable bit from the file or move the file to another directory. This is a matter of personal preference. Services started in these directories usually include snmpd and apache.

You can also use the setup and installation program /stand/sysinstall to enable and disable services through a menu-driven system.

Static ARP

As documented in ARP Poisoning, there is a real threat from man-in-the-middle attacks due to ARP poisoning. A malicious user may be able to convince your workstation that her host is the gateway by forging spoofed packets. By putting a static ARP entry on your host, the effectiveness of this attack is minimized.

Static ARP entries override any dynamic information received over the network. If you are always using the same gateway (i.e., you are not roaming around to different layer 3 wireless networks), you can put a script in /usr/local/etc/rc.d to hardcode your gateway’s ARP address. Create /usr/local/etc/rc.d/staticarp.sh with the following information:

#!/bin/sh
# This script will set static arp entries for FreeBSD
case "$1" in
start)

# Add the MAC address for the gateway to the ARP table

   echo -n 'adding gateway MAC to arp table'
   arp -S <gatewayIP> <gatewayMAC>
   ;;

stop)

# Delete the MAC address from the ARP table

   echo 'removing static MAC from arp table'
   arp -d <gatewayIP>
   ;;
*)

# Standard usage statement
 
   echo "Usage: `basename $0` {start|stop}" >&2
   ;;
esac

exit 0

Make sure the file is executable by performing

chmod 755 /usr/local/etc/rc.d/staticarp.sh

Other security concerns

You can change other configuration settings, depending on your level of concern, but they are outside the scope of this book. It is up to you as an administrator and user to determine the level of risk you are willing to accept with your wireless workstations. For those looking to learn more about FreeBSD security, check out the security section of the FreeBSD handbook at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/securing-freebsd.html.

Audit Logging

Proper auditing of a host is critical to the ongoing security of a host. No matter how secure the initial setup of a machine is, the level of security decreases over time as new services are installed and new vulnerabilities are discovered.

arpwatch

As discussed in ARP Poisoning, man-in-the-middle attacks can be launched via spoofing packets to a target host purporting to be from the gateway but with a malicious MAC address. This allows an attacker to intercept all traffic sent from your workstation.

In conjunction with setting a static ARP entry for the gateway (documented in “Static ARP”), other ARP entries can be monitored via the arpwatch utility. If you have the ports tree installed, you can perform the following to automatically install arpwatch:

cd /usr/ports/net/arpwatch
make
make install

If you do not have the ports tree installed, you can obtain arpwatch from ftp://ftp.ee.lbl.gov/arpwatch.tar.gz or use the command pkg_add -r arpwatch to have the system download the package and install it. Unpack the code and follow the instructions to build and install arpwatch. You need to have the Berkeley Packet Filter compiled into your kernel. See Section 4.1.1 or Section 4.1.2 earlier in this chapter for information on BPF support.

Once arpwatch is installed, you can configure it to mail a user whenever an event is detected. On a normal network, there are very few ARP events of interest so there will be few emails sent. When there is an ARP-based attack under way, arpwatch can generate quite a large quantity of email. By adding -m <youremailaddress> to the arpwatch commands in /usr/local/etc/rc.d/arpwatch.sh, these events will be mailed to a user of your choosing. Ideally this email will be sent to a local account so it will not swamp remote mail servers in the event of a large attack and can be monitored in near real time.

If arpwatch reports a flip-flop, it means an IP address has been hijacked for an existing host on the network. This may be due to simple misconfiguration, where a user has inadvertently duplicated another IP address on the network. It may also be an attacker attempting to either hijack an active session or perform a man-in-the-middle attack. Here is an example of a flip-flop:

From: arpwatch (Arpwatch)
To: root@localhost
Subject: flip flop
Status: O

            hostname: <unknown>
          ip address: 192.168.0.1
    ethernet address: 0:2:2d:8:5b:30
     ethernet vendor: Agere Systems
old ethernet address: 0:30:ab:e:2e:81
 old ethernet vendor: DELTA NETWORKS, INC.
           timestamp: Thursday, February 14, 2002 2:46:21 +0000
  previous timestamp: Thursday, February 14, 2002 2:45:49 +0000
               delta: 32 seconds

The old Ethernet address is from a wired Ethernet vendor. This was the Ethernet card on the network’s gateway (192.168.0.1). The new Ethernet address is from Agere Systems, a large vendor of wireless networking equipment. This is an attacker on the wireless network attempting to poison the ARP cache of other hosts on the network to perform a man-in-the-middle attack. After receiving this email, you need to make a decision about the integrity of the network you are attached to. If you feel the network is untrustworthy, then you should disconnect from the network and notify the network administrator.

syslog

The syslog facility is the central log collector for any UNIX host, and FreeBSD is no exception. The log files controlled by syslog can provide a wealth of information. Some attacks that will be performed against wireless clients are known and are easy to find in a log. Over time, new attacks will be launched which will not match any known signature. With a complete-enough audit trail, you may be able to reconstruct events in an unknown attack. Once the reconstruction is complete you can then determine the best mechanism to use to defend yourself from the attack.

In order to review the information, the log data needs to be redirected to the proper log files. Rather than break apart the log data into different files based on log facility and severity, it is sometimes useful to send all log data to one file. This allows the data to be distilled using tools such as grep and perl. These unique views of audit data tend to be much more useful than splitting the data up a priori.

In order to log all data sent to syslog to /var/log/messages, add the following line to the top of your /etc/syslog.conf:

*.*                           /var/log/messages

Be sure to comment out any other line that references /var/log/message in the syslog configuration file with a hash mark (#). To force these changes to take effect without rebooting, execute killall syslogd; syslogd as root.

swatch

swatch is a utility to monitor log files and report on interesting strings. It serves as a set of eyes constantly watching your log files. Upon finding a pre-specified string in a log file, swatch can send email, ring the bell, or execute arbitrary system commands. It is incredibly flexible and can be a lifesaver for those of us who do not like watching log files out of the corner of our eyes.

If you have the ports tree installed, you can execute the following commands to install swatch:

cd /usr/ports/security/swatch
make
make install

If you do not have the ports tree installed, you can get the source code for swatch at http://www.oit.ucsb.edu/~eta/swatch/. Install the source according to the instructions included in the source code.

Once installed, you need to determine what strings you want to look for and what actions you want to take when you find them. Ideally you want to monitor connection attempts from other hosts on the wireless network. This is an indication of some potentially malicious activity. The following is an example of a swatch configuration file that will ring a bell for every log entry created due to a request from a local machine. The local subnet in this example is 192.168.0.0:255.255.255.0:

# swatchrc.personal example to watch for connection attempts from 
# local machines

watchfor   /Deny TCP 192.168.0/
        echo
        bell

swatch is quite customizable. After getting familiar with normal and abnormal log traffic on your host, expand this swatch configuration file to suit your needs.

Now that your FreeBSD client is secure, you have a fighting chance of maintaining the integrity of your workstation while using a wireless network. By securing the operating system and supporting programs, you make it difficult for an attacker to subvert your host. Layering proper auditing features on top of the strong layer of security helps you watch for the unknown. When new attacks are launched, hopefully you will have enough information to unwderstand what is happening to your host and react accordingly.