[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: caching dns lookups (fwd)
- To: <linux-il(at-nospam)iglu.org.il>
- Subject: Re: caching dns lookups (fwd)
- From: Dani Arbel <darbel(at-nospam)techunix.technion.ac.il>
- Date: Fri, 31 Aug 2001 09:12:34 +0300 (IDT)
- Delivered-To: iglu.org.il-linux-il@iglu.org.il
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
Hi gang,
I have this discussion with Eran that I think belongs elsewhere
(linux-il-security ?). Does the forum wishes to continue this on here ?
Dani
Eran wrote:
I replied to you alone by mistake, and later on the list. Where do you
wish to continue the discussion?
Regards,
Eran
Dani Arbel wrote:
>
> Hi Tomer,
> indeed, what you describe may be done. however I do not find it
> disturbing. Before I explain let me add that I recomand using a caching
> dns and other proxies whenever possible.
> 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.
> 2) you could change the default time a udp stream live. a few seconds
> sounds reasonable.
> 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 ).
> 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.
> 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