As of writing this I've been running a bridging Linux box for almost two years. I started with 2.5.somewhat, when 2.5 became pretty usable (somewhen in summer 2003), and switched to 2.6 after the release.
I used a bridge to bind WLan and internal Ethernet together, with having the ability to filter on the bridge using iptables. While you can filter layer 2 stuff with ebtables under kernel 2.4 already high-level filtering on bridges with iptables is a 2.6-feature. Almost all Linux-based access points out there use a simple bridge, but since most run kernel 2.4 you can't try that much stuff.
The setup I assume here is pretty simple: eth0 is the internal interface, eth1 the interface with a WLan behind. Those two interfaces are meant to form a bridge. We have one more interface for Internet connection which we consequently ignore here.
Setting up the bridge
Setting up a bridge is pretty much straightforward. At first you create a new bridge, and then continue with adding as many interfaces to it as you want:
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ifconfig br0 netmask 255.255.255.0 192.168.32.1 up
The name br0 is just a suggestion, following the loose conventions for interface names -- identifier followed by a number. However, you're free to choose anything you like. You can name your bridge pink_burning_elephant if you like to. I just don't know if you remember in 5 years why you're having iptables for a burning elephant.
Setting up iptables
After the step above you're having a single interface to use. Problem there -- you'd like some paranoid filtering on everything that comes from the WLan. ebtables aren't of much help here -- you could create filters based on MAC addresses, but that's barely what you want to do. So we'll use iptables. But wait, a rule for br0 will match no matter where the packet came from! The solution is simple -- physdev-matching, a new feature of the 2.6 kernel series (you need recent iptables userland, of course). The sample iptables listing should explain how to use it.
Let's assume that people from the WLan are allowed to use full Internet (so no filtering there), but can only do ssh (port 22), smtp (port 25) and http (port 80) into our internal lan. They are not meant to use IRC (port 6667) anywhere, and we'd like to have SMTP connections redirected to our SMTP server. Of course they are not meant to notice the restriction, therefore we build the bridge and filter on the bridge. The iptables rules might look like tho following:
# log everything which comes in from the WLan. remember, we're paranoid :)
iptables -A INPUT -p udp -m physdev --physdev-in eth1 -j LOG
iptables -A INPUT -p tcp -m physdev --physdev-in eth1 -j LOG
iptables -A INPUT -p icmp -m physdev --physdev-in eth1 -j LOG
# allow ssh, smtp and http on the router _itself_ (INPUT!)
iptables -A INPUT -p tcp --dport 22 -m physdev --physdev-in eth1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -m physdev --physdev-in eth1 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m physdev --physdev-in eth1 -j ACCEPT
# reject all other connections to the router
iptables -A INPUT -p tcp --syn -m physdev --physdev-in eth1 -J REJECT
# allow the some on the FORWARD chain
iptables -A FORWARD -p tcp --dport 22 -m physdev --physdev-in eth1 --physdev-out eth0 -j ACCEPT
iptables -A FORWARD -p tcp --dport 25 -m physdev --physdev-in eth1 --physdev-out eth0 -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -m physdev --physdev-in eth1 --physdev-out eth0 -j ACCEPT
# reject irc to anywhere
iptables -A FORWARD -p tcp --dport 6667 -m physdev --physdev-in eth1 -j REJECT
# reject all other connections to the internal lan
iptables -A FORWARD -p tcp --syn -m physdev --physdev-in eth1 --physdev-out eth0 -j REJECT
This short introduction should give you a good start for playing with bridging on kernel 2.6. Comments about this text are appreciated, of course. You can make some port-scanners (like nmap) going crazy by not accepting things with stupid errors -- i.e. --reject-with icmp-proto-unreachable or --reject-with icmp-host-prohibited.
source : http://bwachter.lart.info/linux/bridges.html
No comments:
Post a Comment