Detecting Malicious Activity With DNS Backscatter Over Time

Fukuda, Kensuke; Heidemann, John; Qadeer, Abdul

doi:10.1109/tnet.2017.2724506

Cited by 23 publications

(14 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our classification procedure and the parameters for duration and threshold all differ from IPv4 because DNS backscatter is less frequent in IPv6 than in IPv4. The IPv6 duration and threshold (d of 7 days and q of 5 queriers) are both laxer than IPv4, where d = 1 and q = 20 [14]. In preliminary investigations using the IPv4 parameters we did not detect any ground truth scans ( Table 5).…”

Section: Dns Backscatter In Ipv6mentioning

confidence: 87%

“…Different from our prior work on DNS backscatter in IPv4 [14], we directly infer the class of originator instead of using machine learning (ML) techniques. We shift away from ML because the number of queriers is much smaller, so the dataset is too small for effective classification with ML.…”

Section: Originator Classification In Ipv6mentioning

confidence: 99%

“…For example, rules that use domain names will misclassify if scanning is done from mail.example.com. As IPv6 use increases, more backscatter will allow use of more robust rules and potentially machine learning, as we used for IPv4 [14].…”

Section: Originator Classification In Ipv6mentioning

confidence: 99%

“…the IPv6 version and circles the IPv4 version. For reference, we also provide observations for scans of random IPv4 addresses (data from Figure 4 from [14]) and a projected fit along the diagonal.…”

Section: Comparing Backscatter: Ipv4 and Ipv6mentioning

confidence: 99%

“…DNS backscatter detects network-wide events by watching for frequent, common reverse DNS names [14]. Although developed for IPv4, its sensitivity depends on traffic triggered by network wide events (not address space size), so DNS backscatter holds promise for IPv6.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Who Knocks at the IPv6 Door?

Fukuda

Heidemann²

2018

Proceedings of the Internet Measurement Conference 2018

Self Cite

View full text Add to dashboard Cite

DNS backscatter detects internet-wide activity by looking for common reverse DNS lookups at authoritative DNS servers that are high in the DNS hierarchy. Both DNS backscatter and monitoring unused address space (darknets or network telescopes) can detect scanning in IPv4, but with IPv6's vastly larger address space, darknets become much less effective. This paper shows how to adapt DNS backscatter to IPv6. IPv6 requires new classification rules, but these reveal large network services, from cloud providers and CDNs to specific services such as NTP and mail. DNS backscatter also identifies router interfaces suggesting traceroute-based topology studies. We identify 16 scanners per week from DNS backscatter using observations from the B-root DNS server, with confirmation from backbone traffic observations or blacklists. After eliminating benign services, we classify another 95 originators in DNS backscatter as potential abuse. Our work also confirms that IPv6 appears to be less carefully monitored than IPv4.

show abstract

Section: Dns Backscatter In Ipv6mentioning

confidence: 87%

Section: Originator Classification In Ipv6mentioning

confidence: 99%

Section: Originator Classification In Ipv6mentioning

confidence: 99%

Section: Comparing Backscatter: Ipv4 and Ipv6mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Who Knocks at the IPv6 Door?

Fukuda

Heidemann²

2018

Proceedings of the Internet Measurement Conference 2018

Self Cite

View full text Add to dashboard Cite

show abstract

Plumb: Efficient stream processing of multi‐user pipelines

Qadeer

Heidemann

2020

Softw Pract Exp

Self Cite

View full text Add to dashboard Cite

Operational services run 24×7 and require analytics pipelines to evaluate performance. In mature services such as domain name system (DNS), these pipelines often grow to many stages developed by multiple, loosely coupled teams. Such pipelines pose two problems: first, computation and data storage may be duplicated across components developed by different groups, wasting resources. Second, processing can be skewed, with structural skew occurring when different pipeline stages need different amounts of resources, and computational skew occurring when a block of input data requires increased resources. Duplication and structural skew both decrease efficiency, increasing cost, latency, or both. Computational skew can cause pipeline failure or deadlock when resource consumption balloons; we have seen cases where pessimal traffic increases CPU requirements 6‐fold. Detecting duplication is challenging when components from multiple teams evolve independently and require fault isolation. Skew management is hard due to dynamic workloads coupled with the conflicting goals of both minimizing latency and maximizing utilization. We propose Plumb, a framework to abstract stream processing as large‐block streaming (LBS) for a multi‐stage, multi‐user workflow. Plumb users express analytics as a DAG of processing modules, allowing Plumb to integrate and optimize workflows from multiple users. Many real‐world applications map to the LBS abstraction. Plumb detects and eliminates duplicate computation and storage, and it detects and addresses both structural and computational skew by tracking computation across the pipeline. We exercise Plumb using the analytics pipeline for B‐Root DNS. We compare Plumb to a hand‐tuned system, cutting latency to one‐third the original, and requiring 39% fewer container hours, while supporting more flexible, multi‐user analytics and providing greater robustness to DDoS‐driven demands.

show abstract