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.
I just want to share my happiness about the RIPE Atlas measurements. If you have not heard about it yet, keep on reading. Following is a very basic overview of how the Atlas tool from the RIPE NCC can be used to test the connectivity of your own equipment.
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.
With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!
However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!
The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)
Seit über einem Jahr zeichne ich die Anzahl der Hops von einer Reihe DSL-Anschlüssen auf (siehe hier). Mein Monitoring-Server läuft dabei hinter einem statischen Anschluss der Telekom, während die privaten Internetanschlüsse von diversen Anbietern (1&1, Kabel Deutschland, Telekom) kommen. Nun habe ich leider nicht im Detail die Ahnung davon, wie diese Anbieter ihren Traffic routen, zumindest scheint aber 1&1 irgendetwas Komisches bei sich verbaut zu haben, da sehr oft nach der nächtlichen Zwangstrennung ein deutlicher Unterschied in der Anzahl der Hops zu sehen ist.
A commonly 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.
One core topic when designing firewall policies is the following question: Is ping a security attack? Should ICMP echo-request messages be blocked in almost any directions?
My short answer: Ping is your friend. :) You won’t block hackers if you block ping. Instead, ping is quite useful for network administrators checking basic network connectivity. That is: I suggest to allow ping anywhere around, accept incoming connections from the Internet to the trusted networks.
I was interested in generating graphs within the MRTG/Routers2 monitoring system that display the number of hops for an IP connection through the Internet. In my opinion its interesting to see the different routing run times/hop counts e.g. for remote offices that are connected via dynamic ISP connections such as DSL. Therefore, I wrote a small script that executes a traceroute command which can be called from MRTG.