How can ICMP echo requests and replies carry a covert tunnel through a firewall, and which traffic signals give one away?
answer
- a payload nobody inspects
- replies must return request data
- a custom responder breaks that rule
- sizes, rates, one distant peer
- allow-list who may ping out
basics
~20 sICMP echo carries a free-form data field, so a tunnel sends upstream data in echo requests and its own responder returns downstream data in replies. Mismatched request and reply data, odd sizes and sustained volume to one peer reveal it.
solid answer
~50 sAn ICMP echo request (type 8 in IPv4, type 128 in ICMPv6) carries a 16-bit identifier, a 16-bit sequence number and a data field of any length, and a firewall that permits ping usually passes the reply that matches an outgoing request. A tunnel client inside wraps its traffic in the data field of echo requests to an outside host. That host runs its own responder rather than the operating system's, and returns downstream data in the replies. That breaks echo semantics: RFC 792, RFC 1122 and RFC 4443 require a reply to return the request's data, so a reply whose payload differs from its request is the strongest signal. Others are varying or large payloads, a sustained message rate to one external address, and high-entropy data. The controls: let only monitoring hosts ping out, cap echo payload size, rate-limit echo, and compare request and reply payloads where the firewall can inspect them.
go deeper
Recall that echo messages have a free-form data field, so anything can ride inside them, and that firewalls usually allow ping.
Explain the mechanics: identifier and sequence matching, the RFC rule that replies mirror request data, and why a custom responder and client polling are needed.
Show detection and control judgment: payload mismatch, size, rate and single-peer duration as signals; allow-listing, payload caps and rate limits as controls that keep ping working.
Treat it as a policy question: every permitted protocol is a potential carrier, so decide which diagnostics each host class genuinely needs and make the permitted ICMP set match that.
## What an echo message can carry ICMP echo has a small fixed header and an open-ended payload: | Field | Size | Purpose | |---|---|---| | Type | 8 bits | 8 = echo request, 0 = echo reply (ICMPv6: 128 and 129) | | Code | 8 bits | 0 | | Checksum | 16 bits | Integrity of the ICMP message | | Identifier | 16 bits | Lets the sender match replies to its requests | | Sequence number | 16 bits | Distinguishes successive requests | | Data | variable | Anything the sender chooses | The protocol puts **no rule on the data's content or length** beyond the size of the IP datagram. Its one firm rule points the other way: RFC 792 says the data received in an echo message must be returned in the reply, RFC 1122 repeats it as a MUST, and RFC 4443 requires ICMPv6 to return it "entirely and unmodified". A normal responder is a mirror. ## How a tunnel is built 1. A client inside the network encodes outbound data (a command, a file chunk, a wrapped IP packet) into the **data field of echo requests** addressed to an outside host the operator controls. 2. The outside endpoint does not let its operating system answer. Its own program reads each request, decodes the data, and builds an **echo reply with the same identifier and sequence number** but **different data**: the downstream traffic. 3. A stateful firewall sees an outbound request and a matching inbound reply, the same pair it sees for every ping, and passes both. 4. Because the outside cannot start a conversation through the firewall, the client **polls**: it keeps sending requests, often with nothing in them, so that the endpoint always has a reply slot to fill. Throughput is bounded by how many echo messages pass per second and how large each payload may be, which is why the controls below aim at exactly those two numbers. Reliability is the tunnel's own problem too: ICMP has no retransmission, so the tunnel software must number, acknowledge and resend its chunks, often reusing the sequence number field for the purpose. ICMPv6 error messages have the same weakness. RFC 4890 §3.5 notes that because some errors must pass a firewall in both directions, their payload could carry a covert conversation or tunnelled packets. ## Why firewalls let it through - "Allow ping" rules are written to permit diagnostics, and rarely say anything about payload. - Stateful matching checks the identifier and addresses, which a tunnel copies faithfully. - Many monitoring setups only count ICMP packets, not bytes or payload content. ## Signals that give a tunnel away - **Reply data that differs from the request data.** A standards-following responder never does this; it is the most specific signal available. - **Payload sizes that vary, or run large.** Typical ping implementations send a small, fixed-size payload by default; this is implementation behaviour, not a protocol rule, but it makes deviations easy to spot. - **Volume and duration.** Steady echo traffic to one external address for hours, or byte counts far above what diagnostics need. - **Regular polling.** A constant cadence of near-empty requests is the client keeping its reply slots open. - **Payload content.** High-entropy data, or data that looks like another protocol's headers. - **ICMPv6 errors whose quoted packet matches no real flow** of the protected network. ## Controls that work - **Allow-list who may send echo out**: monitoring hosts and named targets, not every workstation. - **Cap echo payload size** at the firewall to what diagnostics need. - **Rate-limit echo** per host, which bounds tunnel throughput even when it is not detected. - **Compare request and reply data** where the firewall can inspect payloads, and drop replies that do not mirror their request. - **For ICMPv6 errors**, RFC 4890 recommends inspection that checks the quoted packet is associated with legitimate traffic to or from the protected network. Dropping inbound echo requests does none of this: the tunnel rides outbound requests and their replies. ## Common misconceptions - That ICMP, having no ports, cannot carry application data. - That echo payloads have a protocol-fixed size. - That stateful request/reply matching makes tunnelling impossible.
- Why does an ICMP echo tunnel's client keep sending echo requests even when it has nothing to send?Through a stateful firewall, inbound data can only arrive as a reply to a request the firewall saw leave. The outside endpoint cannot start a conversation, so the client polls with near-empty requests to give it reply slots for downstream data. That steady cadence of small requests to one external address is itself a detection signal.
- Can ICMP error messages, not just echo, carry a covert channel?Yes. RFC 4890 §3.5 warns that because ICMPv6 errors such as Packet Too Big must pass a firewall in both directions, their payload could carry a covert conversation or tunnelled packets. Its remedy is inspection that checks the quoted packet belongs to legitimate traffic of the protected network. A stateful firewall that matches quoted headers to tracked flows applies the same idea to ICMPv4 errors.
saying these in an interview costs you the question
- ICMP has no ports, so it cannot carry application data.
- Echo payloads are fixed at a small size by the protocol.
- Stateful matching of echo replies to requests prevents tunnelling.
- A reply payload that differs from its request is normal and proves nothing.
- Blocking inbound echo requests alone stops an outbound ICMP tunnel.