December 2015 - anti-abuse-wg

Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
by Suresh Ramasubramanian 20 Jun '16

20 Jun '16

I knew the time was, well, ripe for something like this to pop up directly after rfg started asking those questions yesterday. ---------- Forwarded message --------- From: Ronald F. Guilmette <rfg(a)tristatelogic.com> Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: <nanog(a)nanog.org> I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20

6 8

RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
by Tim Bruijnzeels 19 Feb '16

19 Feb '16

Dear working groups, As you know all organisations that have internet number resources allocated or assigned by the RIPE NCC need to have an abuse-c attribute according to policy 2011-06. The following implementation plan was communicated for this policy: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… Phase 1 of this plan was completed in December 2013, setting up abuse-c for then existing LIRs. Phase 2 of this plan was completed for organisations holding sponsored PI resources in November 2014. However, since then LIRs and end-users have been responsible for ensuring that an abuse-c exists for their organisation. In practice it has proven difficult to enforce this, since abuse-c is not a mandatory attribute in the RIPE DB schema, and as a result new cases where organisations do not have an abuse contact have been created. There is an important change in the implementation we would like to do – based on our experiences thus far – which would like the community's mandate on. We propose to use the end-user organisation's email address instead of the sponsoring LIR email address. We believe there are valid reasons for this change, but of course if this suggested change is controversial we would encourage discussing it in the anti-abuse working group. Ideally, we need to have a decision on this by early January so that we can prepare the work. 1) Prevent NEW cases We want to ensure that no new cases will be created as follows: = Since 1 March, the new member application form already provides much better integration with the RIPE Database - because of this an abuse contact is now created whenever a new LIR is activated - it can be modified the LIR, e.g. using web-updates, but not removed = We are currently adapting the new create organisation webupdates form to include abuse-c by default allowing the user to: - reference an existing abuse-c role object, or - enter an email address to create an abuse-c role for the organisation (using the same maintainer) = We are also adapting the edit organisation webupdates form to always suggest adding an abuse-c contact if it's not present = We plan to extend the new request forms: - check that an end-user organisation has abuse-c before it can be used - if not, refer to the edit form for the organisation where it will be easy to add reference an existing abuse contact, or create a new object 2) Resolve remaining EXISTING cases Originally the idea for phase 2 was to use the sponsoring LIR's email address in case the end-user organisation was unresponsive to requests to set their own abuse contact. However, since then policy 2012-08 has been implemented and nowadays the sponsoring LIR, and its abuse contact, can be found through the sponsoring-org attribute. Also, the RIPE NCC found that using the sponsoring organisation's email address leads to a number of issues: - end-users have no incentive to set their own abuse-c, rather then letting abuse questions go to their sponsor, so the majority remains unresponsive - in case an end-user has resources from more than one sponsor it is ambiguous which sponsor's email should be used - many LIRs were unpleasantly surprised by finding their email address in the abuse-c of the organisation they sponsor - in case LIRs no longer wish to sponsor resources, or when they are returned, existing references to their email in the end-user abuse-c are not cleaned up We would therefore like to propose a change to the implementation plan when addressing the remaining cases. Today, in case no abuse contact is set, users of the database will resort to using the organisation's default email. Therefore, adding a dedicated abuse-c role object using this email address, doesn't cause any noticeable new effects on organisations. It may well be the correct email address to use for an organisation, and no action would be required. However, it *enables* an organisation to use a different email address for abuse questions if appropriate. We would like to email remaining LIRs, and end-user organisations and sponsoring LIRs on Monday 1 February, giving them until Monday 15 February to set their abuse contact. We realise that this means we would have another delay, but we believe that it would be unwise to do this change over the end of year holiday period, and to ensure that we can give proper support to questions we want to avoid doing this at the same time as the start of the year invoicing. Please let us know what you think. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 20

Draft Minutes: AA-WG Session at RIPE 71
by Brian Nisbet 04 Jan '16

04 Jan '16

Colleagues, Here are the draft minutes for the AA-WG session at RIPE71. If you would like anything to be removed, corrected or added, please let me know. In the meantime I would like to wish you all a very Merry Christmas or other happy and joyous sentiments as appropriate. I look forward to working with you in the 2016! Brian Co-Chair, RIPE AA-WG Anti-Abuse Working Group Draft Agenda Thursday, 19 November 11:00 - 12:30 A. Administrative Matters [5 min] • Welcome • Scribe, Jabber, Stenography • Microphone Etiquette • Approve Minutes from RIPE 70 • Finalise Agenda B. Update [15 min] • B1. AA-WG Chair Matters Tobias was accepted to continue as co-chair. • B2. Recent List Discussion - Foreign/Undelegated Route Objects (see section C) - no comments - Data Verification & abuse-c contact methods - no comments - LIR Contract Discussions - no comments - Brian has asked the RIPE NCC for more info on the claims that RIPE NCC is party to End User contracts. - Sources of Abuse Contact Info Document - no comments  C. Policies [0 min] - Foreign objects in the RIPE DB - Brian encouraged the group to participate in the discussions taking place in the Database Working Group (DB-WG). D. Interactions [20 min] • D0. Richard Leaning (RIPE NCC) will work on extending Law Enforcement engagement • D1. Update on RIPE NCC Security Outreach Activities - Mirjam Kühne https://ripe71.ripe.net/presentations/5-SecurityUpdate4RIPE71.pdf   Sean Turner (IECA) asked whether the work between ICANN and the RIRs on IP and Whois accuracy and due diligence public safety has started yet, as per the ICANN meeting minutes. Marco Hogewoning (RIPE NCC) confirmed that RIPE NCC is involved with the PS WG. Hans Petter Holen (RIPE Chair) added that lots of suggestions from ICANN meetings come up from misunderstanding existing processes. He suggested that they believe we have more problems with Whois accuracy than they do with domain names - he thinks it’s the opposite. Marco confirmed that the RIRs continue to educate where needed. Mirjam Kühne (RIPE NCC) added that the RIPE NCC is educating and engaging on how to use our tools. Brian Nisbet (AA-WG Chair) commented that the MAAWG meeting was surprisingly good and that there was a positive reaction to the presentation and the openness of the RIPE Community - the relationship continues. Mirjam reiterated that there is a continued need for more collaboration between the two communities. Peter Koch (DENIC) commented that openness can be a barrier to collaboration. Marco d’Itri (Seeweb) reminded the group of the open invitation from MAAWG to RIPE community members to participate. Mirjam rounded off by adding that if RIPE NCC can help to bridge any divide, it is happy to and will continue to. E. Presentation [45 min] • E1. Open Source Abuse Management for Network Operators - Abuse.io (Erik Bais)  https://ripe71.ripe.net/presentations/130-AbuseIO-4.0-RIPE71-AAWG-v1.pdf (Bart Vrancken is on IRC to answer additional questions) Marco D’Itri asked whether the system process ARF and legacy feedback group. Erik confirmed that they do include Spamhaus reports and ARF as well. You can also write your own parsers. Bengt Gorden (Resilans) asked whether it was easy to get your own customer database included? Erik confirmed that they did it manually, but there is an option to do lookups in your own administrative environment. Bart Vrancken (via IRC) confirmed that there is built-in support and 4.0 support for PHP. Erik encouraged everyone to look at the website, join IRC and chat with Bart. • E2. The Traffic Amplifiers Great Hunt - ANSSI (Florian Maury)  https://ripe71.ripe.net/presentations/65-ripe71_antiabusewg_anssi_the_traff… Steve Nash (Arbor Networks) added that another thing people can do is to elevate management visibility so that the money becomes available. Erik Bais (A2B Internet) asked whether the info from the scans has been made available? Florian clarified that they haven’t performed any scans. They used open data, which is already available publicly. • E3. Helping Network Operators to Bring Down DDoS Sources - ANSSI (Markus de Brün) https://ripe71.ripe.net/presentations/72-DDoS_Open_Services_Cleanup_Germany… Brian asked whether there is any feeling for when ANSSI would no longer consider this to be a problem worth worrying about? Do you ever expect it to reduce to zero? Markus explained that the goal is to get as far down as possible and that this will take a long time. Florian Maury confirmed that indeed this would be difficult, but reducing the number of available nodes is a short-term action that can be taken now. But also longer term actions (such as working on anti-spoofing technologies and updating the protocols being used for these attacks) can be useful too. Marco Hogewoning asked what triggered the ISPs into action? Was it the outreach or incidents happening? Markus shared that early on, due to repeated communication, ISPs that were not aware of the situation took action. Mohsen Souissi (AFNIC) asked whether DNS over DNS will ever become a full replacement? Florian suspects that it won’t solve the problem but having DNS over TCP will probably help. Will van Gulik (IP-Max SA) indicated that receiving reports from other countries (e.g. France) would be really appreciated. Markus advised that they only have data for Germany, but perhaps his French colleagues would start an action like this. Florian explained that their data came from worldwide scans, so if you provide the prefixes you are interested in we can share. Brian reminded the room that the Internet has no borders. Chris Baker added that the shadow serve foundation is available to give reports without country restrictions. X. A.O.B. Brian mentioned that there is still time to submit a lightning talk for tomorrow’s session. Z. Agenda for RIPE 72

2 3