Previous

Linux Wireless Access Point HOWTO

Next

Chapter 8. Configuring Firewalling


8.1 Overview of Firewalling

In this chapter we implement packet filtering to protect our Access Point and our local wired network. It is helpful to think of the wireless network as dirty just as we think of the Internet; We have little to no control over who uses the wireless network and for what purposes, so we do not trust it. Further, the data and systems we wish to protect are on our wired LAN.

The standard tool for packet filtering on modern Linux systems is called IPTABLES. It is a collection of kernel modules and userland tools which can be used to formulate complex firewalling solutions. More in-depth guides to iptables can be obtained from the netfilter homepage, the Linux 2.4 Packet Filtering HOWTO and of course the iptables manpage. IPTABLES is included in both Redhat kernels dealt with during this HOWTO. If you are using a different distribution or kernel that doesn't support IPTABLES, you will need to obtain or build a kernel that does.

Note that the IPTABLES configuration given in this chapter will be superceded by the NOCAT configuration outlined in Appendix B as NOCAT configures IPTABLES on the fly. Readers who intend to run NOCAT for HOTSPOTing on their Access Point can safely skip this section.


8.2 Example IPTABLES configuration file

There are a number of GUI tools for configuring IPTABLES, both free and commercial, but we will cut to the chase and edit the IPTABLES configuration file directly. As in other sections, presented here is an example configuration file which you can modify for your use, using the imbedded comments as a guide. In this case, lines beginning with a "#" are comments.

Note that this is a very simple IPTABLES configuration file. It has no facility for logging, reporting or Network/Port address translation. Outside of the core functionality required to make the various services on our Access Point available, nothing is catered for. Further, it assumes that NO traffic is to be allowed on to the LAN from the WLAN except for responses to LAN generated traffic, which may or may not suit your purposes. In short, you can use this example as the basis of your firewalling policy but will need to add to it or modify it extensively in order to make it suitable for use in your environment.

For Redhat, the IPTABLES configuration file is /etc/sysconfig/iptables - Which is used by the /etc/init.d/iptables startup script.

# Example /etc/sysconfig/iptables configuration file
#
# Turn on traffic filtering
*filter

# Set default policies
:INPUT DROP [1:44]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [27040:2493902]

# Accept all traffic from the loopback interface.
-A INPUT -i lo -j ACCEPT

# Accept legitimate responses to traffic we generate.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Accept SSH connections from the wired network only.
# Change this to your LANs IP network
-A INPUT -s 192.168.5.0/255.255.255.0 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s ! 192.168.5.0/255.255.255.0 -p tcp -m tcp --dport 22 -j DROP

# Allow ICMP, though there is a case for disabling it on the WLAN interface.
-A INPUT -s 192.168.5.0/255.255.255.0 -i eth0 -p icmp -j ACCEPT
-A INPUT -s 10.0.0.0/255.0.0.0 -i wlan0 -p icmp -j ACCEPT

# Allow inbound DNS requests from the wireless network.
-A INPUT -i wlan0 -p udp --dport 53 -j ACCEPT
-A INPUT -i wlan0 -p tcp --dport 53 -j ACCEPT

# Allow inbound DNS responses from our ISPs DNS servers.
# Change these to the IP addresses of your ISPs DNS servers.
-A INPUT -s 0.0.0.0 -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT
-A INPUT -s 0.0.0.0 -i eth0 -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -s 1.1.1.1 -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT
-A INPUT -s 1.1.1.1 -i eth0 -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT

# Allow inbound DHCP from the Local wireless network (note: not from 10.0.0/8)
# Change this to the network allocated for your use.
-A INPUT -s 10.1.2.0/255.255.255.0 -i wlan0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

# Allow inbound HTTP from the wireless network. Remove the "#" on the next line to enable.
# -A INPUT -s 10.1.2.0/255.255.255.0 -i wlan0 -p tcp -m tcp --dport 80 -j ACCEPT

# Allow inbound FTP from the entire wireless network. Remove the "#" on the next two lines to enable.
# -A INPUT -d 10.1.2.0/255.255.255.0 -p tcp -m tcp --dport 21 -j ACCEPT
# -A INPUT -d 10.1.2.1 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 21 -j ACCEPT

# Allow all related traffic to/from non-privileged ports.
-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow all traffic from the LAN to be forwarded to the WLAN.
# Change this to your LANs IP network
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth0 -o wlan0 -d 10.0.0.0/255.0.0.0 -j ACCEPT

# Forward all legitimate responses to forwarded traffic.
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Make it all true.
COMMIT
# Completed on Thu Jan 30 18:35:03 2003



8.3 Testing IPTABLES

Now that our configuration file is in place, we can test firewalling. We do this by ensuring that IPTABLES starts correctly, checking that the necessary modules have loaded and testing that connectivity between systems on our networks is filtered as we intended.

8.3.1 Starting IPTABLES manually

We start up IPTABLES with the following command, which will use the /etc/init.d/iptables script to load the necessary kernel modules and set out firewalling rules by loading the entries we made in /etc/sysconfig/iptables in section 8.2 above;

[root@accesspoint root]# service iptables start

Which should produce the following output;

Flushing all current rules and user defined chains:              [   OK   ]
Clearing all current rules and user defined chains:              [   OK   ]
Applying iptables firewall rules:                                          [   OK   ]

Take note of any errors as they will give us hints as to what has gone wrong. More often than not they will be syntax errors in the configuration file. If not, we can need to check that the necessary modules have loaded.

8.3.2 Checking that the IPTABLES modules have loaded

The kernel needs to load a number of modules in order for the firewalling functionality we require to be supported. We can check that the necessary modules have loaded with the following command;

[root@accesspoint root]# lsmod

Ensuring that the following modules are present. (Note that modules irrelevant to IPTABLES have been omitted from this list)

ipt_REJECT     3992       0     (autoclean)
iptable_filter    2444       1     (autoclean)
ip_tables           15096     3     [ipt_state ipt_REJECT iptable_filter]
ipt_state            1080       8     (autoclean)
ip_conntrack     27272     1     (autoclean) [ipt_state]


If the various IPTABLES modules are not present we can try manually inserting them into the kernel with the following command, again taking note of any errors for clues as to what may have gone wrong;

[root@accesspoint root]# insmod ip_tables


8.3.3 Using the IPTABLES userspace command

In order to see a list of the running IPTABLES rules, insert or delete new ones and generally manage firewalling, we can use the /sbin/iptables command. Refer to the iptables manpage for further information. The following command dumps the current running rules used by the kernel.

[root@accesspoint root]# /sbin/iptables -L

Which should show output similar to the following;

Chain INPUT (policy DROP)
target           prot     opt     source                destination
ACCEPT     all       --        anywhere           anywhere
ACCEPT     all       --        anywhere           anywhere     state RELATED,ESTABLISHED
ACCEPT     tcp      --        192.168.5.0/24   anywhere     tcp dpt:ssh
DROP          tcp      --        !192.168.1.0/24 anywhere     tcp dpt:ssh
ACCEPT     icmp   --        192.168.5.0/24   anywhere
ACCEPT     icmp   --        10.0.0.0/8           anywhere
ACCEPT     udp     --        anywhere           anywhere     udp dpt:domain
ACCEPT     tcp      --        anywhere           anywhere     tcp dpt:domain
ACCEPT     udp     --        0.0.0.0                anywhere     state ESTABLISHED udp spt:domain
ACCEPT     tcp      --        0.0.0.0                anywhere     state ESTABLISHED tcp spt:domain
ACCEPT     udp     --        1.1.1.1                anywhere     state ESTABLISHED udp spt:domain
ACCEPT     tcp      --        1.1.1.1                anywhere     state ESTABLISHED tcp spt:domain
ACCEPT     udp     --        10.1.2.0/24        anywhere     udp spts:bootps:bootpc dpts:bootps:bootpc
ACCEPT     tcp      --        anywhere           anywhere     state RELATED,ESTABLISHED tcp spts:1024:65535 dpts:1024:65535

Chain FORWARD (policy DROP)
target           prot     opt      source                destination
ACCEPT     all       --        192.168.5.0/24   10.0.0.0/8
ACCEPT     all       --        anywhere           anywhere     state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target           prot     opt      source                destination

Note that the information displayed is how IPTABLES has translated our configuration file. This can at times be misleading as it leaves some details out. If in doubt, refer to the configuration file.


8.3.4 Other methods of testing

Further testing of firewalling can be achieved by testing connectivity from other systems on your wired and wireless networks. The NMAP port scanner is invaluable in this regard and I recommend that you use it, both from your Access Point and from systems on your networks. If you did not install NMAP during our initial Redhat installation in Chapter 3, you can download and install it.

Further testing of your firewalling setup can be achieved simply by attempting to ping between systems on your networks, or attempting to connect to services that you have running. For instance, you may like to check that wireless clients obtain IP configuration successfully from the Access Point via DHCP and that they can perform DNS lookups. You may also like to confirm that wireless clients cannot ping machines on your wired LAN but that machines on your LAN can ping wireless clients.

Security is always a major concern and it is over to you to audit your network and ensure that it is adequately protected on an on-going basis.


8.4 Enabling IPTABLES from startup

As we did with DHCPD, NAMED, ZEBRA and OSPFD in previous chapters, we need to turn on IPTABLES from boot using the setup utility. We add IPTABLES to our list of services that should start at boot time by adding an asterix beside the IPTABLES entry in the System services menu of setup as described in section 3.3



Previous Home Next