Our Findings
Using AmpMap, we ran our Internet measurements for 6 UDP-based protocols (DNS, NTP, SNMP, Memcached, Chargen, SSDP). While we highly encourage you to check our paper, we briefly summarize a subset of our key findings.
Using AmpMap, we ran our Internet measurements for 6 UDP-based protocols (DNS, NTP, SNMP, Memcached, Chargen, SSDP). While we highly encourage you to check our paper, we briefly summarize a subset of our key findings.
Uncover new patterns and polymorphic variants
Uncover new patterns and polymorphic variants
AmpMap measurements uncovered new patterns and polymorphic variants while confirming the known patterns (e.g., GetBulk for SNMP, ANY or TXT lookups for DNS). For instance, for DNS, apart from ANY lookups, we also uncover multiple patterns (e.g., URI, SRV, CNAME lookups) that collectively incur 21.9 × more risk than a popular-known pattern (ANY lookup). For SNMP, apart from GetBulk requests, AmpMap discovers that GetNext can also incur up to hundreds of amplifications. Refer to our paper for an extensive list of new patterns and polymorphic variants we uncovered. We have reported findings have been disclosed to affected vendors, IP owners, and CERT. Refer to our paper for more extensive list of patterns we found.
AmpMap measurements uncovered new patterns and polymorphic variants while confirming the known patterns (e.g., GetBulk for SNMP, ANY or TXT lookups for DNS). For instance, for DNS, apart from ANY lookups, we also uncover multiple patterns (e.g., URI, SRV, CNAME lookups) that collectively incur 21.9 × more risk than a popular-known pattern (ANY lookup). For SNMP, apart from GetBulk requests, AmpMap discovers that GetNext can also incur up to hundreds of amplifications. Refer to our paper for an extensive list of new patterns and polymorphic variants we uncovered. We have reported findings have been disclosed to affected vendors, IP owners, and CERT. Refer to our paper for more extensive list of patterns we found.
Diversity across protocols and servers
Diversity across protocols and servers
Our measurements revealed significant variability with the amplification that each server can yield; e.g., the amplification factor (AF) can vary between 0 to 1300 for NTP. This confirms we cannot assess amplification risk by looking at mega-amplifiers or simply counting the number of servers. We also observe substantial variability in the AF distribution across protocols. The figure on the right shows the maximum AF distributions with varying amplification factor ranges (e.g., 10-30) across protocols. As seen, 60.4% of Chargen servers can yield AF above 100 (yellow bar) but only 0.02% of servers for DNS. Such variability across multiple dimensions calls for the need to do periodic measurements rather than one-time analysis
Our measurements revealed significant variability with the amplification that each server can yield; e.g., the amplification factor (AF) can vary between 0 to 1300 for NTP. This confirms we cannot assess amplification risk by looking at mega-amplifiers or simply counting the number of servers. We also observe substantial variability in the AF distribution across protocols. The figure on the right shows the maximum AF distributions with varying amplification factor ranges (e.g., 10-30) across protocols. As seen, 60.4% of Chargen servers can yield AF above 100 (yellow bar) but only 0.02% of servers for DNS. Such variability across multiple dimensions calls for the need to do periodic measurements rather than one-time analysis
Significant Residual Risk using Known Patterns
Significant Residual Risk using Known Patterns
By analyzing our measurement data, we unfortunately find that just disabling the few known patterns is far from enough and still leaves significant residual risks. For instance, blocking EDNS0 and ANY or TXT lookups for DNS still leaves 17.9× the residual risk from “other” patterns. For instance, the world map on the right visualizes a bird’s-eye view of the residual risk when these known patterns (by prior work) are BLOCKED. While the size of the circle is proportional the max amplification of each server, the red circles denote when a server is susceptible to significant amplification risk even with the filtering. Check out our paper for more extensive list of residual risk across all protocols we scanned!
By analyzing our measurement data, we unfortunately find that just disabling the few known patterns is far from enough and still leaves significant residual risks. For instance, blocking EDNS0 and ANY or TXT lookups for DNS still leaves 17.9× the residual risk from “other” patterns. For instance, the world map on the right visualizes a bird’s-eye view of the residual risk when these known patterns (by prior work) are BLOCKED. While the size of the circle is proportional the max amplification of each server, the red circles denote when a server is susceptible to significant amplification risk even with the filtering. Check out our paper for more extensive list of residual risk across all protocols we scanned!