If you are seeing one of your services being abused and you want to report it, then the first thing you’re going to need to know is where to report it based on where the abuse is coming from.

This all starts with the IP address that is the source of the abuse. That IP address will be part of a larger network of IP addresses, managed and routed as part of an “Autonomous System” (ASN). The IP networks themselves would have been allocated by a Regional Internet Registry (RIR) and as part of that registration, the address of the owner and a number of contact points are usually required, and these must be kept up-to-date.

Unfortunately, the RIRs all have different policies as to what data is collected and what is required. But, nearly all of these registries require an abuse contact, which is an email address that is dedicated to receiving reports about abuse originating from that network.

This data, collected by the RIRs is then served up to the internet using WHOIS, or its replacement RDAP. These allow you to query the RIRs data in multiple ways, including the address that you need to use to report abuse to.

I could write a volume about RIRs, WHOIS, RDAP and the respective failings and issues with each. Let’s just say that if you want to report abuse in bulk, then you’ll need a fast and automatable way to take an IP address and turn that into the necessary email address(es) and WHOIS/RDAP definitely are not suitable for that.

This is where we come in. Since very early in the life of Abusix, we’ve provided a free service called the Abuse ContactDB; this uses a DNS TXT lookup to allow anyone to take an IP address and turn it into email addresses to where abuse reports should be sent. This service is capable of extremely high throughput and far exceeds the performance of WHOIS or RDAP, but most importantly, there are no rate limits and you can use the service for automated lookups (which are expressly prohibited by WHOIS/RDAP).

Great, so problem solved then? Not quite.

 

Problems

Being able to report abuse to a network is critical to the functioning of the internet and having no ability to report abuse coming from a network is a good indicator that:

• The network is either poorly managed OR it does not care about abuse.
• There is no functioning abuse desk for the network.
• Any abuse coming from that network is not going to stop.
• It will likely become a bigger source of issues when threat actors realise they can operate with impunity inside that network.

The crux of the issue is that no one polices abuse reporting all, it’s mainly a gentleman’s agreement and those networks with huge abuse issues just end up with their IPs being blocked from services and the resultant unhappy customers forcing them to address their issues.

To my knowledge, no RIR has ever taken an entire network back from an owner due to unhandled abuse issues from that network, because the legal framework for doing so is extremely difficult.

It has been a common understanding that RIRs and their communities are acting as the “Internet Police”. This common understanding is being questioned right now as John Curran, President and CEO of ARIN states in this Keynote.

There is no minimum service level for abuse reports that you send to a network and the policies and quality of one abuse desk to another varies greatly.

So, what are we doing about it?

 

Validation and Statistics

Some time ago, we started writing a service to check all of the abuse contacts that we have in the Abuse ContactDB service that we provide (this data is built from the data that is exported daily by each RIR):

This highlights the first problem; AFRINIC (African regional registry) does not mandate that a network must have an abuse contact – so as you can see, most do not provide this.

What is slightly less visible here is that APNIC (Asia-Pacific regional registry) allows delegation to National Internet Registries (NIRs) and getting the same abuse contact data from these NIRs has proven impossible so far, so for some entire countries, we can only return the abuse contact provided by the delegation record and rely on them to forward the report to the correct place.

LACNIC also allows NIRs, but this is limited to NIC Mexico and NIC.br (Brazil), the latter of these two choosing to hide all abuse contacts behind apparent email aliases all ending with @numeracao.registro.br.

So we took this process a step further by attempting to validate all of the abuse contacts by checking that the domain name supplied actually exists and has a valid destination MX and that the MX responds and accepts the recipient.

There are some obvious pitfalls with this process, as you can imagine, periodically checking recipients on an email server, without actually sending a message, tends to attract attention and blocking – despite the fact that abuse addresses should NEVER be filtered. So there will be some errors in these numbers, but this is what we have found so far:

 

 

Here’s a quick look at the top invalid abuse contact addresses ordered by the number of IPs under management of that contact (I manually verified all of these):

 

But, there’s more. The RIRs that mandate an abuse contact, don’t mandate what the abuse address can and cannot be, so we end up with this:

 

This is a count of contacts pointing to consumer “Freemail” accounts (e.g. Gmail, Yahoo, Hotmail, Live, Yahoo, Outlook and AOL). Yes, you read that correctly.

This is a highly questionable practice, likely against a number of terms-of-service and is a very good indicator that:

• These networks are poorly managed and they really don’t care about abuse and don’t want to handle it.
• Reports sent to these addresses will be aggressively spam filtered and lost if they are acted on at all.
• It’s unlikely the abuse will stop, it’s more likely to get worse.

 

Once again, here is a table of the top contacts by the number of IPs they manage:

I’ve redacted any address that appears to point to an individual name instead of a generic role account.

 

Conclusion

The RIRs and especially their respective communities really need to step-up and tackle the issues I’ve raised here head-on and improve policies.

Networks with non-working or freemail abuse contacts should be treated negatively when calculating reputation and allowing access to services.

We are actively doing this inside Abusix, our products are more aggressive in blocking when spam or abuse comes from these IP ranges. We’re also considering the publication of a blocklist for each class e.g. non-functional (unresolvable, non-working MX, invalid recipient) and freemail.