I have an sshping in my ~/bin because I often found myself waiting to log back into a rebooting server and ping starts responding much earlier than ssh.
#!/bin/bash
while sleep 0.5; do
nc -vv -w 1 -z ${1:-localhost} ${2:-22}
done
$ nmap -Pn -p domain e.gtld-servers.net
Starting Nmap 7.01 ( https://nmap.org ) at 2016-05-15 13:32 CDT
Nmap scan report for e.gtld-servers.net (192.12.94.30)
Host is up (0.072s latency).
PORT STATE SERVICE
53/tcp open domain
Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds
The repeated ping function -- which is intended to display packet loss or delay -- isn't useful for TCP services.
actually the naming is bad anyway. the initial implementation only was used to check if a host is reachable (routing etc) inside a network. then later other stuff came in like RTT. however a ping on a higher layer is mostly not a "real" ping.
since it tests way more than just reachability. i.e. a http also checks connectivity and when it comes to domains it even includes a dns check.
Ping has confounding factors as well (firewall blocks, DNS, etc). If it works then you know that it's IP reachable, reachable on that TCP port, and that there's a responsive daemon on the other end. If it doesn't, you know that you need to troubleshoot. A device could not ICMP echo request ping, but respond to httping. Neither is perfect.
Might not bother you if you could convince yourself that it isn't a metaphorical reference to ping(8) but instead was a reference to a sonar ping, or tossing a pebble at a tank to see how full it is -- to former being where the program got its own name in the first place!
It referred to a "high-pitched, short and somewhat sharp sound" (the bullet pinged off his helmet). SONAR uses noises that sound similar, so SONAR emanations became pings and then it became associated with echo/response at that point.
TLDR: A lot of companies block ICMP for security reasons. OP thinks you shouldn't and provides links explaining why. That said, if ICMP is still blocked, you might be able to use httping, dnsping and smtpping as tools that provide similar information based on a server's responses to higher layered protocols.
I wrote a tool a long time back for testing PowerShell remoting connections that started with name resolution, then tried ICMP, TCP, HTTP, WinRM, etc. to figure out what layer was failing. Ping was critical to start out with because if it worked but IP-based protocols failed it was nearly always an IPSec problem. If ping didn't work, it was the firewall.
I just reach for curl in situations where I need a layer 7 request/response to see if things are up. I can see where this might be a little easier, especially for repeated requests.
What does blocking ICMP get you? (other than a broken network) Blocking ICMP fragments is fine if you are worried about DDoS attacks, but don't blanket block everything ICMP (especially ICMPv6).
Just curious as to what problem you are solving by blocking ICMP.
ICMP ECHO has an additional payload field thay we often ignore.
Some malware is known to use the ICMP payload as a C&C channel, or to tunnel out stolen information:
https://en.wikipedia.org/wiki/ICMP_tunnel
While true - ICMP is a ubiquitous protocol used all over the internet, but computers and network devices a like.
It also often gets overlooked, so while "you can tunnel inside almost any protocol", it is very common for malware to use ICMP for C&C.
This isn't to say ICMP should be blocked completely. But limiting the size and the value of the payload in ICMP ECHO requests and replies can definitely help.
Unless you're a member of ac1db1tch3z and happen to be sitting on a particularly big pile of local 0days, as a malware developer you wouldn't rely on having such privileges.
Lets be real here, ICMP is a particularly bad protocol for malware and that's why nobody uses it.
Effective security know what assets they are defending, what threat exist, and what the cost benefit is of applying a defensive measure to prevent the threats. Assuming that you have identified some assets you want to protect, is the threat that someone might tunnel traffic outside of monitored channels?
If yes, again assuming that all traffic is either monitored or blocked, have you done cost-benefit of monitoring ICMP for tunneled traffic vs blocking? A blocking rule need to be maintained, and it prevents diagnostics tools. If you have or will have a outside service that use heartbeat, such usage require whitelisting and maintenance for handling the permissions. In contrast, monitoring ICMP should just involve the same work as adding an additional protocol to the existing monitoring system.
One should also give some thought to the most common forms that adversaries use to tunnel traffic. TCP port 80 and 441 is a commonly used method to break through firewalls and nat, since those are considered outgoing ports which companies can't afford to block. (a small remark, where I work we do block those ports in some situations, and it has caught several intruders). Ports used for email is of course even more common to see malicious use from, and it is not uncommon that ISPs block all outgoing traffic on those ports. No one should consider blocking ICMP at all unless the more common traffic channels are monitored or blocked, unless they just want to create a false sense of security.
With iptables you can read packets, is it an icmp packet, what is it length and so on... If I was a hacker and I notice that icmp packets are blocked, I would feel less fear.
