Overview
To address security issues, for instance the notification to the technical administrators, registrants and hosting providers about a compromised web site, it is essential to be able to identify the correct contact information. These can usually be retrieved from the respective WHOIS database of the Regional Internet registry (RIR), the domain name registry’s database or a Referral Whois (RWhois).
These lookups can be automated in order to be used with automatic abuse notifications.
The reason for publishing this article is the failure at different places in the process of abuse notification, regardless if the task is manual or automatic. A successful (actionable) notification is only possible when the following criteria are met:
- Access to the WHOIS database with the WHOIS protocol is unfiltered and unrestricted (as far as reasonable), e.g. not enforcing usage of web forms instead, no captchas or other artificial hurdles.
- Information stored in the WHOIS databases is correct.
- The abuse email addresses are actually working.
- The abuse email addresses are not Spam filtered.
- The abuse emails are actually read and acted upon in. 8 hours should be the maximum in cases of reported malware, 2 hours in cases of reported denial of service.
The following paragraph collects a few recommendations in order to check the own procedures.
Recommendations
In order to streamline the entire process of Abuse handling, all parties should do their best to process information as thoroughly as possible and with the utmost attention. We as a CERT among many others do our best to create Abuse notifications that contain all relevant information, are comprehensible (even for the customer, because we always assume our message can be forwarded by a reseller to a customer) and easy to process (hence we defang URLs in order not to be caught by Spam filters). We try to get all involved parties on board in our notifications with maximum transparency.
In return, we would love to see the following suggestions implemented everywhere:
- Publish abuse contacts through the respective WHOIS database, after initial test if information is correct.
- Unrestricted access to the WHOIS database (meaning: no reference to a mandatory web site, no captcha to solve, no custom API to use; just the plain WHOIS protocol in order to enable automatic lookup).
- Disable any kind of spam or content filters on abuse mailboxes.
- A periodic check of the availability of the abuse mailbox and a reaction test to make sure the customer’s data is still correct/updated.
- Setup of ‘direct line’ (special email address) between ISP and local national CERT in order to enable a high priority lane between CERT (usually having qualified requests) and ISP
- Always keep the ticket reference intact (e.g. ticket number) in any reply in order to allow tracking of all communication during the lifetime of a ticket.
- In a reseller-customer relationship: don’t just forward the abuse message without either
- following-up yourself and use your own escalation process or
- forwarding the customer contact information to us (if your policies allow this) and
- ensure that no sensitive information, contained in the abuse report and not intended for the customer, is forwarded to the final customer
- An efficient complaint instance with actual power to receive, evaluate and act on complaints about non-sufficient abuse handling in a timely manner.
- Better communication/feedback between CERTS (we sometimes request assistance from foreign CERTs, but neither receive feedback nor do we know if they act on the request).
For registrars, we have some dedicated additional suggestions:
- Proactively participate in security checks
- Check the domain name and compare it with legitimate existing domains and spot potential fraudulent activities from the early beginning
- Check carefully the registration information and look for indicators of fake information
- When terminating a user, don’t delete the WHOIS information straight away but preserve and flag the information.
- Don’t just forward the complaint to your customer. There’s a chance he registered the domain for malicious activities, so he won’t care about your notification. It should be considered your duty to stop the fraud.
In general, if a CERT contacts you, please read the mail carefully. Respect the classification of the document (which is most of the time a traffic-light-protocol (TLP) classification [1]). Don’t forward carelessly sensitive information which is for your eyes only to the client.
Contact
If you have any question or suggestion about this topic, feel free to contact us.
Classification of this document
TLP:WHITE information may be distributed without restriction, subject to copyright controls.
References
Revision of the text
- Version 1.1 - 24 February 2017 - TLP:WHITE - implemented feedback
- Version 1.0 - 23 February 2017 - TLP:WHITE