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.
Just a short post this time, but an interesting fact concerning different Internet Service Providers (ISPs) and their routing to/from other countries. I have a customer in Germany that has a remote office in France, connected via a site-to-site VPN. Around April last year the french office decided to change the ISP to a cheaper competitor that offers the same speed/bandwidth and therefore has no disadvantages… Well, I disagree.
Seit wenigen Tagen bin ich glücklicher Kunde eines Telekom Glasfaseranschlusses. Mit satten 50/10 MBit/s rasen die Daten bei mir ein und aus. Neben der deutlich höheren Geschwindigkeit war ich aber auch an den Latenzen der beiden Anschlüsse interessiert und habe entsprechende Tests gemacht. Hier kommen die Ergebnisse.
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
MRTG can also evaluate values from external scripts such as the “mrtg-ping-probe” program which returns the round-trip time from the initiated ping command to the specified destination host. With an additional GraphStyle called “range” from Routers2, these ping times can be displayed in the monitoring system. This graph style shows the “min” and “max” RTT in one vertical line instead of two independent lines.
Since there is not much to say about this process, I will only paste my MRTG/Routers2 config for mrtg-ping-probe and will show a few example graphs here.