Flylib.com

Books Software

 
 
 

Hack65.Protect Your Bridge with a Firewall


Hack 65. Protect Your Bridge with a Firewall

Maintain control over your Layer 2 bridge with iptables and ebtables .

As shown in "Bridge Your Linux AP" [Hack #64] , creating a Linux Ethernet-to-wireless bridge is straightforward. While this allows for easy integration with your existing network, it isn't always the best decision from a security point of view. Rather than simply connect two networks together at Layer 2, wouldn't it be nice to be able to tightly control the flow of packets between the two networks?

In 2.4.x kernels when 802.1d bridging was in effect, the netfilter/iptables code never saw bridged packets. In order to make traffic visible to standard firewall tools, you had to patch your kernel. Fortunately, the code (referred to as bridge-nf ) and the user -space binary ( ebtables ) are now a part of the 2.6 kernel series.

While third-party packages are available for Fedora Core, we were not able to get them or the source code (available at http://ebtables. sourceforge .net) to compile. So, this hack concentrates on Ubuntu Linux. However, ebtables should work with any 2.6 kernel.

Bridge-nf is part of the 2.6 kernel, so all you need to do is add the user-space binary package:


sudo apt-get install ebtables


With the binary installed, you can now manipulate the firewall exactly as you would expect using iptables . You can also use ebtables to do all sorts of interesting things at the MAC layer. For example, to ignore all traffic from a given IP that doesn't match a known MAC address, you could try this:


ebtables -A FORWARD -p IPv4 --ip-src 10.15.6.10 -s ! 00:30:65:FF:AA:BB -j
	DROP


This prevents other users from camping on known IP addresses. While it won't help much with MAC spoofing attacks, this will help keep average users from stepping on other people's IP addresses. You can also use it in reverse to lock a MAC address into a particular IP:


ebtables -A FORWARD -p IPv4 --ip-src ! 10.15.6.10 -s 00:30:65:FF:AA:BB -j
	DROP


This will prohibit the machine with the specified MAC address from using any IP but 10.15.6.10.

These are just a couple of examples of the power and flexibility of ebtables . You can also do all sorts of other neat things, such as MAC redirection and NAT, or filter on protocol types. (Need to drop all IPv6 traffic? No problem!) For more information, check out the ebtables web site as well as man ebtables .



Hack 66. Filter MAC with HostAP and Madwifi

Filter MAC addresses before they associate with your Linux- powered access point .

While you can certainly perform MAC filtering at the link layer using iptables or ebtables [Hack #65] , it is far safer to let the HostAP or Madwifi drivers [Hack #63] do it for you. This not only blocks traffic that is destined for your network, but also prevents casual snoopers from even associating with your access point.

Both drivers are configured to do MAC filtering through the iwpriv command. The most useful way to filter MAC address is to make a list of wireless devices that you wish to allow, and then deny all others:


iwpriv wlan0 addmac 00:30:65:23:17:05
	iwpriv wlan0 addmac 00:40:96:aa:99:fd

	iwpriv wlan0 maccmd 1
	iwpriv wlan0 maccmd 4


The addmac directive adds a MAC address to the internal table. You can add as many MAC addresses as you like to the table by issuing more addmac commands. You then need to tell Host AP what to do with the table you've built. The maccmd 1 command tells Host AP to use the table as an allowed list, and to deny all other MAC addresses from associating. Finally, the maccmd 4 command boots off all associated clients , forcing them to reassociate.

Sometimes, you need to ban only a troublemaker or two, rather than set an explicit policy of permitted devices. If you need to ban a couple of specific MAC address but allow all others, try this:


iwpriv wlan0 addmac 00:30:65:fa:ca:de
	iwpriv wlan0 maccmd 2
	iwpriv wlan0 kickmac 00:30:65:fa:ca:de


As before, you can use addmac as many times as you like. The maccmd 2 command sets the policy to deny , and kickmac boots the specified MAC immediately, if it happens to be associated. This is probably nicer than booting everybody and making them re-associate just to ban one troublemaker. Incidentally, if you'd like to remove MAC filtering altogether, execute maccmd 0 .

If you make a mistake typing in a MAC address, you can use the delmac command just as you would addmac , and it (predictably) deletes the given MAC address from the table. Should you ever need to flush the current MAC table entirely but keep the current policy, use this command:


iwpriv wlan0 maccmd 3


Finally, if you are running HostAP, you can view the running MAC table by viewing the appropriate data in /proc :


cat /proc/net/hostap/wlan0/ap_control


The iwpriv program manipulates the running wireless driver, but doesn't preserve settings across reboots. Once you're happy with your MAC filtering table, be sure to put the relevant commands in an rc script to run at boot time.

Note that even unassociated clients can still listen to network traffic, so MAC filtering does little to prevent eavesdropping and MAC impersonation. To combat passive listening techniques (as done with Kismet in "Detect Networks with Kismet" [Hack #29] ), you will need to encrypt your wireless data. Use WPA [Hack #42] to protect your wireless network at the link layer.