Re: Suspecious DNS traffic
Dear Matus, I think you got my point. Yes. I am using Stateful Firewall and not sure my DNS server connecting to remote DNS on non standard port? So where i need to now look? Regards Papdheen M From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:46 PM Subject: Re: Suspecious DNS traffic On 26.03.13 00:21, babu dheen wrote: Hi Matus, please, skip personal replies. this is mailing listand issued should be discussed here. Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? If you have statefull firewall, you simply need to allow open connections (statefull firewalls can track outgoing UDP packets and match the replies). If not, you have to allow all traffic from port 53 on remote DNS servers to your DNS server. Since you can't know all DNS servers, you have to allow all incoming traffic to your DNS server where source port is 53. all the security is useless if blocks your service. Luckily, most of firewalls can track the connection state. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
Dear Brown, I am using Stateful firewall from leading vendor company. So let me know why still my server initiate connection to remote DNS server on non standard destination port? Regards Babu From: wbr...@e1b.org wbr...@e1b.org To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:48 PM Subject: Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. 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. Another reason for TCP replies is DNS Response Rate Limiting (RRL). 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. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
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 v...@rhyolite.com To: bind-users@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
Re: Suspecious DNS traffic
In message 1364323396.89012.yahoomail...@web190806.mail.sg3.yahoo.com, babu d heen writes: Dear Brown, I am using Stateful firewall from leading vendor company. And you have not configured it correctly. So let me know why still my server initiate connection to remote DNS server on non standard destination port? It doesn't. You send to port 53 from any port. The replies come back from port 53 to any port. A properly configured stateful firewall lets these reply packets in. Your firewall is dropping them. I do mean any port not just those greater 1024. A stateful firewall still needs to be configured to record the state necessary to identify the reply packets. e.g. pass out quick proto udp from any to any keep state keep frag This say to record that we sent a UDP packet from any address and port to any other address and port so that we will accept the reply traffic and also to not block UDP fragments. For UDP that state table entry will exist for a few seconds before it is cleaned up. For TCP the firewall will track the TCP state transitions. Mark Regards Babu From: wbr...@e1b.org wbr...@e1b.org To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:48 PM Subject: Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. 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. Another reason for TCP replies is DNS Response Rate Limiting (RRL). 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. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall already answered you the other day (brackets mine): The reply to such a query [from your server] originates from port 53 on the remote server, and is destined for the port on your server which was used as the source of the query[, which will be a randomly chosen port above 1024 if you are doing things the way they are usually done]. On 03/26/2013 02:44 PM, babu dheen wrote: Dear Brown, I am using Stateful firewall from leading vendor company. So let me know why still my server initiate connection to remote DNS server on non standard destination port? Regards Babu *From:* wbr...@e1b.org wbr...@e1b.org *To:* babu dheen babudh...@yahoo.co.in *Cc:* bind-users@lists.isc.org bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 7:48 PM *Subject:* Re: Suspecious DNS traffic babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. 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. Another reason for TCP replies is DNS Response Rate Limiting (RRL). 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. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$| |__| | | |__/ | \| _| |novos...@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/ iEYEARECAAYFAlFR8dcACgkQmb+gadEcsb4r3ACeNPse/dcwDd/rkipAo/mO3iJ0 eScAoKn2IRu+JAnIWdGQEMjUWd6irdnv =WVBw -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
-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. 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 v...@rhyolite.com *To:* bind-users@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
Re: Suspecious DNS traffic
On Mar 26, 2013, at 3:09 PM, Novosielski, Ryan novos...@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 v...@rhyolite.com *To:* bind-users@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
Re: Suspecious DNS traffic
Maybe I can try. In the very old days - when BIND as a recursive resolver was chasing down an answer to a question, it would sent the remote authoritative DNS server the query in a UDP packet which has a query ID which was numbered sequentially. This was bad as bad people could guess your next query ID and send back their own answers. Then BIND randomised this 16 bit query ID which made it more difficult. Tie that in with a reasonable TTL, so answers are cached - and the world was a better place. We asked and received answers all on port 53. Then Dan Kaminsky (actually a good guy) discovers a protocol weakness which somewhat negated the effectiveness of the randomness of the 16 bit query ID. The short term solution for this is to add some more randomness in the query. A resolving name-server will now ask an authoritative server on port 53 but will ask from an almost random port. The Answer has to come back from port 53 but to the same random port and obviously with the same Query ID (or maybe ports are the other way around?) You can by configuration restrict or even remove this extra randomness - but it makes it easier for bad people to pollute your cache with bad answers. The Security Solution is to run DNSSEC - ie Sign all your own zones and to use DNSSEC recursive resolvers. You'll then ignore bad answers. If I start 'named' with the '-g' option - I get: 26-Mar-2013 ... using default UDP/IPv4 port range: [1024, 65535] 26-Mar-2013 ... listening on IPv4 interface lo, 127.0.0.1#53 I believe this is BIND telling me its intending to use from port 1024 to port 65535 as the local source of queries. This is a Good Thing. Your Firewall could be configured to allow BIND to do this. One alternative is to lock BIND and the Firewall to only allow port 53 queries and have them all forwarded to a recursive name-server on the outside of your firewall. If I sell machines - I think this is a great solution (I sell more machines). Don't restrict the Randomness that Queries can use. Even with DNSSEC - the majority of the Internet's DNS is not yet signed. If my explanation is not quite right - I'm pretty sure its at least in the right direction. On Wed, 2013-03-27 at 02:40 +0800, babu dheen wrote: Dear Matus, I think you got my point. Yes. I am using Stateful Firewall and not sure my DNS server connecting to remote DNS on non standard port? So where i need to now look? Regards Papdheen M From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 7:46 PM Subject: Re: Suspecious DNS traffic On 26.03.13 00:21, babu dheen wrote: Hi Matus, please, skip personal replies. this is mailing list and issued should be discussed here. Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? If you have statefull firewall, you simply need to allow open connections (statefull firewalls can track outgoing UDP packets and match the replies). If not, you have to allow all traffic from port 53 on remote DNS servers to your DNS server. Since you can't know all DNS servers, you have to allow all incoming traffic to your DNS server where source port is 53. all the security is useless if blocks your service. Luckily, most of firewalls can track the connection state. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
Hi, I am able to query one of the PTR record available in my company BIND caching DNS server from internet(ANY IP address) successfully. As per your statement, If I am denying the response, how could I get response successfully? Regards Babu From: Mark Andrews ma...@isc.org To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-us...@isc.org Sent: Monday, 25 March 2013 12:33 AM Subject: Re: Suspecious DNS traffic In message 1364140396.42023.yahoomail...@web190806.mail.sg3.yahoo.com, babu d heen writes: Dear, We have Caching DNS server and certain PTR record(reverse entry verification purpose) only is allowed from internet. But I am observing suspicious DNS traffic from my BIND caching DNS server towards 67.215.80.15,67.215.80.13,207.192.69.4,67.227.239.85 IP address on destination port 1033,1090,1743, etc. Since we haven't allowed non standard port from our DNS server to public DNS server, its dropped in firewall. Any idea as to why our company DNS server is contacting external IP on non standard port? It's contacting it on port 53. You are allowing the query out but denying the response. Below is the logs taken from DNS server on one of the destination IP address. ## ## client 67.215.80.15#58230: view localhost_resolver: query (cache) '109.232.12.217.in-addr.arpa/PTR/IN' denied client 67.215.80.15#18395: view localhost_resolver: query (cache) '86.232.12.217.in-addr.arpa/PTR/IN' denied client 67.215.80.15#34068: view localhost_resolver: query (cache) '114.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#20915: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#64724: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#16374: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#30391: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#17745: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#36163: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#6391: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#37586: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#55208: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#40076: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied Below is the firewall logs: # action=Deny sent=0 rcvd=112 src=our_company_DNS_server_ip dst=67.215.80.15 src_port=53 dst_port=16529 action=Permit sent=0 rcvd=0 src=67.215.80.15 dst=our_company_DNS_server_ip src_port=52370 dst_port=53 Regards Babu -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
On 25.03.13 16:59, babu dheen wrote: I am able to query one of the PTR record available in my company BIND caching DNS server from internet(ANY IP address) successfully. As per your statement, If I am denying the response, how could I get response successfully? you must allow the packets from TCP+UDP port 53 coming to any =1024 port on your nameserver. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
Hi Matus, Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. Regards Babu From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, 25 March 2013 3:30 PM Subject: Re: Suspecious DNS traffic On 25.03.13 16:59, babu dheen wrote: I am able to query one of the PTR record available in my company BIND caching DNS server from internet(ANY IP address) successfully. As per your statement, If I am denying the response, how could I get response successfully? you must allow the packets from TCP+UDP port 53 coming to any =1024 port on your nameserver. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
Are you talking about SOURCE or destination ports ? regards ~CArlos On 3/25/13 1:21 PM, babu dheen wrote: Hi Matus, Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. Regards Babu *From:* Matus UHLAR - fantomas uh...@fantomas.sk *To:* bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 3:30 PM *Subject:* Re: Suspecious DNS traffic On 25.03.13 16:59, babu dheen wrote: I am able to query one of the PTR record available in my company BIND caching DNS server from internet(ANY IP address) successfully. As per your statement, If I am denying the response, how could I get response successfully? you must allow the packets from TCP+UDP port 53 coming to any =1024 port on your nameserver. -- Matus UHLAR - fantomas, uh...@fantomas.sk mailto:uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org mailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
On 25 Mar 2013, at 16:21, babu dheen wrote: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Your DNS server will likely need to send queries to other DNS servers. When it does this, it uses a destination port of 53 and a source port from the range above 1024. It is important for security that it not use a fixed source port, but rather pick one at random for each query. [Hint: Google source port randomization (without the quotes)] The reply to such a query originates from port 53 on the remote server, and is destined for the port on your server which was used as the source of the query. If you block access to high-numbered UDP ports on your server, you block these replies. For TCP, allowing established packet flows is usually sufficient to allow the replies to reach your server. Best regards, Niall O'Reilly ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
On 26.03.13 00:21, babu dheen wrote: Hi Matus, please, skip personal replies. this is mailing listand issued should be discussed here. Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? If you have statefull firewall, you simply need to allow open connections (statefull firewalls can track outgoing UDP packets and match the replies). If not, you have to allow all traffic from port 53 on remote DNS servers to your DNS server. Since you can't know all DNS servers, you have to allow all incoming traffic to your DNS server where source port is 53. all the security is useless if blocks your service. Luckily, most of firewalls can track the connection state. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
babu dheen wrote on 03/25/2013 12:21:30 PM: Still not convinced because if i need to allow 1024 port from our DNS server to external world(internet).. where is the security? Total security requires total isolation. It is a matter of accepting some risks to perform the needed task. I beleive we just need to allow TCP and UDP 53 from our DNS server to internet(any) which is already done. Not sure why we have to open non standard port from our DNS server to internet? Kindly provide some details. 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. Another reason for TCP replies is DNS Response Rate Limiting (RRL). 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. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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 Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
In message 1364140396.42023.yahoomail...@web190806.mail.sg3.yahoo.com, babu d heen writes: Dear, We have Caching DNS server and certain PTR record(reverse entry verification purpose) only is allowed from internet. But I am observing suspicious DNS traffic from my BIND caching DNS server towards 67.215.80.15,67.215.80.13,207.192.69.4,67.227.239.85 IP address on destination port 1033,1090,1743, etc. Since we haven't allowed non standard port from our DNS server to public DNS server, its dropped in firewall. Any idea as to why our company DNS server is contacting external IP on non standard port? It's contacting it on port 53. You are allowing the query out but denying the response. Below is the logs taken from DNS server on one of the destination IP address. ## ## client 67.215.80.15#58230: view localhost_resolver: query (cache) '109.232.12.217.in-addr.arpa/PTR/IN' denied client 67.215.80.15#18395: view localhost_resolver: query (cache) '86.232.12.217.in-addr.arpa/PTR/IN' denied client 67.215.80.15#34068: view localhost_resolver: query (cache) '114.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#20915: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#64724: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#16374: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#30391: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#17745: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#36163: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#6391: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#37586: view localhost_resolver: query (cache) '150.232.12.217.in-addr.arpa/PTR/IN' denied client 67.227.239.85#55208: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied client 67.227.239.85#40076: view localhost_resolver: query (cache) '232.12.217.in-addr.arpa/NS/IN' denied Below is the firewall logs: # action=Deny sent=0 rcvd=112 src=our_company_DNS_server_ip dst=67.215.80.15 src_port=53 dst_port=16529 action=Permit sent=0 rcvd=0 src=67.215.80.15 dst=our_company_DNS_server_ip src_port=52370 dst_port=53 Regards Babu -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
