Suspecious DNS traffic

Tue Mar 26 19:13:56 UTC 2013

On Mar 26, 2013, at 3:09 PM, "Novosielski, Ryan" <novosirj at umdnj.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It sounds like exactly the reverse of what Niall described in his
> other e-mail (brackets mine):
> 
> "The reply to such a query originates from port 53 on the remote
> server [in this case, your server], and is destined for the port on
> your server [in this case, the remote server] which was used as the
> source of the query [which will, again, almost certainly be a random
> port above 1024, but the same port the request just came in from to
> your port 53]."
> 
> Why your firewall is confused about this is anyone's guess. I'd check
> with them.

Another option is to just follow the standard dictum of "Don't put your DNS server behind a firewall".

It almost always makes debugging much harder and either monkeys with stuff that it shouldn't, or simply provides no benefit, all while adding another thing to fall over under DoS conditions.

W

> 
> On 03/26/2013 02:50 PM, babu dheen wrote:
>> Dear Vernon,
>> 
>> Thanks for your wonderful and detailed reply. I read the update
>> given by you as below.
>> 
>>> Many stateful firewalls can also record the source and
>>> destination IP addresses and port numbers of outgoing UDP packets
>>> and allow subsequent incoming UDP packets with source and
>>> destination reversed. This has nothing to do with TCP.
>> 
>> I am using stateful firewall and still why my BIND DNS server 
>> connection iniated using source port 53 to remote DNS server on
>> non standard destination port is getting blocked?
>> 
>> Not sure why my DNS server is initiating the connection to remote
>> DNS server on non standard destination Port?
>> 
>> Regards Babu
>> 
>> 
>> 
>> *From:* Vernon Schryver <vjs at rhyolite.com> *To:*
>> bind-users at lists.isc.org *Sent:* Monday, 25 March 2013 8:40 PM 
>> *Subject:* Re: Suspecious DNS traffic
>> 
>>>> Still not convinced because if i need to allow >1024 port from
>>>> our DNS server to external world(internet).. where is the
>>>> security?
>> 
>> Every UDP and TCP packet has two port numbers, the source port and 
>> the destination port.  When a resolver sends a request to a
>> distant DNS authority, it sends to destination port 53 with a
>> random local source port number.  When the distant resolver
>> responds, it will send a UDP packet with source port 53 and with
>> destination port equal to the source port number in the request.
>> If you block all packets from port 53 to local ports other than 53,
>> then you will block all response to your resolver's requests.
>> 
>> Some DNS resolver software in ancient days sent requests to
>> distant authorities with source port 53, so that both the source
>> and destination port numbers in DNS/UDP packets were 53.  There are
>> many reasons why that was a bad idea.  For one modern reason, see 
>> https://www.google.com/search?q=cache+poisoning+attack and 
>> https://www.google.com/search?q=dns+source+port+randomization
>> 
>> Contrary to claims in this thread, that source port need not be
>> greater than 1024 except on some operating systems.  The notion of
>> "privileged ports" smaller than 1024 is an ancient "BSDism" that
>> many consider a mistake.  However, the source ports in DNS/UDP
>> requests (as well as DNS/TCP) are likely to be restricted to parts
>> of the complete [1,65535] range of port nubmers, but those partial
>> ranges depend on the operating system, operating system
>> configuration, DNS resolver software, and the resolvers
>> configuration.  For TCP and stub DNS resolvers, see 
>> https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND
>> as a resolver, see the BIND Administrators Reference Manual (ARM)
>> including the query-source,use-v4-udp-ports, use-v6-udp-ports, 
>> avoid-v4-udp-ports, and avoid-v6-udp-ports options.
>> 
>> 
>>> You send request via UDP from random high port to an
>>> authoritative
>> server.
>>> Answer is too large to fit in UDP packet, so it responds via TCP
>>> to the source port of the request (random high port from above).
>>> If you block that TCP connection, you cannot receive answer to
>>> your query.
>> 
>> No, a distant DNS authority certainly does not respond via TCP
>> after a UDP response fails to fit in a DNS/UDP packet.  Instead,
>> the distant authority responds with a DNS/UDP packet with the TC or
>> "truncated" error bit.
>> 
>> A resolver will react to TC bits or truncation errors by making
>> the same request with TCP unless it has already received the
>> required data from some other DNS authority.  This can happen after
>> the local resolver has tired of waiting for an answer from one
>> authority and sent the request to some other authority.
>> 
>> Making a request via TCP consists of sending a TCP segment (or 
>> packet) with SYN bit sent to port 53 at the distant authority and 
>> with yet another random source port number.  The distant authority 
>> will respond with a TCP segment with both the SYN and ACK bits
>> set. The local resolver will respond with another TCP segment with
>> both the SYN and ACK bits set.  This is the famous "3-way
>> handshake" that establishes a TCP connection.  Only after the TCP
>> connection is established does the local resolver send the DNS
>> request through the TCP connection.
>> 
>>> Another reason for TCP replies is DNS Response Rate Limiting
>>> (RRL).
>> 
>> Not exactly.
>> 
>>> Some "modern" stateful firewalls understand DNS and if there is a
>>> UDP packet sent to port 53, it will accept TCP connections back
>>> from the destination address on port 53 to the source
>>> address/port.
>> 
>> That is wrong.  UDP packets have nothing to do with telling
>> reasonable firewalls to allow TCP.
>> 
>> Firewalls for more than 10 years have automatically dealt with TCP 
>> in at least two ways.  One is to notice and remember (i.e. save 
>> state) the initial TCP SYN segment 3-way handshake and allow the 
>> later predictaBle TCP segments.  Another mechanism is to blindly 
>> block incoming TCP segments with SYN but without ACK.  The first 
>> mechanism requires saving state or memory for every established
>> TCP connection, and so can be vulnerable to some kinds of "state 
>> exhaustion attacks." The second mechanism prevents outsiders from 
>> originating TCP connections, but does not protect against using
>> the local system for some kinds of reflection DoS attacks.
>> 
>> Many stateful firewalls can also record the source and destination 
>> IP addresses and port numbers of outgoing UDP packets and allow 
>> subsequent incoming UDP packets with source and destination
>> reversed. This has nothing to do with TCP.
>> 
>> 
>> Vernon Schryver    vjs at rhyolite.com <mailto:vjs at rhyolite.com> 
>> _______________________________________________ Please visit
>> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>> 
>> bind-users mailing list bind-users at lists.isc.org
>> <mailto:bind-users at lists.isc.org> 
>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
>> 
> 
> 
> - -- 
> - ---- _  _ _  _ ___  _  _  _
> |Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
> |$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
> \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iEYEARECAAYFAlFR8lIACgkQmb+gadEcsb4B7QCg2f64+sltIkM6KzHV13+pFCR0
> +7sAn3J/sEWHigF8MbC4+RCfowfkfyWQ
> =YMnI
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup. 