Should you have any questions, you may want to take a look at the Frequently Asked Questions (FAQ) below. If your question is not anwsered by the FAQ, you can drop us a line.

In the early years of the 21th century, rogue networks where popping up in the internet which were operated by miscreants with intent to provide bulletproof hosting to spammers and botnet operators. Such networks hosted a significant amount of malicious content, such as spammer sites and servers that were being used to control infected computers (botnet C2s). Many internet users became victim of the fraudsters, but the internet community managed to stand up and took action against known bulletproof hosters: They have simply been depeered from the internet. So the internet community and Internet Service Providers (ISPs) found a way to defend themselves. The fight for the good of the internet was successful. As of today, bulletproof hosters became very rare. Nobody wants to provide IP transit to rogue networks anymore these days. But miscreants didn't thought about giving up. They were seeking for other solutions than bulletproof hosters - and found them.

These days, miscreants are flooding legit hosting providers with fraudulent orders which allow them to host fraudulent content (such as spammer sites or Botnet C2s) by abusing the hosting provider's infrastructure. While most of the big players in the hosting business already have appropriate measures in place to sort out fraudulent orders, many smaller ones fail to do so. This results in massive amount of abusive content being hosted in smaller networks (usually /21, /24 etc).

A fraudulent order is an order placed for a resource or service (e.g. a VPS - Virtual Private Server) that has been placed at a hosting provider by a miscreant. It is important to understand that the miscreant's intent is to use the resource he ordered for the exclusive purpose of committing a crime or hosting malicious content (such as spammer sites or botnet C2s). There will never ever be any legit content hosted on the resource the miscreant has ordered. It is 100% malicious.

To protect himself from criminal prosecution by law enforcement, the miscreant orders the resource using a fake or stolen identity. In case of a fraudulent order, information provided by the customer (customer information), such as name, postal address, email, phone number etc is all either stolen or completely fake. In addition, miscreants are using stolen credit cards or accounts from payment service providers (such as PayPal) to order the resource. If you offer bitcoin as payment method, miscreants will love you, as this payment method is completely anonymous and the miscreants can just use the bitcoins they have previously extorted from victims of ransomware.

Characteristics of a fraudulent order:

A resource can be any service you offer: a VPS, dedicate server, domain name, DNS service, proxy service etc.

If you are a hosting provider, you may ask yourself why you should care about fraudulent orders. There are various reasons why you actually should care:

What makes the whole story with fraudulent orders to a real mess is the fact that it doesn't really matter if you care about abuse reports that are being sent to you by other internet users or not. If you act up on an abuse report you have received and you terminate the associated resource due to abuse, the miscreants most likely won't care and will just order a new resource which they then will use for malicious purpose as well. So it all ends up in a cat and mouse game that harms the reputation of your network. To solve this problem in a permanent way, hosting providers should make sure that fraudulent orders are being detected and stopped before a service ordered by a miscreant is being commissioned.

Suspect networks are networks (prefixes) with a high amount of abuse (a high amount of phishing sites, spammer sites or botnet C2 that are hosted in a particular network), obviously caused by a weak or insufficient customer verification process.

A prefix may get listed on suspect-networks.io under the following conditions:

There are various ways to verify a customer account. What is important to know is that there is not a single solution that does all the work for you and solve your problems at once. The key is to combine multiple approaches and solutions in order to prevent and block fraudulent orders. suspect-networks.io does not care about how your customer verification process looks like. It just has to be sufficient - this is the only thing that counts.

If you are looking for ideas on how to create or improve a customer verification process, this may help:

If your network is listed as suspect network, the only way to get delisted is by implementing a proper customer verification / vetting process. If you believe your customer verification process is sufficient (which is likely not the case, otherwise your network wouldn't be listed as suspect network) and you wish to get delisted, you can contact us via email. Please do not ask for a delisting unless all of the following conditions are met:

If you believe these conditions are met, you can contact suspect-networks using the email address de$li#st { at } suspect-networks.io (remove $ and #). Please do not contact us unless you are the hosting provider responsible for prefix listed on suspect-networks. Your request should be handled within 48 hours.

You can use suspect-networks.io as a DNS Response Policy Zone (RPZ), for example to redirect or block domain names that resolve to an IP address listed on suspect-network.io. In order to do so, your DNS resolver needs to support the RPZ technology. The examples below show you how to configure your BIND DNS server to use suspect-network.io as a Response Policy Zone (RPZ), by using Paul Vixie's AXFR server (DNS zone transfer). By using AXFR, your DNS server will automatically look for changes in the suspect-network.io RPZ and update the zone if needed.

Modify your BIND configuration (usually located under /etc/bind/named.conf) as following:

options {
	response-policy {
		zone "rpz.suspect-networks.io";
	};
};

logging {
	channel log-rpz {
		file "/var/log/rpz.log" versions 10 25m;
		severity info;
	};
	category rpz {
		log-rpz;
	};
};

zone "rpz.suspect-networks.io" {
	type slave;
	masters { 24.104.150.234; };
	file "/etc/bind/rpz.suspect-networks.io";
};

If you configure RPZ with BIND, please consider the following:

If you want to download the suspect-networks.io RPZ zone directly and don't want to take advantage of the AXFR server, you just have to change the type of the zone configuration to master and remove the masters statement.

BIND zone configuration using AXFR (DNS zone transfer):

zone "rpz.suspect-networks.io" {
        type slave;
        masters { 24.104.150.234; };
        file "/etc/bind/rpz.suspect-networks.io";
};
	

BIND zone configuration using the zone file offered by suspect-netoworks.io:

zone "rpz.suspect-networks.io" {
        type master;
        file "/etc/bind/rpz.suspect-networks.io";
};
	

If you don't use the AXFR service, you will also have to configure cronjob (e.g. /etc/crontab) that downloads the RPZ zone from suspect-networks.io and reloads the BIND configuration. Such a cronjob may look like this:

*/15 * * * * bind	wget -qO /etc/bind/rpz.suspect-networks.io https://suspect-networks.io/downloads/suspect-networks.rpz && /etc/init.d/bind9 reload
	

If you have questions on configuring BIND as a DNS RPZ, you can find further information and configuration examples here: