Live data from Hacker News

IP traffic over ICMP tunneling

github.com

21–30 of 86 posts

Re: IP traffic over ICMP tunneling

#21
post #3

Not the first of its kind, just look-up in Wikipedia: https://en.wikipedia.org/wiki/ICMP_tunnel Any captive portal these days block also ICMP. Most firewalls block ICMP these days, because the days of blacklisting are over and ICMP is not the one who is getting white listed. Why? The only way these days is to misuse DNS. But even that works less and less reliable.

Why would you block ICMP rather than police it or only allow certain opcodes and sizes? I hope the people blocking ICMP don't ever try and run IPv6.

Re: IP traffic over ICMP tunneling

#22

For anybody that's tried both - how do these compare to DNS tunnels (e.g. iodine), in terms of speed and reliability?

DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way.

DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you are going to use the max available DNS record size. If anything in the way will keep your DNS queries in cache then you might be screwed and run out of space very quickly.

If you need internet access ICMP tunnel will be better, bandwidth will be limited but it will be more or less a P2P tunnel, if you need to exfiltrate data without explicitly needing to maintain a bi-directional tunnel DNS is the way to go, will also work in more captive portal restrictive cases than ICMP. Today ICMP is usually utterly blocked DNS sometimes work especially in common cases where the restricted network offers some white listed sites (e.g. airport wifi that allows you to access the airport's site and the local train service but blocks everything else).

Re: IP traffic over ICMP tunneling

#23
post #7

I use to restrict ICMP to echo/reply using -m icmp on iptables, but this uses just that kind of packets... Is there anyway to stop things like this at the corporate firewall?

Out of curiosity, why would you drop echo requests or replies? I know the normal thought is "So no one will know if the IP is in use or not," but that argument doesn't hold water. Scanning toolkits have been fast enough for the past decade to skip ICMP altogether. They know you're home even with ICMP blocked.

Edited for spelling

Re: IP traffic over ICMP tunneling

#24

For anybody that's tried both - how do these compare to DNS tunnels (e.g. iodine), in terms of speed and reliability?

DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way. DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you…

With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.

Re: IP traffic over ICMP tunneling

#28

Earlier quoted context omitted.

DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way. DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you…

With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.

I haven't seen a single network stack that doesn't limit the size of the tailing payload or packet in general (MTU's ;)), go try and push 65507 bytes of payload into the message and tell me how it goes.

In any case DNS tunnel offers you both TCP and UDP tunneling at much higher throughput, I'll take a look at your code when I'll have the time and see how it compares to ptunnel or ICMP shell.

Re: IP traffic over ICMP tunneling

#29

Earlier quoted context omitted.

DNS is less reliable, but could give you bigger throughput (you can send and request large records) ICMP packets would arrive quicker, will be more reliable will bypass various DNS hijackers (common with many ISP's) along the way. DNS also requires you to have a DNS server and a domain, and you'll need something to constantly clear the cache on the local machine otherwise you'll eventually run out of room even if you…

With even ICMP you can send/receive large messages. There is no restriction on the maximum payload length.

Normally, an ethernet or wifi restricts an MTU of 1500. I use ping packets accordingly

Re: IP traffic over ICMP tunneling

#30

Earlier quoted context omitted.

Yes. In my opinion they should restrict the payload size of an ICMP message. Blocking all echo/reply can have adverse impact on other applications as well.

A couple of million small packets in a short timeframe will still eat up your resources. If an application needs ICMP echo to pass transparently through your firewall then you should probably review your need for that application, you're one step away from becoming a partner in someone else's amplification attack.

ICMP echo isn't amplification, as long as you don't respond to multicast/broadcast addresses. It's still 1:1 reflection, so you probably want to rate limit if it's simple (FreeBSD and Linux come out of the box with sane default rate limits).
Post reply on HN