In our Internet scanning experiments over the years, we have observed that some simple probes (for example, a TCP SYN or ICMP echo request) yield large volumes of packets in response although at most a few packets would be expected from the protocol specifications. We call this unexpected response traffic ‘blowback’.
Blowback presents a hurdle to Internet-scanning measurements as experimenters must cope with blowback bursts and distinguish the blowback from the traffic relevant to their study. More problematically, the blowback can be used as part of denial-of-service (DoS) attacks — once the attacker identifies the targets that trigger blowback, the attacker can use these targets to reflect and amplify the attacker’s traffic.
Consequently, my fellow researchers and I from Case Western Reserve University and ICSI investigated the blowback phenomenon in more detail in the recent paper ‘On Blowback Traffic on the Internet‘. This post will summarize the finding of that paper.
In the paper and below, we refer to all traffic triggered by a single probe as the ‘response’ to that probe, regardless of the nature or senders of this traffic, and the probe’s target as the ‘response generator’ — not to be confused with the senders of the response packets as these are often distinct from the probe’s original target. Recently, another study independently looked at this phenomenon in the context of DNS probes. We consider blowback broadly across multiple probe types and over several weeks.
Methodology
Our study considers blowback to six commonly used probe types — a DNS query (‘DNS scan’), an ICNP echo request (‘ICMP scan’), an NTP time request (‘NTP scan’), and TCP SYNs to ports 25, 80, and 443 (‘TCP25, TCP80, and TCP443 scans’). Since responses may not match the probe’s protocol and come from different senders, we must match the probes with the resulting incoming traffic.
We match incoming packets to outstanding probes by:
- Matching protocol features we explicitly set our probe packets (DNS query string, TCP sequence numbers, ICMP ID) when available (for example, from the in-protocol response packet or from quoted information in an incoming ICMP packet).
- Matching the probe’s target IP address with the quoted destination address in an incoming ICMP packet.
- For incoming UDP and TCP packets, matching both the source IP address with the probe’s target address and the destination port number of the incoming packet with the static source port number we used for our probes.
Any probes not receiving new matches for 10 minutes are flushed from the set of probes to be matched. This procedure matches 95 to 99% of the incoming traffic across all our scans and probe types. We ignore the (relatively few, <5%) unmatched packets in our analysis to keep it conservative in that the blowback phenomenon can only be worse than we find.
For each protocol, we conduct a full scan and, after matching probes to responses as discussed above, identify a set of response generators that triggered a response of at least four packets for subsequent rescans. Focusing on these generators — which we call ‘blowback generators (BBG)’ below — cuts the number of rescan targets by an order of magnitude in most of the protocols while still covering a majority — from 58% in the TCP80 scan to 99.8% in the ICMP scan — of multi-packet response traffic.
We conduct six rescans of blowback generators, starting six to nine days after the corresponding full scan and continuing every three to four days. Together with the full scan, this gives us a view of the blowback generator behaviour over the period of at least three weeks. Note that the targets in rescans for a given protocol are determined by the full scan and are fixed regardless of the responsiveness of these targets in a given rescan.
Key findings
Every probe type we tested encounters a large number of blowback generators, as shown in the second column of Table 1.
| Probe type | BBGs | Probe volume (MB) | Average response packets (X106) | Average response volume (MB) | Average packet amplification | Average volume amplification |
| DNS | 60,511 | 6.1 | 1.8 | 132.6 | 30x | 22x |
| ICMP | 107,912 | 3.0 | 103.5 | 7,271.6 | 959x | 2,424x |
| NTP | 56,149 | 4.3 | 21.0 | 1,585.2 | 374x | 369x |
| TCP443 | 241,353 | 9.7 | 2.7 | 144.2 | 11x | 15x |
| TCP25 | 85,687 | 3.4 | 1.6 | 89.0 | 19x | 26x |
| TCP80 | 298,379 | 11.9 | 3.2 | 167.7 | 11x | 14x |
Not only are BBGs numerous but they are also fairly stable and continue to produce high blowback volumes. Table 1 presents the average amplification in our six rescans for each protocol, using the BBGs discovered during the corresponding full scans. At the extreme, ICMP exhibits three orders of magnitude amplification in both packet numbers and the overall bytes. Recall that our rescans end after three weeks since the corresponding full scans. Thus, blowback presents a large time window for a DoS attacker to leverage BBGs they learn from the full scan (note that a full scan is not a good attack vector because wasted probes to unresponsive addresses overweigh any blowback produced).
While Table 1 shows large amplification, the actual DoS damage depends on how concentrated in time the blowback is. We found blowback from different BBGs to have vastly different timing behaviours, including some bizarre patterns. For example, 132.248.104.107 responded to a DNS probe with a linearly growing blowback rate for the next 15 seconds until the rate reached 25K blowback packets per second, and then stopped (more pattern examples can be found in our paper).
However, an attack simulation using the BBGs discovered in our full scans and the blowback packet timing from the first rescan shows that the overall damage can be significant. By sending 850K packets and 38.4MB in the first second, the attacker can trigger a blowback response of 9M packets during the first second and >1M packets per second (pps) sustained over the first ten seconds. In terms of data volume, in the first three seconds, the blowback response is >100MB per second — sufficient to saturate a common Ethernet link of 1Gbps.
Blowback contains a large number of packets indicating routing abnormalities. One can expect a probed target to produce either an in-protocol response (a DNS response to a DNS query probe, for example), some variant of an ICMP type-3 message (‘Destination unreachable’), or no response at all. However, blowback includes a large number of ICMP ‘TTL Expired’ and ‘Host Redirect’ messages. These messages accounted for 66% of all multipacket responses in DNS, 89% in ICMP, 42% in TCP443, 54% in TCP25, 37% in TCP80, and 38% in NTP full scans.
Tracerouting random subsets of BBGs that had persistent multipacket response throughout the rescans indeed showed a large prevalence of routing loops (although loops still do not explain the blowback phenomenon since they should not produce multiple ICMP responses). The loop prevalence among our routes to these BBGs ranged from 8 to 10% in TCP80 and TCP443 to over 60% in NTP and ICMP. These findings are consistent with those observed in ‘Routing Loops as Mega Amplifiers for DNS-Based DDoS Attacks‘, in the context of DNS probing.
In summary, we find a significant number of blowback generators that produce large volumes of blowback when probed. Whether intentional or the result of misconfigurations, the blowback is a significant concern as it presents a hurdle to Internet experimenters and a potentially dangerous vector for denial of service attacks.
Michael Rabinovich, PhD is an Emeritus Professor at the Department of Computer and Data Sciences at Case Western Reserve University. After retiring from regular teaching, he continues conducting active research in Internet performance and security.
Contributors: Dallan Goldblatt, Calvin Vuong, and Mark Allman.
This work was supported in part by NSF through grant CNS-2219736.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.