We receive abuse reports every day: automated spam complaints, copyright notices, reports of scanning or brute force from one of our addresses, and occasionally a phishing page. Most hosts describe their policy in one sentence in the terms of service. This is the longer version: what happens when a report arrives, what earns a warning and what earns a null route, and why we tell you before acting whenever the situation allows it.
Verification first
A report is a claim, not a fact. Before anything is done, someone on the abuse desk checks it: does the address in the report belong to us and to which server, does the timestamp fall within the customer's tenancy, does the evidence support the claim, and is the reporter who they say they are. Automated complaints about traffic that a looking-glass check shows never left our network are closed without contacting anyone. Copyright notices that name no work are answered with a request for one.
Roughly a third of what we receive is closed at this stage. The rest becomes a ticket on the customer's account.
The ticket, and 24 hours
A verified report opens a ticket in your panel with the evidence attached, a plain explanation of what was reported, and what would resolve it. In most cases you have 24 hours to respond: to fix the compromised WordPress that is sending spam, to remove the file named in the notice, to stop the scanner a tenant of yours installed. Responding means telling us what you did; “I am looking into it” buys another 24 hours once.
Ninety per cent of tickets end here. The customer did not know, fixed it, and the report is closed. Nothing is suspended, nothing is logged against the account beyond the ticket itself.
What gets a null route first
Some things cannot wait a day because they are harming other people every minute:
- An outbound DDoS or a flood from a server, however it got there.
- A live phishing page impersonating a bank, a wallet or a login form.
- Malware distribution or command-and-control traffic confirmed by a reputable source.
- Content that is illegal to host in the server's jurisdiction, with a court order or an equivalent notice.
In those cases the server's address is null-routed immediately, the ticket is opened at the same moment with the reason, and the console in the panel stays available so you can log in, investigate and clean up. The null route is lifted when the cause is gone and you have told us how it happened. A first occurrence that was clearly a compromise is not held against you; a server that is null-routed for the same reason three times is not a server we keep.
What does not happen
- We do not read your disks, your databases or your traffic to investigate a report. We look at flow records, which show addresses, ports and volumes, and at what is publicly reachable on the address in the report.
- We do not terminate an account over a single report, or without a ticket that explains why.
- We do not forward your identity to a reporter. We forward your response if you ask us to.
- We do not act on reports that ask us to take down content because someone dislikes it. Lawful content stays up; that is what the abuse policy is for.
The usual causes, so you can avoid them
Almost every abuse ticket we open traces back to one of five things: an unpatched CMS or plugin, a password-only SSH or RDP login, an open resolver or NTP server used for amplification, a mail server relaying for anyone, or a Docker daemon exposed on the public interface. The first-hour checklist covers all five for Linux, and the RDP post covers the Windows case. A server that follows either has never appeared in our abuse queue for a compromise.
Reporting abuse to us
If one of our addresses is bothering you, the abuse page takes reports with logs and timestamps in UTC. Reports with evidence are acted on within hours; reports without it are answered with a request for some. We publish the abuse contact in the RIR database for every prefix, and we read it.