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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Gadegast wrote:

> 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.

My impression is that the irt object provide an unambiguous way to
provide this information; if it is present.

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

The proposal doesn't ensure that the abuse mailbox is read or that the
information is acted upon. That's not something that's easy to tell just
by records of e-mail transmission. Many abuse mailboxes are monitored
and acted upon but otherwise show no external signs of a response.

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

I don't think that's a good idea. There are legitimate reasons to want
to know the real abuse email address, or you may simply not want to
relate a report to a specific IP address.

> 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.

What do you propose as a metric for this? The raw volume of reports, or
reports per IP address, whilst obvious are not too helpful.

I'm sure that  at specific time there's always a host on our network
causing lots of reports to be sent to our abuse mailbox, but that's not
a sign that we're running the network badly but simply that our network
is very large.

You could look at reports averaged across address space but that'll
count unfairly against large networks using address translation. We have
this problem here where a few IP addresses generate unusual levels of
reports, but not when you take into account that those few addresses
have many tens of thousands of computers and users behind them.

I'm not suggesting it's not possible, but that this is a very difficult
question that we've had to think about in the past, and I'd love to hear
the answers :) More useful to us is when we talk to our customers about
activity and realize that something 'hinky' is going on
(http://www.schneier.com/blog/archives/2007/04/recognizing_hin_1.html).

> 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.
> ...
> 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.

The stats that RIPE would gather, in no way would correspond to the
actual reports ending up in front of the abuse handler, as the RIPE
stats would include spam sent to a.b.c.d at abuse.ripe.net

> 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).

That could be a good idea. You'd have to have a think about how many
man-hours that'd involve though.

> 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).

Not only incoming spam, but it also would include all the other stuff
that ends up in our abuse mailboxes but isn't "abuse". I'm thinking of
people wanting us to step into personal disputers, or people who are
just very confused as to what we can help them with ;)

> 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.

No, it'll just ensure that the reports end up being delivered to an
mailbox. Even if they then end up being read, that's not going to be
enough is it?

> 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.

I'd like to see RIPE members being more aware of the irt object.

James

- --
James Davis	+44 1235 822 229    	   PGP: 0xD1622876
JANET CSIRT	0870 850 2340	        (+44 1235 822 340)
Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLveY6hZi14NFiKHYRAqBIAJ9xQf07MrEaw3sspxd8NpBCkQoh9QCfa7Mw
1wqUA/ZUML/crgpi/visJHo=
=MdAe
-----END PGP SIGNATURE-----

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG