Angreifer verwenden gern Ping und Traceroute, um Server im Internet ausfindig zu machen. Das bringt viele Security-Admins in Versuchung, den Ping- und Traceroute-Verkehr mittels ihrer Firewall in ihrem Netz zu unterbinden. Doch damit behindern sie nur die Arbeit von Server-Administratoren, denn es gibt noch viel mehr Möglichkeiten, Server aufzuspüren.
What failover times do you expect from a network security device that claims to have high availability? 1 ms? Or at least <1 second? Not so for a fully featured Infoblox HA cluster which takes about 1-2 minutes, depending on its configuration. Yep. “Works as designed”. Ouch. Some details:
Implementing DNSSEC for a couple of years now while playing with many different DNS options such as TTL values, I came around an error message from DNSViz pointing to possible problems when the TTL of a signed resource record is longer than the lifetime of the DNSSEC signature itself. Since I was not fully aware of this (and because I did not run into a real error over the last years) I wanted to test it more precisely.
If you’re running your own DNS resolver you’re probably interested in some benchmark tests against it, such as: how fast does my own server (read: Raspberry Pi) answer to common DNS queries compared to 188.8.131.52.
In this blogpost I am showing how to use two tools for testing/benchmarking DNS resolvers: namebench & dnseval. I am listing the defaults, giving some hints about them and showing examples in which I tested some private and public DNS resolvers: a Fritzbox router, a Raspberry Pi with Unbound, Quad9, OpenDNS, and Google Public DNS.
Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.
Beside detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.
I really love ping! It is easy to use and directly reveals whether the network works or not. Refer to Why Ping is no Security Flaw! (But your Friend) and Advanced Tracerouting. At least outgoing pings (from trust to untrust) should be allowed without any security concerns. However, many companies are denying these ICMP echo-requests from untrust into the DMZ which makes it difficult to test whether all servers are up and running.
I was sitting at the customer’s site replacing the DMZ firewall. Of course I wanted to know (from the outside) whether all servers are connected correctly (NAT) and whether the firewall permits the connections (policy). However, ping was not allowed. Therefore I used several layer 7 ping tools that generate HTTP, DNS, or SMTP sessions (instead of ICMP echo-requests) and revealed whether the services (and not only the servers) were running. Great!
This post shows the installation and usage of httping, dnsping, and smtpping on a Linux machine, in my case a Ubuntu server 14.04.4 LTS, as well as some Wireshark screenshots from captured sessions. Finally, a pcap file can be downloaded that shows the sample runs of all three tools.