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

Bradley Freeman wrote:
> 

Hello,

> Maybe I am missing something but I can't see the benefit in having RIPE

Please read section 5. Advantages ... I described a lot of good reasons.

I personally think that its really important to automate abuse reports.
And this can not be done with the current practice of non standarized
abuse contacts hidden somewhere in whois queries.

> proxy abuse requests, as a member of a CSIRT I feel this would add a layer
> of abstraction between the 2 network operators and definitely wouldn't use
> it as a first port of call. Additionally RIPE are not in a position to force
> the badly behaving ISPs to cooperate, if you have an uncooperative ISP with

Well RIPE NCC can at least force their members to have a working
contact address.

> problem X do you really believe that RIPE suggesting they go on a training
> course is going to help? Sure the RIPE NCC may have some other contact

Maybe on some, we are running an internal blacklist that clearly states
that most spam is coming from NEW members, if you compare it to
the amount of IPs the members have.
If you see that there is even a lot of spam coming out of the new
IPv6 allocation it is clear, that most new members do not even
think about abuse they cause.

> details but most ISPs within the RIPE region you can get hold of even if the
> abuse mailbox does not work by making a few phone calls etc.
> 
> And if the only benefit is a common abuse alias, hasn't this has already
> been suggested with an abuse@ address in RFC2142 - Mailbox Names for Common
> Services, Roles and Functions which is not RIPE region specific?

Yes, but it is only a recommendation, reality looks different.
Most abuse addresses are hidden or not working or do not exist.

RIPE can easily monitor a working address with this alias proxy.
Thats what its for.

I really believe it would work better than now, if the NCC
can control and monitor the addresses. This will even
work better than trying to make the abuse-field mandatory
again.

What we need now are comments to make the system working
better and taking care about problems I wasnt thinking of
in the first place ...



Kind regards, Frank
> 
> Bradley
> 
>> -----Original Message-----
>> From: anti-abuse-wg-admin at ripe.net [mailto:anti-abuse-wg-
>> admin at ripe.net] On Behalf Of Frank Gadegast
>> Sent: 08 April 2010 14:30
>> To: anti-abuse-wg at ripe.net
>> Subject: [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
>>
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 10.0.0
> Charset: us-ascii
> 
> wsBVAwUBS73dxjR8IIjdC+5SAQJEAQf/cG+OZ3r0JYXxLhTxk2dXumEATmrULXl4
> /ZBCJ5szqvhCArMCg5/dUAhA2Fp2j2jm8knh7+I2IIOX62UThDQiQRjwxvX2QDbB
> 8moAsEiGlOWw5SCkydXCu2l/a1O7xSZuU5lmggJa85xaCw/eQEOsHQD5lEi7YEHN
> VCTiV0+n4xLFniKLE1PfqS9xo7xqlZ4yq4YqJazCQIBd44siDlGh86Ck8oLjA5FK
> IgRyHRwNBPh1Tbg4WdGQUyms/gXeO1cldK4F/FPWPUOobKNR8VZwed++sxgf/ECE
> yWng6ckMNkknKZJDp4tXUp5f2D4Vjc4GSL9Aur+woNws+n2YV2xIwQ==
> =eI5K
> -----END PGP SIGNATURE-----
> 
> 
> 


-- 

Mit freundlichen Gruessen,
--
PHADE Software - PowerWeb                       http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast             mailto:frank at powerweb.de
Schinkelstrasse 17                                fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany             fax: +49 33200 52921
======================================================================
Public PGP Key available for frank at powerweb.de