Advanced Ping: httping, dnsping, smtpping(blog.webernetz.net)
blog.webernetz.net
Advanced Ping: httping, dnsping, smtpping
http://blog.webernetz.net/2016/05/10/advanced-ping-httping-dnsping-smtpping/
7 comments
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.
Why don’t you wait for ssh to respond if you need it to log back?
Why not just use nmap?
$ 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
Why the inconsistent naming? Why is it httping and smtpping? Why not httpping?
Different people creating different tools
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.
[deleted]
This got me as well.
There is also paping [1] that lets you "ping" to arbitrary port, although it only works for TCP.
[1] https://code.google.com/archive/p/paping/
[1] https://code.google.com/archive/p/paping/
It bugs me a bit that "ping" has got into general use. eg "Ping me with an email later".
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!
'Ping' (the word) is older (as in: 1835 old) than the 'ICMP Ping'.
I always thought it came from old fashioned submarine sonar. What would it have meant in 1835?
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.
I thought it came from ping pong. As in you send a "ping" and it responds with a "pong".
reminds me of mIRC's "Ping? Pong!" events...
I usually just curl -I a host to see if it's accessible.
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.
I'm not a network architect but I like it when ICMP is blocked because I know it can be used to tunnel traffic in penetration situations.
Any type of traffic can be used to tunnel other types of traffic.
You can tunnel over DNS as well: https://zeltser.com/c2-dns-tunneling/
You can tunnel over DNS as well: https://zeltser.com/c2-dns-tunneling/
Of course but security is multi layered and blocking ICMP is one layer, while using internal DNS is another. It's mitigation that costs nothing.
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.
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
You can tunnel inside almost any protocol. That's not a great reason. Valid, sure; good, no.
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.
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.
> it is very common for malware to use ICMP for C&C.
This is not true in the slightest.
And it'd only be realistic on windows as all other prevalent platforms require administrative privileges for such.
This is not true in the slightest.
And it'd only be realistic on windows as all other prevalent platforms require administrative privileges for such.
Good thing malware doesn't have administrative privileges.
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.
Lets be real here, ICMP is a particularly bad protocol for malware and that's why nobody uses it.
ICMP is a valuable diagnostics and control tool. Blocking it doesn't come without a cost.
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.
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.
I agree with this sentiment. To me, blocking ICMP solves a symptom of the security problem, not the actual problem
This is often said by people that do not understand that ICMP is not only echo/reply.
There are countless other situations where you want to receive an ICMP: e.g. "TTL expired" or "Fragmentation needed but DF bit set".
There are countless other situations where you want to receive an ICMP: e.g. "TTL expired" or "Fragmentation needed but DF bit set".