Kernel Configuration

In order to securely use a wireless network, you must start with a secure host configuration. At the heart of any secure host is a solid, well-planned kernel configuration. A secure kernel must be governed by the Principle of Least Privilege. The Principle of Least Privilege indicates that a user or system should only be given the minimum amount of privilege in order to achieve the desired tasks. This means that a kernel should be stripped of all unneeded configuration options. If you don’t have any SCSI devices, then you shouldn’t have any SCSI devices specified in your kernel configuration.

Wireless Kernel Configuration

In order to use wireless NICs, the kernel must be configured to support the networking card. The process of compiling a Linux kernel is outside the scope of this book. For more information on compiling a kernel, see /usr/src/linux-2.4/README on your Linux system or http://www.tldp.org/HOWTO/Kernel-HOWTO.html. Configure and compile a kernel with as few configurations options as possible. Once you have a bare-bones kernel for your machine, continue with the steps in the rest of this chapter.

There are many ways to configure a kernel. Whether you use make menuconfig, make xconfig, or simply make config, the changes are saved to a configuration file. This file is typically in /usr/src/linux-2.4/configs/kernel-[ver].config. The configuration options specified in this chapter are directives in that file. How they get written to the file is up to you; you can edit it directly, or use the make *_config scripts.

Wireless NICs are generally connected to either an internal PCI connector or a PCMCIA (PC-card) interface. You must first enable whichever interface type you are going to be using. PCI support, probably already compiled in your kernel, is enabled with the following:

CONFIG_PCI=y

There is support in the Linux kernel for various PCI-based wireless cards including those made by Lucent, Cisco, and Linksys. Consult the kernel documentation to determine how to add support for your particular card.

PCMCIA can be added several ways. The easiest way to get wireless PC-card support on a 2.4 kernel is via the pcmcia-cs package, which is available from http://pcmcia-cs.sourceforge.net/. In order to use pcmcia-cs, you must enable loadable modules and disable native PC-card support:

CONFIG_MODULES=y
CONFIG_CARDBUS=y

Next, enable wireless networking support. This is also known as “non-hamradio” support:

CONFIG_NET_RADIO=y

You should be able to make and install your kernel at this point. Everything else is handled via the pcmcia-cs package.

Most Linux distributions ship with precompiled pcmcia-cs modules. You can probably use the precompiled distribution of pcmcia-cs with no problems. If you have a reason to compile pcmcia-cs by hand (or are feeling adventurous), then press on.

Download the pcmcia-cs source from http://pcmcia-cs.sourceforge.net/. Uncompress the source code in the same directory that contains the root of your Linux source code (usually /usr/src). Enter the directory that was created during the decompression and run make config. You will be asked the following questions:

Alternate target install directory?

You can specify where your Linux source code is. This defaults to /usr/src/linux.

Build “trusting” versions of card utilities?

Normally, the utilities created in this package must be run by root to make changes to the card configuration. A “trusting” utility allows any user to modify the configuration of the card. Only build a trusting utility if you are sure this is what you want.

Include 32-bit (CardBus) card support?

If you have CardBus cards you want to use, you must enable this feature. Even if you do not have CardBus cards at this point, it is usually safe to enable this feature.

Include PnP BIOS resource checking?

PnP BIOS resource checking allows pcmcia-cs to try to avoid resource conflicts on the host. However, this option may cause problems on some machines. You may or may not have to use this option.

Module install directory?

You can specify an alternate module directory if needed.

Once you have answered these questions, run make all then make install. Review the files in /etc/pcmcia to see if any changes need to be made to accommodate your equipment. Reboot the machine to verify your card is now recognized by the host.

Security Kernel Configuration

Now that the wireless devices are working properly, it is time to add security enhancements to the kernel. These security options will provide you with a hardened core for the rest of your client to use.

A firewall provides a primary line of defense against attacks from the network. This is particularly important in wireless networks. Two clients on the same access point typically have no network-level access control mechanism preventing them from communicating. Therefore, it is up to the client to defend itself from attacks from malicious wireless users.

Linux provides a robust firewalling mechanism called Netfilter. The Netfilter firewall is implemented in the kernel and controlled by a userland program called iptables. Previous versions (Version 2.2 and earlier) of Linux used a firewall called IPFW that could be controlled by either ipfwadm or ipchains, but these mechanisms have been deprecated. This chapter concentrates solely on using Netfilter and iptables to protect a client. For a more complex usage of Netfilter, see Chapter 11, where a Linux gateway configuration is explored.

Enable Netfilter with the following option: 

CONFIG_NETFILTER=y

There are many configuration options for Netfilter. Some are required, however most of the following options can be added at your discretion based on your needs:

CONFIG_IP_NF_IPTABLES

This option provides the framework in the kernel that iptables uses to manage the firewall. This option is required.

CONFIG_IP_NF_FILTER

This option allows the firewall to filter packets that the host is attempting to send and receive. This option is required.

CONFIG_IP_NF_MATCH_MAC

This option allows the firewall to match packets based on source and destination MAC addresses. This can be very useful on a wireless network where IP spoofing is very easy to perform.

CONFIG_IP_NF_MATCH_STATE

This parameter turns Netfilter into a stateful firewall. Stateful firewalls are able to keep track of active and legitimate sessions. After a packet has been sent and received forming a two-way conversation, the firewall will add that session to a state table. This state table allows for faster parsing of packets in an established session as well as preventing forged established packets from getting through (this is a problem with packet filtering firewalls such as IPFW). This option is not required but is very strongly recommended, as our examples make use of these features.

CONFIG_IP_NF_CONNTRACK

This option allows connections to be tracked by the firewall. This makes use of the stateful nature of Netfilter to track established connections in a more efficient manner.

CONFIG_IP_NF_FTP

This module adds logic for tracking FTP connections in the firewall. FTP connections are historically difficult for firewalls to handle since they have separate command and data channels. With this module, both active and passive mode FTP are possible.

CONFIG_IP_NF_IRC

This is similar to the FTP connection-tracking module. It provides higher-level logic to allow the firewall to properly track IRC connections.

CONFIG_IP_NF_TARGET_LOG

This option allows the firewall to log packets to syslog for further examination. Logging a packet sends a great deal of information regarding the packet to the log facility allowing for very detailed analysis of an ongoing attack.

This should be enough to configure a robust client firewall. For an example of a client Netfilter configuration, see Section 5.3.1 in this chapter.

CONFIG_SYN_COOKIES

This option allows for a SYN-flood mitigation technique called SYN Cookies to be used. SYN Cookies work by creating a cryptographic challenge in the ACK packet to verify a SYN packet is part of a legitimate session. It takes up a fair bit of resources on the host when turned on. Even when allowed in the kernel, SYN Cookies are turned off by default. You can enable them by issuing the following command:

echo 1 >/proc/sys/net/ipv4/tcp_syncookies

This should not be required on a machine that is only a workstation and not a server. If you are running any services on your machine you should at least have SYN Cookies support enabled.

CONFIG_PACKET=y

This configuration options allows raw packets to be captured from an interface. This is similar to BPF support in the FreeBSD kernel. A root user can use the packet capability to listen for frames destined for other machines on the network. This option is required to run programs such as tcpdump or arpwatch.

Startup Configuration

At boot time, the wireless NIC needs to be initialized with the proper information. All wireless specific information is stored in /etc/pcmcia/wireless.opts. The file that comes with your distribution probably has entries for different cards. While having the ability to select different network settings for different cards may be useful, it is not normal. Most people will want to have the same network setting regardless of what card they are using. You can accomplish this using the following as a template:

case "$ADDRESS" in
*,*,*,*)
    # INFO - name describing this connection
    INFO="Wireless Netork"
    # ESSID - Name of ESSID to join.
    ESSID="Example"
    # MODE - Operation Mode.  Common values are Managed for associations
    # to an access poing and Ad-Hoc to join an iBSS
    MODE="Managed"
    # RATE - Data rate of the connection.  Auto allows the card to 
    # select the best for the condition.
    RATE="auto"
    # KEY - WEP key.  Hex keys are entered like 0123-4567-89.  ASCII
    # keys are pre-pended with an s.  s:secrt
    KEY="s:secrt"
    ;;
esac

The default wireless.opts file has more values that can be configured based on your needs. Read through the file if you require a more advanced configuration. All of the values set in wireless.opts are passed to iwconfig to configure the card. For information on iwconfig, see the next section, Section 5.2.4.

The default startup files should handle getting the interface up and configured beyond the wireless options. However, the interface will probably be configured for DHCP by default. If you wish to configure a static IP address, you will have to edit /etc/sysconfig/network-scripts/ifcfg-[device]. This is an example of an ifcfg-eth0 set to a static IP address:

DEVICE=eth0
IPADDR=192.168.0.100
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
GATEWAY=192.168.0.1
ONBOOT=yes

For a client that will use DHCP to acquire an address, the following can be used instead:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=DHCP

Card Configuration

Configuring a wireless NIC under Linux is a two-step process. The wireless-specific parameters must be set using the iwconfig utility. Once the card has formed a proper association with an access point, then the IP specific information should be configured via the ifconfig utility.

iwconfig uses the following configuration parameters:

interface

This is the name of the interface to be configured. Typically this value will be something like eth0. If iwconfig is passed the interface name only and no other configuration parameters, it will return the current configuration of the wireless interface.

essid essid

This is the name of the Extended Service Set ID (ESSID) to join. This value must the same as the similar value on the access point. A value of any will cause the client to associate with the strongest detected access point. This is not recommended since a nearby attacker may force your client to reassociate with a hostile access point.

nwid nwid

This is the network ID. A network ID is a mechanism used to identify particular access points within an SSID. Many access points may have the same SSID and therefore provide service to the same network. However the nwid for each access point may be different, allowing users to “hard code” what access point they wish to associate with. A value of off will disable nwid checking. This value is not required.

channel channel

This is the channel used to communicate with the access point. The 802.11b PHY specification describes channels in the 2.4 GHz ISM band for use by 802.11b radios. In the U.S., there are 11 usable channels, while European countries have 14. The client must specify the same channel as the access point in order to be able to communicate with it.

mode mode

This is the type of network in which the client will participate. The options are managed for associations with access points and ad-hoc for forming associations in IBSS mode.

ap mac-addr

This is the MAC address of the requested access point. By setting this parameter, the client will only associate with an access point with the specified MAC address. This is useful to minimize the risk presented by nearby rogue access points attempting to spoof your SSID and NWID. An example of this flag is ap 00:08:20:4e:5e:1f. This flag is not required.

key [wepkey] [index] [mode]

This flag controls all the WEP configuration options. The WEP key may be entered as hex (e.g., 0123-4567-89) or ASCII pre-pended with s: (e.g., s:secrt). Multiple keys can be entered and referenced by specifying an index value between 0 and 3. Finally, the association mode can be set to control how the client handles WEP and non-WEP packets. on and off turn WEP protection on and off, respectively. open allows the card to form WEP or non-WEP associations based on what access points are available. restricted will force the card to form WEP-only associations.

This is not a complete list of the flags that can be passed to iwconfig. Other options include power-saving configurations, sensitivity requirements, and client-side identification issues. For a complete list of supported flags, run man iwconfig.

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

iwconfig eth0 essid Example key s:secrt restricted

iwconfig can also be used to query the state of the wireless NIC by passing only the interface name as a parameter:

[root@mo root]# iwconfig eth0

eth0      IEEE 802.11-DS  ESSID:"Example"  Nickname:"Prism  I"
          Mode:Managed  Frequency:2.412GHz  Access Point: 00:02:2D:04:3D:5D
          Bit Rate:2Mb/s   Tx-Power=15 dBm   Sensitivity:1/3
          RTS thr:off   Fragment thr:off
          Encryption key:3433-6435-64
          Power Management:off
          Link Quality:92/92  Signal level:-11 dBm  Noise level:-102 dBm
          Rx invalid nwid:0  invalid crypt:0  invalid misc:0

The WEP key is displayed by iwconfig because the command was run as root. If a non-root user runs iwconfig, the encryption key will not be in the output.

Once the wireless-specific information has been configured, any IP information can be configured as usual with ifconfig. While FreeBSD allows you to configure all wireless and IP parameters via the ifconfig utility, Linux requires two different programs to be run in order to achieve the same result.

Card Utilities

There are several other iw-based commands that can be useful for configuring a client card:

iwgetid interface

This command will return the value of the SSID of the access point to which the client is currently associated.

iwlist [interface] [freq | ap | rate | key | power | txpower | retry]

This command will return various statistics from the wireless interfaces on the client computer and is useful for determining the capabilities of the card. For example, iwlist key will list the available key lengths and the existing keys stored on the card. iwlist rate will give the various data rates at which the card is capable of transmitting.

iwspy interface {+] IPADDR | HWADDR [...]

Iwspy is a mechanism to track the quality of a link between your node and another on the wireless network. You must first set what IP or MAC address you wish to track (e.g., iwspy 192.168.0.1). Pre-pending a + to the list of addresses will add the address set to the end of the existing set of addresses being tracked. Once you are tracking addresses, you can then check the status of that link by passing only the name of the interface:

[root@mo root]# iwspy eth0
eth0      Statistics collected:
    00:60:1D:20:E0:00 : Quality:91/92  Signal level:-11 dBm  Noise level:-102 dBm 
(updated)
iwpriv interface private-command [private-parameters]

This command can set driver-specific parameters which are not accessible via the iwconfig command set. For instance, if you need to enable the roaming features which exist in the wavelan_cs drivers, you would use iwpriv to do so.

Finally, you can query the status of any wireless interface via the /proc filesystem:

[root@mo root]# cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets              |
Missed
 face | tus | link level noise |  nwid  crypt   frag  retry   misc| beacon
  eth0: 0000   92.  245.  154.       0      0      0      0      0        0
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.209.8