[atlas] List of Atlas probes subjected to DNS traffic interception (MITM)

Hi Giovane,

On Fri, Sep 29, 2017 at 03:55:21PM +0200, Giovane C. M. Moura wrote:
> > It seems that the "DNS Root Instances" map could be used for that purpose,
> > because DNS traffic interception shows up as if the probe was contacting
> > an "Unknown" root instance.  To get the list of probes, I ended up using
> > an URL like the following, showing probes for all possible "unknown" root
> > instance hostnames:
> 
> You're right. We've done the same in a study on the Roots[1].
> On that time, we found 74 probes with this issue.

Thanks for the pointer!  Quoting the relevant part of your IMC paper:

    Moreover, we also discard measurements of a few VPs where traffic to a
    root appears to be served by third parties.  We identify hijacking in
    74 VPs (less than 1%) by the combination of a CHAOS reply that does
    not match that letter’s known patterns and unusually short RTTs (less
    than 7 ms), following prior work [23].

Did you discard probes that match *both* criteria, or just one of the
criteria?  In my preliminary experiments I did notice the very low RTT,
but just filtering on unusual CHAOS replies seemed to be enough.

> > Or has
> > anybody already done this classification work independently?
> 
> Root Servers return a standard answer for chaos queries. So you can use the
> Ripe measurements to the roots for that.
> 
> Lemme illustrate that with B-Root. B-Root CHAOS IPv4  measurement is
> https://atlas.ripe.net/measurements/10310.
> 
> The chaos answer should either be b*-lax or b*-mia (it has two anycast
> sites, Miami and LA).

I was running UDM towards a public resolver to perform CHAOS queries, but
re-using the root measurements is quite clever, thanks for the idea!

> Here's how you can do it:
> 
> 1. Download part of the dataset from the measurement on B-root
> (https://atlas.ripe.net/measurements/10310/#!download). Start with the last
> 30 min or so.
> 
> 2. Parse the json and extract the answers [2], you'll need to decode the
> abuf field [3]
> 
> 3. See which probes do not give the standard answers (b*-mia or b*-lax).
> 
> Another indicator I found is that usually is that hijacked probes tend to
> have *very short RTTs*. Imagine a probe in Eastern Europe connecting on
> b-root in LA with a RTT of 3ms.... just physically impossible. So by
> coupling the chaos  answers with rtt you'll be fine.
> 
> Heads-up: be aware that the list of hijacked probes may change as probes can
> change their locations, or ISPs change their configurations. So make sure
> you use the right time frame you're interested.
> 
> good luck,
> 
> /giovane
> 
> [1] https://www.sidnlabs.nl/downloads/papers-reports/imc2016.pdf
> [2] https://github.com/RIPE-NCC/ripe.atlas.sagan
> [3] https://atlas.ripe.net/docs/code/#decoding_dns_abuf
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </ripe/mail/archives/ripe-atlas/attachments/20170929/31222c58/attachment.sig>