This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
- Previous message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
- Next message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Frank Gadegast
phade at www.powerweb.de
Thu Apr 8 20:27:43 CEST 2010
> > > You dont need to know the real one until you have one for every IP. > > As I mentioned, you might simply want to contact the abuse team > regarding a more general issue. Quite often if I can't find a published > abuse contact for foo.com so I'll dig www.foo.com and then lookup the > returned address in the RIPE DB - I'm not at all interested in an > address specific to that IP address though. well, you can still look it up. But see it this way: - most provider use anti spam tools like SpamAssassin to protect there customer - SA surely lists the IP that was connecting and causing the spam - you can then automatically forward the spam plus a initial text, describing that you do not want this to the general "IP like" address - and the monitoring system will then forward it to the right RIPE member (and to EVERY member) > Metric as in a standard of measurement. Sorry that probably wasn't very > clear language on my part. > > > And that prooves what ? > > I have 17 million+ users, and a remit to provide very open network > access to them. It's inevitable that somewhere on the network someone is > sending large volumes of spam, what's important is how quickly and > effecitvely we react to that incident. Clear. Think about, how easy it would be for you, when you are receiving a report ASAP via the new system. It is likely, that you get a problem report just a few minutes after on of your users started to send spam, because his PC is invected. You can then look up the report (or even automate it), reset his radius password and kick him out, waiting for him to phone your support :o) Or you could redirect him to a webpage describing that there are too many reports coming in for his IP in a whatever time. Its all up you. My dream system looks like this: - abuse reports will get standarized - monitoring systems will be developed at all RIRs - spam detection will be automated at the providers side and send standarized reports to the RIRs monitoring system - and the RIRs member automates and scans the incoming reports like he wants (maybe by devining minimum values and limits) and automates the blockage and information of his users Sounds great ? Well, thats actually what we are doing already with our own users. If we detect incoming spam with high scores a couple of times in a short time we kick the users offline automatically and redirect him next time he loggs in to a information page, where he finds our support numbers :o) Wroks simply great, and I would love to get closer to such a system together with ALL ISP > Someone from RIPE calling us, to offer us a training course we don't > need, because last year we had a few hosts sending 100,000+ spam e-mails > isn't a useful use of anyone's resources. Thats was just an idea to inform newer members. For you it might be more important to automate as much as you can, and to be informed as quick as possible, and the monitoring system in my draft simply acchieves that. > This, and my comment about NAT, are just illustrations of how you need > to be careful over deciding what you consider to be a large volume of > reports. Well, limits, counts and how you act on them, are fully up to you. We had to test limits as well for our users. Lets say, you receive 100 reports in about 10 minutes for one IP, where this IP had no report ever ? What is likely to happen ? What would you do ? Its up to you, but surely you would read about 5 reports more closely ( to check, that you are not spammed) and then do whatever you are doing normally, (like looking up your own logs, checking other blacklists to proove that there is a problem, dial into the supposed hacked server aso) when you detect a dialin user or a hacked server. > > Well at least you will hear about incidents with the new system > > and thats more thats currently happening. > > We already hear about incidents. Almost all the address space used on But very slow, we see from our own blacklist, that ISPs most often realize problem far later than our blacklist detected the problem or even get informed about the problem via our blacklist for the first time. > our network has an irt object published and reports reach us at the > correct address. I'm not convinced that any abuse team who really wants > to make themselves contactable has problems doing so (whether they are Yes they have, the really have a problem receiving breakout infos quick enough ... believe me, we have experiences for now more than 3 years with them. > aware of the irt object or not is another matter). > > The difficulty is in convincing network owners that they need abuse > teams that take the issue seriously :) Defny agree. But an implemented system will make them even more aware, espacillay when they have to have a working abuse address and this one is getting flodded with reports. The only thing they can do, is emptying it with cp -f /dev/null /var/spool/mail/abuse every minute. But this will then result in some attention at RIPE NCC, because they do not answer incoming reports to set their state via the backlink. "Bad providers" could be even published by RIPE :o) The incoming reports will maybe even stress their mail servers :o) > > The member would not want that many emails arrive at that main address > > and fix the abuse address asap. > > > > This process could be automated at RIPE system. > > I don't know anything about RIPE's existing processes for making sure > that member information is correct but I suspect that it still requires > human effort as a last resort. Well, thats only work at RIPE NCC, its not that complicated to automated bounces ... > > Another idea to stop spam coming in, could be to open > > the whole system only to RIPE members first ! > > > > The ISP could work together and all others stay out. > > > > Will that be a solution ? > > No, I suspect most of our reports come from non RIPE members. The link Hm, we receive still more than 20% of all spam from RIPE members. TTNET, TPNET and most russian (and new) eastern ISPs are a bid problem. Sure, the most is currentyl coming out of china, brasial and korea. But that has nothing to do, with getting the RIPE zone more advanced and cleaned. Think about the headline: "Europe is clear of spam senders now !" (ok, ok, newl reporters are never correct and a bit too much entusiastic, but it could come close). > confirmation would be enough, although you'd need some way to deal with > automated reports. Well, the monitoring system could send always the same backlink for the same IP, so that the ISP could still count the amount of incoming reports for one IP automatically and then "answers" it as being closed with just clicking ONE link. Good idea ? > Shuffling bits from one mailbox to another doesn't constitute actual > progress. You need to give a reason for the recipient to care enough > about the reports to do something - and if they have that reason they'll > take care of making themselves contactable for you :) Defny right, but lets start with something ... Kind regards, Frank -- 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 > > 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/ > > iD8DBQFLvgCNhZi14NFiKHYRAnvWAJ9z0cWJq/rXaNZgyEPcG3MhdEODhgCfb2OZ > MMz5kWuRdgtPKF3vuY9L2OI= > =DfbR > -----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 >
- Previous message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
- Next message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]