Tag Archives: ipv6

ThreatSTOP announces first IPv6 feed

We are making available our first IP v6 feed – the v6 full bogons – as a technology demonstration. It uses the exact same DNS distribution method as our standard IP v4 lists and thus demonstrates clearly that our mechanism is IP v6 compliant.

The feed is available to our subscribers via DNS as follows:

dig @ bogonsv6.threatstop.local ptr +tcp

and then a subsequent apl lookup of all the entries returned by that i.e.

dig @ 001-netb.bogonsv6.threatstop.local apl +tcp
dig @ 002-netb.bogonsv6.threatstop.local apl +tcp
dig @ 060-netb.bogonsv6.threatstop.local apl +tcp

The feed is extremely large (over 53000 networks broken down into 60 groups of 900). It has been made available the same way that our basic feed is – that is any registered IP address can retrieve it.

In the near future we will also add the IP v6 versions of our current IP v4 feeds in IPv4-mapped IPv6 address format as defined in RFC 2373 (i.e. ::FFFF:ip.add.re.ss )

ThreatSTOP and IPv6

Since the Internet is nearly out of IPv4 addresses, people are finally getting serious about using IPv6. As people start deploying IPv6 we will find new bugs and loopholes that crooks can exploit. Holes like this one that mean that a bot on a network could act as the “man in the middle” for everyone else nearby.

The good news is that, assuming the bot uses the existing IPv4 infrastructure to contact its controllers, an IP reputation service such as ours will block it just as it will block any IPv4 “call home”.

But this is probably the limit for most current IP reputation services and is why there have been various claims that IPv6 kills IP reputation. Fortunately ThreatSTOP was designed to handle IPv6 so we are unaffected (indeed anyone who would like to be an IPv6 beta tester is welcome to contact us).

Let me illustrate two additional cases where ThreatSTOP’s patent pending mechanisms function in a mixed world. In the case where the enterprise as whole has moved to IPv6 and it is its upstream provider that does the IPv4-IPv6 mapping ThreatSTOP can still work as we can serve up our IPv4 blocklists in IPv6 formats quite easily. So long as we are told of the IPv4-IPv6 mapping used we can simply provide an IPv6 DNS response with the appropriate maps (similar to the way that the MITM attack linked to above works).

Secondly, as more and more of the Internet runs IPv6, we will start to see native IPv6 malware hosts. The reason why people say that IPv6 kills IP reputation is twofold, first, that endpoints are 128 bits long, and that is an unmanageable number to blacklist individually, and second that users get assigned address spaces that are larger than the entire current Internet. If you use IP reputation the way it’s done by DNSbls and others, this does, indeed, mean that the method is unlikely to work, because the number of potential /128 addresses an attacker can use is sufficiently large that they will always be able to find one that isn’t listed. However, due to the way V6 addresses are assigned, a single end-user is unlikely to have a full /128 address. More likely they will have a /64 (or perhaps a /56). Any of the unmasked addresses can change without effect on the IP route, and so, all you need to filter on is the network, instead of the host, address. The problem for current IP reputation services is that they have no concept of netmask in their query or response mechanism.

If an IP reputation service just did a straightforward change from IPv4 (A record) address to IPv6 (AAAA record) then they won’t provide useful blocking information. However ThreatSTOP is able to transmit both the address and mask – it is the same way that we do geo-blocking (blocking say the PRC or Ukraine) – so our subscribers are able to block all IPv6 addresses assigned to a particular host with a single record.

ThreatSTOP is looking forward to IPv6 – we see it as an opportunity, not a challenge – and we built our service to be ready for it from day 1.

IPv6 and IP reputation

The Register has an article today about how IPv6 will make (spam) blocklists fail. The article is correct that current DNSBL techniques – as developed by Paul Vixie & co – will struggle but that doesn’t in fact mean that IPv6 kills IP (or DNS) reputation, all it means is that the exact technique used by the current DNSBL solutions is not IPv6 compatible.

There are at least two ways forward. One way – the ThreatSTOP way – has the ability to distribute not just ip addresses but also entire subnets. We do this already on IPv4, where we currently distribute the network blocks from places like DShield and Spamhaus to our subscribers, and as of a few minutes ago, were distributing 1342 subnets equating to 17377 /24 networks with the largest single block being a /15 ( which is AS43659 in Ukraine FWIW).

The only thing that changes with IPv6 is that the addresses of the networks are longer (/64s being the anticipated network for an individual subscriber whereas today most subscriber net blocks are more often /24 or smaller), but current devices that are IPv6 capable (which is pretty much everything modulo buggy code versions) can do these matches now so the problem Stuart Paton talks about in the Register:

“As an example, the address space is so large that it would be easy for spammers to use a single IP address just once to send a single email”

is irrelevant.