

IPv6!
kensuke@nii.ac.jp



 /


1

Kensuke Fukuda ()• Affiliation:– National Institute of Informatics (
– Sokendai ())• Position: Associate professor• Research interests: Network measurement,
Network security

2

Kensuke Fukuda ( )• Affiliation:– National Institute of Informatics (– Sokendai ( )




 )



• Position: Associate professor• Research interests: Network measurement,
Network security

3

Detecting IPv6 network scanners
Kensuke Fukuda
National Institute of Informatics / Sokendai
Fukuda, et al. ”Detecting Malicious Activities with DNS Backscatter over Time."
In IEEE/ACM Transactions on Networking, vol.25, no.5, pp.3203–3218, 2017.
Fukuda, et al. ”Who Knocks at the IPv6 Doors? Detecting IPv6 Scanning" In ACM
Internet Measurement Conference 2018, Boston, MA, 2018. (to appear)4

Today’s talk• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
5Deployment of IPv6
• Growth of IPv6 deployment– 20% of Google users– 25% of ASes announce IPv6 prefix

www.google.com/intl/en/ipv6

IPv6 security does matter?

6

IPv4 scan
• Easy to scan whole IPv4 address space– Research purpose• Finding vulnerability• Detecting outage– Other purpose• De facto scanning tool: Zmap
– Takes 45 min with a single 10GE port
– Many security studies used Zmap
Z.Durumeric, et al. “Zmap: Fast Internet-wide Scanning and Its Security Applications.” In
7
USENIX Security Symposium 2013, pp.605-620, Washington D.C, 2013

IPv4 scan in the wild

work measureuld limit meanning context,
essiveness andthe work ofects have alsoe documentasuit. Up to ourin the wild.

AWI repository
ed from 14:00
nk connectingo the Internet.
en universities
m (AS) where Figure 1: Port targeted by TCP network scans (radius reprethrough BGP sents the monthly number of scans).
xes J.Mazel,
add up to
et al. “Profiling Internet Scanners: Spatiotemporal Structures and Measurement
trace(i.e. In
15 TMA 2017, Dublin, Ireland, 2017, IEEE/IFIP
8
Ethics.”ily traffic, the by the firewalls participating in the DShield project. SANS

• Measured at a transit link in WIDE (AS2500)

Figure 3: Scanning patterns in MAWI longitudinal: monthly number a

IPv4 scan in the wild

second.
ZMap aWe ma

C. ScaNaiv
quentia
Randomtraffic
time-w
Figure 2: Monthly number of scans exhibiting Zmap and adminis[23] usMasscan fingerprints in MAWI longitudinal.
• > 100 scanning IPs / month with scan tools observe
spreadJ.Mazel, et al. “Profiling Internet Scanners: Spatiotemporal Structures and Measurementpoobservations
qualitatively
consistent with past any
9Ethics.” In These
TMA 2017,
Dublin, Ireland,are
2017,
IEEE/IFIP

IPv4 scan in the wild

• Source: /18 IPv4 darknet
10• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
11Difficulty in IPv6 scan
• Huge address space– IPv4: 4.3 x 109 -> IPv6: 3.4 x 1038

• SLAAC: Stateless Address Auto Configuration– EUI-64 based (RFC4291)– Semantically Opaque Interface Identifiers(RFC7217)

Random probing is not efficient!
Question: How to generate target IPv6 addresses?
12

Making target hitlists for scan
• Passive data collection– Traffic data

• Active data collection– Alexa top 1M, rDNS (IPv4 -> A -> AAAA -> IPv6),
traceroute, Zone files,• Target generation– rDNS scan
– Generating plausible addresses
13Passiveand Active measurement
TABLE XI: Statistics of active, passive, and traceroute sources.

We
File size
75MB
5.4GB
2.4MB
40MB
gatherUnique input lines
2.7M
149M
1.3M
618k
of preUnique targets
2,699,573
148,631,234
109,554
102,580
Unique ASes
5,750
8,219
4,170
5,488
responUnique announced prefixes
8,602
17,554
5,367
9,269
with rAS coverage
56.46%
80.71%
41.00%
53.90%
recom
ASes unique to source
128
1,276
14
147
Normalized ASes
1,918.33
3,684.67
1,158.83
1,873.17
Addit
Prefix coverage
33.37%
68.09%
20.76%
36.00%
on a hPrefixes unique to source
346
5,798
53
514
Normalized prefixes
3,199.25
10,302.58
1,569.92
3,681.25
There
ICMPv6 response rate
75.5%
13.3%
n/a
42.0%
addre
Combined unique IPs
149,619,624
Futur
Combined AS coverage
8,531 (83.77%)
type aCombined prefix coverage
18,502 (71.77%)
help.
IP addO. Gasser, et al. “ScanningTABLE
the IPv6 Internet:
Towardsa Comprehensive
XII: Web
Serverstatistics. Hitlist.” In TMA Ackn
14
2016., Louvain La Neuve, Belgium, 2016. IFIP
perco
Characteristic

Active sources Passive sources Traceroutes CAIDA [5]Passive and Active measurement

TABLE XI: Statistics of active, passive, and traceroute sources.

W
File size
75MB
5.4GB
2.4MB
40MB
gath
Unique input lines
2.7M
149M
1.3M
618k
of p
Unique targets
2,699,573
148,631,234
109,554
102,580
Unique ASes
5,750
8,219
4,170
5,488
resp
Unique announced prefixes
8,602
17,554
5,367
9,269
with
AS coverage
56.46%
80.71%
41.00%
53.90%
reco
ASes unique to source
128
1,276
14
147
Normalized ASes
1,918.33
3,684.67
1,158.83
1,873.17
Add
Prefix coverage
33.37%
68.09%
20.76%
36.00%
on a
Prefixes unique to source
346
5,798
53
514
Normalized prefixes
3,199.25
10,302.58
1,569.92
3,681.25
The
ICMPv6 response rate
75.5%
13.3%
n/a
42.0%
addr
Combined unique IPs
149,619,624
Futu
Combined AS coverage
8,531 (83.77%)
type
Combined prefix coverage
18,502 (71.77%)
help
IP a
O. Gasser, et al. “Scanning the IPv6 Internet: Towards a Comprehensive Hitlist.” In TMA
TABLE
15
2016., Louvain La Neuve,
Belgium,XII:
2016.WebIFIP Server statistics.
Ack
Characteristic

Active sources Passive sources Traceroutes CAIDA [5]Reverse DNS (rDNS) scan
• Crawling PTR registered nameip6.arpa.

0.
1.
2.

0 1 2 …
0 1… f⋮32.

0 1… f

1.0.0.2.ip6.arpa. -> NOERROR
f

0.1.0.0.2.ip6.arpa. -> NOERROR
0.0.1.0.0.2.ip6.arpa. -> NOERROR⋮

1.1.0.0.2.ip6.arpa. -> NXDOMAIN -> (ignore subtree)
2.1.0.0.2.ip6.arpa. -> NOERROR
0.2.1.0.0.2.ip6.arpa. -> NOERROR⋮• Found 5.8M new addresses (from 73K /32
seeds)
T. Fiebig, et al. “Something from nothing (There): Collecting global IPv6 datasetsfrom DNS,” In PAM’17, pp.30-43, Sydney, Australia, 2017.

16

Note on rDNS scan
• How often PTRs are registered in v6?
• Checking route advertised 175K /32 prefixes(2018.09)– No error: 7K– Serv fail: 33K– NX domain: 135K

• Sparsely registered!
– Usage is limited?
– Registration is limited?
, et al. “IPv6 .” 

2018.0917

visualthodfor aelco’se.
ntery perhis int the, the• Bayesian inference with nibble-based entropyA

1.0

Normalized value

BC

D E F G H I

J

K

(a)

0.8
0.6
0.4
0.2

Entropy (per nybble)
0.0
0Probability

nting
esses
ncreymizes, weGenerating plausible addresses

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

16

(b)

A

20010db8

32

48

64

80

Prefix length / Hex char location (bits)
B

00

96

112

128

C

D E F G H I

J

K

10
22
20
21

0
0
0 0
1
3
1
1 8
3
5
6
d 1
2
4
0 2
9 5
4
8
5
5 9
5
0
3
2 2
f
7
d
f f
d

00000000000
0000ed18068
fffb2bc655b

000
fff

e.g. 2001:0db8:0022:1048:17ec:d7eb:19b0:dfe4

P. Foremski, et al. "Entropy/ip: Uncovering structure in ipv6 addresses." In IMC’16,
pp.167-181, Santa Monica, USA, 2016.

18

Generating plausible addresses
Murdock et al.
• Clustering dense partof nibbles

2::?:?0?

1: Dynamic nybbles for a cluster of 7 seeds (the cluseed set). The cluster has three dynamic nybbles (the29 nybble indices have identical values for all ads) and a range of 2::?:?0?

A.Murdock, et al. ”Target Generation for Internet-wide IPv6 Scanning." In IMC’17,
pp.167–181,
London,UK, 2017. because addressalculate distanceat the nybble
granularity

19Summary: Hitlist generationĥ

1: xÿçìĝ£ďĝ" IPv6 /CY;¾

N

Gasser et al. [7]\Defeche et al. [8],traﬃc, traceroute,

150M

BitTorrent peers

1.5M

Method #Addresses (seeds)

*#Addresses

DNS AAAA/PTRěR

Data source

Fiebig et al. [9]rDNS scan

5.8M (73K)

Foremski et al. [10]Entropy

770K (10K)

Murdock et al. [11]Clustering

55M (3.0M)

t+*'8^EÞĕT^9^·/ãÞ(+&Ħ

, et al. “IPv6 

2. 2 

.” 

 IID 2018.0920

• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
21

IPv6 scan response

TABLE XI: Statistics of active, passive, and traceroute sources.

We
File size
75MB
5.4GB
2.4MB
40MB
gatherUnique input lines
2.7M
149M
1.3M
618k
of prefi
Unique targets
2,699,573
148,631,234
109,554
102,580
Unique ASes
5,750
8,219
4,170
5,488
responUnique announced prefixes
8,602
17,554
5,367
9,269
with reAS coverage
56.46%
80.71%
41.00%
53.90%
recommASes unique to source
128
1,276
14
147
Normalized ASes
1,918.33
3,684.67
1,158.83
1,873.17
Additio
Prefix coverage
33.37%
68.09%
20.76%
36.00%
on a hPrefixes unique to source
346
5,798
53
514
Normalized prefixes
3,199.25
10,302.58
1,569.92
3,681.25
Theref
ICMPv6 response rate
75.5%
13.3%
n/a
42.0%
addresCombined unique IPs
149,619,624
FutureCombined AS coverage
8,531 (83.77%)
type aCombined prefix coverage
18,502 (71.77%)
help. M
IP addO. Gasser, et al. “Scanning the IPv6 Internet: Towards a Comprehensive Hitlist.” In TMA
TABLE XII: Web Server statistics.
Ackno
22
2016., Louvain La Neuve, Belgium, 2016. IFIP
Characteristic

Active sources Passive sources Traceroutes CAIDA [5]IPv6 scan response

TABLE XI: Statistics of active, passive, and traceroute sources.

We
File size
75MB
5.4GB
2.4MB
40MB
gatherCoverageisso-so,
but
Coverage
is
good,
but
a
Unique input lines
2.7M
149M
1.3M
618k
Uniquetargets
2,699,573
148,631,234
109,554
102,580
more
responses
few
responses of prefi
Unique ASes
5,750
8,219
4,170
5,488
responUnique announced prefixes
8,602
17,554
5,367
9,269
with reAS coverage
56.46%
80.71%
41.00%
53.90%
recommASes unique to source
128
1,276
14
147
Normalized ASes
1,918.33
3,684.67
1,158.83
1,873.17
Additio
Prefix coverage
33.37%
68.09%
20.76%
36.00%
on a hPrefixes unique to source
346
5,798
53
514
Normalized prefixes
3,199.25
10,302.58
1,569.92
3,681.25
Theref
ICMPv6 response rate
75.5%
13.3%
n/a
42.0%
addresCombined unique IPs
149,619,624
FutureCombined AS coverage
8,531 (83.77%)
type aCombined prefix coverage
18,502 (71.77%)
help. M
IP addO. Gasser, et al. “Scanning the IPv6 Internet: Towards a Comprehensive Hitlist.” In TMA
TABLE XII: Web Server statistics.
Ackno
23
2016., Louvain La Neuve, Belgium, 2016. IFIP
Characteristic

Active sources Passive sources Traceroutes CAIDA [5]IPv4/v6 scan response0Percent of Population Open
10
15
20
5

15.3%
18.0%

NTP
0.4%
6.2%

SSH

Telnet

HTTP
HTTPS
DNS

0.2%
1.8%
0.4%
0.3%
0.4%
0.2%
0.2%
0.1%

}+14%
}+166%

0.3%
3.0%
0.6%
3.9%

BGP

SNMP

25

}+73%
}+156%
Both
IPv4
IPv6

}+285%
}−3%
}−12%
}−6%

Fig. 1: Percentage of 25K dual-stack routers (RB ) responsive to ping that were open via IPv4 and/or IPv6 for eachapplication tested. For each application, the green bar
corresponds to reachability (connection success) over only
IPv4, the red bar only IPv6, and the blue bar reachability
over both. Beside each bar we report the percentage ofhosts tested that were only reachable by IPv4 or IPv6,and beside each application is the percentage difference inreachability over IPv6 compared to IPv4.

signal less attention paid to blocking its traffic over IPv6 thanhas been deployed for IPv4 [18]. Further, we found that the
NTP version command we used can leak the device vendor
and version in many cases, which may be helpful to attackers
targeting specific vulnerabilities.
SSH: The second most open application we see is SSH.
SSH also has the second largest discrepancy between the two
protocols, with IPv6 being more than twice as open; 166%
more routers allow connecting over IPv6 than IPv4. As SSH
is a management application allowing control over the device,this is a troubling finding. If exploited via brute-force password
attempts, harvested passwords used by administrators on othercompromised sites or hosts, or via software vulnerabilities, SSH
access could lead to stealthy and large-scale attacks. As withmost router vulnerabilities, these might include, for example,
redirecting traffic for specific websites, email, or DNS queries
to attackers, and facilitating other various forms of man-in-themiddle attacks. Further, since routers are specialized systems
with typically proprietary operating systems and less generalpurpose computing power, they may be less likely than servers
to be bolstered with protections against a range of SSH-based
attacks—e.g., password attempt limits, SSH key-only logins,and logging failed attempts.

• Ping to 25K Dual stack routers• More open ports in IPv6

BGP: The third most open application is BGP, which we would
expect to
be running on routers,ofbutIPv6
not to Network
necessarily be open
J.Czyz et al. “Don’t Forget to Lock the Back Door!
Characterization
the routers, and six of eleven tested applications are more
for anyone to connect. An open BGP port on routers leaves
Security
In While
NDSS18%2016.,
SanandDiego,
InternetSocietyopenover IPv6Policy.”
for servers.
of routers
17% 2016.
them potentiallymore
susceptible to various TCP-based attacks, 24of servers we tested were reachable in IPv4 for at least one
such as SYN floods, and blind in-window attacks [36]. The

• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
25Detecting Network-wide Scans• Passive backbone/IXP traffic collection• Darknet (aka network telescope)– Routed but no legitimate hosts• Distributed firewall logs (e.g., SANS)• DNS backscatter

26

Key idea of DNS backscatter• Large event triggers reverse DNS
queries near target automatically

+

He

+
He
+

He

– SMTP server: hostname of spammer– Firewall: hostname of scannerDetector– Web server: hostname of web crawler
Backscatter

Projectile
energy

Ag
Ag
Ag

Mg
Ag
Ag

Ag

Mg

Ag

Samplematerial

Ag

Ag

Li

Mg

Ag

Ag
Ag

• Many reverse DNS queries (DNS
backscatter) at auth server are hint
to identify events

Fukuda, et al. ”Detecting Malicious Activities with DNS Backscatter over Time." In
IEEE/ACM Transactions on Networking, vol.25, no.5, pp.3203–3218, 2017.

27

Detecting Events through DNS backscatter
Originator

TargetQuerier

Mailserverspam.bad.jp(1.2.3.4)

a.example.com(192.168.0.1)

Spammer

MailserverRecursive
resolverrdns.example.com(192.168.0.3)(5) analysis of thequeriers tells about
originatorAuthserverm.root-servers.net(1.in-addr.arpa)

b.example.com(192.168.0.2)(1) Q: whooriginates,
and for what
purpose?

Authority

Mail
serverRecursive
resolverc.example.jp(172.16.0.1)

rdns.example.jp(172.16.0.2)

a.dns.jp(2.1.in-addr.arpa)
bad.jp: the final authority(3.2.1.in-addr.arpa
and 4.3.2.1.in-addr.arpa)(4) DNS goes to theauthority servers
192.168.0.3 "PTR? 4.3.2.1.in-addr.arpa"(3) they makeQuery log @ Auth server

SMTP (application traffic)(2) bothering
many targets

DNS: PTR? 4.3.2.1.in-addr.arpa

172.16.0.2 "PTR? 4.3.2.1.in-addr.arpa"
reverse DNS queries
to log or check theoriginatorDifferent Authorities See Different
Amount of Backscatter
More events and
Ex: 203.178.18.19 -> pinger-j2.ant.isi.edu
more attenuation

Zone -> Authority

Root
Root

Com
Com

AC
AC

JP
JP

AD
AD

UK
UK

in-addr.
in-addr.
arpa
arpa

00 11 203
203 255
255
COCO
00 11 178
178 255
255

NII
NII

SINET
SINET
SINET

NTT
NTT
00 148148 150150 255
255

Local
Local

00 11 19
19 255255

Tradeoff
betweenin-addr.arpa-> Root DNS
visibilityof events
203.in-addr.arpa-> APNIC&
178.203.in-addr.arpa-> JP-DNS
attenuation of signal

148.178.203.in-addr.arpa -> WIDE

19.148.178.203.in-addr.arpa -> Final Auth

Less events andless attenuation

29

%
10
0

10
%

1%

0.1
%

%
0.0
1

01
0.0

%

00
6

10

0.0

105
full IPv4 space

Number of unique queriers (IP addresses)

1%

IPv4 backscatter sensitivity

4

10

(fit

3

10

)

final authority

102(measurements)
detection threshold (20 queriers)

101

B-longM-ditl-2015

0

10

103

(censuses)

104

105
106
107
108
Number of targets (IP addresses)

10930

Advantages• Deployable– Centralized monitoring at DNS authority• Privacy friendly– Information is on queriers NOT originators– Reverse queries are generated automatically– Focus on large events (ignore small users)• Robust against malicious originators• Can infer different class of originator (e.g., scanner)with Machine Learning
31

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)32

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)

Query logs: from any server
2 Root DNS
JP-DNS
Local authority(Querier -> Originator)
mail1.example.com -> 1.2.3.4
fw0.foo.jp -> 5.6.7.8
spam.good.jp -> 1.2.3.4
ns0.example.jp -> 7.8.9.10

33

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)

Query logs: Large originators(N > 20)(Originator -> #Uniq Queriers)
1.2.3.4 -> 50 (Keep)5.6.7.8 -> 10 (Drop)
7.8.9.10 -> 5 (Drop)34

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

querier

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)

originator feature

smtp0.ok.com -> 1.2.3.4 (mail)mail1.example.com -> 1.2.3.4 (mail)spam.foo.jp -> 1.2.3.4 (spam)
ns0.bar.jp -> 1.2.3.4 (ns)35
Feature vector: 1.2.3.4: <mail 50%, ns 25%, spam 25%, #AS, qps…>

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)

Ground truth from dozen of public sources (darknet, DNLBL…)(Class: ad-tracker, cdn, cloud, crawler, dns, mail, scan, spam…)
Originator
Feature vector
class
11.12.13.14 <mail 45%, ns 20%, spam 5%,…> mail21.22.23.24 <mail 60%, ns 15%, spam 5%,…> mail31.32.33.34 <mail 45%, ns 15%, spam 15%,…> spam 36

Identification process
Labeled data
12 originator classes

Data
collection
Query log at Authority

Extract large
originators

Featureextraction

Class
Identification

Keep Originators
more than N queriers

Static: keywords
Dynamic: time&space

Supervised learning(Random forest)

1. Training with labeled data
2. Classify test data with classification matrix
Originator 1.2.3.4 <mail 50%, ns 25%, spam 25%, #AS, qps…>-> spam37

Discriminative power of static features1

fraction

0.8
0.6
0.4

other
other of mail
Ratiosotheruncl
are differentuncl
nxdom

uncl

other
uncl

other

other
uncl
spam

nxdom

nxdom
ns

other

nxdom uncl
ns

ns

Ratio of spam is different
in mail and spam

mail

mail

nxdom nxdom
ns

0.2

home

ns

ns

unclassified
spam
mail
nxdom
ns

home home home0
scn-icmp scn-ssh ad-track

cdn

Significant ratio
home home
home
of
home
mail
spam

case study

Different mixes of features allow distinguishing different
classes of events
38

Picking the best ML algorithm
dataset algorithm accuracy precision recall F1-score
CART
0.66
0.63
0.60
0.61
JP
RF
0.78
0.82
0.76
0.79
ditl
SVM
0.73
0.74
0.71
0.73
B
CART
0.48
0.48
0.45 RandomForest
0.46
postRF
0.62
0.66
0.60
0.63
is best
ditl
SVM
0.38
0.50
0.32
0.39
CART
0.53
0.52
0.49
0.51
M
RF
0.68
0.74
0.63
0.68
ditl
SVM
0.60
0.68
0.52
0.59
to improve
CART
0.61
0.65 Hope
0.58
0.61 withMRF
0.79
0.82 better
0.77training
0.79data
sampled
SVM
0.72
0.76
0.70
0.73

• Cross validation with 3 ML algorithms
Table 1: Validating classification against labeled ground• truth.
Num classes: 12, labeled data:200-800• Precision: 70-80% (imbalanced dataset problem)39• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
40How to adapt to IPv6
• Number of queriers is much smaller in v6– ML doesn’t work well
– More aggregation (1day -> 1week)• We directly infer the type of originator– Originator’s Keyword and AS• smtp.foo.bar -> mail– Originator-Querier relation• All belongs to the same AS -> not network-wide events– Matching with Blacklists• Spam, scan, etc
Fukuda, et al. ”Who Knocks at the IPv6 Doors? Detecting IPv6 Scanning" In IMC’18,
Boston, MA, 2018. (to appear)41

Classification• Major services: Google, MS, FB, Yahoo (by ASN)
• CDN: Akamai,,, (by ASN)
• DNS: Zone files, keyword• NTP: NTP pool, keyword• Mail/Web• Iface: traceroute, keyword• Tunnels: 6to4, Teledo• Spam: Blacklist• Scan: Blacklist, backbone data42• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
43Analyzing IPv6 backscatter sensitivity• Custom IPv6 network scanner– Multiple proto/service (ICMP, TCP22, TCP80,UDP53,
UDP123)– Uniq source IP for each target• Local authoritative server– TTL = 1s

Who Knocks at the IPv6 Door? Detecting IPv6 Scanning• Three hitlists
Label
Alexa
rDNS
P2P

# addrs Description
10k Alexa 1M; servers
1.4M Reverse DNS
40k P2P Bittorrent; clients
Table 1: IPv4/IPv6 hitlists

44

6

10

105

IPv4 random

104

full IPv4 space

Number of unique queriers (IP addresses)

V4/V6 backscatter sensitivity

)

(fit

rdns4
p2p4

3

10

rdns6

alexa4

2

10

101
100 3
10

p2p6

alexa6
4

10

5

6

7

8

10
10
10
10
Number of targets (IP addresses)

910• x10 smaller DNS backscatter
45

Application response
IMC’18, October 31–November 2, 2018, Boston, MA, USA

icmp6 (ping)type
queries
expected reply
other reply
no reply
expected v4 reply

928953145264402292

62.9%
9.8%
27.2%

-

57.8%

Kensuke Fukuda and John Heidemanntcp22 (ssh)tcp80 (web)udp53 (DNS)...
1476509100%...
410421 27.8% 661182 44.8%
69965
4.7%
205446 13.9% 201627 13.7% 672171 45.5%
860642 58.3% 613700 41.5% 734373 49.4%
-

30.0%

-

35.4%

-

udp123 (NTP)
140893371044964572

9.5%
25.1%
65.3%

-

5.9%

6.3%

Table 2: Scan results overview (rDNS): expected reply is the number of expecting unique replies, e.g., ICMP echo reply for
ICMP echo. Other reply is unexpected one, e.g., ICMP destination unreach., and no reply is lack of reply.

v6 backscatter
w/expected reply
w/other reply
w/no reply

icmp6 (ping)
1809(0.12%)
1371 75.8% (0.09%)
44 2.4% (0.002%)
394 21.8% (0.03%)

tcp22 (ssh)774(0.05%)
365
47.2% (0.03%)
94 12.1% (0.006%)
315
40.7% (0.02%)

tcp80 (web)1020(0.07%)
597 58.5% (0.04%)
87 8.5% (0.006%)
336 32.9% (0.02%)

udp53 (DNS)653(0.04%)
137 21.0% (0.01%)
265 40.6% (0.02%)
251 38.4% (0.02%)

udp123 (NTP)746(0.05%)
134 18.0% (0.01%)
183 24.5% (0.01%)
429 57.5% (0.03%)

v4 backscatter

4478

2731

3094

3961

4045

• Source: rDNS
• ICMP6 > tcp80 > tcp22 > udp123 > udp53• No significant difference between v4 and v6(0.30%)(0.18%)(0.21%)(0.27%)(0.27%)

Table 3: DNS backscatter and application behavior (rDNS).

The relationship between DNS backscatter and applications is not
obvious, because DNS backscatter typically results from logging,

Backbone tra�c: To con�rm scanners we use MAWI
46 tra�c
traces [6] that are captured at a transit link of AS2500 (WIDE) from

icmp6 (ping)type
queries
expected reply
other reply
no reply

tcp22 (ssh)tcp80 (web)udp53 (DNS)...
1476509100%...
410421 27.8% 661182 44.8%
69965
4.7%
205446 13.9% 201627 13.7% 672171 45.5%
860642 58.3% 613700 41.5% 734373 49.4%

Backscatter and response

expected v4 reply

928953145264402292

62.9%
9.8%
27.2%

-

57.8%

-

30.0%

-

35.4%

-

udp123 (NTP)
140893371044964572

9.5%
25.1%
65.3%

-

5.9%

6.3%

Table 2: Scan results overview (rDNS): expected reply is the number of expecting unique replies, e.g., ICMP echo reply fo
ICMP echo. Other reply is unexpected one, e.g., ICMP destination unreach., and no reply is lack of reply.

v6 backscatter
w/expected reply
w/other reply
w/no reply

icmp6 (ping)
1809(0.12%)
1371 75.8% (0.09%)
44 2.4% (0.002%)
394 21.8% (0.03%)

774
365
94
315

tcp22 (ssh)(0.05%)
47.2% (0.03%)
12.1% (0.006%)
40.7% (0.02%)

v4 backscatter

4478

2731

(0.18%)(0.30%)

tcp80 (web)1020(0.07%)
597 58.5% (0.04%)
87 8.5% (0.006%)
336 32.9% (0.02%)

udp53 (DNS)653(0.04%)
137 21.0% (0.01%)
265 40.6% (0.02%)
251 38.4% (0.02%)

udp123 (NTP)746(0.05%)
134 18.0% (0.01%)
183 24.5% (0.01%)
429 57.5% (0.03%)

3094

3961

4045

(0.21%)(0.27%)(0.27%)

Table 3: DNS backscatter and application behavior (rDNS).

•
Backscatter:
how
often
firewalllogs?
The relationship between DNS backscatter and applications is not
Backbone tra�c: To con�rm scanners we use MAWI tra�
obvious, because DNS backscatter typically results from logging,traces [6] that are captured at a transit link of AS2500 (WIDE) fromand thelog (or not) depends on perceptionsof protocollarger
June 2017
to March 2018.
• choice
V4to backscatter
is x3-5thanv6Data is a sample taken for 15 minutesensitivity.
at 2pm JST each day. We extract IPv6 packets from the mixed un
Table 3 shows DNS backscatter detections and their yield, howanonymized v4 and v6 trace. We see about 7M IPv6 packets in eac
Backscatter
expected
reply:okbutloggedmany•replies
are seen relative to di�erentwith
types of replies(expected,
day’ssample.
other, or no reply). Yield is small, varying from 0.12% for ICMP
Followed by a heurestic classi�er [21] for MAWI data, we de�necho (icmp6) to 0.04% for DNS (udp53), consistent with limited
monitoring in IPv6, compared to monitoring DNS backscatter in
IPv4 (0.2-0.3%). The amount of DNS backscatter depends on the
protocol. For common protocols like icmp6 and web, we see morea network scanner as a source IPv6 address that (1) has �ve omore destination IPs, (2) all going to a common destination por
47 IP, an(3) with, on average, fewer than ten packets per destination(4) the entropy of packet length is smaller than 0.1. The last crite• Introduction• Network scans: state of the art– Hitlist generation– IPv4/IPv6 sensitivity• Finding IPv6 scanners with DNS backscatter– DNS backscatter– How to adapt to IPv6
– Measurement results• Sensitivity• Detecting IPv6 scanners
48

Datasets• DNS backscatter:– B-root DNS server– Full capture (31M uniq querier-originator pairs)• Backbone: MAWI traffic repository– Transit link in AS2500 (WIDE)– Tcpdump in 15 min each day• Darknet: SINET darknet– v6 /37 advertised from AS2907 (SINET)
49

Classification results (B-root)

Who Knocks at the IPv6 Door? Detecting IPv6 Scanning

Category
Services:
Content Provider
Facebook
GoogleMicrosoft
Yahoo
CDN
Well-known service
DNS
NTP
mail (SMTP)
web (HTTP)
Minor service
other services
qhost
Routers:
Routeriface
near-iface
TunnelTeredo/6to4
tor
Potential Abuse:
Abuse
spam
scan
unknown (potential abuse)
Total

IMC’18, October 31–November 2, 2018, Boston, MA, USACount(mean/week)

%
total

4722
3653
727
329
13
286
815
337
414
42
22
268
83
185

70.24
54.34
10.82
4.89
0.19
4.25
12.12
5.01
6.16
0.62
0.33
3.99
1.23
2.75

288
256
32
216
207
9

4.28
3.81
0.48
3.21
3.08
0.12

128
17
16
95
6723

1.90
0.25
0.24
1.41
100.00the backbone segment or send tra�c to the darknet, but potentiallymore sensitive at detecting small scans.
First, we �nd four scanners in both DNS backscatter and MAWI
backbone data: scanners (a) through (d) in Table 5. Only scanner(a) appears in darknet data.
Scanner (a) probes TCP port 80. It appears in MAWI on six days,
but the intensity of DNS backscatter is not high (Parenthetic number
in DNS BS indicates the number of weeks the originator appears atleast once). Scanners (b) to (d) appear two times in DNS backscatterand also two days in MAWI. These results provide con�rmationthat DNS backscatter does see actual scanners.
This result also shows the limited e�ectiveness of darknets forIPv6: they can only see a tiny fraction of the vast IPv6 space, making
DNS backscatter and tra�c observation more important techniques
in IPv6. Only scanner (a) appears in the darknet, MAWI, and DNS
backscatter. Some of CAIDA’s Archipelago measurements [3] appear only in the darknet.
Second, we see that DNS backscatter misses three of the scanners
we see in MAWI (scanners e, f, and g). DNS backscatter only detects
big events that generate many reverse DNS queries, and thesescanners are fairly brief (1 or 2 days seen in MAWI). In addition,scanners (e) through (g) target only a narrow range of IP blocks (i.e.,a single /48), so DNS backscatter from many locations is unlikely.
Thus, these scanners show that DNS backscatter will miss smallscans.
Third, we see that there are 95 unknown (potential abuse) detections seen in backscatter data only. We suggest that these arepotential scanners missed in MAWI and our darknet.
Scan types: A natural question is to ask what hitlists these50
known, detected scanners employ. Carefully checking target IP

Classification results (B-root)

Who Knocks at the IPv6 Door? Detecting IPv6 Scanning

Category
Services:
Content Provider
Facebook
GoogleMicrosoft
Yahoo
CDN
Well-known service
DNS
NTP
mail (SMTP)
web (HTTP)
Minor service
other services
qhost
Routers:
Routeriface
near-iface
TunnelTeredo/6to4
tor
Potential Abuse:
Abuse
spam
scan
unknown (potential abuse)
Total

IMC’18, October 31–November 2, 2018, Boston, MA, USACount(mean/week)

%
total

4722
3653
727
329
13
286
815
337
414
42
22
268
83
185

70.24
54.34
10.82
4.89
0.19
4.25
12.12
5.01
6.16
0.62
0.33
3.99
1.23
2.75

288
256
32
216
207
9

4.28
3.81
0.48
3.21
3.08
0.12

128
17
16
95
6723

1.90
0.25
0.24
1.41
100.00the backbone segment or send tra�c to the darknet, but potentiallymore sensitive at detecting small scans.
First, we �nd four scanners in both DNS backscatter and MAWI
backbone data: scanners (a) through (d) in Table 5. Only scanner(a) appears in darknet data.
Scanner (a) probes TCP port 80. It appears in MAWI on six days,
DNS
backscatter
mainlybut the intensityof DNS
backscatter is nothigh (Parenthetic number
in DNS BS indicatesthe content
number of weeks
the originator appears at
detectproviderleast once). Scanners (b) to (d) appear two times in DNS backscatter
CDNThese(benign)
and also two daysandin MAWI.
results provide con�rmationthat DNS backscatter does see actual scanners.
This result also shows the limited e�ectiveness of darknets forIPv6: they can only see a tiny fraction of the vast IPv6 space, making
DNS backscatter and tra�c observation more important techniques
in IPv6. Only scanner (a) appears in the darknet, MAWI, and DNS
backscatter. Some of CAIDA’s Archipelago measurements [3] apTraceroute triggers
pear only in the darknet.
Second, we seemany
that DNSbackscattersbackscatter misses three of the scanners
we see in MAWI (scanners e, f, and g). DNS backscatter only detects
big events that generate many reverse DNS queries, and thesescanners are fairly brief (1 or 2 days seen in MAWI). In addition,scanners (e) through (g) target only a narrow range of IP blocks (i.e.,a single /48), so DNS backscatter from many locations is unlikely.
Clear
Thus, these scanners
show abuse
that DNSandbackscatter will miss smallscans.
potential ones
Third, we see that there are 95 unknown (potential abuse) detections seen in backscatter data only. We suggest that these arepotential scanners missed in MAWI and our darknet.
Scan types: A natural question is to ask what hitlists these51
known, detected scanners employ. Carefully checking target IP

Scanners confirmed at MAWI

18, October 31–November 2, 2018, Boston, MA, USA

Kensuke Fukuda and John Heide

MAWI
Backscatter
Dark
ASN info#days
port scan type#weeks #weeks(a)2001:48e0:205:2::/64
6 TCP80 Gen
1 (5)140498 New Mexico Lambda Rail(b)
2a02:418:6a04:178::/64
2 ICMP rand IID
2 (4)029691 Nine, CH(c) 2a02:c207:3001:8709::/64
2 TCP80 rand IID
2 (2)051167 Contabo, DE(d)2a03:f80:40:46::/64
2 ICMP rDNS
2 (3)05541 ADNET-Telecom, RO(e)2405:4800:103:2::/64
2 ICMP rDNS0 (4)018403 FPT-AS-AP, VN(f)2a03:4000:6:e12f::/64
1 ICMP rDNS0 (0)0 197540 NETCUP-GmbH, DE(g)2800:a4:c1f:6f01::/64
1 ICMP rDNS0 (0)06057 ANTEL, UY
5: Observed IPv6 scanners in MAWI; /64 of IPs are anonymized. Scan types consist of Gen: target generation, ran
om and small right most nibble, and rDNS: reverse name registered.

12
10
8
6
4
2
0
45
40
35
30
25
20
15
10
5
0

IP

• 4 scanners are detected both MAWI andbackscatter
since three factors are relevant: greater scanning, greater ccation of scanning, and generally greater use of IPv6. We
this increase outpaces the general increase in all DNS backs• 3 small scanners are missed
in backscatterover that time, which went from about 5000 to 8000 IPs ov
period. However, the 3⇥ increase in scanning is larger than thincrease in all DNS backscatter. Our count of con�rmed sca• Darknet only finds 1 scanner
is based on seeing them some other source (MAWI or dark

(a) x

07/27

(b)

x xx x

08/10

08/24

09/07

x

09/21
xx

x

10/05

mawi scans

10/19
11/02
mawi scans

11/16

52

Scanners confirmed at MAWI
Research scanner @ Berkeley

18, October 31–November 2, 2018, Boston, MA, USA

Kensuke Fukuda and John Heide

MAWI
Backscatter
Dark
ASN info#days
port scan type#weeks #weeks(a)2001:48e0:205:2::/64
6 TCP80 Gen
1 (5)140498 New Mexico Lambda Rail(b)
2a02:418:6a04:178::/64
2 ICMP rand IID
2 (4)029691 Nine, CH(c) 2a02:c207:3001:8709::/64
2 TCP80 rand IID
2 (2)051167 Contabo, DE(d)2a03:f80:40:46::/64
2 ICMP rDNS
2 (3)05541 ADNET-Telecom, RO(e)2405:4800:103:2::/64
2 ICMP rDNS0 (4)018403 FPT-AS-AP, VN(f)2a03:4000:6:e12f::/64
1 ICMP rDNS0 (0)0 197540 NETCUP-GmbH, DE(g)2800:a4:c1f:6f01::/64
1 ICMP rDNS0 (0)06057 ANTEL, UY
5: Observed IPv6 scanners in MAWI; /64 of IPs are anonymized. Scan types consist of Gen: target generation, ran
om and small right most nibble, and rDNS: reverse name registered.

12
10
8
6
4
2
0
45
40
35
30
25
20
15
10
5
0

IP

• 4 scanners are detected both MAWI andbackscatter
since three factors are relevant: greater scanning, greater ccation of scanning, and generally greater use of IPv6. We
this increase outpaces the general increase in all DNS backs• 3 small scanners are missed
in backscatterover that time, which went from about 5000 to 8000 IPs ov
period. However, the 3⇥ increase in scanning is larger than thincrease in all DNS backscatter. Our count of con�rmed sca• Darknet only finds 1 scanner
is based on seeing them some other source (MAWI or dark

(a) x

07/27

(b)

x xx x

08/10

08/24

09/07

x

09/21
xx

x

10/05

mawi scans

10/19
11/02
mawi scans

11/16

53

Scanners confirmed at MAWI

18, October 31–November 2, 2018, Boston, MA, USA

Kensuke Fukuda and John Heide

MAWI
Backscatter
Dark
ASN info#days
port scan type#weeks #weeks(a)2001:48e0:205:2::/64
6 TCP80 Gen
1 (5)140498 New Mexico Lambda Rail(b)
2a02:418:6a04:178::/64
2 ICMP rand IID
2 (4)029691 Nine, CH(c) 2a02:c207:3001:8709::/64
2 TCP80 rand IID
2 (2)051167 Contabo, DE(d)2a03:f80:40:46::/64
2 ICMP rDNS
2 (3)05541 ADNET-Telecom, RO(e)2405:4800:103:2::/64
2 ICMP rDNS0 (4)018403 FPT-AS-AP, VN(f)2a03:4000:6:e12f::/64
1 ICMP rDNS0 (0)0 197540 NETCUP-GmbH, DE(g)2800:a4:c1f:6f01::/64
1 ICMP rDNS0 (0)06057 ANTEL, UY
5: Observed IPv6 scanners in MAWI; /64 of IPs are anonymized. Scan types consist of Gen: target generation, ran
om and small right most nibble, and rDNS: reverse name registered.

12
10
8
6
4
2
0
45
40
35
30
25
20
15
10
5
0

IP

• rDNS hitlists: 4 scanners
since (e.g.,
three factors2001:db8:1::10)
are relevant: greater scanning, greater c• Rand IID hitlists: 2 scanners
cation of scanning, and generally greater use of IPv6. We
this increase outpaces the general increase in all DNS backs• Generative hitlists: 1 scannerover that(6Gen)
time, which went from about 5000 to 8000 IPs ov

(a) x

07/27
(b)

x xx x

08/10

08/24

09/07

x

09/21
xx

x

10/05

mawi scans

10/19
11/02
mawi scans

11/16

period. However, the 3⇥ increase in scanning is larger than thincrease in all DNS backscatter. Our count of con�rmedsca
54
is based on seeing them some other source (MAWI or dark(Why darknet misses?)• Current scanners rely on hitlists– Never scan IP addresses not in hitlists• Require to register to hitlists– Add v4 PTR, A, and AAAA records!
– Add v6 PTR records!

55

Number of unique queriers

MAWI scan and backscatter
12
10
8
6
4
2
0
45
40
35
30
25
20
15
10
5
0
50
40
30
20
10
0
70
60
50
40
30
20
10
0

(a) x

x xx xx

x

mawi scans

07/27

08/10

08/24

09/07

09/21
xx

10/05

10/19
11/02
mawi scans

11/16

07/27

08/10

08/24

09/07

09/21
x

10/05
x

10/19
11/02
mawi scans

11/16

07/27

08/10

08/24

09/07

09/21
xx

10/05

10/19
11/02
mawi scans

11/16

07/27

08/10

08/24

09/07

10/19

11/16

(b)

(c)

(d)

09/21
10/05
date (2017)• Strong temporal correlation!

11/02

56

Abuse over time
200
180

unknown (potential abuse)

Number per week

160
140
120
100
80
60
40
20

confirmed scan

0
07

08

09
10
11
Month (2017)12• The number of scans increases over time57

Abuse over time
200
180

unknown (potential abuse)

Number per week

160
140
120
100
80

2 researchscanners
included60
40
20

confirmed scan

0
07

08

09
10
11
Month (2017)12• The number of scans increases over time58

Conclusion• IPv6 scanning: state of the art– Hitlist generation– Comparison with IPv4 scans• DNS backscatter - a new data
source for Internet-wide events– Adapt to IPv6
– Works well

• IPv6 scanners increase over time

+

He

+
He
+

He

Projectile
energyAg

Detector
Backscatter

Ag
Ag

Mg
Ag
Ag

Ag

Mg

Ag

Ag

Samplematerial

Mg

Ag
Li
Ag

Ag
Ag

59

Thanks to• JSPS Kakenhi Grant (15KK0019, 18H03237)• Collaborators:– John Heidemann (USC/ISI)– Yudai Aratsu (U.Tokyo)• Others:– Johan Mazel (ANSSI, FR)– Romain Fontugne (IIJ)– Kenjiro Cho (IIJ)– Yoshinobu Matsuzaki (IIJ)

k
n
a
h
T
you!
60