Filtering bridge - how to decide which of the bridge's interfaces a packet arrived on?

Tobias Ernst tobi at casino.uni-stuttgart.de
Tue Oct 2 01:01:40 PDT 2007


Dear members of this list,

Recently, it was stated here by Andrew Thompson that

> anything that is destined for the
> local host is tapped off early and handled specially. 

This referred to the fact that packets passing through a bridging
firewall can be filtered on the individual inbound/outbound interfaces,
but packets destined for the bridging firewall (that has assigned an ip
address to the bridge interface) can only be filtered on the bridge
interface.

I have now run into a problem with this. I am setting up a routing
firewall with several DMZ, but for various reasons the DMZ use the same
IP range as the internal net. I.e., the DMZ are bridged to the internal
net, and the entire IP subnet is then routed to the external world.

To clarify things, this looks similar to the following:

bridge0 = em0, em1
bridge0 has IP x.x.x.254

DMZ connected to em0 and consists of the IP addresses x.x.x.0 - 15
Internal net connected to em1 and consists of x.x.x.16-253

em2 is the external interface and has IP x.x.y.123

Now, first of all, I wanted to set up a rule that makes sure that it is
impossible to use IPs from the internal range in the DMZ network segment
and vice versa, so that a hacked server in the DMZ cannot change its IP
and pretend to be one of our (maybe powered off) internal servers.

My first try was as follows:

block quick on em0 from !x.x.x.0/28
block quick on em1 from x.x.x.0/28

This works fine as long as a machine in the DMZ is trying to communicate
with a machine in the internal zone.

However, the above rules do not match packets sent from a machine with
an illegal IP in the DMZ and destined for the firewall, because those
packets only appear on bridge0. However, when I filter the packets on
bridge0, I have no idea whether they arrived on the DMZ interface or on
the internal interface.

Is there any other possibility of finding out which member of a bridge
an inbound packet has arrived on?

Regards
Tobias

P.S.: FreeBSD 6.2-RELEASE

-- 
Universität Stuttgart|Fakultät für Architektur und Stadtplanung|casinoIT
70174 Stuttgart Geschwister-Scholl-Straße 24D
T +49 (0)711 121-4228             F +49 (0)711 121-4276
E office at casino.uni-stuttgart.de  I http://www.casino.uni-stuttgart.de


More information about the freebsd-pf mailing list