FYI - IP tunnelling via DNS

Paul A Vixie vixie at mibh.net
Mon Sep 11 22:30:45 UTC 2000


> Can someone help explain (briefly) the technique and exposure/risk of what
> was noted in the url? I understand how one can write code to construct
> whatever packet content is wanted, but I'm not sure I understand what
> within bind/dns is catching the packets and allowing tunnelling to some
> other application/system/network (and therefore do not understand the
> exposure/risk).  Is this actually tunnelling protocols/content other than
> dns, or is this another DoS mechanism?
> 
> In a corporate invironment with a typical firewall, would an external DNS
> server only (Linux or whatever, providing only DNS service) combined with
> firewall rules (that only allow internal dns servers to communicate with
> the one or two external dns servers (eg, internal forwarders)
> reduce/eliminate the exposure?  Or, is this just adding another hop to the
> tunnelling?

if dns data is allowed to flow, then this technique will allow ip packets
to be encapsulated inside that dns data.  the sending direction is encoded
into the name being queried for, which will be a pseudo-subdomain of some
domain for which the distant endpoint is authoritative.  dns is very adept
at routing queries toward authority servers.  the receiving direction is
encoded in TXT RR's which have TTL 0.  because the TTL is 0, the firewall
or gateway or proxy dns server or whatever else you've got will not cache
these "responses".  they can be forwarded intact, inside the dns response
sent by the "authority server" (really: the distant endpoint), or they can
be regenerated through an application layer firewall.

in other words this ip tunnel does not rely on dns messages, but rather on
dns data flows.  whether you're forwarding packets, or proxying transactions,
or regenerating through a cache, anywhere there is "dns connectivity" there
can be an ip tunnel.

this doesn't invalidate a firewall as a means of keeping people out of your
network, because it relies on a compromised or "owned" resource on both sides
of your firewall.  however, this invalidates a firewall's ability to keep
people INSIDE your network, since once they're in, they can use this technique
to contact arbitrary points on the outside.

some companies focus their firewall on preventing unauthorized outside access.
that will still work.

other companies focus their firewall on preventing information leaks from
determined insiders.  that really hasn't worked for a long time, but it will
absolutely not work now that this ip-over-dns technique is available.



More information about the bind-workers mailing list