[Gllug] Forwarding mac address...

Nix nix at esperi.org.uk
Sat Nov 15 17:41:10 UTC 2003


On Fri, 14 Nov 2003, Chris Bell stipulated:
>    I looked a while ago and found more than one HOWTO on bridges,
> transparent bridges, transparent bridge + firewall + DSL, etc. Transparent
> bridges without any IP address looked interesting for use on an ADSL
> connection with restricted IP addresses, but could they pose problems while
> updating their software? Perhaps add a serial connection with normal IP
> address as well?

What I've done is quite involved but also quite secure (I think/hope).

host: two bridges, adsl and gordianet. `gordianet' is the LAN interface,
and ties together a TUN/TAP device (tap0) and the physical LAN
interface; it has the machine's local IP address.

`adsl' ties together another TUN/TAP device (tap1) and the ADSL
interface; it has *no* IP address on the host.

`inflight' is another TUN/TAP interface that I'll explain below.

This is likely to be the nastiest part to get working, so here's the
code that sets that up (using Alexey Kuznetsov's ip(8) tools):

(It's complicated by the fact that the ADSL router is on the same subnet
as IP addresses go as the inner network, but on the ADSL interface ---
of course. So there's an extra route to handle that.)

# Bring up the inner network, the Gordianet.
# All the real networks consist of physical network links
# bridged to TUN/TAP devices, so that the UML-based firewall
# (esperi) can access the network. (It's the only thing
# except for Snort which accesses the ADSL link.)

# First, set up the physical links for the internal network
# (the Gordianet), and the ADSL link.

ip link set eth0 up multicast on txqueuelen 100 mtu 1458 name gord-phys
ip link set eth1 up multicast off txqueuelen 50 mtu 1458 name adsl-phys

# Now set up the TUN/TAP links. They're always called the same thing
# (tap0, tap1, and tap2).

for name in 0 1 2; do
   tunctl -u firewall >/dev/null
   ip link set tap${name} mtu 1458 up
done

# Create the bridges.

for name in gordianet adsl; do
    brctl addbr $name
    brctl stp $name off
    brctl setfd $name 1
    brctl sethello $name 1
done

# Populate them.

brctl addif gordianet gord-phys
brctl addif gordianet tap0

brctl addif adsl adsl-phys
brctl addif adsl tap1

# Bring them up.

ip link set dev gordianet mtu 1458 up
ip link set dev adsl mtu 1458 up
ip link set dev tap2 mtu 1458 up

# Give the Gordianet link its IP address (there is intentionally none
# associated with the ADSL link, as only the firewall should ever reference
# it, nor with the tap2 link, as only snort references it, and neither
# need an IP address to do that.)

ip addr add local 192.168.14.16/24 broadcast 192.168.14.255 dev gordianet

# Point the default route, and the route for the ADSL router configuration
# dialog, to the firewall UML partitions.

ip route add default via 192.168.14.1 dev gordianet
ip route add 192.168.14.160 via 192.168.14.1 dev gordianet


The tap1 device (the ADSL interface) points to a nearly-userspaceless
UML partition. It runs nothing but syslogd, klogd, and init, and as soon
as I've hacked UML to send kernel messages directly to my syslog server
it'll not run those either. Its boot script starts up the bridging
firewall, which is pretty much identical to a standard NATting firewall:
I don't do any layer 2 filtering at all. None of its network interfaces
have any IP addresses on them, but that doesn't affect packet filtering
:)

The interaction of bridging and iptables is explained in more detail
here: <http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html>.

The only wrinkle to be aware of is that while the bridge is in learning
state, it forwards *all* packets to *both* sides of the bridge --- so
you don't want to REJECT those packets, or the bridge will pass the
REJECT back and you'll get unexpected connection drops (because the
packet's been duplicated, REJECTed on one side and ACCEPTed on the
other). So this means a rule like this:

iptables --append in-all --jump LOG --in-interface lan --source ! 192.168.0.0/16 --log-prefix "nonlocal inbound on local "
iptables --append in-all --jump DROP --in-interface lan --source ! 192.168.0.0/16

not this:

iptables --append in-all --jump LOG --in-interface lan --source ! 192.168.0.0/16 --log-prefix "nonlocal inbound on local "
iptables --append in-all --jump REJECT --in-interface lan --source ! 192.168.0.0/16


The bridging firewall talks over another TUN/TAP link to the `primary
firewall' UML partition, a pretty ordinary stripped-down firewall
running a few port forwards, an sshd, some daemons to keep my ADSL link
up whenever it goes down because of the wrong kind of electrons on the
line, and not very much else. *This* then has a link to tap0, the
gordianet bridge on the host.

That `other TUN/TAP link' is exposed on the host as the tap2 interface,
and snort listens to it, beyond the ken of attackers.

Oh, and both the UML filesystems are stored on CD-R; the one with a
useful userspace uses the UML copy-on-write filesystem so that I can
upgrade it more easily. The firewall only gets touched when a kernel or
iptables security hole is discovered, so it's not CoWed at all.

Here's a diagram, in very bad ASCII-art, where [blah] is a host,
blah is a network interface or bridge, and / UML / indicates a
transition into or out of a UML partition:

- adsl-phys -- [host] -- tap0 -- / UML / -- adsl -- [firewall] -
        \                 /                                     \
         \---- adsl -----/                                      |
                                                                |
     -------- adsl -- / UML / -- tap2 -- / UML / -- gordianet --/
    /    194.247.41.52            |
    |                 [snort, listening on host]
    |
    \--- [esperi, the *visible* firewall] -- gordianet -- / UML / --\
                                            (internal IP x)          |
                                                                     |
                              [LAN] -- gord-phys -- [host] -- tap1 --/
                                           \   (internal IP y)  /
                                            ------ gordianet  -/

Ah. A nice simple firewall setup. ;}

-- 
`Me, I want exploding spaceships and pulverized worlds and clashes of
 billion-year-old empires *and* competently written sentences.'
                                                    --- Matt Austern

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list