[anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse monitor system

Dear all,

please discuss and comment to following draft proposal ...
(and please forgive but correct my english, bad formatting
  or terms)

Kind regards, Frank

--------------------------------------------------------------


DRAFT: implementation of an abuse monitor system
(draft RIPE proposal)



Abstract
This document describes the implementation of an abuse monitor system
at RIPE NCC. Its intention is to ensure working abuse contacts on the
members side and to improve the awareness, responsiveness and work flow
for abuse reports for the reporting (and abused) internet users and the
RIPE members (owning the misused services).


Contents
1. Introduction
2. Goals of an abuse monitor system
3. Requirements
4. Description
5. Advantages
6. Disadvantages
7. Enhancements
8. Outlook


1. Introduction
Taking in account the amount of spam and other abuse currently
happening every day, there is a need to ensure that ISPs and
other organisations are aware of the problem their customers
and end users can cause for others.

The current procedure of having non-mandatory abuse contacts in
whois output is causing several problems for the incident reporting
side as well as for the receiver.

RIPEs member should be responsible for the abuse their
customers cause, like this is enforced by law in many countries
already.


2. Goals of an abuse monitor system
Currently most abuse contact addresses are hidden in whois output
remark fields in several non-standarized ways or do not even exist,
because the real abuse-field is non-mandatory. There should be
a standarized method how to contact responsible people to send
abuse reports too.

It should be possible to to send abuse reports to a standarized
email address, because whois queries are limited. The system should
bypass whois queries, so that reports can be automated.

Currently there is no control, if existing abuse contacts are still
valid, working or incoming emails are beeing read.

The real abuse email address of any RIPE member should be hidden
by the abuse monitor system.

Finally a monitoring system should be able to messure the amount
of incoming reports for any RIPE member. This will enable
RIPE NCC to help members to become more aware of security breakouts
or help members that are not aware of the problems they cause.

RIPE NCC could e.g. arrange for security training cources and
invite members with a very high reporting rate according to
the amount of allocated IP addresses.


3. Requirements
RIPE NCC should enhance the member section with an extra abuse contact
field. This field should be filled at startup with the main email
address of any member automatically, but should be editable for the
members.


4. Description
RIPE NCC should implement a mailserver able to receive emails in the
form of

         IP1.IP2.IP3.IP4 at abuse.ripe.net (example)

Incoming emails to these addresses can be treated as incoming abuse
reports and will be forwarded to the members internal abuse contact
address (non-public), after the mailserver finds the correct member by
looking up internal allocation tables.

The amount of incoming emails for every member will be logged and should
create internal statistics for RIPE NCCs internal usage.

Their should be no anti spam systems implemented on this server to
ensure that every incoming email gets forwarded. Anti spam systems
should be up to the member.

Furthermore, RIPE NCC should monitor, if the members abuse contact
address generates errors, bounces or other problems like "User unknown"
or "Mailbox full". If the members abuse contact address is not valid
anymore, it could be reset to the members hidden main email address, and
the member could be informed about the problem in other ways (letter,
phone call aso).


5. Advantages
The system does neither have to define or decide what spam or abuse is,
because it only forwards abuse reports to the responsible person.
It is likely that any incoming email is a description of a real
abusive problem (except incoming spam).

The described system would make it very easy for any ISP or private
person to report received spam, hacks or other abuses directly to
the responsible RIPE member, without having to know its name and without
having to know how to use whois.
Reporting systems could be easily automated without having to query whois.

The ISP or RIPE member can easily change and control his internal abuse
contact address without having to update several objects in RIPEs
database.

RIPE NCC can ensure that all alocations have a working abuse address.

This all can ensure that incidents are really reported by the abused
users (and not beeing ignored or forgotten because its to much work to
report incidents) and that reports will be read by the right and
responsible person.

This will finally increase the awareness of any RIPE member about the
problems his end users or misused servers may cause and will hopefully
force any member to implement methods to monitor there own servers
and/or dialin users to improve the detection of misused services.

This will hopefully reduce the amount of spams and abuse worldwide.

Finally this will maybe influence other RIRs to implement similar
systems.


6. Disadvantages
It is likely that spammer will misuse the new general abuse adresses
massively. Anti spam methos needs to be implemented at the members side.


7. Enhancements
The system could be enhanced with addtional services easily on RIPE NCCs
side, after implementation and a test period of the system. More
detailed statistics could help improving the awareness at the members
side.

Enhancing forwarded abuse report with an feedback link could help to
categorize incoming reports. Members could then visit a ticket system to
back report incoming reports as "spam", "incident" or "wrong report"
(like popular spam blacklist like SpamCop are doing this already), add
comments like "missing information", "incident currently under
investigation" or "incident solved". This could help members to track
reports and incident easily without having to implement a own system
(what could be very interesting for smaller ISPs). Finally this would
allow the reporting internet user to receive feedback to ensure that his
input is valuable, important and taking care off.


8. Outlook
Standarization of a general abuse address will be another step to the
standarization of an abuse report format, wich are currently in process.
This could lead to open source implemantations of spam detection
solutions that include standarized reporting features.
Standarized reporting could also be included in other monitoring
and detection software, like Intrusion Detection Systems or
Antispam Solutions.



Author: Frank Gadegast
Company: PHADE Software - PowerWeb
Contact: frank at powerweb.de
Version: 0.1
Date: 08.04.2010