Suspecious DNS traffic
Warren Kumari
warren at kumari.net
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.
More information about the bind-users
mailing list