On Tue, Jan 06, 2004 at 05:40:45PM +0100, Henning Brauer wrote:
> it is still everything but easy to spoof packets onto an extsing
> connection. don't make stuff worse than it was; it wasn't.
It's not that spoofing (a non-TCP connection) is difficult (it's
trivial), but the kinds of setups where this matters is not all
that common.
We've been thinking about binding states to interfaces for a long while
now, and all this time I've tried to come up with a convincing scenario
where matching a state on an unrelated interface is really bad (so as to
justify the work, additional complexity and drawbacks). Just to give you
an idea, here's about the worst case I can imagine.
Say, you have a /24 netblock routed to your firewall, which is
three-legged, one interface to the internet, and two interfaces to two
local networks where hosts use half of your routable netblock each,
let's call them netA and netB.
You allow a host on netA to talk to a host on netB using some UDP protocol
that uses fixed or guessable ports (IKE, DNS, NFS), and create state on
both internal interfaces for such 'connections'.
Further assume that the protocol (or either host's implementation) has a
vulnerability that an external attacker could exploit by delivering
packets blindly (without getting any replies) and without prior
knowledge of protocol-related authentication and timing etc. to the
vulnerable local host, unless the firewall blocks it. You might strictly
block that protocol on the external interface and rely on just that block.
Since the states created on the local interfaces will allow matching
packets to bypass rule evaluation on the external interface, you can't
block the attacker's packets if they match. To exploit this, the attacker
has to know (or guess or brute-force) the IP addresses (and ports,
depending on protocol) of both local hosts. He sends the packet with
those addresses as source and destination. The packet arrives on the
external interface of the firewall (since the netblock is routed to
there), it matches one of the two existing state entries, passes, and
gets forwarded to the local destination, where it does the harm.
But this requires
- (at least) three interfaces on a single firewall
- creating state on several of them (not just the external one)
- routable addresses on multiple interfaces (the attacker can't
reach non-routable destination addresses, unless he's local)
- creating state for a non-TCP protocol with guessable parameters
(addresses, ports)
- a vulnerability within that non-TCP protocol on either local host
(which other local hosts may already exploit anyway, but
you trust them to not do so).
Separating the networks using multiple firewalls would prevent this, of
course. And none of this is relevant for TCP, as the attacker would have
to know the right sequence numbers there.
Daniel
