You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet
Fiebig, Tobias
In this talk we will explore and present various IPv6 scanning techniques that allow attackers to peek into IPv6 networks. With the already known difference between IPv4 and IPv6 firewalling (the latter is worse... ) we then demonstrate how these techniques can be combined and used to obtain a large-scale view on the state of IPv6 in infrastructures and data centers. To give the whole issue a somewhat more fun dimension, we will also look at some (security) sensitive applications of this technique. Complimentary code-snippets will be provided.
 Please give a warm-up now to Tobias Fiebig, who will be talking about IPv6 global scanning. Thank you. So, good evening, everybody. Nice that you still made it, even though it's 11 p.m. Of course, this is not work of me alone. It is joint work with colleagues from UC Santa Barbara, Kevin Bogolto, Shuan Hao, Chris of Krugel and Giovanni Wigner. First thing about me. I have a Bachelor of Science in cognitive science and somewhat noticed that wetware is not really my life. So I actually went on to get a Master's in Network Engineering and since I got that, I'm more or less desperately trying to get a PhD from Professor Feldman and Professor Seifert at TU Berlin. My research interests can be summarized as basically what nobody else does, but not because my stuff is ingenious, but because most people say, well, that's stupid, that won't work anyway. I think we all know this as misconfiguration. You all know these nice people that are running database servers on the Internet without authentication. I have heard of a big ISP that actually managed to run their provisioning system on the Internet, which was not that good for connectivity for their customers. There's also other nice examples, so Mitfarge-Legenheiden.de was actually pretty good in doing backups. They even encrypted them and stored the ASK with it. And there's always a fun of finding an ISCAR device that belongs to some bulletproof host read-write on the Internet, and something I had to learn there is something called remote DMA. What could be better than doing DMA over the Internet? So basically whatever I will tell you today is directed at finding these. But first things first, ethics. I may tell you about a nice tool to have a lot of fun with, but basically... What are you, stones are stupid. You don't hack a bank across state lines from your house. You get nailed by the FBI. Where are your brains in your ass? Follow this good advice. Think about this event, think about the amount of bandwidth you have, think about the amount of bandwidth. Other people have, think about them having this nice time between the holidays at the end of the year where they don't want to work, which might happen if suddenly DNS service start crashing and other services become unreliable. So back to my motivation and some view of related work. The first part will be a little bit dry. So if you start to get bored, there's a special slide where I ask the person next to you to wake you up just right before the fun stuff starts. So please don't run away. So in the beginning, there was ZMAP that was like three years ago. And it starts this whole thing about we can scan the whole IPv4 Internet. We can do like Internet-wide security evaluations. And that was actually a whole, whole lot of fun. So I think two years ago there was this nice service in one of the lecture halls at this event where you would have something like chat relete. Only was VNC service. Yes, you love, but it actually brings us to the second point. It stops being funny when you find some asset construction facility in India on one of these slides. ZMAP was heavily used to scan for hot lead and analysis and how hot lead was mitigated. ZMAP was used to scan for, well, at least open TCP ports where you could then do a key exchange to see how it's key sharing between HTTPS servers in the world. There was research on amplification attack servers. Well, basically the amplifiers for the amplification attacks. And this ability to exhaustively scan actually helps the security community a lot. But as with all good things, or rather not so good things in this case, IPv4 is coming to an end. There's only also many addresses, two to the power of 32, in fact, theoretically. And there's a lot of work investigating how this is getting more and more exhausted and by now getting an IPv4 address is actually pretty hard. So what happened is that people introduced IPv6 like 20 years ago, around about, I think, even more. With IPv6, there comes a lot more addresses, like two to the power of 128, theoretically. And we can actually see that IPv6 is starting to get adapted. So the graph I have here is actually a bandwidth graph from this event. And we see that at peak points, we saw around 25% of outbound IPv6 traffic. This is a little bit skewed because as soon as you deploy IPv6 to your user network, you will suddenly see a lot of traffic to two or three big players like Google with YouTube and Facebook. And it still demonstrates that IPv6 is a thing that's coming. However, if we start to use, for example, that map on IPv6, we will suddenly have to wait. I cannot really pronounce that number, but it's really, really huge. And I don't really intend on living that long. So let's come to related work. So looking at IPv4 addresses was an interesting tool. It was not only used in the security community, but especially there and helped a lot there. So people want to have the same thing for IPv6. Current work is relatively focused on starting or trying to observe IPv6 address usage in the wild. Not doing active scans, but having some vantage point where they sit, where they can read something which provides them information about used IPv6 addresses. So for Romsky, Plonka and Berger, they are using the access logs of a large CDN. Of course, as good scientists, they don't disclose which CDN this is, but one of them has an ekemy mailing address. Six at all who are mostly the vantage point freest of them all. They are using various DNS data sources, but not the same as I will present in this talk. And then there's Grasse at all. They do have for some reason access to a large European IXP and can look on flow data there and thereby can get information about utilized IPv6 addresses in the wild. So let's quickly go over these. So for Romsky, Plonka and Berger actually provided the nice work where they used their data sources to train a tool which could then predict another active, that means replying to ICMP, IPv6 address based on the data sets they had previously. They are mostly using the CDN data. They have a small, really, really tiny portion of data that was gathered as the data I will present on, and they utilize TraceRoute data. This has certain drawbacks. For example, the CDN logs, of course, do not really represent a lot of, well, servers, especially not servers in the wild internet out there. TraceRoute data is by nature really, really, really biased towards networking devices because, well, it's TraceRoute data. The work by Grassett all in principle is somewhat similar. So they also try to predict active IPv6 addresses based on the data sets they have. So then we have Suss et al. Suss et al. are actually doing various mining on DNS data sets. So they have recursor data sets. So they actually get logs from DNS recursors. But they are also doing something really fun where they would actually do a PTR lookup for every address in the IPv4 space. And then do a quad A lookup to get the IPv6 address for that FQDN. And their work is actually one of the big motivations for what I'll be presenting today because they figured out that IPv6 security is not really doing that well. In other words, it's doing terribly. But well. So in summary, I looked in my basement. I didn't find a CDN. I looked it off further and I didn't find an IXP. And when I asked my IXP if they wanted to let me read their recursor's access logs, they also said something, including no. But on the other hand, if I was a politician, I would now be like, but we have this IoT, this Internet of Things. We really need the scanning to protect all the people. So well. We came up with methodology. By the way, this is the point where you want to wake up people next to you that didn't really care about related work. So first things first. So there's another person I'd like to credit. It's Peter van Dijk. I'm not really sure if I can do the IJ thing correctly because I'm not Dutch. But I hope I tried. Anyway, I met him at last ITF in Berlin. And as I heard, he's Dutch. I believed him when he started to talk about DNS. And he said, if I want to get a lot of IPv6 addresses that are assigned to servers, not clients, I should actually look at, well, IPv6 reverse DNS. He said he had some interesting preview result thingies. And I should start to dig into that. So well, as I said, Dutch people know about DNS. Like most of the DNS servers we're currently using come from the Netherlands. Let's try it. So let's start with a short recap. So IPv6 address, as I said, 128 bits. And you can represent it in 32 so-called nibbles. Those are the little things representing hexadecimal characters we see here. And reverse DNS is a way to get for an IP address you have, an FQD and a fully qualified domain name. You do this by doing some transformation to the IPv6 address. So you first reverse it. And then you put basically points between each of the nibbles for different levels in the PTR tree. And as top level domain and second level domain, you have IPv6.arper. And under that tree, you then find a record. And that record you can do a PTR request to and then you get an FQDN from the DNS server. So the next thing that is somewhat important at this point is how DNS works. So RFC 1034, I hope I get this right. I see somebody in the audience that will probably beat me up if I don't. It's not really clear about it but tries to mean it so it got clarified in RFC 8020 the meaning of NX domain. Technically NX domain should mean if you receive the reply NX domain from a server for a point and a tree, like the one to the right, that there is nothing at that point you requested or anywhere there under. So what this technology basically is, is descending trees where we received a no error for the root node. We can actually try this. So we have our given root here which is IPv6.arper. We do a DNS query for 0.ipv6.arper. We get an NX domain. So we don't descend in that tree. We do the same for the one, we do the same for the two, three, four, up to the E and we always get an NX domain. We know we don't have to descend that tree. When we have the F, we do get a no error. We don't get any data back but we get no error. So we descend that tree. Let's try. I never managed to clear our class. Sorry. Anyway, we do the same thing again and this time we start with a zero and we immediately get a no error. So we can descend that tree already. And do the same thing again and then we descend that tree and by doing this 32 times, so an IPv6 address, 32 nipples, we can finally arrive at utilized IPv6 addresses. And you see if we start with a zero, this is basically a depth first search in this huge DNS tree that is spanned out by the reverse DNS name system. So as I said, this is in itself not new. You have RC7707 which actually discusses this as a possible technique for network reconnaissance in smaller networks. They actually reference this Peter from Dyke who recommended this technique to me. And he actually wrote a small block article about this like three, four years ago and provided a Python implementation which you can utilize to actually scan the network or rather DNS, PDI prefix. This was also the starting ground for the tooling which will be provided to you in the end of this talk. First, what I used to conduct these scans is, well, it's basically the compute server we have for doing machine learning at the research group. My colleagues were not so happy that they had to stop doing this while I did my scans. But as I produce something called academic code which is basically like startup code which we don't call production ready. Everybody who loved works in a startup. But I'm pretty sure that somebody who is actually better with code than me, so like a programmer who can actually write production code, will also be able to run this code well, the code they write themselves on their laptop. So the first thing when I thought about this technique was that I do a depth first search which is a pretty bad thing if the first part of the tree is on a really, really slow DNS server on the other side of the world. So you want to have the opportunity to do some kind of breadth first search to paralyze over different DNS servers. For this I basically just iterate in four nibble steps. So in a first step I will iterate up to a length of four nibbles for all possible FGDN rack, well, PD iron trees. Then I will collect all of these and for each of these do the enumeration step for another four nibbles. If on flavor, on personal case, one might also opt to go from 16 nibbles to 32 directly, so from 64 bit to 128 bit, which may have advantages, may have disadvantages, but we will see that later when we look at the data. So this was basically what I built directly after ITF. I hacked this together, went to the office, ran it. I was pretty happy because after I let it run for a week I found 70 million records. So I then looked into the data and was wondering why I got this funny email from a large ISP with them complaining about a lot of traffic from my machine to theirs. And I learned about a really nice feature you want to have in your reverse zones when you're offering reverse zones or rather networks to customers and end users, which is dynamic reverse zones. So I have an example here. So when you have a big network and you don't want to manually set all those to the power of 64 reverse entries for all the possible users you could have, you just set a script in your DNS server that actually generates a reverse FQDN for any given reverse pointer record. They also may be static. And I also found funny, dynamically generated looking domains that are probably DNS tunnels or something like that. At least they were always returning 32 bits of something random. And being in this case you will never find an X domain. So when your algorithm is just plainly stupidly going in there, it will find a lot of records, but they all belong to, well, however big this dynamically generated reverse zone is. So I thought about a heuristics. And I first thought about doing something computational linguistics and stuff where I would compare reverse returned FQDNs to figure out if they may or may not be actually somewhat related. Turns out it doesn't really work, doesn't really perform. What performs for better is just trying to query a static set of records. And if at least three of these exist, assume the domain or rather the subtree is dynamically generated. So at least three records is a personal preference. The picking of filling up the tree to a length of 32 nipples with zeroes, ones, two, threes up until F is a not so personal reference. Some people recommended to me to do this with random data, but then you actually have to have enough non-blocking entropy for that. So, well, taste question, but this actually works. So using this, I actually tried this again. So I started at IP6.upper, let it enumerate, and then I found 1.6 million records. And you have to say I started off with like 70 million. I was really amazed. And now I only have 1.6 million records. So I was somewhat confused, which brought me to another nice finding. So they're DNS servers that are for some reason not RFC8020 compliant. So they may actually send NX domain instead of no error. We have an example here. So if the DNS server on which F.ip6.upper is resident on sends an NX domain because it has no explicit record at that point, well, then I will not say 0.f.ip6.upper. And to actually counter this issue, I got the idea of seeding my algorithm. So I do not start at IP6.upper, but I started various well-known predetermined to exist, well, sub-trees of the DNS tree for IP6.upper. I built a somewhat funny algorithm for that. Well, at each step, so at each nipple length, remember the slide, couple slides back. So for four nipples, I would actually crop the seed record to a length of four nipples and re-add the full record length again of the seed record. So that I get at each iteration all the information possible from my seed records. The seed sources I used were the route views project and the RIPE NCC. How is it called? Something with BGPV view, I always forget. Anyway, these are publicly available and actually are documented in the script that will be published with this talk. Other possible sources are, of course, the algorithm that all used where they would actually do the quad A lookups for the returned FQDNs of IPv4 reverse pointers and basically whatever data set you can get your hands on. So if you can, for example, if you are at a big event where a lot of people are using remote IPv6 servers and you were actually able to read the network traffic, which I recommend not to do, then you could also use that as a source for seeding. So with the seed set, I actually ran the programs again. This time it took nearly three days, running a parallel with 80 threads and I found 5.3 million records, which is sounding really small, but due to the, well, state of IPv6 and deployment practices on IPv6, this is still pretty decent. So it doesn't show a full, full picture, but it shows a large subset. But I was not really satisfied with the speed of this, so I tried to parallelize more because I realized that my server was, well, not really that busy. I tried to run those 400 threads. It ran faster, found less. And the lesson I had to learn was that basically the one IP address I used for resolving ran out of sockets. So if you want to heavily parallelize this, do it on multiple machines with more addresses to actually use for outbound DNS queries. Another thing that falls into this is if you are running this yourself, have a local resolver because latency to your local resolver, for example, in this network, the resolver offered by network operations will extremely increase the length of these scans and possibly will overload them. So don't run it against your speed port. So this is basically the start of other key studies. First look into this. You see basically plotted here the amount of queries I needed for records in slash 64. And we basically see a nice distribution between extremely structured zones. So zones that have colon, colon 1, colon, colon 2, extremely structured. And those that have nearly random addresses are possibly UI 64 addresses. To the left are basically those where I need more queries to find less records. And then here are the structured ones which due to the depth first nature of the algorithm will also be found first that I was then found with less queries. But I promised more fun parts. You can also utilize this tool to look at something specific. So from the huge data set you collect, you can single out specific networks. And this, for example, is an overview of how a software as a service provider does their network assignment policy. So how IPv6 addresses and networks are assigned with that service provider. Going out which service provider this is is left as an exercise to the reader. And I was told that this is too academic and just boring. So I looked at something else which is a little bit more fun. So I personally do not really do a lot of stock trading. But if you look at IPv6 networks, people suddenly have a whole lot of addresses to use. So they will address everything. They will address loop back addresses, public addresses. They will address IPME with public addresses, everything. So if you look at such a network, in this case, starting here in September with 65K of hosts around the boat, you suddenly see a huge jump of around 10K in just a matter of, well, two weeks. And like two months later, you can realize that this is a provider actually announces a record sales quarter. So this is one of the opportunities where you could use this tooling for, actually gathering information on company growth. But which is probably a lot more fun is looking at topologies. So for me, this was the most fun thing I could do with this, apart from security scans, where we all know what they will turn up. So first thing I did was looking at an IXP. By the way, I'd like to mention that this all is my personal opinion and I'm not representing affiliations and so forth. So a rendered graphs, 3A, our hosts. Blue R slash 64s, red R slash 48s, and green R slash 32s. And if you zoom out a little, you can also see black ones. Black ones are hosts that are for some reason connected to 2 slash 64s or more. So after importing this, this actually looks more like a block cube than anything fun. However, it's basically directed graph. One can sort this, make it float apart a little so you can actually recognize parts of the structure. You can add funny labels to it. Then you can look at what you can see. So this is a network of a huge IXP. This is, for example, their pop-in Hamburg. Basically their peering network. Of course, they also have a deep-end in Frankfurt. Nice thing you can actually see is, or black friend over there, they can actually see the networks the customers are having behind the router, behind the peering in Frankfurt. They also have this famous black-holing infrastructure, which you can see, being connected to their provisioning and some internal routing or interconnect infrastructure. And firewall 6 appears to be their central firewall in Frankfurt. There's a whole lot of hosts connected to it, for example, an elastic search system for customer counting and processing flow data. But I think nerds are somewhat more into other networks. So this is an example of NASA.gov. There's also somewhat bigger topologies one might want to look at. Everybody familiar with Doc Mill? So, little side note, I'm also doing the monitoring for network operations. And we will now look into it at the moment, the only network. I have the feeling that I know the topology of better than the network at this conference. For reasons, it will remain anonymous for the purpose of this talk, but technically, the data sets are public. So let's have a huge journey through a network. So like all of the networks, it has a border router and some portal systems, administration interfaces, and possibly user access networks. They also run like network infrastructure, for example, hosts called Big Brother, which is actually an ancient monitoring system. I want to give them that, which they actually had to have a lot of service for, but they are currently migrating to Prometheus, which is a somewhat new monitoring system. So, let's look at their infrastructure, how do they run? So they run a lot of open source software, so we see Gentoo. For us, probably not so who, and they also have a puppet production host. They also have an Admiral Ackbar, which made me think that it might be a honeypot. But what worked me most is actually this one. On a little more serious note, what does also teach us that these networks are run by nerds? So some more fun things due to popular demand, technical IoT. The reductions happened due to, well, for some reason, it is not opportunity to expose the IP fridges and military installations when you have collaborators from the United States. Another nice thing we found in our dataset is TCP666, the number of the back plane, 666 in this case is a place holder, because for reasons I actually talked to the company before this talk and they were like, hmm, we kind of know about this and I was like, cool, nice, so I can talk about it and they were like, yeah, well, with us. So when we are scanning some of the IPv6 addresses we collected, we would find the TCP port being open on hosts that would also expose talent as HNBGP and somewhat look like backbone links. Funnily enough, the TCP port, which should be on the slides, was more related to a technology you usually don't find on a backbone router. After some communication with a couple of friends, we figured out that technically this port should be bound to local hosts on the systems, as it is used for some back plane services. Funny side note, the vendor didn't even know how the customers managed to get this exposed. So then we have DHCPv6. We all know the issues of devices that suddenly get IPv6 addresses and become then reachable, my most favorites were printers. And something you see a lot is that these devices that are then exposed and that are really vulnerable actually do have a forward pointer for the FQDN that is returned for the IPv6 address that points to an RFC 1918, so a private network address. Other things you find is IPME, so out of bound management and various forms, what you basically use when everything burns down. One really nice, nice large operator actually has all their IPME interfaces reachable with ICMPv6, which made me wonder what would happen, which I of course didn't do, but well, it's something I'm wondering about because, well, you don't really want your IPME on the internet. And also something for the people a little bit more into network infrastructure besides our exposed back planes. Besides our exposed back planes, you will also find a lot of RIP out there, a lot of IPGP and talent as sage of internet infrastructure and internet backbone services. Another fun thing to find is Docker. One part is the nice things you can deploy with Docker, for example, Elasticsearch. It's really amazing who runs Elasticsearch as a service without authentication, only reachable via IPv6, but reachable with IPv6. For Docker instances, I don't know if you do know what these TCP ports mean for Docker installation. This is actually an API which you have to protect. There's information in the documentation, how you can enable authentication. There's actually good blog posts on how you can enable authentication using certificates and Nginx reverse proxy, but you can also just expose it to the internet. Well. So this is just a set of the opportunities you can have, which you shouldn't have. So besides actually doing the right thing and doing firewalling for your IPv6 network, you could also do something, well, security bar security. You could try to configure the reverse DNS zones in a way that always returns no data or no error. Basically masking them to this. It feels hard to say that this is an attack, but basically do this. This was already available in 2012 when Fondac first played with this. There's tools available, not applicable to all DNS servers out there, but the concept should be clear, so it should be implementable. On the other hand, we should think about techniques that probably are applicable even though this specific technique I just presented is not available. So let's quickly conclude. In the end, you can try to reject packets, but you cannot hide your network topology. You should think before setting PTR records, and you should think before connecting things to the internet. You can download my tool chain from the GitLab instance of my research group. And there's an academic publication coming up in March 2017, which is also dealing with this technique on a more measurement-related point of view. Thank you, and I'll be happy to answer any questions that are. Thank you very much indeed. First question as usually goes to the second Angel. Did you actually think about trying DNS zone transfer to see if the server would give up a bunch of PTR records due to misconfiguration? Using other techniques like AXFR is discussed in the research publication, but we didn't actually try it. Well, there's a Git link. Next question goes to Mark for number five. You got me lost a little bit here when you said that, and maybe correct me if I'm wrong, you should run your own local DNS resolver to get faster. I don't know what. And I'm kind of wondering, did you use some kind of asynchronous IO in order to parallel your resolutions instead of using a local resolver? Or maybe I misunderstood what this was solving. So running a local resolver on the machine you're doing the measurements on is basically solving the issue of overloading the local resolver for your research institution, having your system administrator standing in your office, being really, really angry. All these things that happen when they suddenly have to deal with the DNS recursors that is doing mostly the queries you're doing and not those of other people in the room or research institutions. So it's not improving the speed? It actually helps a little with speed because either you do the resolving yourself or you put it somewhere else and you basically have to wait for the answers. So if you have a little bit of latency towards your recursor, the whole process will part up, take longer. If it's on your local machine, you basically reduce one small part of latency. But again, you can probably do this better when you do the recursing and resolving from the tool chain, which I didn't do because I'm not a good programmer. Okay. Thank you. Next question goes to Mark for number one. Okay. So did you actually consider that there might be a few servers hidden in those subnets who have these generated PTR records? Yes, there may be servers hidden in there, but due to the dynamically generated PTR records, I cannot verify this without exhaustively enumerating the whole tree, which just gets really, really large. Okay. So you just, there's like the... I don't know and I cannot know. All right. Thank you. Okay. Next question goes to Mark for number two. Hi. From experience, I found that IPv6 reverse lookups are more sparse than the IPv4 versions. So do you have a reference on how many hosts you find with that technique versus hosts that are there without reverse lookup? I would really love to have that. I also...so basically if you want to make the statement you just basically asked for, you would have to compare this dataset with another independent dataset which looks at another angle of IPv6. For example, large IXP, for example, CDN dataset. Well, CDN dataset will be biased for clients and servers. So most probably the IXP dataset. At the moment, I didn't have availability of those, so I didn't investigate that. Okay. Microphone number six. You mentioned that results or the dataset of your work are public. So where is the dataset? Well, it's actually stored in a distributed manner on a lot of DNS servers. As you know it from all cool platforms, there's a dedicated download client you have to utilize. Download client source code is available at that GitLab location. Okay, microphone number five. Hello. So quick question. Most of the data on the slides were sort of western and the dot mail exploration and so on. So just as a general question, did you explore the IPv6... Oh, sorry. Did you explore a lot of this on the Asian networks of say Korea, China which has massive IPv6 use? Because of the latency thing, you know. Actually I didn't really focus on a specific per-continent analysis. I mostly presented so far in the academic work, the technique in itself and I picked interesting case studies that would demonstrate the potential of the technique. But what you suggest is actually an interesting point for further work. I would, for anyone interested in that, I would recommend Hong Kong as to the starting point to do the scans. Cheers. Okay. Any more questions? Okay. Thank you very much. Thank you. Bye.
 Please give a warm-up now to Tobias Fiebig, who will be talking about IPv6 global scanning.  Thank you.  So, good evening, everybody.  Nice that you still made it, even though it's 11 p.m.  Of course, this is not work of me alone.  It is joint work with colleagues from UC Santa Barbara, Kevin Bogolto, Shuan Hao, Chris  of Krugel and Giovanni Wigner.  First thing about me.  I have a Bachelor of Science in cognitive science and somewhat noticed that wetware is not really  my life.  So I actually went on to get a Master's in Network Engineering and since I got that,  I'm more or less desperately trying to get a PhD from Professor Feldman and Professor  Seifert at TU Berlin.  My research interests can be summarized as basically what nobody else does, but not because  my stuff is ingenious, but because most people say, well, that's stupid, that won't work  anyway.  I think we all know this as misconfiguration.  You all know these nice people that are running database servers on the Internet without authentication.  I have heard of a big ISP that actually managed to run their provisioning system on the Internet,  which was not that good for connectivity for their customers.  There's also other nice examples, so Mitfarge-Legenheiden.de was actually pretty good in doing backups.  They even encrypted them and stored the ASK with it.  And there's always a fun of finding an ISCAR device that belongs to some bulletproof  host read-write on the Internet, and something I had to learn there is something called remote  DMA.  What could be better than doing DMA over the Internet?  So basically whatever I will tell you today is directed at finding these.  But first things first, ethics.  I may tell you about a nice tool to have a lot of fun with, but basically...  What are you, stones are stupid.  You don't hack a bank across state lines from your house.  You get nailed by the FBI.  Where are your brains in your ass?  Follow this good advice.  Think about this event, think about the amount of bandwidth you have, think about the amount  of bandwidth.  Other people have, think about them having this nice time between the holidays at the  end of the year where they don't want to work, which might happen if suddenly DNS service  start crashing and other services become unreliable.  So back to my motivation and some view of related work.  The first part will be a little bit dry.  So if you start to get bored, there's a special slide where I ask the person next to you to  wake you up just right before the fun stuff starts.  So please don't run away.  So in the beginning, there was ZMAP that was like three years ago.  And it starts this whole thing about we can scan the whole IPv4 Internet.  We can do like Internet-wide security evaluations.  And that was actually a whole, whole lot of fun.  So I think two years ago there was this nice service in one of the lecture halls at this  event where you would have something like chat relete.  Only was VNC service.  Yes, you love, but it actually brings us to the second point.  It stops being funny when you find some asset construction facility in India on one of these  slides.  ZMAP was heavily used to scan for hot lead and analysis and how hot lead was mitigated.  ZMAP was used to scan for, well, at least open TCP ports where you could then do a key  exchange to see how it's key sharing between HTTPS servers in the world.  There was research on amplification attack servers.  Well, basically the amplifiers for the amplification attacks.  And this ability to exhaustively scan actually helps the security community a lot.  But as with all good things, or rather not so good things in this case, IPv4 is coming  to an end.  There's only also many addresses, two to the power of 32, in fact, theoretically.  And there's a lot of work investigating how this is getting more and more exhausted and  by now getting an IPv4 address is actually pretty hard.  So what happened is that people introduced IPv6 like 20 years ago, around about, I think,  even more.  With IPv6, there comes a lot more addresses, like two to the power of 128, theoretically.  And we can actually see that IPv6 is starting to get adapted.  So the graph I have here is actually a bandwidth graph from this event.  And we see that at peak points, we saw around 25% of outbound IPv6 traffic.  This is a little bit skewed because as soon as you deploy IPv6 to your user network, you  will suddenly see a lot of traffic to two or three big players like Google with YouTube  and Facebook.  And it still demonstrates that IPv6 is a thing that's coming.  However, if we start to use, for example, that map on IPv6, we will suddenly have to  wait.  I cannot really pronounce that number, but it's really, really huge.  And I don't really intend on living that long.  So let's come to related work.  So looking at IPv4 addresses was an interesting tool.  It was not only used in the security community, but especially there and helped a lot there.  So people want to have the same thing for IPv6.  Current work is relatively focused on starting or trying to observe IPv6 address usage in  the wild.  Not doing active scans, but having some vantage point where they sit, where they can read  something which provides them information about used IPv6 addresses.  So for Romsky, Plonka and Berger, they are using the access logs of a large CDN.  Of course, as good scientists, they don't disclose which CDN this is, but one of them  has an ekemy mailing address.  Six at all who are mostly the vantage point freest of them all.  They are using various DNS data sources, but not the same as I will present in this talk.  And then there's Grasse at all.  They do have for some reason access to a large European IXP and can look on flow data there  and thereby can get information about utilized IPv6 addresses in the wild.  So let's quickly go over these.  So for Romsky, Plonka and Berger actually provided the nice work where they used their  data sources to train a tool which could then predict another active, that means replying  to ICMP, IPv6 address based on the data sets they had previously.  They are mostly using the CDN data.  They have a small, really, really tiny portion of data that was gathered as the data I will  present on, and they utilize TraceRoute data.  This has certain drawbacks.  For example, the CDN logs, of course, do not really represent a lot of, well, servers,  especially not servers in the wild internet out there.  TraceRoute data is by nature really, really, really biased towards networking devices because,  well, it's TraceRoute data.  The work by Grassett all in principle is somewhat similar.  So they also try to predict active IPv6 addresses based on the data sets they have.  So then we have Suss et al.  Suss et al. are actually doing various mining on DNS data sets.  So they have recursor data sets.  So they actually get logs from DNS recursors.  But they are also doing something really fun where they would actually do a PTR lookup  for every address in the IPv4 space.  And then do a quad A lookup to get the IPv6 address for that FQDN.  And their work is actually one of the big motivations for what I'll be presenting today  because they figured out that IPv6 security is not really doing that well.  In other words, it's doing terribly.  But well.  So in summary, I looked in my basement.  I didn't find a CDN.  I looked it off further and I didn't find an IXP.  And when I asked my IXP if they wanted to let me read their recursor's access logs, they  also said something, including no.  But on the other hand, if I was a politician, I would now be like, but we have this IoT,  this Internet of Things.  We really need the scanning to protect all the people.  So well.  We came up with methodology.  By the way, this is the point where you want to wake up people next to you that didn't  really care about related work.  So first things first.  So there's another person I'd like to credit.  It's Peter van Dijk.  I'm not really sure if I can do the IJ thing correctly because I'm not Dutch.  But I hope I tried.  Anyway, I met him at last ITF in Berlin.  And as I heard, he's Dutch.  I believed him when he started to talk about DNS.  And he said, if I want to get a lot of IPv6 addresses that are assigned to servers, not  clients, I should actually look at, well, IPv6 reverse DNS.  He said he had some interesting preview result thingies.  And I should start to dig into that.  So well, as I said, Dutch people know about DNS.  Like most of the DNS servers we're currently using come from the Netherlands.  Let's try it.  So let's start with a short recap.  So IPv6 address, as I said, 128 bits.  And you can represent it in 32 so-called nibbles.  Those are the little things representing hexadecimal characters we see here.  And reverse DNS is a way to get for an IP address you have, an FQD and a fully qualified  domain name.  You do this by doing some transformation to the IPv6 address.  So you first reverse it.  And then you put basically points between each of the nibbles for different levels in  the PTR tree.  And as top level domain and second level domain, you have IPv6.arper.  And under that tree, you then find a record.  And that record you can do a PTR request to and then you get an FQDN from the DNS server.  So the next thing that is somewhat important at this point is how DNS works.  So RFC 1034, I hope I get this right.  I see somebody in the audience that will probably beat me up if I don't.  It's not really clear about it but tries to mean it so it got clarified in RFC 8020 the  meaning of NX domain.  Technically NX domain should mean if you receive the reply NX domain from a server for a point  and a tree, like the one to the right, that there is nothing at that point you requested  or anywhere there under.  So what this technology basically is, is descending trees where we received a no error for the  root node.  We can actually try this.  So we have our given root here which is IPv6.arper.  We do a DNS query for 0.ipv6.arper.  We get an NX domain.  So we don't descend in that tree.  We do the same for the one, we do the same for the two, three, four, up to the E and we  always get an NX domain.  We know we don't have to descend that tree.  When we have the F, we do get a no error.  We don't get any data back but we get no error.  So we descend that tree.  Let's try.  I never managed to clear our class.  Sorry.  Anyway, we do the same thing again and this time we start with a zero and we immediately  get a no error.  So we can descend that tree already.  And do the same thing again and then we descend that tree and by doing this 32 times, so an  IPv6 address, 32 nipples, we can finally arrive at utilized IPv6 addresses.  And you see if we start with a zero, this is basically a depth first search in this huge  DNS tree that is spanned out by the reverse DNS name system.  So as I said, this is in itself not new.  You have RC7707 which actually discusses this as a possible technique for network reconnaissance  in smaller networks.  They actually reference this Peter from Dyke who recommended this technique to me.  And he actually wrote a small block article about this like three, four years ago and  provided a Python implementation which you can utilize to actually scan the network or  rather DNS, PDI prefix.  This was also the starting ground for the tooling which will be provided to you in the  end of this talk.  First, what I used to conduct these scans is, well, it's basically the compute server  we have for doing machine learning at the research group.  My colleagues were not so happy that they had to stop doing this while I did my scans.  But as I produce something called academic code which is basically like startup code  which we don't call production ready.  Everybody who loved works in a startup.  But I'm pretty sure that somebody who is actually better with code than me, so like a programmer  who can actually write production code, will also be able to run this code well, the code  they write themselves on their laptop.  So the first thing when I thought about this technique was that I do a depth first search  which is a pretty bad thing if the first part of the tree is on a really, really slow DNS  server on the other side of the world.  So you want to have the opportunity to do some kind of breadth first search to paralyze  over different DNS servers.  For this I basically just iterate in four nibble steps.  So in a first step I will iterate up to a length of four nibbles for all possible FGDN  rack, well, PD iron trees.  Then I will collect all of these and for each of these do the enumeration step for another  four nibbles.  If on flavor, on personal case, one might also opt to go from 16 nibbles to 32 directly,  so from 64 bit to 128 bit, which may have advantages, may have disadvantages, but we  will see that later when we look at the data.  So this was basically what I built directly after ITF.  I hacked this together, went to the office, ran it.  I was pretty happy because after I let it run for a week I found 70 million records.  So I then looked into the data and was wondering why I got this funny email from a large ISP  with them complaining about a lot of traffic from my machine to theirs.  And I learned about a really nice feature you want to have in your reverse zones when  you're offering reverse zones or rather networks to customers and end users, which is dynamic  reverse zones.  So I have an example here.  So when you have a big network and you don't want to manually set all those to the power  of 64 reverse entries for all the possible users you could have, you just set a script  in your DNS server that actually generates a reverse FQDN for any given reverse pointer  record.  They also may be static.  And I also found funny, dynamically generated looking domains that are probably DNS tunnels  or something like that.  At least they were always returning 32 bits of something random.  And being in this case you will never find an X domain.  So when your algorithm is just plainly stupidly going in there, it will find a lot of records,  but they all belong to, well, however big this dynamically generated reverse zone is.  So I thought about a heuristics.  And I first thought about doing something computational linguistics and stuff where  I would compare reverse returned FQDNs to figure out if they may or may not be actually  somewhat related.  Turns out it doesn't really work, doesn't really perform.  What performs for better is just trying to query a static set of records.  And if at least three of these exist, assume the domain or rather the subtree is dynamically  generated.  So at least three records is a personal preference.  The picking of filling up the tree to a length of 32 nipples with zeroes, ones, two, threes  up until F is a not so personal reference.  Some people recommended to me to do this with random data, but then you actually have to  have enough non-blocking entropy for that.  So, well, taste question, but this actually works.  So using this, I actually tried this again.  So I started at IP6.upper, let it enumerate, and then I found 1.6 million records.  And you have to say I started off with like 70 million.  I was really amazed.  And now I only have 1.6 million records.  So I was somewhat confused, which brought me to another nice finding.  So they're DNS servers that are for some reason not RFC8020 compliant.  So they may actually send NX domain instead of no error.  We have an example here.  So if the DNS server on which F.ip6.upper is resident on sends an NX domain because  it has no explicit record at that point, well, then I will not say 0.f.ip6.upper.  And to actually counter this issue, I got the idea of seeding my algorithm.  So I do not start at IP6.upper, but I started various well-known predetermined to exist,  well, sub-trees of the DNS tree for IP6.upper.  I built a somewhat funny algorithm for that.  Well, at each step, so at each nipple length, remember the slide, couple slides back.  So for four nipples, I would actually crop the seed record to a length of four nipples  and re-add the full record length again of the seed record.  So that I get at each iteration all the information possible from my seed records.  The seed sources I used were the route views project and the RIPE NCC.  How is it called?  Something with BGPV view, I always forget.  Anyway, these are publicly available and actually are documented in the script that  will be published with this talk.  Other possible sources are, of course, the algorithm that all used where they would actually  do the quad A lookups for the returned FQDNs of IPv4 reverse pointers and basically whatever  data set you can get your hands on.  So if you can, for example, if you are at a big event where a lot of people are using  remote IPv6 servers and you were actually able to read the network traffic, which I  recommend not to do, then you could also use that as a source for seeding.  So with the seed set, I actually ran the programs again.  This time it took nearly three days, running a parallel with 80 threads and I found 5.3  million records, which is sounding really small, but due to the, well, state of IPv6  and deployment practices on IPv6, this is still pretty decent.  So it doesn't show a full, full picture, but it shows a large subset.  But I was not really satisfied with the speed of this, so I tried to parallelize more because  I realized that my server was, well, not really that busy.  I tried to run those 400 threads.  It ran faster, found less.  And the lesson I had to learn was that basically the one IP address I used for resolving ran  out of sockets.  So if you want to heavily parallelize this, do it on multiple machines with more addresses  to actually use for outbound DNS queries.  Another thing that falls into this is if you are running this yourself, have a local resolver  because latency to your local resolver, for example, in this network, the resolver offered  by network operations will extremely increase the length of these scans and possibly will  overload them.  So don't run it against your speed port.  So this is basically the start of other key studies.  First look into this.  You see basically plotted here the amount of queries I needed for records in slash 64.  And we basically see a nice distribution between extremely structured zones.  So zones that have colon, colon 1, colon, colon 2, extremely structured.  And those that have nearly random addresses are possibly UI 64 addresses.  To the left are basically those where I need more queries to find less records.  And then here are the structured ones which due to the depth first nature of the algorithm  will also be found first that I was then found with less queries.  But I promised more fun parts.  You can also utilize this tool to look at something specific.  So from the huge data set you collect, you can single out specific networks.  And this, for example, is an overview of how a software as a service provider does their  network assignment policy.  So how IPv6 addresses and networks are assigned with that service provider.  Going out which service provider this is is left as an exercise to the reader.  And I was told that this is too academic and just boring.  So I looked at something else which is a little bit more fun.  So I personally do not really do a lot of stock trading.  But if you look at IPv6 networks, people suddenly have a whole lot of addresses to use.  So they will address everything.  They will address loop back addresses, public addresses.  They will address IPME with public addresses, everything.  So if you look at such a network, in this case, starting here in September with 65K  of hosts around the boat, you suddenly see a huge jump of around 10K in just a matter  of, well, two weeks.  And like two months later, you can realize that this is a provider actually announces  a record sales quarter.  So this is one of the opportunities where you could use this tooling for, actually gathering  information on company growth.  But which is probably a lot more fun is looking at topologies.  So for me, this was the most fun thing I could do with this, apart from security scans, where  we all know what they will turn up.  So first thing I did was looking at an IXP.  By the way, I'd like to mention that this all is my personal opinion and I'm not representing  affiliations and so forth.  So a rendered graphs, 3A, our hosts.  Blue R slash 64s, red R slash 48s, and green R slash 32s.  And if you zoom out a little, you can also see black ones.  Black ones are hosts that are for some reason connected to 2 slash 64s or more.  So after importing this, this actually looks more like a block cube than anything fun.  However, it's basically directed graph.  One can sort this, make it float apart a little so you can actually recognize parts of the  structure.  You can add funny labels to it.  Then you can look at what you can see.  So this is a network of a huge IXP.  This is, for example, their pop-in Hamburg.  Basically their peering network.  Of course, they also have a deep-end in Frankfurt.  Nice thing you can actually see is, or black friend over there, they can actually see the  networks the customers are having behind the router, behind the peering in Frankfurt.  They also have this famous black-holing infrastructure, which you can see, being connected to their  provisioning and some internal routing or interconnect infrastructure.  And firewall 6 appears to be their central firewall in Frankfurt.  There's a whole lot of hosts connected to it, for example, an elastic search system for  customer counting and processing flow data.  But I think nerds are somewhat more into other networks.  So this is an example of NASA.gov.  There's also somewhat bigger topologies one might want to look at.  Everybody familiar with Doc Mill?  So, little side note, I'm also doing the monitoring for network operations.  And we will now look into it at the moment, the only network.  I have the feeling that I know the topology of better than the network at this conference.  For reasons, it will remain anonymous for the purpose of this talk, but technically,  the data sets are public.  So let's have a huge journey through a network.  So like all of the networks, it has a border router and some portal systems, administration  interfaces, and possibly user access networks.  They also run like network infrastructure, for example, hosts called Big Brother, which  is actually an ancient monitoring system.  I want to give them that, which they actually had to have a lot of service for, but they  are currently migrating to Prometheus, which is a somewhat new monitoring system.  So, let's look at their infrastructure, how do they run?  So they run a lot of open source software, so we see Gentoo.  For us, probably not so who, and they also have a puppet production host.  They also have an Admiral Ackbar, which made me think that it might be a honeypot.  But what worked me most is actually this one.  On a little more serious note, what does also teach us that these networks are run by nerds?  So some more fun things due to popular demand, technical IoT.  The reductions happened due to, well, for some reason, it is not opportunity to expose  the IP fridges and military installations when you have collaborators from the United  States.  Another nice thing we found in our dataset is TCP666, the number of the back plane, 666  in this case is a place holder, because for reasons I actually talked to the company before  this talk and they were like, hmm, we kind of know about this and I was like, cool, nice,  so I can talk about it and they were like, yeah, well, with us.  So when we are scanning some of the IPv6 addresses we collected, we would find the  TCP port being open on hosts that would also expose talent as HNBGP and somewhat look like  backbone links.  Funnily enough, the TCP port, which should be on the slides, was more related to a technology  you usually don't find on a backbone router.  After some communication with a couple of friends, we figured out that technically this  port should be bound to local hosts on the systems, as it is used for some back plane  services.  Funny side note, the vendor didn't even know how the customers managed to get this exposed.  So then we have DHCPv6.  We all know the issues of devices that suddenly get IPv6 addresses and become then reachable,  my most favorites were printers.  And something you see a lot is that these devices that are then exposed and that are  really vulnerable actually do have a forward pointer for the FQDN that is returned for  the IPv6 address that points to an RFC 1918, so a private network address.  Other things you find is IPME, so out of bound management and various forms, what you basically  use when everything burns down.  One really nice, nice large operator actually has all their IPME interfaces reachable with  ICMPv6, which made me wonder what would happen, which I of course didn't do, but well, it's  something I'm wondering about because, well, you don't really want your IPME on the internet.  And also something for the people a little bit more into network infrastructure besides  our exposed back planes.  Besides our exposed back planes, you will also find a lot of RIP out there, a lot of  IPGP and talent as sage of internet infrastructure and internet backbone services.  Another fun thing to find is Docker.  One part is the nice things you can deploy with Docker, for example, Elasticsearch.  It's really amazing who runs Elasticsearch as a service without authentication, only  reachable via IPv6, but reachable with IPv6.  For Docker instances, I don't know if you do know what these TCP ports mean for Docker  installation.  This is actually an API which you have to protect.  There's information in the documentation, how you can enable authentication.  There's actually good blog posts on how you can enable authentication using certificates  and Nginx reverse proxy, but you can also just expose it to the internet.  Well.  So this is just a set of the opportunities you can have, which you shouldn't have.  So besides actually doing the right thing and doing firewalling for your IPv6 network,  you could also do something, well, security bar security.  You could try to configure the reverse DNS zones in a way that always returns no data  or no error.  Basically masking them to this.  It feels hard to say that this is an attack, but basically do this.  This was already available in 2012 when Fondac first played with this.  There's tools available, not applicable to all DNS servers out there, but the concept  should be clear, so it should be implementable.  On the other hand, we should think about techniques that probably are applicable even  though this specific technique I just presented is not available.  So let's quickly conclude.  In the end, you can try to reject packets, but you cannot hide your network topology.  You should think before setting PTR records, and you should think before connecting things  to the internet.  You can download my tool chain from the GitLab instance of my research group.  And there's an academic publication coming up in March 2017, which is also dealing with  this technique on a more measurement-related point of view.  Thank you, and I'll be happy to answer any questions that are.  Thank you very much indeed.  First question as usually goes to the second Angel.  Did you actually think about trying DNS zone transfer to see if the server would give up  a bunch of PTR records due to misconfiguration?  Using other techniques like AXFR is discussed in the research publication, but we didn't  actually try it.  Well, there's a Git link.  Next question goes to Mark for number five.  You got me lost a little bit here when you said that, and maybe correct me if I'm wrong,  you should run your own local DNS resolver to get faster.  I don't know what.  And I'm kind of wondering, did you use some kind of asynchronous IO in order to parallel  your resolutions instead of using a local resolver?  Or maybe I misunderstood what this was solving.  So running a local resolver on the machine you're doing the measurements on is basically  solving the issue of overloading the local resolver for your research institution, having  your system administrator standing in your office, being really, really angry.  All these things that happen when they suddenly have to deal with the DNS recursors that is  doing mostly the queries you're doing and not those of other people in the room or research  institutions.  So it's not improving the speed?  It actually helps a little with speed because either you do the resolving yourself or you  put it somewhere else and you basically have to wait for the answers.  So if you have a little bit of latency towards your recursor, the whole process will part  up, take longer.  If it's on your local machine, you basically reduce one small part of latency.  But again, you can probably do this better when you do the recursing and resolving from  the tool chain, which I didn't do because I'm not a good programmer.  Okay.  Thank you.  Next question goes to Mark for number one.  Okay.  So did you actually consider that there might be a few servers hidden in those subnets who  have these generated PTR records?  Yes, there may be servers hidden in there, but due to the dynamically generated PTR records,  I cannot verify this without exhaustively enumerating the whole tree, which just gets  really, really large.  Okay.  So you just, there's like the...  I don't know and I cannot know.  All right.  Thank you.  Okay.  Next question goes to Mark for number two.  Hi.  From experience, I found that IPv6 reverse lookups are more sparse than the IPv4 versions.  So do you have a reference on how many hosts you find with that technique versus hosts  that are there without reverse lookup?  I would really love to have that.  I also...so basically if you want to make the statement you just basically asked for,  you would have to compare this dataset with another independent dataset which looks at  another angle of IPv6.  For example, large IXP, for example, CDN dataset.  Well, CDN dataset will be biased for clients and servers.  So most probably the IXP dataset.  At the moment, I didn't have availability of those, so I didn't investigate that.  Okay.  Microphone number six.  You mentioned that results or the dataset of your work are public.  So where is the dataset?  Well, it's actually stored in a distributed manner on a lot of DNS servers.  As you know it from all cool platforms, there's a dedicated download client you have to utilize.  Download client source code is available at that GitLab location.  Okay, microphone number five.  Hello.  So quick question.  Most of the data on the slides were sort of western and the dot mail exploration and  so on.  So just as a general question, did you explore the IPv6...  Oh, sorry.  Did you explore a lot of this on the Asian networks of say Korea, China which has massive  IPv6 use?  Because of the latency thing, you know.  Actually I didn't really focus on a specific per-continent analysis.  I mostly presented so far in the academic work, the technique in itself and I picked  interesting case studies that would demonstrate the potential of the technique.  But what you suggest is actually an interesting point for further work.  I would, for anyone interested in that, I would recommend Hong Kong as to the starting  point to do the scans.  Cheers.  Okay.  Any more questions?  Okay.  Thank you very much.  Thank you.  Bye.
33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_0_767.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_768_959.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_960_1079.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_1080_1139.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_1140_1187.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_1188_3671.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_3672_5423.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_5424_10451.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_10452_16895.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_16896_17279.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_17280_17471.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_17472_19127.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_19128_29699.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_29700_29855.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_29856_31415.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_31416_33887.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_33888_35051.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_35052_36287.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_36288_40103.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_40104_43859.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_43860_44111.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44112_44171.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44172_44291.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44292_44435.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44436_44663.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44664_44759.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_44760_45083.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_45084_45383.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_45384_46427.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_46428_47819.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_47820_47963.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_47964_48131.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_48132_48251.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_48252_48395.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_48396_48695.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_48696_49091.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_49092_49619.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_49620_49727.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_49728_50099.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_50100_50147.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_50148_60947.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_60948_63239.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_63240_63959.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_63960_64355.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_64356_66491.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_66492_66695.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_66696_67499.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_67500_67595.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_67596_67847.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_67848_67895.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_67896_68147.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_68148_68723.png 33c3-8061-you_can_-j_reject_but_you_can_not_hide_global_scanning_of_the_ipv6_internet_68724_69476.png
Please give a warm-up now to Tobias Fiebig, who will be talking about IPv6 global scanning. Thank you. So, good evening, everybody. Nice that you still made it, even though it's 11 p.m. Of course, this is not work of me alone. It is joint work with colleagues from UC Santa Barbara, Kevin Bogolto, Shuan Hao, Chris of Krugel and Giovanni Wigner. First thing about me. I have a Bachelor of Science in cognitive science and somewhat noticed that wetware is not really my life. So I actually went on to get a Master's in Network Engineering and since I got that, I'm more or less desperately trying to get a PhD from Professor Feldman and Professor Seifert at TU Berlin. My research interests can be summarized as basically what nobody else does, but not because my stuff is ingenious, but because most people say, well, that's stupid, that won't work anyway. I think we all know this as misconfiguration. You all know these nice people that are running database servers on the Internet without authentication. I have heard of a big ISP that actually managed to run their provisioning system on the Internet, which was not that good for connectivity for their customers. There's also other nice examples, so Mitfarge-Legenheiden.de was actually pretty good in doing backups. They even encrypted them and stored the ASK with it. And there's always a fun of finding an ISCAR device that belongs to some bulletproof host read-write on the Internet, and something I had to learn there is something called remote DMA. What could be better than doing DMA over the Internet? So basically whatever I will tell you today is directed at finding these. But first things first, ethics. I may tell you about a nice tool to have a lot of fun with, but basically... What are you, stones are stupid. You don't hack a bank across state lines from your house. You get nailed by the FBI. Where are your brains in your ass? Follow this good advice. Think about this event, think about the amount of bandwidth you have, think about the amount of bandwidth. Other people have, think about them having this nice time between the holidays at the end of the year where they don't want to work, which might happen if suddenly DNS service start crashing and other services become unreliable. So back to my motivation and some view of related work. The first part will be a little bit dry. So if you start to get bored, there's a special slide where I ask the person next to you to wake you up just right before the fun stuff starts. So please don't run away. So in the beginning, there was ZMAP that was like three years ago. And it starts this whole thing about we can scan the whole IPv4 Internet. We can do like Internet-wide security evaluations. And that was actually a whole, whole lot of fun. So I think two years ago there was this nice service in one of the lecture halls at this event where you would have something like chat relete. Only was VNC service. Yes, you love, but it actually brings us to the second point. It stops being funny when you find some asset construction facility in India on one of these slides. ZMAP was heavily used to scan for hot lead and analysis and how hot lead was mitigated. ZMAP was used to scan for, well, at least open TCP ports where you could then do a key exchange to see how it's key sharing between HTTPS servers in the world. There was research on amplification attack servers. Well, basically the amplifiers for the amplification attacks. And this ability to exhaustively scan actually helps the security community a lot. But as with all good things, or rather not so good things in this case, IPv4 is coming to an end. There's only also many addresses, two to the power of 32, in fact, theoretically. And there's a lot of work investigating how this is getting more and more exhausted and by now getting an IPv4 address is actually pretty hard. So what happened is that people introduced IPv6 like 20 years ago, around about, I think, even more. With IPv6, there comes a lot more addresses, like two to the power of 128, theoretically. And we can actually see that IPv6 is starting to get adapted. So the graph I have here is actually a bandwidth graph from this event. And we see that at peak points, we saw around 25% of outbound IPv6 traffic. This is a little bit skewed because as soon as you deploy IPv6 to your user network, you will suddenly see a lot of traffic to two or three big players like Google with YouTube and Facebook. And it still demonstrates that IPv6 is a thing that's coming. However, if we start to use, for example, that map on IPv6, we will suddenly have to wait. I cannot really pronounce that number, but it's really, really huge. And I don't really intend on living that long. So let's come to related work. So looking at IPv4 addresses was an interesting tool. It was not only used in the security community, but especially there and helped a lot there. So people want to have the same thing for IPv6. Current work is relatively focused on starting or trying to observe IPv6 address usage in the wild. Not doing active scans, but having some vantage point where they sit, where they can read something which provides them information about used IPv6 addresses. So for Romsky, Plonka and Berger, they are using the access logs of a large CDN. Of course, as good scientists, they don't disclose which CDN this is, but one of them has an ekemy mailing address. Six at all who are mostly the vantage point freest of them all. They are using various DNS data sources, but not the same as I will present in this talk. And then there's Grasse at all. They do have for some reason access to a large European IXP and can look on flow data there and thereby can get information about utilized IPv6 addresses in the wild. So let's quickly go over these. So for Romsky, Plonka and Berger actually provided the nice work where they used their data sources to train a tool which could then predict another active, that means replying to ICMP, IPv6 address based on the data sets they had previously. They are mostly using the CDN data. They have a small, really, really tiny portion of data that was gathered as the data I will present on, and they utilize TraceRoute data. This has certain drawbacks. For example, the CDN logs, of course, do not really represent a lot of, well, servers, especially not servers in the wild internet out there. TraceRoute data is by nature really, really, really biased towards networking devices because, well, it's TraceRoute data. The work by Grassett all in principle is somewhat similar. So they also try to predict active IPv6 addresses based on the data sets they have. So then we have Suss et al. Suss et al. are actually doing various mining on DNS data sets. So they have recursor data sets. So they actually get logs from DNS recursors. But they are also doing something really fun where they would actually do a PTR lookup for every address in the IPv4 space. And then do a quad A lookup to get the IPv6 address for that FQDN. And their work is actually one of the big motivations for what I'll be presenting today because they figured out that IPv6 security is not really doing that well. In other words, it's doing terribly. But well. So in summary, I looked in my basement. I didn't find a CDN. I looked it off further and I didn't find an IXP. And when I asked my IXP if they wanted to let me read their recursor's access logs, they also said something, including no. But on the other hand, if I was a politician, I would now be like, but we have this IoT, this Internet of Things. We really need the scanning to protect all the people. So well. We came up with methodology. By the way, this is the point where you want to wake up people next to you that didn't really care about related work. So first things first. So there's another person I'd like to credit. It's Peter van Dijk. I'm not really sure if I can do the IJ thing correctly because I'm not Dutch. But I hope I tried. Anyway, I met him at last ITF in Berlin. And as I heard, he's Dutch. I believed him when he started to talk about DNS. And he said, if I want to get a lot of IPv6 addresses that are assigned to servers, not clients, I should actually look at, well, IPv6 reverse DNS. He said he had some interesting preview result thingies. And I should start to dig into that. So well, as I said, Dutch people know about DNS. Like most of the DNS servers we're currently using come from the Netherlands. Let's try it. So let's start with a short recap. So IPv6 address, as I said, 128 bits. And you can represent it in 32 so-called nibbles. Those are the little things representing hexadecimal characters we see here. And reverse DNS is a way to get for an IP address you have, an FQD and a fully qualified domain name. You do this by doing some transformation to the IPv6 address. So you first reverse it. And then you put basically points between each of the nibbles for different levels in the PTR tree. And as top level domain and second level domain, you have IPv6.arper. And under that tree, you then find a record. And that record you can do a PTR request to and then you get an FQDN from the DNS server. So the next thing that is somewhat important at this point is how DNS works. So RFC 1034, I hope I get this right. I see somebody in the audience that will probably beat me up if I don't. It's not really clear about it but tries to mean it so it got clarified in RFC 8020 the meaning of NX domain. Technically NX domain should mean if you receive the reply NX domain from a server for a point and a tree, like the one to the right, that there is nothing at that point you requested or anywhere there under. So what this technology basically is, is descending trees where we received a no error for the root node. We can actually try this. So we have our given root here which is IPv6.arper. We do a DNS query for 0.ipv6.arper. We get an NX domain. So we don't descend in that tree. We do the same for the one, we do the same for the two, three, four, up to the E and we always get an NX domain. We know we don't have to descend that tree. When we have the F, we do get a no error. We don't get any data back but we get no error. So we descend that tree. Let's try. I never managed to clear our class. Sorry. Anyway, we do the same thing again and this time we start with a zero and we immediately get a no error. So we can descend that tree already. And do the same thing again and then we descend that tree and by doing this 32 times, so an IPv6 address, 32 nipples, we can finally arrive at utilized IPv6 addresses. And you see if we start with a zero, this is basically a depth first search in this huge DNS tree that is spanned out by the reverse DNS name system. So as I said, this is in itself not new. You have RC7707 which actually discusses this as a possible technique for network reconnaissance in smaller networks. They actually reference this Peter from Dyke who recommended this technique to me. And he actually wrote a small block article about this like three, four years ago and provided a Python implementation which you can utilize to actually scan the network or rather DNS, PDI prefix. This was also the starting ground for the tooling which will be provided to you in the end of this talk. First, what I used to conduct these scans is, well, it's basically the compute server we have for doing machine learning at the research group. My colleagues were not so happy that they had to stop doing this while I did my scans. But as I produce something called academic code which is basically like startup code which we don't call production ready. Everybody who loved works in a startup. But I'm pretty sure that somebody who is actually better with code than me, so like a programmer who can actually write production code, will also be able to run this code well, the code they write themselves on their laptop. So the first thing when I thought about this technique was that I do a depth first search which is a pretty bad thing if the first part of the tree is on a really, really slow DNS server on the other side of the world. So you want to have the opportunity to do some kind of breadth first search to paralyze over different DNS servers. For this I basically just iterate in four nibble steps. So in a first step I will iterate up to a length of four nibbles for all possible FGDN rack, well, PD iron trees. Then I will collect all of these and for each of these do the enumeration step for another four nibbles. If on flavor, on personal case, one might also opt to go from 16 nibbles to 32 directly, so from 64 bit to 128 bit, which may have advantages, may have disadvantages, but we will see that later when we look at the data. So this was basically what I built directly after ITF. I hacked this together, went to the office, ran it. I was pretty happy because after I let it run for a week I found 70 million records. So I then looked into the data and was wondering why I got this funny email from a large ISP with them complaining about a lot of traffic from my machine to theirs. And I learned about a really nice feature you want to have in your reverse zones when you're offering reverse zones or rather networks to customers and end users, which is dynamic reverse zones. So I have an example here. So when you have a big network and you don't want to manually set all those to the power of 64 reverse entries for all the possible users you could have, you just set a script in your DNS server that actually generates a reverse FQDN for any given reverse pointer record. They also may be static. And I also found funny, dynamically generated looking domains that are probably DNS tunnels or something like that. At least they were always returning 32 bits of something random. And being in this case you will never find an X domain. So when your algorithm is just plainly stupidly going in there, it will find a lot of records, but they all belong to, well, however big this dynamically generated reverse zone is. So I thought about a heuristics. And I first thought about doing something computational linguistics and stuff where I would compare reverse returned FQDNs to figure out if they may or may not be actually somewhat related. Turns out it doesn't really work, doesn't really perform. What performs for better is just trying to query a static set of records. And if at least three of these exist, assume the domain or rather the subtree is dynamically generated. So at least three records is a personal preference. The picking of filling up the tree to a length of 32 nipples with zeroes, ones, two, threes up until F is a not so personal reference. Some people recommended to me to do this with random data, but then you actually have to have enough non-blocking entropy for that. So, well, taste question, but this actually works. So using this, I actually tried this again. So I started at IP6.upper, let it enumerate, and then I found 1.6 million records. And you have to say I started off with like 70 million. I was really amazed. And now I only have 1.6 million records. So I was somewhat confused, which brought me to another nice finding. So they're DNS servers that are for some reason not RFC8020 compliant. So they may actually send NX domain instead of no error. We have an example here. So if the DNS server on which F.ip6.upper is resident on sends an NX domain because it has no explicit record at that point, well, then I will not say 0.f.ip6.upper. And to actually counter this issue, I got the idea of seeding my algorithm. So I do not start at IP6.upper, but I started various well-known predetermined to exist, well, sub-trees of the DNS tree for IP6.upper. I built a somewhat funny algorithm for that. Well, at each step, so at each nipple length, remember the slide, couple slides back. So for four nipples, I would actually crop the seed record to a length of four nipples and re-add the full record length again of the seed record. So that I get at each iteration all the information possible from my seed records. The seed sources I used were the route views project and the RIPE NCC. How is it called? Something with BGPV view, I always forget. Anyway, these are publicly available and actually are documented in the script that will be published with this talk. Other possible sources are, of course, the algorithm that all used where they would actually do the quad A lookups for the returned FQDNs of IPv4 reverse pointers and basically whatever data set you can get your hands on. So if you can, for example, if you are at a big event where a lot of people are using remote IPv6 servers and you were actually able to read the network traffic, which I recommend not to do, then you could also use that as a source for seeding. So with the seed set, I actually ran the programs again. This time it took nearly three days, running a parallel with 80 threads and I found 5.3 million records, which is sounding really small, but due to the, well, state of IPv6 and deployment practices on IPv6, this is still pretty decent. So it doesn't show a full, full picture, but it shows a large subset. But I was not really satisfied with the speed of this, so I tried to parallelize more because I realized that my server was, well, not really that busy. I tried to run those 400 threads. It ran faster, found less. And the lesson I had to learn was that basically the one IP address I used for resolving ran out of sockets. So if you want to heavily parallelize this, do it on multiple machines with more addresses to actually use for outbound DNS queries. Another thing that falls into this is if you are running this yourself, have a local resolver because latency to your local resolver, for example, in this network, the resolver offered by network operations will extremely increase the length of these scans and possibly will overload them. So don't run it against your speed port. So this is basically the start of other key studies. First look into this. You see basically plotted here the amount of queries I needed for records in slash 64. And we basically see a nice distribution between extremely structured zones. So zones that have colon, colon 1, colon, colon 2, extremely structured. And those that have nearly random addresses are possibly UI 64 addresses. To the left are basically those where I need more queries to find less records. And then here are the structured ones which due to the depth first nature of the algorithm will also be found first that I was then found with less queries. But I promised more fun parts. You can also utilize this tool to look at something specific. So from the huge data set you collect, you can single out specific networks. And this, for example, is an overview of how a software as a service provider does their network assignment policy. So how IPv6 addresses and networks are assigned with that service provider. Going out which service provider this is is left as an exercise to the reader. And I was told that this is too academic and just boring. So I looked at something else which is a little bit more fun. So I personally do not really do a lot of stock trading. But if you look at IPv6 networks, people suddenly have a whole lot of addresses to use. So they will address everything. They will address loop back addresses, public addresses. They will address IPME with public addresses, everything. So if you look at such a network, in this case, starting here in September with 65K of hosts around the boat, you suddenly see a huge jump of around 10K in just a matter of, well, two weeks. And like two months later, you can realize that this is a provider actually announces a record sales quarter. So this is one of the opportunities where you could use this tooling for, actually gathering information on company growth. But which is probably a lot more fun is looking at topologies. So for me, this was the most fun thing I could do with this, apart from security scans, where we all know what they will turn up. So first thing I did was looking at an IXP. By the way, I'd like to mention that this all is my personal opinion and I'm not representing affiliations and so forth. So a rendered graphs, 3A, our hosts. Blue R slash 64s, red R slash 48s, and green R slash 32s. And if you zoom out a little, you can also see black ones. Black ones are hosts that are for some reason connected to 2 slash 64s or more. So after importing this, this actually looks more like a block cube than anything fun. However, it's basically directed graph. One can sort this, make it float apart a little so you can actually recognize parts of the structure. You can add funny labels to it. Then you can look at what you can see. So this is a network of a huge IXP. This is, for example, their pop-in Hamburg. Basically their peering network. Of course, they also have a deep-end in Frankfurt. Nice thing you can actually see is, or black friend over there, they can actually see the networks the customers are having behind the router, behind the peering in Frankfurt. They also have this famous black-holing infrastructure, which you can see, being connected to their provisioning and some internal routing or interconnect infrastructure. And firewall 6 appears to be their central firewall in Frankfurt. There's a whole lot of hosts connected to it, for example, an elastic search system for customer counting and processing flow data. But I think nerds are somewhat more into other networks. So this is an example of NASA.gov. There's also somewhat bigger topologies one might want to look at. Everybody familiar with Doc Mill? So, little side note, I'm also doing the monitoring for network operations. And we will now look into it at the moment, the only network. I have the feeling that I know the topology of better than the network at this conference. For reasons, it will remain anonymous for the purpose of this talk, but technically, the data sets are public. So let's have a huge journey through a network. So like all of the networks, it has a border router and some portal systems, administration interfaces, and possibly user access networks. They also run like network infrastructure, for example, hosts called Big Brother, which is actually an ancient monitoring system. I want to give them that, which they actually had to have a lot of service for, but they are currently migrating to Prometheus, which is a somewhat new monitoring system. So, let's look at their infrastructure, how do they run? So they run a lot of open source software, so we see Gentoo. For us, probably not so who, and they also have a puppet production host. They also have an Admiral Ackbar, which made me think that it might be a honeypot. But what worked me most is actually this one. On a little more serious note, what does also teach us that these networks are run by nerds? So some more fun things due to popular demand, technical IoT. The reductions happened due to, well, for some reason, it is not opportunity to expose the IP fridges and military installations when you have collaborators from the United States. Another nice thing we found in our dataset is TCP666, the number of the back plane, 666 in this case is a place holder, because for reasons I actually talked to the company before this talk and they were like, hmm, we kind of know about this and I was like, cool, nice, so I can talk about it and they were like, yeah, well, with us. So when we are scanning some of the IPv6 addresses we collected, we would find the TCP port being open on hosts that would also expose talent as HNBGP and somewhat look like backbone links. Funnily enough, the TCP port, which should be on the slides, was more related to a technology you usually don't find on a backbone router. After some communication with a couple of friends, we figured out that technically this port should be bound to local hosts on the systems, as it is used for some back plane services. Funny side note, the vendor didn't even know how the customers managed to get this exposed. So then we have DHCPv6. We all know the issues of devices that suddenly get IPv6 addresses and become then reachable, my most favorites were printers. And something you see a lot is that these devices that are then exposed and that are really vulnerable actually do have a forward pointer for the FQDN that is returned for the IPv6 address that points to an RFC 1918, so a private network address. Other things you find is IPME, so out of bound management and various forms, what you basically use when everything burns down. One really nice, nice large operator actually has all their IPME interfaces reachable with ICMPv6, which made me wonder what would happen, which I of course didn't do, but well, it's something I'm wondering about because, well, you don't really want your IPME on the internet. And also something for the people a little bit more into network infrastructure besides our exposed back planes. Besides our exposed back planes, you will also find a lot of RIP out there, a lot of IPGP and talent as sage of internet infrastructure and internet backbone services. Another fun thing to find is Docker. One part is the nice things you can deploy with Docker, for example, Elasticsearch. It's really amazing who runs Elasticsearch as a service without authentication, only reachable via IPv6, but reachable with IPv6. For Docker instances, I don't know if you do know what these TCP ports mean for Docker installation. This is actually an API which you have to protect. There's information in the documentation, how you can enable authentication. There's actually good blog posts on how you can enable authentication using certificates and Nginx reverse proxy, but you can also just expose it to the internet. Well. So this is just a set of the opportunities you can have, which you shouldn't have. So besides actually doing the right thing and doing firewalling for your IPv6 network, you could also do something, well, security bar security. You could try to configure the reverse DNS zones in a way that always returns no data or no error. Basically masking them to this. It feels hard to say that this is an attack, but basically do this. This was already available in 2012 when Fondac first played with this. There's tools available, not applicable to all DNS servers out there, but the concept should be clear, so it should be implementable. On the other hand, we should think about techniques that probably are applicable even though this specific technique I just presented is not available. So let's quickly conclude. In the end, you can try to reject packets, but you cannot hide your network topology. You should think before setting PTR records, and you should think before connecting things to the internet. You can download my tool chain from the GitLab instance of my research group. And there's an academic publication coming up in March 2017, which is also dealing with this technique on a more measurement-related point of view. Thank you, and I'll be happy to answer any questions that are. Thank you very much indeed. First question as usually goes to the second Angel. Did you actually think about trying DNS zone transfer to see if the server would give up a bunch of PTR records due to misconfiguration? Using other techniques like AXFR is discussed in the research publication, but we didn't actually try it. Well, there's a Git link. Next question goes to Mark for number five. You got me lost a little bit here when you said that, and maybe correct me if I'm wrong, you should run your own local DNS resolver to get faster. I don't know what. And I'm kind of wondering, did you use some kind of asynchronous IO in order to parallel your resolutions instead of using a local resolver? Or maybe I misunderstood what this was solving. So running a local resolver on the machine you're doing the measurements on is basically solving the issue of overloading the local resolver for your research institution, having your system administrator standing in your office, being really, really angry. All these things that happen when they suddenly have to deal with the DNS recursors that is doing mostly the queries you're doing and not those of other people in the room or research institutions. So it's not improving the speed? It actually helps a little with speed because either you do the resolving yourself or you put it somewhere else and you basically have to wait for the answers. So if you have a little bit of latency towards your recursor, the whole process will part up, take longer. If it's on your local machine, you basically reduce one small part of latency. But again, you can probably do this better when you do the recursing and resolving from the tool chain, which I didn't do because I'm not a good programmer. Okay. Thank you. Next question goes to Mark for number one. Okay. So did you actually consider that there might be a few servers hidden in those subnets who have these generated PTR records? Yes, there may be servers hidden in there, but due to the dynamically generated PTR records, I cannot verify this without exhaustively enumerating the whole tree, which just gets really, really large. Okay. So you just, there's like the... I don't know and I cannot know. All right. Thank you. Okay. Next question goes to Mark for number two. Hi. From experience, I found that IPv6 reverse lookups are more sparse than the IPv4 versions. So do you have a reference on how many hosts you find with that technique versus hosts that are there without reverse lookup? I would really love to have that. I also...so basically if you want to make the statement you just basically asked for, you would have to compare this dataset with another independent dataset which looks at another angle of IPv6. For example, large IXP, for example, CDN dataset. Well, CDN dataset will be biased for clients and servers. So most probably the IXP dataset. At the moment, I didn't have availability of those, so I didn't investigate that. Okay. Microphone number six. You mentioned that results or the dataset of your work are public. So where is the dataset? Well, it's actually stored in a distributed manner on a lot of DNS servers. As you know it from all cool platforms, there's a dedicated download client you have to utilize. Download client source code is available at that GitLab location. Okay, microphone number five. Hello. So quick question. Most of the data on the slides were sort of western and the dot mail exploration and so on. So just as a general question, did you explore the IPv6... Oh, sorry. Did you explore a lot of this on the Asian networks of say Korea, China which has massive IPv6 use? Because of the latency thing, you know. Actually I didn't really focus on a specific per-continent analysis. I mostly presented so far in the academic work, the technique in itself and I picked interesting case studies that would demonstrate the potential of the technique. But what you suggest is actually an interesting point for further work. I would, for anyone interested in that, I would recommend Hong Kong as to the starting point to do the scans. Cheers. Okay. Any more questions? Okay. Thank you very much. Thank you. Bye.
view of related work. The first part will be a we can scan the whole IPv4 Internet. We can do based on the data sets they have. So then we have IPv6 security is not really doing that well. In provided to you in the end of this talk. First, what I used to conduct these scans is, well, it's code, will also be able to run this code well, state of IPv6 and deployment practices on IPv6, somewhat more into other networks. So this is an look at their infrastructure, how do they run? So are run by nerds? So some more fun things due to should think about techniques that probably are