The firewall configuration on a wireless client is relatively simple. Most clients are not running any services such as web or mail servers. The only new connections should be outbound from the host; there should be no inbound connection requests. If you do have services running on your client, you will need to modify your firewall configuration appropriately.

The Netfilter firewall included in Linux 2.4 is controlled by the program iptables. In a nutshell, Netfilter uses a list of firewall rules called chains to process packets. There are three different chains in a Netfilter firewall:

In order to manage the firewall, you need to create a shell script that invokes the proper iptables commands to implement your desired ruleset. The example file below is a simple firewall configuration for a wireless client. It makes use of the stateful options in Netfilter. Be sure to have the appropriate modules compiled into the firewall as documented in “Security Kernel Configuration” earlier in this chapter. For more information on iptables and Netfilter, see Chapter 11, http://www.netfilter.org/, or the iptables man page.

#!/bin/sh
# simple rc.firewall to for wireless client

# setup variables
IPTABLES=/sbin/iptables 

# flush all chains to get a clean start
$IPTABLES -flush

# Both INPUT and FORWARD chains will be jumped to the user-defined
# "client" chain
# Create the client chain
$IPTABLES -N client

# Allow any established traffic through
$IPTABLES -A client -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept any new connections that are not coming in the primary Ethernet
# interface (the wireless interface)
$IPTABLES -A client -m state -state NEW -i ! eth0 -j ACCEPT

# Drop everything else
$IPTABLES -A client -j DROP

# Jump the INPUT and FORWARD chains to the client chain
$IPTABLES -A INPUT -j client
$IPTABLES -A FORWARD -j client

# allow all outbound traffic
$IPTABLES -A OUTPUT -j ACCEPT

Save this as an executable file at /etc/init.d/rc.firewall. Then add the following lines to /etc/rc.d/rc.local:

# IP Firewall
echo "starting IP Firewall"
/etc/init.d/rc.firewall

At the next reboot, your firewall rules will take effect. To immediately apply the firewall rules, run /etc/init.d/rc.firewall. Some distributions may have an alternate way to load firewall rules at boot time. Refer to your distribution’s documentation for any potential issues.

The Principle of Least Privilege not only applies to kernel compiling but also to services running on your workstation. Extraneous services running on your host are potential vectors for attackers to compromise your machine. The more services you have running, the higher the likelihood of one of them having a security vulnerability. Determine what services you need to have running and disable all others. By disabling unneeded services, you minimize your exposure to the attack and simplify your job as a systems administrator.

You can determine what services you are offering by using the -i flag with the lsof utility:

[root@mo etc]# lsof -i
COMMAND    PID USER   FD   TYPE DEVICE SIZE NODE NAME
portmap    639 root    3u  IPv4    913       UDP *:sunrpc
portmap    639 root    4u  IPv4    914       TCP *:sunrpc (LISTEN)
rpc.statd  668 root    4u  IPv4    939       UDP *:844
rpc.statd  668 root    5u  IPv4    966       UDP *:1024
rpc.statd  668 root    6u  IPv4    969       TCP *:1024 (LISTEN)
sshd       933 root    3u  IPv4   1198       TCP *:ssh (LISTEN)
xinetd     966 root    3u  IPv4   1222       TCP mo:1025 (LISTEN)
xinetd     966 root    3u  IPv4   1273       TCP *:echo
sendmail  1006 root    4u  IPv4   1274       TCP mo:smtp (LISTEN)
X         1233 root    1u  IPv4   1477       TCP *:x11 (LISTEN)

The commands on the left have opened the ports specified on the right. On this host, echo and sendmail (smtp) are running. These services are probably not necessary and can be shut off. According to lsof, the echo port is controlled by xinetd, while the sendmail port is controlled by sendmail itself. In order to disable these services I will have to find the sendmail configuration and disable it and modify the xinetd configuration to stop launching echo.

Services can be started in any number of ways on a Linux machine. Many services, such as telnet, ftp, and portmapper are launched by a super daemon such as inetd or xinetd. inetd has been the standard super daemon for quite a while. However, some distributions such as RedHat have migrated to xinetd due to its enhanced feature set and security.

Services started through inetd are controlled via inetd.conf (usually found in /etc). You can stop services launched by inetd by commenting them out of inetd.conf with a hash mark (#). These changes will take effect on the next reboot. To have the changes take effect immediately, send a HUP signal to inetd to force it to reread its configuration file:

killall -s HUP inetd

xinetd configuration is a bit different. On most systems, there is a configuration wrapper file at /etc/xinetd.conf. This file calls scripts located in /etc/xinetd.d/. To disable services listed in xinetd.d, add the following line to the configuration file for the desired service:

disable = yes

Again, changes will take effect on the next reboot. xinetd will not reread its configuration file when sent a HUP signal. The process must be terminated completely and restarted for changes to take effect immediately:

killall xinetd; xinetd -stayalive -reuse -pidfile 
   /var/run/xinetd.pid

For a tutorial on all that xinetd has to offer, see http://www.macsecurity.org/resources/xinetd/tutorial.shtml.

For services not launched out of a super daemon, they are probably launched out of one of the runlevel startup directories. The startup files are stored in varied locations depending on your distribution, for example, /etc/rc.d/rc[0-6].d on RedHat and /etc/rc[0-6].d on Debian. The number corresponds to the runlevel in which the scripts are invoked. Most of the time, the scripts you will want to disable are in rc2.d and rc3.d. To disable a service in the rc directories, rename the file to start with something other than an S, usually a K. For example, in order to disable sendmail on RedHat, perform the following:

cd /etc/rc.d/rc2.d
mv S80sendmail K80sendmail

Sendmail will not start at the next reboot.

ARP poisoning attacks, discussed in Chapter 2, are a real threat to all entities on a wireless network. A host on a wireless network can fall victim to a man-in-the-middle or DoS attack due to a malicious user poisoning your ARP cache. By statically assigning MAC-to-IP address mapping for important hosts on the network, you can minimize the risk posed by ARP poisoning attacks.

At the very least, you should set a static ARP entry for your default gateway. The following is an example file which you can place in /etc/init.d/staticarp to perform that task. Replace the <gatewayIP> and <gatewayMAC> with your specific values:

#!/bin/sh
# This script will set static arp entries for Linux
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

In order to have the ARP entries loaded automatically at boot time, make sure the file is executable and add a symlink in /etc/rc.d/rc2.d:

[root@mo rc2.d]# chmod 755 /etc/init.d/staticarp
[root@mo rc2.d]# cd /etc/rc.d/rc2.d
[root@mo rc2.d]# ln -s /etc/init.d/staticarp S98staticarp

Depending on your level of paranoia, you can further secure your workstation. These enhanced security concerns are outside the scope of this book. A good reference on Linux security is the Linux Security HOWTO available at http://www.tldp.org/HOWTO/Security-HOWTO.html.