The Cambridge Cloud Cybercrime Centre formally started work this week … but rather than writing about that I thought I’d document some publicly visible artefacts of improper behaviour (much of which, my experience tells me, is very likely to do with the sending of email spam).

RIPE is one of the five Regional Internet Registries (RIRs) and they have the responsibility of making allocations of IP address space to entities in Europe and the Middle East (ARIN deals with North America, APNIC with Asia and Australasia, LACNIC with Latin America and the Caribbean and AfriNIC with Africa).

Their public “WHOIS” databases documents these allocations and there are web interfaces to access them (for RIPE use https://apps.db.ripe.net/search/query.html).

The RIPE Database also holds a number of other sets of data including a set of “routes”. Unfortunately some of those routes are prima facie evidence of people behaving badly.

The route objects in the RIPE Database are placed there by RIPE Database users and they say that a particular Autonomous System (AS) may well make a BGP (Border Gateway Protocol) announcement of a particular prefix. Translating the jargon: that an ISP or hosting company has been allocated some IP address space and they have an expectation that their Internet router will be using BGP to spread the word that data packets for machines on these IP addresses should be sent to them.

You don’t need to put route objects into the RIPE Database. However, in the absence of any real security for routing announcements, many companies use the RIPE information to automatically construct filters so that valid (i.e. in the database) route announcements are permitted and other announcements are blocked. So if you want your routing announcement to be effective and for you to be able to contact any other part of the Internet from your IP addresses, a route object is generally a good idea.

There are lots of techniques for spamming “at scale”. One of them is to acquire a brand-new block of IP address space and then send email in bulk from each IP address in turn. Since the IP addresses have no previous “reputation” many recipients of the email will give these new senders the benefit of the doubt and accept email from them for some time. When the truth becomes apparent they will blacklist one of the IPs, but they will still accept email from the other IPs until they finally realise the whole block is “bad”.

Since the world has pretty much run out of IPv4 addresses, it isn’t as easy as it used to be to acquire pristine new blocks of address space. As a result, some organisations have taken to misbehaving and using blocks of address space without permission. They identify an unallocated block and just use it! No-one stops them (at least not especially quickly) because there’s no gatekeepers in the routing system — anyone with a router can announce anything they like.

However, if you use a block of unallocated address space you need your announcements to be propagated onward — and that’s where the route objects come in…

I recently came across AS204224 (CJSC Mashzavod-Marketing-Servis, Saint Petersburg, Russia) who had placed six route objects (four /19s and two /21s … that’s 36,000 individual IP addresses) into the RIPE database for unallocated IP address space. I reported this (of course) to RIPE who told me that they would mount an investigation and then at the start of the week they told me the routes had been removed. They were removed briefly yesterday (1 October) and they were promptly put back again by AS204224 !

Anyway — I’ve run a scan of ALL of the routes in the RIPE Database which are for unallocated address space and found 227 examples. Some of them are clearly a failure to clean things up in the dim and distant past, for example 216.98.217.0/24 is a block which was returned to ARIN and in 2012 ARIN returned it to IANA. I assume that the previous user of this address space “Heller Ehrman” is the international law firm Heller Ehrman LLP which was dissolved in 2008. There’s a number of similar examples.

However, many of the route objects appear to come from companies who have added the route objects in the past few months, for example AS201432 (RapidVDS of Vitry on Seine, France) has a dozen route objects, mainly /24s but also a route object for 151.158.0.0/16 (an unallocated block of 65536 IPs) which they added in May 2015. Also AS204225 (OJSC Kommunenergo, Kirov, Russia) has 33 route objects of which 29 /22 routes (just under 30,000 IPs) are for unallocated space. These all date from September 2015.

I have published the full list of the anomalies at https://cambridgecybercrime.uk/20151002-ripedatabase.txt since I am sure that RIPE will wish to delete any and all of these bogus entries. It’s clear to me (from the rapidity of AS204224 replacing their deleted entries) that some proper hygiene here, in this rather abstruse area of documenting usage of IP address space, is likely to make some difference. It may even (slightly) reduce the amount of spam that we all receive.