8 February 2017

Composing an abuse report

What to send, how to send it, where to send it – and what not to send or do.

‘Personal firewall’ pitfalls

  • When setting up an access list, you will often start by denying and logging all incoming traffic. However, this does not mean that you should report everything you find in your logs.
  • Abuse desks do not exist in order to teach basic IP networking. If you are confused, contact your local technical support people instead, or search the web for information.
  • Do not report an alert generated by a personal firewall unless you understand what the traffic in question is and why you should consider it hostile.
  • Do not report ‘intrusion attempts’ from your provider’s routers or its DHCP, DNS, mail, WWW etc. servers. Because you use those services, it is normal for them to send traffic back your way.

A few other caveats

  • If your complaint refers to abuse on the network rather than abuse of the network, consider contacting some other party instead of (or in addition to) the ISP. For example, report copyright violations to the relevant copyright enforcement association, and report crime to the police.
  • If unsolicited promotional email is illegal in your jurisdiction and someone within that jurisdiction sends you some, please report the matter to the police so that the sender may be prosecuted instead of just mole-whacked into using another provider.
  • Think twice, and then twice more, before reporting personal disputes, such as disagreements regarding:
    • politics, taste, opinion etc. – common carrier ISPs are not content censors
    • IRC channel operator status – if ‘your’ channel was taken from you, either
      • the IRC network does not support channel ownership, so the channel was not yours in the first place, or
      • you are experiencing problems with the network's registration system (not an abuse issue)
  • Never try to fight abuse with abuse, e.g. by ‘mail bombing’ an ISP, or you may find your account suspended.

Remember that these addresses are special

IPv4

  • 0.0.0.0 – 0.255.255.255: ‘this’ network
  • 10.0.0.0 – 10.255.255.255: private
  • 127.0.0.0 – 127.255.255.255: loopback
  • 169.254.0.0 – 169.254.255.255: link local
  • 172.16.0.0 – 172.31.255.255: private
  • 192.0.0.0 – 192.0.0.255: protocol assignments
  • 192.0.2.0 – 192.0.2.255: documentation
  • 192.88.99.0 – 192.88.99.255: 6to4 relay anycast
  • 192.168.0.0 – 192.168.255.255: private
  • 198.51.100.0 – 198.51.100.255: documentation
  • 198.18.0.0 – 198.19.255.255: benchmark tests
  • 203.0.113.0 – 203.0.113.255: documentation
  • 224.0.0.0 – 239.255.255.255: multicast
  • 240.0.0.0 – 255.255.255.255: broadcast and future use

IPv6

  • ::/0: default unicast route
  • ::/128: unspecified address
  • ::1/128: loopback
  • ::ffff:0:0/96: IPv4-mapped
  • ::<ipv4-address>/96: IPv4-compatible
  • 2001::/32: Teredo
  • 2001:10::/28: ORCHID
  • 2001:db8::/32: documentation
  • 2002::/16: 6to4
  • 3ffe::/16: 6bone (second instance)
  • 5f00::/8: 6bone (first instance)
  • fc00::/7: unique-local
  • fe80::/10: link local
  • ff00::/8: multicast

You may also find Team Cymru’s list of bogons useful.

Consider sending your reports through a service

…such as DShield FightBack (for intrusion attempts), or SpamCop (for unsolicited bulk email).

They may:

  • help you avoid mistakes;
  • update blocking lists based on reports received;
  • produce streamlined reports that are easy for ISPs to act on; and
  • allow you to track, in real time, the status of your complaint.

General advice on reporting

  • Send your report as plain text. Many request-tracking systems do not support images, HTML pages, proprietary word processor documents, spreadsheets etc.
  • Ensure that the recipient will be able to identify your message as an abuse report at first glance. For example, avoid starting with a long-winded description of your organisation.
  • If your report includes time stamps from your own systems:
    • Check whether your system clocks are correct; if they are not, indicate any error exactly (this becomes especially important e.g. when identifying a dial-up user).
    • State the difference between UTC and the time zone used in your time stamps. Not everyone will be familiar with your time zone and daylight saving schedule, so avoid using local time zone names or abbreviations; instead, use e.g. ‘+0200’ to indicate that your local time is two hours ahead of UTC.
  • Avoid issuing demands. It is up to the provider to investigate the issue and take action as it sees fit.
  • Remember that ISPs may be legally prohibited from disclosing (or even determining) subscriber information, such as the identity of a dial-up customer, without a court order.
  • Do not harass the persons listed as NIC contacts. Whois lookups show their names because they handle administrative, billing and/or technical tasks, often for large chunks of IP address space. They might not have anything to do with their organization's abuse response duties, and they certainly are not likely to commit acts of abuse, such as attempt to crack their way into your systems.
  • If you receive a tracking number and you later find you need to follow up on your report, use that number so that the abuse desk team will be able to connect your new message with your initial report. If you are not assigned a tracking number, keep the ‘Subject:’ line unchanged and quote previous correspondence as necessary.

What to send

Email and Netnews abuse

Usually, you should simply forward the abusive message in full, without editing it in any way. The visual presentation a mail or news reader offers is often very different from the actual message format, so it might not be enough to just copy what you see and paste it into your report – you must forward the original message, including all header lines. An email abuse report without ‘Received:’ lines, or a Netnews abuse report without a ‘Path:’ line, is probably useless.

Sometimes you may want to edit the message in order to anonymise the original email recipient. If you alter e.g. the ‘Received:’ and ‘To:’ lines, please make it obvious; the de facto standard is to replace the recipient information with the string ‘x’ (without the quotation marks), as in:

Received: from leo (61-217-61-120.HINET-IP.hinet.net [61.217.61.120])by walrus.megabaud.fi (8.11.3+3.4W/8.11.3) with SMTP id fBP9P1V03370 for <x>; Thu, 25 Dec 2008 11:25:03 +0200 (EET)
To: x

Extremely large messages, as well as messages that contain malicious software, are also exceptions to the forward-in-entirety rule; instead of forwarding e.g. a Trojan or a 20-megabyte Microsoft Office document, add a note describing the size and content of the attachment. If appropriate, include a plain-text sample.

Unauthorised access attempts, denial of service attacks and similar activity

Send the relevant log lines from the device (such as your firewall, router or server) on which you detected the attack. State that the traffic in question was unauthorised, and indicate whether the target systems were running services intended for the general public (the originators might try the ‘I had permission to scan the network for security holes’ and/or the ‘I was trying to use a public service’ excuses). Especially if the log format is not self-explanatory, add a descriptive header line, such as ‘type,date,time,source,destination,transport’.

What to add

In typical cases, no ‘cover letter’ is necessary, but sometimes a couple of explanatory lines may be useful, such as when:

  • the abusive message is encoded (e.g. uses client-side scripting or exotic character sets);
  • the connection between the abuser and the report recipient is not immediately obvious (such as in the case of web site redirection, or if you are escalating the complaint because the end provider's abuse contact has not resolved it adequately); or
  • you have blocked traffic due to the abuse incident. It would be a good idea to indicate this in detail (e.g., ‘all mail exchangers for example.net now reject connections from 192.0.2.0/24’). You might then receive a personal reply explaining the issue and how it has been resolved.

Additionally, you may want to use one of the following tags in your ‘Subject:’ line to specify the medium on which the abuse was perpetrated:

[email]
Internet email
[usenet]
Netnews (including non-Usenet groups)
[irc]
Internet Relay Chat
[icq]
ICQ
[chat]
Other chat media
[misc]
Other media

… and what not to add

  • Do not send screen shots.
  • Do not send your entire log file, expecting the recipient to determine just which five or so lines out of a thousand actually are relevant to your report.
  • Do not routinely enclose traceroute, whois or similar output. ISPs usually know how they have set up their NIC records and their routing, so mailing that information back to them usually just adds noise to your report.
  • Do not obfuscate your report by including representations of your mail or news client's user interface buttons such as ‘Block address’ or ‘Add to address book’.
  • Do not issue empty threats of legal action. When you report a case of network abuse, you want the provider to work with you in resolving the problem. If you instead threaten to sue the ISP, it may refer the matter to its legal department, and you will have positioned yourself against the provider. In addition, an ISP might not want to interfere with a police investigation by alerting a suspect.
  • Profanity, personal insults or other kinds of tantrum throwing are not useful.

Where to send your report

If you decide to mail the ISP directly, keep in mind the convention of using the abuse mailbox of the provider, e.g. abuse@example.net. Do not needlessly ‘shotgun’ your report to a ‘bitch list’ of addresses. If the abuse address does not work, chances are the organization in question would not know what to do with an abuse report anyway; in such a case, you should probably contact the uplink provider's abuse desk instead.

Abuse reports are normally not sent to RIRs or to the IANA, as these organizations are not access providers. However, recent discussion indicates that the community does wish for RIRs to take actions against abusive ISPs.

Please double-check to make sure you do not send your report to an innocent bystander. Spam-reporting software will frequently mislead you. For example, one widely used lookup tool directed complaints regarding a certain /16 network to us just because we were responsible for the first /19 chunk. In addition, remember that email and Netnews headers are easy to falsify; do not complain to forgery victims.

Commonly falsified email headers

HeaderComments
Date:The message may appear older or newer than it is.
From:The address of the purported sender of a spam message is usually forged.
To:There are often several recipients per spam message, even if the ‘To:’ line lists only one address. The actual recipients are always listed in the RCPT command, which is part of SMTP; the ‘To:’ line does not define the destination of the message.
Received:To make the message more difficult to trace, the spammer may ‘preload’ it with one or more forged ‘Received:’ headers. You can rely on the ‘Received:’ line that your mail server wrote, but you should treat any others with suspicion.

Third parties may be interested in your abuse case

  • Spam collectors such as KnujOn may accept junk email submissions regardless of the message topic.
  • Certain organizations and agencies collect messages that are relevant to their specific duties. Such topics may include phishing, stock fraud, advance payment fraud or chain letters.
  • Copyright enforcement agencies are usually interested in any illegal distribution of their clients’ copyrighted material such as software, music or video. Many copyright holders also accept direct reports.

Summary

  1. Consider whether the issue really should be reported to an ISP.
  2. If a personal firewall detected the issue, reconsider whether to file a report.
  3. Make sure you have identified the provider correctly.
  4. If you contact an ISP, write to its abuse address (e.g. abuse@example.net).
  5. Use plain text.
  6. You should usually describe the incident by sending either a complete ‘raw’ message copy or the relevant log lines.
  7. Advise the recipient regarding any difference (such as clock error or time zone offset) between your time stamps and UTC.
  8. If you follow up on your report later, include sufficient background information.