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.
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 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 origin.
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.
Here comes a discussion:
Hier kommen zwei interessante Graphen von der AVM FRITZ!Box, welche mit einem gängigen DSL-Anschluss im Internet hängt:
- Traffic in Richtung Internet mit einem Peak beim Upload
- Ping-Antwortzeiten des internen Interfaces mit einem noch viel höherem Peak während des Uploads
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.