- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an
by Frank Gadegast 09 Apr '10

09 Apr '10

Bradley Freeman wrote: Hello, >> Its only against members, that are ignoring that there attitude >> or business model causes real harm to others. > > This proposal still will not help the abuse desks which are uncooperative > which is the real problem. Yes, thats true, if your are willing to ignore reports, it will help nothing. But it will help to make uneducated members more aware and to help others that are not really far in the process of developing a real abuse team. >>> If a RIPE member has an abuse contact and sets up abuse contact >> objects for every allocation, why do you need anything else? >> >> Like I outline already: >> - whois is complicated and unusefull for end users > > And do you believe that this proposal will be used by end users who couldn't > use whois? Yes, it this easy IP-scheme-email address will get public, there will be a lot of more people akt, when they receive spam. Our customers asking as a lot, where to report spam too ... ... and we have no easy answer to that. >> - IRT objects makes it even more complicated > > I simply disagree, IRT objects simplify the whois and provide a clear > contact email. IRT objects will be additional and maybe even non-mandatory again. It will end up having two things to check. The remarks of a netrange object, maybe even the route object and the IRT object. And thats send all different for a lot of RIRs. If like the IRT object being a help, it would have to be mandatory, and there we start again. >> - nobody is meassuring the members so far >> - nobody has detailed data about how much abuse is really happening >> except really well-known blacklists like spamhaus > > My network != your network, I don't see any point in measuring the abuse > from ISPs in this manner. As James said previously larger networks will > generate greater amounts of abuse, and ISPs with different businesses models > will generate varying amounts of abuse, a high level of abuse from a network > is not indicative that you are running a bad network. Additionally there is > nothing that RIPE could do with this data it is simply a meaningless metric. Clear. I clarified this in another mail today, as an example how I think it could work ... > >> It isnt that bad, if you will get reports, that are more standarized. > > There is an IETF working group on Messaging Abuse Reporting Format, I am not > involved in it and not aware of its status, this proposal would not achieve > standardisation. Somebody just posted a link, thnx for that ! Will include that in the next version of the draft, including all valuable feedback I collected so far. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank(a)powerweb.de

1 0

Re: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an
by Michele Neylon :: Blacknight 09 Apr '10

09 Apr '10

On 9 Apr 2010, at 10:02, Frank Gadegast , Dipl-Inform. Frank Gadegast wrote: >> > > Thats up for discussion. > Preferably every incident will generate one mail to be qick as possible. > Surely its also possible to summarizereal outbreaks. OK > >>> >>> 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) >> >> Not everyone has the same business model > > Right, some members seem to make money with abuse ... Again - if you expect there to be ANY dialogue you need to drop that attitude It's offensive and totally unhelpful > >>> 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 >> >> that would be helpful > > Indeed. > >>> - monitoring systems will be developed at all RIRs >> >> Monitoring for what exactly??? > > abuse reports I'm having difficulty understanding this. If a RIPE member has an abuse contact and sets up abuse contact objects for every allocation, why do you need anything else? >> >> >> And again you are working under the false assumption that ALL RIPE members offer the same services as you do and in the same way. > > So we are even not clear that abuse is kind of "evil" and should be acceptable > because its the business of the member ? > > We should close this list, if we could not even have the same oppinion here. > > But feel free to explain these "business models" to me ... Again - drop the attitude You have to understand that not every RIPE member offers the same services or has the same resources at their disposal etc., > >>> "Bad providers" could be even published by RIPE :o) >> >> >> Are you insane? RIPE cannot open itself up for that kind of liability > > Why not, blacklists are doing the same, whats the difference ? Ask a lawyer. > >>> Well, thats only work at RIPE NCC, its not that complicated to >>> automated bounces ... >> >> So you say .. > > Yes, its quite easy. No it isn't. Either: - learn how to discuss this with other RIPE members or keep on with your stupid attitude and see how far it gets you > >> You cannot speak for all providers / RIPE members. > > Thats one of the reasons for a centralized system located at RIPE. > The system only needs to be implemented once, there will be nearly > no costs on the members side (except that they have > to deal with report, but they can still ignore them and except > the costs that might be added to RIPEs fees, but that should not be that > much. You do not know that. You have no way of knowing how much of a load would be placed on RIPE's systems > >> You are also suggesting putting a very heavy load on RIPE's systems which someone will have to pay for. Who? > > The member. > Simply add the costs to RIPE general costs and shared the along the members > with the current mechanism, small member pay less, big one more. > >>>> 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 ? >> >> So you expect RIPE members to completely rework their abuse desks to fit into your view of the world? > > Not MY VIEW, a standarized view. You're not a very good listener, are you? > Thats the goal. > > Lets see it this way: providers have to change their infrastructure > regulary for a couple or reasons and always have done. > Serverhousing changed pretty much during the last years. > There was the change from ISDN to DSL dialin, there are new > technologies for HTML, Flash and Mail every day. > > And do not forget IPv6, EVERY member has to change that in the new future. > >> I can't see that happening, because not all RIPE members are the same or work in the same way. > > Well they work on the same basics, what are allocations and other resources. > Resources cause traffic, and every members uses resources like nameservices, > webpages and email. And spam problem comes into play with the later. > > The difference isnt that big. > Business models have nothing to do with how to deal with resources the got from RIPE. Yes it does If you think that you can live in a world where business models have zero impact on reality then you are deluded > > > Kind regards, Frank > >> >> >> Mr Michele Neylon >> Blacknight Solutions >> Hosting & Colocation, Brand Protection >> ICANN Accredited Registrar >> http://www.blacknight.com/ >> http://blog.blacknight.com/ >> http://mneylon.tel >> Intl. +353 (0) 59 9183072 >> US: 213-233-1612 >> UK: 0844 484 9361 >> Locall: 1850 929 929 >> Twitter: http://twitter.com/mneylon >> ------------------------------- >> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty >> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >> >> > Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

3 3

Re: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
by Frank Gadegast 09 Apr '10

09 Apr '10

James Davis wrote: Hello, >> 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. > > This already happens. Our contact details are published in a clear and > unambiguous fashion, in all the places that you'd expect. Automated spam > reporting schemes appear to have no problems contacting us. This is > because as a network operator we have chosen to deal with these issues, > not because we're told to. Sorry but this is not true for all members. Most newer or smaller ISPs are pretty puzzled, when they have their first real outbreak, and even ask us for advise and help to fix their holes and others do not subscribe lists, that could give them up-to-date warnings or get enough reports, if its only a smaller problem. At least, this is our experience here with our own blacklist. >> 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) > > Not all ISPs can operate like that. Every one of our customers would > rather we offered them help and advice on how to deal with the problem > rather than taking automated action. That is why we have a CSIRT/abuse > team.p Good for you, impossible for big ISPs that have no real contact to their customers. Cutting the line is a hard method, right, but for some ISPs the only methods to get attention immediatelly. But again: its up for the member what to do with the reports ... And Im not saying, that the system would fit everybody needs, but I defny think that it would be better than the current state. >> 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 ? > > An incident would likely be opened in our ticketing system before that > ten minutes were up, and someone would be on the phone to our customer > shortly afterwards. We deal with every complaint of spam, even if it's > just a single report, although the response is proportionate to the > particular incident. Great, you are part of a very small club ;o) > Like I said, you'd have to think really carefully about how you'd > measure what a "bad provider" was, or you risk not only wasting your > efforts but making a lot of people angry. Sure, so that why limits have to very high and these kind of limits are up for discussion on this list. But making analysis like this public should not be the first step for the system at all, it might be a future option, if things are settled, everybody got used to the new system aso ... > We get questions like this a lot from our customers - asking us how they > rank abuse wise compared to other customers and honestly there isn't an > easy way to measure this. Ok, got it ... > The proposal, whether I agree with it or not, needs a concrete answer > for how you would measure a 'bad provider'. I dont think so, because the first intention of the system is not how to define a "bad provider", it only talkes about how RIPE staff could talk to those providers. If I would implement limits, I would messure rates according to the size of the member allocations first and monitor these rates to see whats currently normal for a member. And if those rates are much higher than compared to others, I would ask the member to try to do something against that or to explain it, then slowly adjusting the allowed rates up or down again. Finally, after a long period, I would tell all members, that its time to drop the rates, if they are rising over their allowed limit or not really dropping over a long period, THEN, and only then I would call them a "bad provider", because they are obviously not capable or willing to do anything ... But thats a big step for the future. The first step should be a backlink system, to ensure that reports are read and categorized (ok, "really bad provider" will propably program something arround that backlink system to bypass it, I heared even about people that are bypassing captcha codes already with OCR-software). >> Well, thats only work at RIPE NCC, its not that complicated to >> automated bounces ... > > Say the abuse contact is abuse(a)foo.com and the billing contact is > john.doe(a)foo.com, if the domain foo.com expires then no amount of e-mail > is going to resolve the issue. Someone has to get on the phone and find Clear, but a member without any working email contact ? Is that really possible ? How can you work with new allocations or changes to old one without any working email contact ? > out what's happened. This happens fairly frequently here with only > around a thousand customers. Cant believe it. Does the RIPEs system do not check automatically if (e.g.) allocations messages bounce ? >> Defny right, but lets start with something ... > > Starting is good when you know what direction you're heading in. It's > the other half of the question that people here are more interested in :) Interesting point ... Kind regards, Frank > > 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/ > > iD8DBQFLvvqahZi14NFiKHYRAkpHAJ4s3tiryuoTmY3j8Jivot909exfkgCfYLy3 > Wm34pL98ZdkkHClYthklcEg= > =b+z3 > -----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 > > > -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank(a)powerweb.de

1 0

DRAFT: RIPE proposal - implementation of an abuse monitor system
by Frank Gadegast 09 Apr '10

09 Apr '10

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(a)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(a)powerweb.de Version: 0.1 Date: 08.04.2010

7 7

Re: [anti-abuse-wg] mandatory information in the IRT object
by Frank Gadegast 08 Apr '10

08 Apr '10

> > This functionality is already provided by the irt object, maybe it would be more beneficial to change the policy to require that the irt-object contains valid information. But it seems that there is no majority to make abuse fields (whatever abuse fields) mandatory. And there is still no idea how to validate the supplied email addresses. Thats why I thought that my system is better (and easier, because the member has just one email address to setup instead to take care about hundred objects). Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank(a)powerweb.de > > Bradley >

1 0

update on netsecdb project
by Claus Marxmeier 08 Apr '10

08 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When starting with www.netsecdb.de in 2008 i'd never expected the decrease of spams to round about 1% of former amount to remain a stable value. Stats from last weeks, monthes and year now give proof that the setup of a central communitation matrix based on worldwide IPv4-whois databases was a great help in fighting abusive mails and a lot more. Inspite of common hosting environments the number of spams is generally lower that the amount of mails containing wanted messaging. The hourly auto-generated configuration files for MTAs like postfix, exim, qmail and MS Excchange 2007 and later used on external partner servers show same progresses. In addition, files that contain the blocking lists for leading TOP25 spammer-country are distributed for free. Starting from scratch with a localized german based environment, we opened netranges from additional countries based on the incoming spamlevel. Nowadays, networks from DE, CH, AT, BE, NL, FR, GB, LU, LI, IE, IT, CZ, SE, GR, PT, NO, PL, IS, FI, ES, DK, SK, HU, RO, BG, LT, LV, EE, US, CA, IL and defined customer nets don't get blocked but get tickets instead. If a non-customers's netrange abuse-email is invalid/non-functional, range gets blocked. Many providers integrated ticket-systems for abuse-handling and improved their quality management a lot. Only a few remained passive and surprisingly a handful of ISPs still seem to work with quota limited mailboxes to avoid a kind of work-overload. Logfiles show an increasing number of HEADER connects to our smtp-ports just to check the current status of single IP or netrange returned by our servers. Within the last monthes, netsol worked on rwhois integration into ARIN whois outputs which finetuned the process of generating abuse-tickets a lot. Many RIPE members started updating their whois records and abuse-mail contacts. Sometimes this results in an very effective workflow with only a few seconds response time over far distance whereas local providers still cannot be reached cause of invalid or missing contact records. Unfortunately the RIPE team stated by mail, that they have no job-order to take care of the integrity of it's database records i.e. finding ancient content with missing or invalid information gives random results. There seems to be no need for a RIPE member to keep it's records up-2-date ? Any additional information regardings spams, exploit attacks, hacking can be taken from www.netsecdb.de site's sections. I wonder how long hosters are willing to pay the traffic, energy and CPU-time for something nobody needs to have. I wonder how long i takes for the DialUp- and Business Customers to learn, that security is a crucial part of internet activities and that their ISP's deliver very diffent qualities behind their mostly coloured flash-animated websites. Looking forward to see the current unsolved problems beeing transported to public clouds in datacenter and poisoned high bandwith customer connections if everything remains 'same procedure as every year' ... Kind regards, Claus - -- Claus Marxmeier - --- Claus Marxmeier EDV-Service Johann-Kierspel-Straße 5 51491 Overath Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku6h3oACgkQUIsBFYVeBxC82gCfReNpv+rLKbb2n9vRxwoizCv+ 0UAAn18QA/Y6irneBZyvcty9NGiKDHgq =MuBy -----END PGP SIGNATURE-----

9 11

DRAFT: RIPE proposal - implementation of an abuse monitor system
by Frank Gadegast 08 Apr '10

08 Apr '10

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(a)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(a)powerweb.de Version: 0.1 Date: 08.04.2010

2 1

RE: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse monitor system
by Thor Kottelin 08 Apr '10

08 Apr '10

> -----Original Message----- > From: anti-abuse-wg-admin(a)ripe.net [mailto:anti-abuse-wg- > admin(a)ripe.net] On Behalf Of Bradley Freeman > Sent: Thursday, April 08, 2010 4:45 PM > To: 'Frank Gadegast'; anti-abuse-wg(a)ripe.net > 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? It is not always obvious which abuse@ domain should be selected for a particular IP address. I like the suggestion of routing reports according to the IP address of the abuse source. -- Thor Kottelin http://www.anta.net/

1 0

Re: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse monitor system
by Frank Gadegast 08 Apr '10

08 Apr '10

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(a)ripe.net [mailto:anti-abuse-wg- >> admin(a)ripe.net] On Behalf Of Frank Gadegast >> Sent: 08 April 2010 14:30 >> To: anti-abuse-wg(a)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(a)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(a)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@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank(a)powerweb.de

1 0

RIPE 60 - Draft Agenda
by Brian Nisbet 08 Apr '10

08 Apr '10

As promised, we have a draft agenda for the meeting in Prague. I wish to emphasise the draft nature of this agenda at present, I have no doubt it will change over the next four weeks. http://www.ripe.net/ripe/meetings/ripe-60/agendas/anti-abuse.html Anti-Abuse Working Group Agenda - RIPE 60 Location: - Bohemia I Date: Thursday, 6 May 2010, 16:00-17:30 Anti-Abuse Working Group Home Page A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 59 * Finalise agenda B Update * B1. Network Abuse Update - Richard Cox * B2. Recent List Discussion - Abuse contacts, Sanctions, etc. C. Technical Measures * C1. RIPE NCC Tools update. D. Interactions * D1. Working Groups * D2. Law Enforcement Interaction - Wout de Natris, LAP * D3. RIPE NCC Gov/LEA Interactions Update E. Documents * E1. BCP Documentation X. A.O.B. Z. Agenda for RIPE 61; Plenary Presentations

1 0