Like any other operating system, a secure host starts with a secure kernel configuration. If unneeded devices or options are included in your kernel configuration, you will not only have a bloated and slower kernel, but you may also open yourself up to attacks. The kernel should be configured using the Principle of Least Privilege. In short, if you do not need something in your kernel, do not add it! Also, an OpenBSD kernel can be configured with special options that can lead to a more secure machine. These options should be added when possible to help keep attackers out.
In order to use wireless
NICs, the kernel must be configured to support your wireless
networking card. The process of compiling an OpenBSD kernel is
outside the scope of this book. For more information on compiling a
custom OpenBSD kernel, see http://www.openbsd.org/faq/faq5.html and the
options(4) manual page.
When compiling an OpenBSD kernel, there are two different files that
you may need to edit in order to add or remove all of the required
options. The first configuration file,
/usr/src/sys/conf/GENERIC, contains options that
are common across all the architectures OpenBSD can run on. OpenBSD
has been ported to many platforms, including i386, Sparc, PowerPC,
and VAX. Some options, such as firewalling and IPv6 support, are
shared between all the platforms, and therefore when you change an
option in /usr/src/sys/conf/GENERIC, it will be
reflected in any kernel you build for any
platform.
The second file is the platform-specific file found in
/usr/src/sys/arch/<arch type>/conf/. The
<arch type> is whatever architecture
you’re running on, which in most cases is i386.
There is a GENERIC file in the architecture specific directory. You
may edit this file directly or copy it to a new name, such as the
hostname of your machine in all caps, for editing.
Your wireless card will probably be either PCI-based or PCMCIA-based. Add the appropriate options and devices to your architecture-specific configuration file:
# PCI PCMCIA controllers pcic* at pci? dev? function ? # PCMCIA bus support pcmcia* at pcic? controller ? socket ? pcmcia* at tcic? controller ? socket ?
You must then add the proper devices for your particular wireless
card. The wi driver works with Prism II-based
cards as well as Hermes cards such as the Orinoco Silver. The
an driver works with the Cisco wireless cards. Add
the correct driver for your card. Note that there are different
configuration lines depending on whether your card is PCI or PCMCIA
based:
wi* at pci? dev ? function ? # WaveLAN IEEE 802.11DS wi* at pcmcia? function ? # WaveLAN IEEE 802.11DS an* at pci? dev ? function ? # Aironet IEEE 802.11DS an* at pcmcia? function ? # Aironet IEEE 802.11DS
Now that you have support for your wireless cards, remove support for anything you do not need. For example, the GENERIC configuration file has many SCSI controllers and ISA network cards turned on by default. Comment out any devices you do not have. Once you have stripped down both the architecture-specific configuration file and the global file, compile your kernel according to the instructions on the OpenBSD web site. Verify your machine is operating as you expect it to. Once you have a functioning, bare-bones kernel, continue on to the security-specific configuration.
The OpenBSD development
teams place security above almost all else. Because of this, there
are many security-specific options that you can and should compile
into your kernel. Most of these options are in the global kernel
configuration file that is found in
/usr/src/sys/conf/GENERIC.
OpenBSD has a cryptographic framework that allows drivers to hook into cryptographic services provided by the kernel. The IPsec implementation relies heavily upon the cryptographic framework. If you plan on using IPsec, enable this support with the following option:
option CRYPTO # Cryptographic framework
If you plan to use IPsec to secure your traffic, you will need to compile in IPsec support:
option IPSEC # IPsec
OpenBSD’s
firewall is provided a mechanism called packet filter (pf
). pf provides a device
(/dev/pf ) to allow userland control of the
firewall. Through /dev/pf you can issue
ioctl calls to add and remove rulesets, gather
statistics on the firewall, and enable or disable the firewall
completely. Through the use of pflog,
pf can also provide packets to userland
processes through a pseudo-interface called
pflog. A firewall ruleset can log all denied
packets to a pflog interface (such as
pflog0) and a sniffer program such as
tcpdump can monitor all the logged traffic. You
should enable both pf and
pflog:
pseudo-device pf 1 # packet filter pseudo-device pflog 1 # pf log if
Finally, you should enable the ability to promiscuously sniff traffic
from local interfaces. This ability can help greatly in debugging
network problems and in using network-monitoring tools. This is
accomplished through the use of a Berkeley Packet Filter
(bpfilter). bpfilter will
create a certain number of devices that will limit the number of
connections processes can make to promiscuous interfaces. For
example, if you have four different interfaces, then you will
probably want four bpfilter instances so you can
sniff on all interfaces at once:
pseudo-device bpfilter 4 # packet filter
There are several different ways
to manipulate the wireless network card once the system is online.
For Prism II and Hermes-based cards, the
wicontrol utility can be used to configure
wireless specific parameters. For Cisco Aironet cards the
ancontrol utility is used instead. Some wireless
capability has been added for all chipsets into the standard
ifconfig utility. However you choose to
configure your wireless network, you must be sure you configure your
IP-specific parameters as well.
The following parameters are the more commonly used features of
wicontrol. For a complete list, please see the
wicontrol manual page.
-
interface This is the interface that
wicontrolshould operate on. If no interface is specified,wi0is assumed. If no other flags are passed towicontrol,wicontrolwill print out the existing configuration and statistics of the interface.- -n
network name This parameter specifies the name of the service set to join. In infrastructure mode, this would be the ESSID and in IBSS mode this would be the SSID of the network you wish to join. An empty string instructs the card to associate to the strongest available service set.
- -s
station name The station name is the value your station is to be known by on the network. Certain diagnostic and monitoring utilities will attempt to determine the station name in an effort to uniquely identify the end host. This is not required and should not be set.
- -f
channel This parameter indicates what channel the card should use to communicate with the access point. This value must be the same as the access point’s channel or else association will not be possible. If no channel is specified, the card will scan all channels in an attempt to find an available access point.
- -p
port type This specifies the type of network to join. A value of
1orbsswill cause the card to only associate to infrastructure mode access points. A value of4oribsswill cause the card to operate in ad-hoc mode.- -k
key [ -v 1|2|3|4 ] This parameter controls the various WEP keys used by the station to authenticate and encrypt traffic to the access point.
keycan be entered either as decimal (e.g.,secrt) or as hexadecimal (e.g.,0x0123456789). The numbers following the key indicate which key index the specified key should be placed in. The WEP specification allows for four different keys to be stored for use in various key rotation strategies. If the -vflag is not specified, the first index is assumed.- -T
1|2|3|4 This parameter specifies the index of the WEP key to use for encrypting transmitted frames.
For example, to configure your wi0 interface to
associate to the ESSID Example using the WEP key
secrt, issue the following command:
wicontrol wi0 -n Example -k secrt
To display statistics and configuration parameters of the
wi0 interface, run the following command:
bash-2.05a# wicontrol wi0 NIC serial number: [ 99SA01000000 ] Station name: [ WaveLAN/IEEE node ] SSID for IBSS creation: [ IBSS ] Current netname (SSID): [ Example ] Desired netname (SSID): [ Example ] Current BSSID: [ 00:02:2d:04:3d:5d ] Channel list: [ 2047 ] IBSS channel: [ 11 ] Current channel: [ 1 ] Comms quality/signal/noise: [ 51 98 0 ] Promiscuous mode: [ Off ] Port type (1=BSS, 3=ad-hoc, 6=Host AP): [ 1 ] MAC address: [ 00:04:e2:36:68:02 ] Etc......
The ancontrol
utility for the Cisco cards is similar to the
wicontrol utility. Unfortunately the options
passed to the different utilities are different. Again, the options
discussed below are not a complete list of all possible options that
can be passed to ancontrol. For the complete
list and explanation, please see the ancontrol
manual page.
- interface
This is the interface that
ancontrolshould operate on. If no interface is specified,wi0is assumed. If no other flags are passed towicontrol,wicontrolwill print out the existing configuration and statistics of the interface.- [ -v 1|2|3 ]
-n ssid These options work in tandem to allow you to specify a hierarchy of service sets to join. The card will attempt to associate to the SSID specified in the first index, then the second, and finally the third. If the -
voption is not used, the specified SSID is placed in the first index location.- -l
stationname The station name is the value your station is to be known by on the network. Certain diagnostic and monitoring utilities will attempt to determine the station name in an effort to uniquely identify the end host. This is not required and should not be set.
-
-cchannel This parameter indicates what channel the card should use to communicate with the access point. This value must be the same as the access point’s channel or else association will not be possible. If no channel is specified, the card will scan all channels in an attempt to find an available access point.
- -o
0|1 This option specifies the network mode the card will attempt to join. A value of 0 instructs the card to join an ad-hoc network. A value of 1 will cause the card to participate in infrastructure mode networks.
- -v
0|1|2|3|4|5|6|7-kkey These options work together to specify the WEP keys the card will use to communicate with. The
ancontrolcan only have four keys configured at a time. The even indexed keys are considered “permanent” and are stored in NVRAM on the card. The odd number keys are “temporary” and are stored in volatile memory.keycan be entered either as decimal (e.g.,secrt) or as hexadecimal (e.g.,0x0123456789). Unless the -e flag is used to specify the key to use to transmit,ancontrolwill use the most recently entered key.-
-e 0|1|2|3 This is the index of the WEP key to use to transmit encrypted frames.
-
-v 1|2|3|4 -aAP This option allows you to specify the MAC addresses of the preferred access points. The MAC address must be entered as six hexadecimal values separated by colons. By providing MAC addresses for your access points, your provide some level of protection from an attacker standing up an access point claiming to be part of your service set and hijacking your association.
For example, to configure your an0 interface to
associate to the ESSID Example using the WEP key
secrt, issue the following command:
ancontrol -n Example -v 0 -k secrt
The wireless card needs to be
properly initialized and configured at boot time to avoid having to
hand configure the interface after each reboot. In OpenBSD, each
interface has a file in hostname named
hostname.<interface> that contains
information regarding the configuration of the interface. For
instance, the first Prism-based interface on a host will be
controlled by a file called hostname.wi0.
The file can specify basic IP configuration information as well as execute arbitrary commands to configure other aspects of the interface. At the most basic level, the IP configuration takes the following form:
addr_family [alias] address netmask broadcast_address options
addr_family can be inet,
inet6, or dhcp. For the
case of DHCP with no required options, the options fields should be
filed in with the string NONE. To execute commands
within the file, precede the command with an exclamation point. For
example, to configure the first Prism-based controller with an IP
address of 192.168.0.248 on a class C network with
a default gateway and associating to an SSID of
Example, use the following file:
inet 192.168.0.248 255.255.255.0 192.168.0.255 !route add default 192.168.0.1 !wicontrol $if -n Example
The hostname.interface file is very flexible and
powerful. For a complete discussion of the structure of this file,
see the hostname.if manual page.