Category: Bind and DNS tools

Counter DNS Attack: Enabling DNSSEC

To reach another person on the Internet you have to type an address into your computer – a name or a number. That address has to be unique so computers know where to find each other. ICANN coordinates these unique identifiers across the world. Without that coordination we wouldn’t have one global Internet. When typing a name, that name must be first translated into a number by a system before the connection can be established. That system is called the Domain Name System (DNS) and it translates names like www.icann.org into the numbers – called Internet Protocol (IP) addresses. ICANN coordinates the addressing system to ensure all the addresses are unique. – ICANN

Screenshot from 2016-07-23 20-56-11

Finally, i decided to enable DNSSEC on Tunnelix.com. It can be tested on the http://dnssec-debugger.verisignlabs.com link and its really cool. This is just another security addons to kept away from being attacked. For example, an attacker can take control of the session with the aim to make the user believe that the hijacker deceptive website is the right one. We also need to understand the basics of how  DNS traffic work. We are normally like three players in the normal DNS world that is your computer, the ISP’s recursive DNS servers, and the website’s authoritative DNS servers. Of course there are cached DNS servers that facilitate the DNS query. So to get into more detail how the attack goes on is where the attacker try to trick the resolver making it to believe that, lets say, tunnelix.com lives at the IP xx.xx.xx.xx and even to remember it for lets say 7 days. Its important to understand that since most of the traffic pass on UDP, it is kind difficult to prevent attackers from sending a flood of responses to the resolver.

DNSSEC is a technology which acts as a security layer on top of the DNS traffic by means of cryptographic tools to re-assure you that the website you are visiting is the real one. In 2008, Dan Kaminsky revealed a flaw that could allow attackers to easily perform cache poisoning attacks on most nameservers. Here is a link from the ISC (Internet System Consortium) which shed lots of interesting material about the DNSSEC technology. For bloggers behing Cloudfare, you can easily activate DNSSEC on for your domain, of course, if the root domain name is supporting DNSSEC, otherwise its impossible to achieve it. For example .mu domain does not support DNSSEC. On cloudflare, the steps are easy. You just need to activate the DNSSEC with a simple click and save all those informations like DS records, Digest, Digest type, Algorithm uses, Public key etc.. and feed it to the domain name registrar. The information will be verified by Cloudflare after which you are happily DNSSEC enabled domain owner.

Screenshot from 2016-07-23 21-48-53

To test out on your linux  terminal if a domain is signed use the following command:

[email protected]:~# dig tunnelix.com +dnssec

; <<>> DiG 9.10.3-P4-Ubuntu <<>> tunnelix.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36645
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;tunnelix.com. IN A

;; ANSWER SECTION:
tunnelix.com. 177 IN A 104.18.41.96
tunnelix.com. 177 IN A 104.18.40.96
tunnelix.com. 177 IN RRSIG A 13 2 300 20160724190355 20160722170355 35273 tunnelix.com. L5t/xVbsuB99HntpdpHkYu4ig52YL9QA+Vvi509KFgdgKrtY3pvZfKfD LGjtT0Ev0UFEn73TObofJyOmzIEmUg==

;; Query time: 46 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Jul 23 22:05:57 MUT 2016
;; MSG SIZE rcvd: 181

“To fix this, all major DNS servers implemented Source Port Randomization, as both djbdns and PowerDNS had before. This fix is widely seen as a stopgap measure, as it only makes the attack up to 65,536 times harder. An attacker willing to send billions of packets can still corrupt names. DNSSEC has been proposed as the way to bring cryptographic assurance to results provided by DNS, and Kaminsky has spoken in favor of it.” – blackhat.com

Domain owners might consider enabling DNSSEC on their domains to increase the security of letsencrypt in their infrastructure for ACME, as there is a return on investment in terms of security. Loganaden of Hackers.mu

Other article i wrote on BIND: Anatomy of a simple dig result 

 


Anatomy of a simple dig result

The ‘dig’ (Domain Information Gropper) command is one of the tool which is frequently used to troubleshoot DNS and BIND configurations. Its main purpose is to perform DNS lookups and query DNS servers. Though the subject is vast, i decided to blog some DNS stuffs under the ‘Bind and DNS tools’ category which i just created. I will keep on updating this article as i keep on finding interesting dig commands.

Screenshot from 2015-11-08 15:45:52

Lets analyze the result from a simple dig google.com. You would have a result similar to this one (In green). By default dig perform query A record when launched without any arguments.

1.I made a dig google.com on my linux terminal

[[email protected] ~]# dig google.com

2. The header section starts here. Several files in /etc/ld.so.* is being read and the dig command will also launch a uname with the argument sys and node. The uname is already inbuilt in the code of the dig command. It then reads the /etc/resolv.conf

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> google.com

3. The ;; global options: +cmd is referred to the default arguments sets by dig to use only the the +cmd variables.  The opcode value is always static. The status is to inform us if any error occurred during the query. Each query is also associated with an id number ( ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133).

The flags qr (query response), rd (recursion desired) and ra (recursion available) are also information retrieved from the DNS header. As per the IETF RFC1035, when a dig with the default arguments is performed it will flag the qr, rd, ra and when the bit is 1 its a response and 0 for a query. Therefore ‘qr’ appears as 1

The ANSWER:2 is the numbers of answers received in the Answer section, same for QUERY, AUTHORITY and ADDITIONAL.

 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

4. The “question section” is what you are querying for. In this case, a dig has been done on the A record. An A record simply means Adress i.e; the address associated with the website. We have several DNS records types which i will elaborate in future articles.

;; QUESTION SECTION:
 ;google.com.            IN    A

5. The number 173 is the TTL (Time To Live), IN refers to Internet i.e the class in which it is. TTL  is a 32 bit signed integer which correspond to the time interval a record can be cached before the information is again queried. A TTL zero is used for extremely volatile data.

To resume we read it as follows: Google.com has a 173 seconds Time To Live on the Internet with the IP Address 74.125.226.168

;; ANSWER SECTION:
 google.com.        173    IN    A    74.125.226.168
 google.com.        173    IN    A    74.125.226.162

6. This section acts like a stat section. Information is given about the time it takes to query. The server IP address i.e; 4.2.2.1 and the port number 53 which is associated with it. The date and finally the message size received is 204 bytes.

;; Query time: 22 msec
 ;; SERVER: 4.2.2.1#53(4.2.2.1)
 ;; WHEN: Sun Nov 08 01:19:23 EST 2015
 ;; MSG SIZE  rcvd: 204

More analysis can be performed by launching a strace in front of a dig command. The RFC 1035 is also of great help. You can also check out the Internet System Consortium (ISC) website for more details.

Tips:

  • dig -t MX google.com will show you in the list of MX records in the ‘Answer Section’
  • A  dig result is compose of only 5 parts i.e; Header, Question (question for the name server), Answer (resource records answering the question ), Authority (resource records pointing towards an authority) and Additional (resource records holding additional information).
  • To filter information from a default dig command you can use dig google.com +nocomments +noauthority +noadditional +nostats which will give you only the answer. With an additional +noanswer wont give you anything.
  • However, the reverse way to filter dig results with a specific answer can be dig google.com +noall +answer will give you only the answer section.