blog.anta.net

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 doesn’t 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 do a web search for information.
• Do not report an alert generated by a personal firewall unless you understand what the traffic in question is, and why it should be considered hostile.
• Do not report “intrusion attempts” from your provider’s routers, or their DHCP, DNS, mail, WWW etc. servers. You are using those services, so it’s normal for them to send traffic back your way.
• If you do not have a firewall, or if the one you have is outdated, please visit our shop.

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 same 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 doesn’t support channel ownership, so the channel wasn’t 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 “mailbombing” an ISP, or you may find your account nuked.

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.2.0 – 192.0.2.255: documentation and examples
• 192.88.99.0 – 192.88.99.255: 6to4 relay anycast
• 192.168.0.0 – 192.168.255.255: private
• 198.18.0.0 – 198.19.255.255: benchmark tests
• 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
• ::/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

Consider sending your reports through a service

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

They may:

• help you avoid mistakes
• generate blocking lists based on reports received
• produce streamlined reports, easy for ISPs to act on
• allow you to track your complaint status in real time

General points about sending reports

• Send your report as plain text. Many request tracking systems don’t support images, HTML pages, proprietary word processor documents, spreadsheets…
• If your report includes time stamps from your own systems:
  • check that your system clocks are exactly correct; if they’re not, indicate any error (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’s up to the provider to investigate the issue and take action as they see fit.
• Note 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 are certainly not likely to commit acts of abuse, such as attempt to crack their way into your systems.
• If you receive a tracking number, and 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 original report. If no tracking number is assigned, 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. Good examples can usually be found in news.admin.net-abuse.sightings, and you can post your own sightings there as well. An email abuse report without Received: lines, or a netnews abuse report without a Path: line, is likely worthless.

Sometimes you may want to edit the message in order to anonymize the original email recipient. If you alter e.g. the Received: and To: lines, please make that obvious; the de facto standard is to replace the recipient information with the string x, 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 fBP9P1V03370for<x>; Tue, 25 Dec 2001 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 MB Microsoft Office document, add a note describing the size and content of the attachment. If appropriate, include a sample.

Unauthorized access attempts, denial of service attacks, and similar activity

Send the relevant log lines from your firewall, router, server, or whatever device you detected the attack on. State that the traffic in question was unauthorized, 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). If the log format isn’t self-explanatory, prepend a descriptive header line, such as:

What to add

In typical cases no “cover letter” is needed, but sometimes a couple of explanatory lines may be useful, such as when

• the abusive message is encoded (e.g. client-side scripting, or exotic character sets)
• the connection between the abuser and the report recipient isn’t immediately obvious (such as in the case of web site redirection, or if you need to escalate the report because the end provider’s abuse contact has failed to adequately resolve your complaint)
• 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 are rejecting 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 in order to specify the medium where the abuse occurred:

[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 whole 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. An ISP can be expected to 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 ISP’s abuse desk people to be able to work with you in resolving the problem. If you instead threaten to sue them, the matter may be referred to the legal department, and you will have positioned yourself against them. Also, 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, the convention is to use the abuse role mailbox of the provider in question, e.g. abuse@example.net. Do not needlessly “shotgun” your report to a “bitch list” of different addresses belonging to the same organization. If the abuse address doesn’t work, chances are the organization in question wouldn’t know what to do with an abuse report anyway; in such a case, you should probably contact the uplink provider’s abuse desk instead.

Additionally, certain third parties may be interested in your abuse case:

• “Spam archives” such as spam@uce.gov may accept junk email submissions regardless of the message topic, but will often, at least in the short run, not take any other measures besides storing the message in a database (which may be available to the public).
• Certain organizations and agencies collect messages that are relevant to their specific duties. Such topics may include “phishing”, stock fraud, advance payment fraud, chain letters, child pornography, and illegal drugs.
• Copyright enforcement agencies are usually interested in any illegal distribution of their clients’ copyrighted material, such as software, music or video. Many copyright holders will also accept direct reports.

Please double-check to make sure you’re not sending 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 me just because I happened to be responsible for the first /19 chunk. Also, remember that email and netnews headers can be falsified; do not complain to forgery victims.

Abuse reports are normally not sent to RIRs nor to the IANA, since these organizations are not access providers. However, since recent discussion indicates that the community does wish RIRs to take actions against abusive ISPs, this policy may need to be revisited soon.

Summary

1. Consider whether the issue really should be reported to the ISP at all.
2. If the issue was detected by a personal firewall, reconsider whether it should be reported.
3. Make sure you have identified the provider correctly.
4. If you contact an ISP, write to their abuse address (e.g. abuse@example.net).
5. Use plain text.
6. Usually send either a complete “raw” message copy, or the relevant log lines describing the incident.
7. Advise the recipient regarding any difference (clock error, time zone offset) between your time stamps and UTC.
8. If you follow up on your report later, include sufficient background information.
9. Please post your comments below!