automatically gather more information on block detection

[darkk]

Simple mtr --report-wide --show-ips --tcp --port 443 blocked.ws and mtr --report-wide --show-ips --udp --port 53 8.8.8.8 in addition to plain mtr --report-wide --show-ips --icmp example.net may add valuable information to web_connectivity report when some network block happens.

Sending DNS query directly to SOA NS may be useful too as 8.8.8.8 is well-known and may be hijacked on per-IP basis.

ooniprobe may gather alike data as soon as it detects major difference between measurement & control.

[bassosimone]

Yes, very good suggestion! On a related note (perhaps of the note to self type) the traceroute engine in measurement-kit is very basic, and I'd like to be able to do some mtr --report ish from measurement-kit (I doubt this could work on mobile, at least to the full extent that mtr works on desktops).

[darkk]

BTW, mtr may be misleading too. I've observed mtr showing stars for the final hop when the final hop was just replying slooowly (say 7-20seconds) while studying the data on TCP PEP (Performance-enhancing proxy) of a 3G ISP.
Always-on tcpdump revealed that mtr behavior and saved me from producing a false claim :)

[darkk]

Some notes while observing DNS spoofing at AS41843:

1. There is DNS answer race (like TCP RST race to terminate connection in other networks) when "bad" domain is queried — so patient client gets two answers
2. Both A and AAAA queries point to well-known blockpage webserver
3. DNS requests to whole internet (say, RA.N.DO.M or dig +trace) are intercepted and spoofed response is returned for bad domains
4. TCP/DNS requests to the internet (say, 8.8.8.8, 77.88.8.8, 208.67.222.222) are not intercepted
5. Latency — min(spoofed) 2ms, min(8.8.8.8) 36ms, min(77.88.8.8) 35ms, min(208.67.222.222) 75ms
6. curl -H 'Host: dns.google.com' https://google.com/resolve is not intercepted (obviously) either cloudfronted or not
7. TTL does not tick in spoofed replies when requests to caching recursive resolver are retried in a couple of seconds
8. EDNS OPTs are echoed by well-known recursor and this specific hijacking recursor drops them
9. Usual ip.id & ip.ttl reasoning applies as well. ip.id is likely hard to capture for non-root MK, but ip.ttl may be read with IP_RECVTTL, it's also possible to have control server sending packets with TTL=192 (or anything uncommon), so IP_RECVTTL will show injected packets in a more contrast way

So (2) and (3) are already gathered, gathering data for (1), (4), (5), (7), (8) and (9) may be useful in some cases.

[darkk]

Some notes while observing RST injection at AS8997:

1. curl https://rutracker.org/forum/index.php fails due to RST injection
2. curl https://RuTracker.org/forum/index.php works due to case-sensitive SNI field comparison
3. openssl s_client -connect rutracker.org:443 works as openssl does not send SNI by default
4. fun fact: rutracker.org is closer to me (in terms of TTL) than the injector service while doing tcptraceroute with payload packet
5. splitting ClientHello or GET in the middle of domain name does not trigger RST
6. splitting ClientHello anywhere within the ClientHello packet passes through the filter
7. splitting Host: rutracker.org\r\n header right before \r\n still triggers redirect injection, although it's technically incorrect as Host: rutracker.org may become Host: rutracker.org.example.org\r\n in further packets

[darkk]

RIPE Atlas DNS hackathon have brought another awesome masterpiece: Recursive DNS Server Fingerprint.
I wonder if there is anything in IDN handling that may be used for fingerprinting as well.

[darkk]

PTRs of infrastructural IPs are also useful as services may migrate and it may be good to have that information stored (that can also be done in the pipeline).

[darkk]

Some notes while observing DNS zone hijacking at some of recursors in AS22047:

1. queries to riseup.net domain return NXDOMAIN response without any additional data
2. query to really non-existent domain under net TLD returns SOA record for the TLD

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> -t soa riseup.net @190.160.0.14
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14098
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;riseup.net.                    IN      SOA

;; Query time: 11 msec
;; SERVER: 190.160.0.14#53(190.160.0.14)


; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> -t soa riseup-21059-24778-32011.net @190.160.0.14
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50719
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;riseup-21059-24778-32011.net.  IN      SOA

;; AUTHORITY SECTION:
net.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1499795223 1800 900 604800 86400

;; Query time: 17 msec
;; SERVER: 190.160.0.14#53(190.160.0.14)

[darkk]

measurement-kit/measurement-kit#1311 brings the idea of fingerprinting https blockpage server checking supported TLS versions and ciphersuites. See also DinoTools/sslscan.