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

Re: caching dns lookups



Greetings,

[I'll take the silence in reponse to the offtopicity query as an OK]

Dani Arbel wrote:
> 1) A high port that is being used as a source port for a query is never
> associated with a service (otherwise it would have been already allocated
> and hence not free for the query usage). If a late packet for this port
> arives, it will be droped by the ip stack (because no process is listening
> on that port). so the attack will only succeed in geting the packet one
> node further, but not to the application.

Sure -- if the service is already open. But I was describing the case
where the service is opened *after* (perhaps long after) the DNS query.
It could be some obscure service that's activated manually or at
specified times, and it could also be some buggy client application that
talks UDP and forgets to verify that the source IP imcoing packets is
correct. If you trusted your firewall to protect these (which is very
reasonable) then you're toast.


> 2) you could change the default time a udp stream live. a few seconds
> sounds reasonable.

a. A few seconds may not suffice for DNS queries that require several
lookups (cache misses, CNAME indirection). Other UDP services may also
suffer. 
b. If the attacker knows which port to target (see below), even a single
spoofed UDP packet per second would eventually catch an "established"
DNS connection.
c. This change requires a (trivial) kernel patch to
ip_conntrack_proto_udp.c. For many this isn't an option.


> 3) to actualy launch this attack, the attacker needs to know what dns you
> are using and sniff your traffic to know the ports in use at real time. if
> he can do that he must be located in the ISP backbone, and can gather
> much more dangerous info, and launch more dangerous attacks. Random
> scanning of udp port with source port 53 will be loged by the fw and you'd
> know about it. All you have to do then is to switch dns server (asuming
> the attacker spoof the correct ip ).

a. Guessing which DNS you use is often trivial, especially for dial-up
users.
b. Linux uses just 3976 ephemeral ports (1024-4999) by default, and DNS
queries are very frequent. With the default timeout of 3 minutes, even a
very slow scan which your portscan detector may miss is likely to hit an
established UDP connection within weeks if not days.
c. In some circumstances there are very few candidate ports, e.g.,
immediately after reboot.
d. Thus: the attack can be completed long before you read the log.
e. Generally: "It will show up in the logs" is not a satisfactory way to
address a known security breach. Maybe it's good for DoS, but not for a
potential circumvention of access controls.
f. I don't trust my ISP's backbone. I don't even trust my ADSL modem. Do
you?


> So although this attack is possible, unless you are a premium target
> (holding state secrects or controling bilions of dollars) I wouldn't wory
> about it. Keep defending against the common and scan your logs from time to time to
> see if new attacks start. That will keep you surfing hapy.

I don't value myself so lowly that I think nobody would ever think I may
be a worthy target, and I don't think assuming lack of motivation is a
very good security measure -- such assumptions can be as wrong as your
assumption that my only use of the Internet is "surfing hapy". In any
case, when I scan my logs I *always* discover new attacks, which is why
I want my setup so tight I won't need to care about them.


To summarize, I still claim that from the paranoid point of view which
is
appropriate in these matters:
# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
effectively implies
# iptables -A INPUT -p UDP -s $DNS --dport 1024:4999 -j ACCEPT


  Regards,
    Eran Tromer

> 
> Dani
> 
> On Fri, 31 Aug 2001, Eran Tromer wrote:
> 
> > 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