2008-04-17
The limits of isolated interfaces
So you've carefully isolated your management interfaces, making sure that packets can't leak from one side to another because they literally can't see the other side. You're safe, right?
Well, not quite. While an attacker can't get their own packets across to your management interface, they may still be able to trick things on your machine into generating outgoing packets for them. There's a number of cases:
- packets with a management origin to your management IP: this should
be handled by interface isolation, which makes the outside
interfaces pretend that the management IP isn't a reachable IP.
- packets with a management origin to your outside IP: if your programs
respond with the origin IP that they were contacted on, everything is
fine; the outside IP forces the packet to use the outside routing
table, which does not include your management network, which means
that they fail to route.
(TCP connections automatically behave this way, and my impression is that many but not all UDP-based programs behave this way because it makes life happier on multi-homed machines.)
- your programs are willing to send packets or initiate connections to an IP address that it gets from the payload of a message (for example, XDM works this way). This is trouble, because not even a firewall can stop these and programs on your system have access to all of the interfaces, including the management one.
(If you have things so isolated that only some programs can talk to the management interface, you've gone well beyond mere interface isolation.)
Just to make life more interesting, this exposure exists whether or not the machine actually routes packets; it is enough for it to be multi-homed on your management network and for an attacker to know it.
This doesn't let the attacker get arbitrary packets to your management network; depending on what they're tricking, the packet contents are likely to be highly restricted. Still, it's useful to remember that interface isolation is not a cure-all.