At SharkFest’22 EU, the Annual Wireshark User and Developer Conference, I attended a beginners’ course called “Network Troubleshooting from Scratch”, taught by the great Jasper Bongertz. In the end, we had some high-level discussions concerning various things, one of them was the insight that TCP RSTs are not only sent from a server in case the port is closed, but are also commonly sent (aka spoofed) from firewalls in case a security policy denies the connection. Key question: Can you distinguish between those spoofed vs. real TCP RSTs? Initially, I thought: no, you can’t, cause the firewalls out there do a great job.
It turned out: you can!
Continue reading Who sends TCP RSTs?
I already published a few examples how you can use layer four traceroutes in order to pass firewall policies that block ping but allow some well-known ports such as 80 or 443. Long story short: Using TCP SYN packets on an opened firewall port with the TTL trick will probably succeed compared to a classical traceroute based on ICMP echo-requests.
Another nice use case for layer 4 traceroutes is the recognition of policy based routes within your own network (or even beyond). That is: Depending on the TCP/UDP port used for the traceroute you can reveal which paths your packets take over the network. This is quite useful compared to classical traceroutes that only reveal the straightforward routing tables but not the policy based ones.
Continue reading Discovering Policy-Based Routes with Layer 4 Traceroutes (LFT)
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.
Continue reading Signed DNS Zone with too long-living TTLs
I am testing a lot with my own DNS servers as well as with third-party DNS implementations such as DNS proxies on firewalls, DNSSEC validation on resolvers, etc. While there are a number of free DNS online tools around the Internet I was lacking some DNS test names with certain properties or resource records. Hence I configured a couple of them on my own authoritative DNS servers and its zone
For example, we encountered a bug on the Palo Alto DNS proxy that has not stored the TTL value correctly – hence some test names with different TTL values. Or we had some problems when a single DNS name has more than 15 IPv4/IPv6 addresses – hence some test names with lots of addresses. And many more: Continue reading DNS Test Names & Resource Records
The third tool out of the DNSDiag toolkit from Babak is dnseval. “dnseval is a bulk ping utility that sends an arbitrary DNS query to a given list of DNS servers. This script is meant for comparing response times of multiple DNS servers at once”. It is not only listing the response times but also further information about the DNS responses such as the TTL and the flags. Really great for comparison and troubleshooting different DNS forwarders as well as own authoritative DNS server responses as seen by others.
Continue reading Compare & Troubleshoot DNS Servers: dnseval
A common misunderstanding of traceroute is that it fully relies on ping. “If I block ping at my firewall, no one can use traceroute to reveal my internal routing path”. Unfortunately, this is not true. If traceroute is used with TCP SYN packets on permitted TCP/UDP ports, all intermediary firewalls will handle the IP packets with TTL = 0 corresponding to the RFCs and will reply with an ICMP time exceeded packet to the source.
In this post, I am listing an example that uses traceroute with TCP port 25 (SMTP) to traverse a firewall. A sample pcap file can be downloaded while some Wireshark screenshots show a few details.
Continue reading Advanced Tracerouting