[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: caching dns lookups



Hello,

Dani Arbel wrote:

> Thats where IPtables comes in and adds the stateful inspection. all ports
> (above and under 1023 ) are closed unless specificaly opened (for
> supplying services) or for an expected incoming packets belonging to a
> stream initiated by a trusted machine.

I addressed this:
> >                      Connection tracking helps a bit, but is far from
> > perfect (esp. for UDP replies, since there is no explicit connection
> > close, so the "connection" is considered established long after the DNS
> > query was finished).

To elaborate, consider what happens when you do "nslookup foo.com"
without a local caching proxy. nslookup sends a UDP packet from, say,
client port 2048 to DNS server port 53. conntrack notes this. A second
later, the DNS server sends a UDP packet from its port 53 to client port
2048. conntrack considers this a reply to the first packet, and now
considers the "connection" to be established because it's seen traffic
both ways. conntrack doesn't know when a UDP connection ends, so it uses
a simple timeout mechanism: the connection is considered closed only
when there was no traffic either way for a fixed amount of time
(UDP_STREAM_TIMEOUT, hardcoded at 3 minutes). If you allow any UDP
packets marked ESTABLISHED by conntrack, you will accept UDP packets
from the DNS server to port 2048 for three full minutes. Worse yet, I
keep the connection established forever by sending some UDP packet every
2 minutes. Relevant code:
linux/net/ipv4/netfilter/ip_conntrack_{core,proto_udp}.c

Therefore, if you *ever* open a UDP-based service on this port, I could
access it by spoofing the DNS server's IP, which is dangerous in two
ways: first, if you indeed allow any packets on ESTABLISHED connections
then you're toast. Second, even if you try to set up some filters, it's
quite plausible that you'll inadvertantly allow the DNS server anyway
(because of some prior DNS-related rules in your chain, or because you
got your LAN netmask slightly wrong, et cetera).

After many DNS lookups (each from a different port), I get to access
just about any UDP-based service you open on any user port. I believe
this is a very real attack and that it's very easy to implement.


> > With a properly configured caching nameserver on your firewall, you just
> > need to allow packets/connections from port 53 of the ISP's DNS to port
> > 53 of your box. If you're in LAN settings there's also the obvious
> 
> no... close port 53 to packets from the Internet. Make your caching DNS
> use high port for its requests. You give dns services to your internal LAN
> only.

You're right about that. I don't want to use autoallocated user ports
because of the above, but it's good to tell named to query from a
*fixed* system port other than 53 and allow replies on that port instead
of 53.

  Regards,
    Eran Tromer

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il