Search the Community

I have written a short bash function for measuring website metrics such as DNS lookup, redirects, redirect time, the first byte (TTFB), connect time and the total time. Short version (Only TTFB) function ttfb() { if [ $# -eq 0 ] then echo "Usage: ttfb url" else curl -o /dev/null \ -H 'Cache-Control: no-cache' \ -s \ -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" \ $1 fi } Usage example: aelius@macbook:~$ ttfb Usage: ttfb url aelius@macbook:~$ ttfb https://www.unixteacher.org/ Connect: 0.046315 TTFB: 0.157112 Total time: 0.157400 aelius@macbook:~$ Long version (DNS Lookup, Redirects, Redirect time, First byte, Connect time, Total time) function metrics { if [ $# -eq 0 ] then echo "Usage: metrics url" else curl -H 'Cache-Control: no-cache' -Lw "DNS Lookup: %{time_namelookup} seconds \nRedirects: %{time_redirect} seconds with %{num_redirects} redirects \nFirst Byte: %{time_starttransfer} seconds \nConnect Time: %{time_connect} seconds \nTotal Time: %{time_total} seconds\n" -so /dev/null $1 fi } Usage example aelius@macbook:~$ metrics Usage: metrics url aelius@macbook:~$ metrics https://www.unixteacher.org/ DNS Lookup: 0.009266 seconds Redirects: 0.000000 seconds with 0 redirects First Byte: 0.173887 seconds Connect Time: 0.051254 seconds Total Time: 0.174168 seconds aelius@macbook:~$ References: – https://en.wikipedia.org/wiki/Time_to_first_byte – https://curl.haxx.se/docs/manual.html Published on UnixTeacher: https://www.unixteacher.org/blog/measuring-website-metrics-with-curl/

DNS is a naming system for computers that converts human readable domain names e.g. (infosecinstitute.com) into computer readable IP-addresses. However some security vulnerabilities exist due to misconfigured DNS nameservers that can lead to information disclosure about the domain. This forms an important step of the Information Gathering stage during a Penetration test or Vulnerability assessment. In this article we will look at the following areas.. DNS Basics Resource records and the Zone file DNS Lookup and Reverse DNS Lookup Understanding Wildcard Entries DNS Zone transfer DNS Bruteforcing Chapters 1 and 2 you can read in the link below to understand the basics of DNS. 3) DNS Lookup and Reverse DNS Lookup DNS Lookup - Let’s perform a DNS Lookup ourselves for infosecinstitute.com. We will do this by traversing the entire DNS hierarchy from the root servers to the top level domain. Open up the terminal in Backtrack (you can use your own favourite distro) and type in “dig”. You will get something as shown in the figure below. What we get is a list of the Root DNS Servers. Let’s use this root DNS server to query infosecinstitute.com. We do this as shown in the figure below What we get is a list of authoritative name servers for the com domain. Notice the dot (.) at the end, this is what makes this a fully qualified domain name (FQDN). Let’s use these Name servers to query again. Now we get the list of authoritative name servers for infosecinstitute.com (which is ns1.pairnic.com and ns2.pairnic.com). Now we need to query these name servers to get the IP-address of Infosecinstitute.com And now in the Answer Section we can see that the Ip-address for infosecinstitute.com is 216.92.251.5. SUCCESS ! Reverse DNS Lookup - Performing Reverse DNS Lookup converts an IP-address into it’s hostname. For this we need to write the IP-address in reverse order (for e.g. 192.168.1.1 will be 1.1.168.192) and then append “.in-addr.arpa.” to it. Next we need to make a query for a PTR Record using DIG. Let’s make a DNS PTR query for 216.92.251.5, the command here would be “dig 5.251.92.216.in-addr.arpa PTR” As we can clearly see, this IP-address resolves to infosecinstitute.com. As Simple as that! 4) Understanding Wildcard Entries WildCard – A wildcard entry is used to provide responses for subdomains that do not exist. For e.g. let’s say we have a domain example.com. If we set a wildcard record for *.example.com and give it the value example.com then the requests for all the non-existent subdomains of example.com (for e.g. abcd.example , blah.example.com) will point to example.com. In the information gathering stage of a penetration test of a website, it is important to identify the subdomains and the IP-addresses corresponding to them. Introducing a Wildcard feature reduces this to a small extent. Bypassing Wildcard entries – In case wildcard entries are set on a particular domain, they could be bypassed to reveal information about it’s subdomains. This is done by brute forcing the subdomains. We have a wordlist in which we contain the subdomain names we want to test the domain against. Then we do a ping of all these subdomains, if these domains resolve to an IP-address different than the host IP-address, then we can very surely say that this subdomain actually exists. However before performing a brute force it would be better to actually check if Wildcard entries are enabled or not. For that we can ping some random subdomains for e.g. 434234.example.com and see if it’s IP-address is the same as the host IP-address(in this case example.com). If this is the case for some random subdomains, then we can clearly say that Wildcard entries are enabled for this domain. We will perform a demo of this in the coming section. 5)DNS Zone Transfer - We saw in the previous exercises that every domain has some authoritative name servers associated with it. For eg in the case of google.com, the nameservers were ns1.google.com to ns4.google.com .These Nameservers are used for handling requests related to the domain google.com. Let’s say we have a domain example.com and it has it’s two nameservers as ns1.example.com and ns2.example.com. Usually a big organization will have more than one nameservers so that if one goes down for some time, the other one is ready to back it up and handle the requests. Usually one of these servers will be the Master server and the other one will be the slave server. Hence to stay in sync with each other, the slave server must query the Master server and fetch the latest records after a specific period of time. The Master server will provide the slave server with all the information it has. This is basically what is called a “Zone Transfer”. It’s like asking the nameserver “Give me everything you have”. A properly configured nameserver should only be allowed to serve requests of Zone transfer from other Nameservers of the same domain. However if the server is not configured properly it will serve all requests of Zone transfer made to it without checking the querying client. This leads to leakage of valuable information. DNS Zone transfer is sometimes referred through it’s opcode mnemonic AXFR. Let’s see an example of a Zone transfer. We will be using the tool Fierce present by default in Backtrack. Fierce is one of the best tools available out there for DNS Analysis. Type in the following command “perl fierce.pl -dns searching-eye.com”. We get something as shown in the figure below. What fierce does is that it first finds out the nameservers for the domain. It then checks to see if they allow zone transfers. Since one of the nameservers is not properly configured, it allows zone transfer and what we see is a dump of all the information (records,subdomains etc). Why is Zone transfer a Security Issue? A zone transfer reveals a lot of information about the domain. This forms a very important part of the “Information Gathering” stage during a penetration test, vulnerability assessment etc. We can figure out a lot of things by looking at the dump.For e.g. we can find different subdomains. Some of them might be running on different servers.Those server may not be fully patched and hence be vulnerable.From this point, we can start thinking about Metasploit ,Nessus,Nmap etc and do a full vulnerability assessment of the domain. Hence this kind of information increases our attack vector by a fair amount, an amount which cannot be ignored. To protect your nameservers from leaking valuable information, one must allow zone transfer to other nameservers of the same domain only. For e.g. ns1.example.com should allow zone transfer to ns2.example.com only and discard all the other requests. 6)DNS Bruteforcing -DNS Zone transfers may not work all the time. In fact, it will not work most of the time. Most of the DNS servers are properly configured and do not allow zone transfers to every client. Well what do we do then ? Simple answer, the same thing we do when nothing works, BRUTE FORCE it ! Basically we have a wordlist containing a huge list of hosts. We first check for wildcard entries by checking if a random subdomain for e.g. 132qdssac.example.com resolves to the same IP-address as example.com .If this is the case, we know Wildcard entries are set. We then query the domain by using each of the word in our wordlist. For e.g. if one of the entries in the wordlist file is “ads” , then we make a query for ads.example.com. If it resolves to a different IP-address then we are sure that this subdomain actually exists. Hence we now have information about the name of subdomain and it’s IP-address. If wildcard entries are not set , we do the same thing and see if we get response from any subdomain we query. If we get a response back, we could be sure that the subdomain actually exists. In the end what we get is a bunch of information about the domain. Let’s see this through a demo. We will again use the tool “Fierce”. Fierce is a very handy tool for DNS Analysis and it is something everyone should have in their armory. Fierce will first check if Zone transfers are allowed or not, if zone transfers are allowed, it will dump all the information and exit happily, otherwise it will brute force it. We need to supply Fierce with a wordlist containing a list of all the possible subdomain names (for e.g. hosts,ads,contracts). Fierce comes with an inbuilt wordlist file “hosts.txt” and we will be using the same for our demo. As we can see, Fierce dumps out information about the subdomains of google.com CONCLUSION DNS protocol is a very critical component of the Internet as it resolves IP-address into hostnames and makes life a lot easier for us. However, if the nameservers are not properly configured they might leak out the whole DNS server database to any malicious hacker. Even if the servers are properly configured, they can be brute forced to leak information about their mail servers, IP addresses, etc. It is therefore important to properly configure your DNS servers and be aware of the security issues with DNS. Credits: InfoSec Resources – DNS Hacking (Beginner to Advanced)