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

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

Abuse-C attributes - required e-mail address contact method.
by Gist, Jonathan 20 Apr '15

20 Apr '15

Hello, The RIPE policy around the abuse-c attribute requires the presence of an e-mail address, which is asked to be used by subscribers wishing to report abuse incidents. This contact method is resource intensive and Virgin Media would like to propose a change to the policy to remove the requirement for an e-mail address contact field. Virgin Media would like to specify virginmedia.com/netreport (a web-form that feeds an abuse case management system) in the abuse attribute to ensure that we are able to properly manage and prioritise abuse complaints. If we have the web-form listed as the abuse contact we are able to maximise appropriate abuse handling measures to prevent misuse of our network and thereby ensure an optimum experience for all complainants. Is this a view that is help by others? Thanks & regards Jonathan Gist Jonathan Gist | Engineering Support & IP Address Management Virgin Media | Fountain Court, St Mellons, Cardiff, CF3 0FB M 07866 722641 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privileged and are sent solely for the attention of the addressee(s). If you have received this email in error, please delete it from your system: its use, disclosure or copying is unauthorised. Statements and opinions expressed in this email may not represent those of Virgin Media. Any representations or commitments in this email are subject to contract. Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire, RG27 9UP Registered in England and Wales with number 2591237

12 12

Meeting with Law Enforcement Agencies (LEAs)
by Marco Hogewoning 23 Mar '15

23 Mar '15

Dear Colleagues, We recently held our seventh meeting for Law Enforcement Agencies (LEAs), in partnership with the British National Crime Agency (NCA) and the other RIRs. Held on 12 March 2015, the purpose of this meeting was to discuss trends and developments that might impact the operations of LEAs and to gather the global law enforcement community’s perspective. A number of key points arose throughout the day: - The RIPE NCC highlighted that much of the information that LEAs required was publicly available and did not require a Dutch court order - Attendees agreed that the current multi-stakeholder model of Internet governance was preferable, but felt that LEAs and governments needed to engage more effectively within the existing structures - The relatively slow adoption of IPv6 and the spread of IP address sharing technologies such as Carrier Grade NAT will increasingly create issues around identifying specific end users - LEAs felt that cooperation with the private sector is extremely important and could improve greatly, but it was also understood that this came with additional costs In response to feedback from the RIPE community, a more detailed report of this meeting has been prepared and is available here: https://www.ripe.net/ripe/meetings/lea-meetings/ripe-ncc-law-enforcement-me… We would like to thank the NCA for its help in putting together this day and are looking forward to continue our engagement with the global law enforcement community. We are happy to answer any questions you may have about this meeting or our LEA engagement activities in general. Regards, Marco Hogewoning External Relations Officer - Technical Advisor RIPE NCC

4 4

New on RIPE Labs: Inferring DDoS Attacks from Darknet Space
by Mirjam Kuehne 20 Mar '15

20 Mar '15

Dear colleagues, Please see this new article on RIPE Labs by Claude Fachkha: This work proposes a novel approach to infer and characterise Internet-scale DNS Distributed Reflection Denial of Service (DRDoS) attacks by leveraging the darknet space. The aim of this work is to extract useful information related to DRDoS activities such as intensity, rate and geo-location in addition to various network-layer and flow-based insights. https://labs.ripe.net/Members/claude_fachkha/inferring-distributed-reflecti… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Introduction and the AbuseIO project
by Bart Vrancken 18 Mar '15

18 Mar '15

Hello AA-WG peoples, I am new to this workgroup so let me start by introducing myself: I am Bart Vrancken, Engineer at a Dutch ISP BIT. Next to the normal day-day work i handle most of the abuse sent by notifiers. For a while now i am also part at the Abuse-NL workgroup. On IRC i can be found under the names CrossWire or Kruisdraad. Outside office hours (who can call it spare time these days ...) i spent my time with my two daughters and volunteer with the dutch 'coastguard' service. Since 2009 i have been working on a tool to manage the abuse flow, and recently started the Open Source AbuseIO (https://abuse.io) project so anyone could benefit from it. For the ISP/Hosters that still manually process their abuse it might be interesting to have a look at it ;) I'll be at the RIPE-70 meeting to shake some hands ;) -- Met vriendelijke groet, Bart Vrancken, Engineer BIT BV | bart(a)bit.nl | +31 318 648688 Kvk: 09090351 | CROS-RIPE | GPG 3A99BD6E

2 1

Re: [anti-abuse-wg] Abuse-C attributes - required e-mail address contact method.
by Ronald F. Guilmette 17 Mar '15

17 Mar '15

My two cents... The person/company who proposed this proposal used the word "complainant" to refer to someone (anyone) attempting to report a case of network abuse to its source network administrators. Personally, speaking only for myself, I object to being called a "complainant" or a "complainer", e.g. when I attempt to do the decent thing and take up _my_ valuable time to notify responsible (?) network administrators about something I feel that they themselves may want to know about, and indeed should want to know about. Of course, the Powers That Be at many networks ... the bean counters and the higher level managers... often view _any_ communication with any party other than a paying customer as a waste of time and money, and thus, the personel underneath these folks inevitably come to develop an "us versus them" attitude which leads inevitably to viewing reports generated by outsiders, aka non-paying customers, as "complaints" and the senders as "complainers" whose only (or primary) goal is to cost the receiving company time and money, rather than the opposite, i.e. attempting to _help_ the receiving company. I would argue that it is this bean counter attitute that has itself given rise to most of the abuse on the Internet, i.e. in the time since the broad commercialization of the net in the mid 1990's. If you view receiving, understanding, and acting upon notifications of bad behavior occuring on your network as nothing other than a non-profit-generating cost sink, then you are entirely less likely to ever actually *do* anything about such reports. And when you don't, the word goes out among the bad guy communities on the Internet, and your network ends up being the source of ever more network abuse. This is just the (Darwinian) way things are. Opportunistic leeches abound. If given safe homes, they and their activities proliferate. I generally expend a good deal of time and effort writing up any abuse report I send. (Note that I say "report" not "complaint".) There are plenty of ways that various networks have dreamed up to avoid reading these "complaints", i.e. because they don't immediately or obviously generate any instantaneous revenue or profits for the receipient networks. The simplest method to avoid spending any non-profit-generating company man hours on reading abuse reports is just to alias abuse@network to /dev/null. If Virgin feels that reading incoming e-mail reports is not worth their time, then I respectfully suggest that they simply enter devnull(a)example.com into the abuse contact e-mail address fields for all of their relevant RIPE database records. This will be maximally efficient for all concerned. (There really is no more efficient way for Virgin to process all of their incoming "complaints". And since they _are_ clearly concerned about the efficiency of this process, that would seem to be ttheir best solution.) Regards, rfg

3 3

Re: [anti-abuse-wg] Abuse-C attributes - required e-mail address contact method.
by Thorsten 14 Mar '15

14 Mar '15

> Am 14.03.2015 um 07:35 schrieb andre(a)ox.co.za: > > On Fri, 13 Mar 2015 17:03:25 +0100 > Gert Doering <gert(a)space.net> wrote: >> On Fri, Mar 13, 2015 at 03:18:17PM +0000, Gist, Jonathan wrote: >>> The RIPE policy around the abuse-c attribute requires the presence >>> of an e-mail address, which is asked to be used by subscribers >>> wishing to report abuse incidents. This contact method is resource >>> intensive and Virgin Media would like to propose a change to the >>> policy to remove the requirement for an e-mail address contact >>> field. >>> Virgin Media would like to specify virginmedia.com/netreport (a >>> web-form that feeds an abuse case management system) I would support an *additional field* for „abuse-webform“ in the abuse-c attributes, to ensure that *manual reports* contain everything what is needed for an ISP to act on, beside the "abuse-mailbox“ for automated (e.g. X-ARF complaints). But not in the fashion that it is getting the „single point of contact“. >> I would not support such a change, at least not without a *well >> defined* format for such web forms. For companies like us, reporting out thousands of abuse-reports (phishing sites, malware complaints, etc.) per day, webforms are making it impossible to report abuse. >> On the reporting side of abuse, it is just way too much work to >> figure out how particular ISPs expect to receive abuse reports, >> offloading half the work of abuse handling to the reporter. >> (I report quite a lot of abuse, but I refuse to do anything but >> e-mail, because it is just too much work for me - it's your >> customers, they are giving *you* money, their abuse should not cost >> *me* extra time). Exactly! Rgds, Thorsten

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 41, Issue 2
by Karl-Josef Ziegler 13 Mar '15

13 Mar '15

> Virgin Media would like to specify virginmedia.com/netreport (a > web-form that feeds an abuse case management system) in the abuse > attribute to ensure that we are able to properly manage and > prioritise abuse complaints. If we have the web-form listed as the > abuse contact we are able to maximise appropriate abuse handling > measures to prevent misuse of our network and thereby ensure an > optimum experience for all complainants. I also don't support this proposal because filling (maybe also a different form for each ISP) webforms correctly is a tedious work and only transfers parts of the workload from abuse desk to the reporter. But the reporter is not responsible for the abuse; responsibility lies with the ISP so the workload must be done there. Best regards, - Karl-Josef Ziegler

1 0

Draft AA WG Minutes - RIPE 69
by Brian Nisbet 04 Mar '15

04 Mar '15

Colleagues, Here are the draft minutes from the AA-WG meeting at RIPE69. Could you please take a look and come back to me with any corrections on your part? Thanks, Brian --------- Anti-Abuse Working Group Draft Minutes - RIPE 69 Date: 5 November 2015, 14:00-15:30 Working Group Co-Chairs: Brian Nisbet, Tobias Knecht Scribe: Marco Hogewoning Status: Draft Brian Nisbet, WG co-chair, welcomed the attendees and apologised on behalf of Tobias Knecht who due to illness could not attend the session. A. Administrative Matters Brian apologised for the minutes of RIPE 68 being sent out late and asked the audience if there where any comments or additions. Alexander Isavin, NetLine, mentioned that the section on law enforcement agencies is missing from the minutes. Brian says he remembers the discussion and will look into the matter. He asked the working group to approve the session's agenda, which they did without further comments. B. Update - Brian Nisbet, AA Working Group Co-Chair Brian mentioned the charter was discussed in Warsaw and some follow up discussion took place in June. The new charter has been published on the website and Brian closed this action point. Brian introduced the procedure to select working group chairs and gave the working group some background on why this is needed. A draft text was sent to the mailing list and a version with some minor changes in wording was published on Tuesday evening. Brian highlighted the main elements of the proposal that the chairs will have a term, there will be no limit on the number of terms and each term will last for three years. There will be two or a maximum of three chairs for the working group and the decision on who will become chair preferably is made by consensus or alternatively by a secret ballot. Brian asked if there were any further comments and deferred the discussion back to the mailing list to come to a conclusion about this topic Sander Steffann raised his thumb. Brian pointed to a discussion the mailing list about AS Numbers and said that due to the recent number of emails he was not able to catch up.He suggested to leave the discussion on the mailing list as more people are likely to be behind on this topic. Brain mentioned that the RIPE NCC was already looking into some of the questions raised in the list and was expected to reply. He clarified the discussion has to do with the credentials supplied when an AS Number is requested and any allocations that have been revoked. C. Policies Brian mentioned that due to Tobias' illness they haven’t looked into the issue and mentioned that a conference call with the RIPE NCC has been planned in December to talk about this. D2: RIPE NCC anti-abuse outreach activities Mirjam Keuhne and Ivo Dijkhuis from the RIPE NCC presented about their outreach activity. A copy of the presentation is available at https://ripe69.ripe.net/presentations/116-SecurityUpdate4RIPE69.pdf Brian reminded Mirjam about an open action point for the RIPE NCC from Warsaw to send some more information to the list, which hadn’t happened yet. D3. RIPE NCC Governemnt/LEA Interactions Update Marco Hogewoning, RIPE NCC, gave a short update on the interactions with law enforcement and governments. An archived copy of Marco’s presentation is available at https://ripe69.ripe.net/archives/video/10140/ Coming back to Alexander Isavin’s earlier question about the minutes, Marco mentioned there is an open action point to provide more information about the LEA meetings. As there haven’t been any LEA meetings yet, this information was not published. Heather Schiller, ARIN, asked if the RIPE NCC published a report about the number of LEA enquiries they receive. Marco mentioned the RIPE NCC in 2012 and 2013 published a transparency report which is available on the website. Ruediger Volk, Deutsche Telekom, pointed out that the report does not list the level of access given to law enforcement agencies. Marco explains the information contained in the report and said that it not only provides the number of enquiries but also gives some information on where the are coming from and provides an overview of the nature and reason of declined requests. E2. Tor censorship countermeasures and how you can help Jurre van Bergen, Greenhost, presented about countermeasures to Tor censorship. A copy of the presentation is available at https://ripe69.ripe.net/presentations/112-tor-ripe69.pdf Erik Bais, A2B Networks, asked if he understood correctly that Jurre had set up a foundation for this and what kind of work was involved in running an exit node. Jurre clarified that the foundation was set up to maintain a dialogue with the law enforcement community and to actively assist them with warrants and subpoenas. He said they are happy to provide operators with training and help them to set up and suggested to take the discussion private. Brian Nisbet mentioned that research networks have two issues with running tor exit nodes. One being the acceptable use policy prohibiting ^a third party from using these networks for this purpose. The other being that the misconceptions about the Tor project might lead to questions from the governments who fund the research network. Jurre pointed out that majority of funding for the Tor project comes from governments. He explained they are using an IP block from a Dutch research institute, but as it was re-purposed they are not really using the research network. Sacha van Geffen, Greenhost, asked if the foundation was busy creating and publishing any best current practices. Jurre answered this is done and gave an example on controlling which ports can be used on a Tor exit node to limit certain services. Brian suggested to Jurre to share some of this information with the mailing list, especially the ones on abuse policy as they relate to the working group. E1. Impact of rom-0 vulnerability in SOHO routers Tomas Hlavacek, NIC.CZ, presented on the ROM vulnerability in routers, an archived copy of his presentation is available at https://ripe69.ripe.net/presentations/61-rom0-vuln.pdf Erik Bais, A2B Internet, asked if the holders of the IP addresses found in the research were notified about the issue. Tomas explained this was not done because people were not interested and the team chose to use mass media to create awareness. Erik suggested to have a chat about this as he had experience with cleaning up botnets and mailing owners might help. Elvis Valea, V4Escrow, asked if there was a list with vulnerable modems available. Tomas answered it is usually the cheaper brands but they would not disclose names as the manufacturers don’t like that. Elvis asked Tomas if they scanned the whole Internet. Tomas confirmed. Heather Schiller, Google, mentioned there are other groups looking into CPE vulnerabilities and it might help to share the data with them. Bruce van Nice, Nominum, asked if any work was done in profiling the resolvers to see which sites were abused. Tomas answered they found one doing Google and Facebook phishing. Marco Hogewoning, RIPE NCC, asked how many abuse reports came in after scanning the entire Internet. Tomas said he received three complaints. E3. DDoS as a service Jair Santanna, Universiteit Twente, presented on Booters: the DDoS as a Service phenomenon. An archived copy of his presentation can be found at https://ripe69.ripe.net/presentations/115-20141105_RIPE69_jjsantanna.pdf A member of the audience mentioned they did some investigation to Booters themselves and find out these often use commercial anti-DDoS protection services as Booters sites tend to attack themselves. He suggested to work with these companies to take the front-end offline. Jair said it is hard to find the evidence, but when they do these sites get taken offline by their providers. X. AOB Brian asked for any other business. Erik Bais mentioned he had noticed that after an IP transfer abuse reports get sent to the old IP address holder and that is a clear indication that people are not using the RIR whois databases and fail to update their own information in time. He said it also takes quite an effort to de-list transferred resources with blacklist operators. Brian asked for suggestions on how the working group can help to improve this. Erik responded that more information about transfers to the abuse community could help and offers to explain how a transfer is actually done. Another suggestion is to make it easier to prove a transfer is legitimate. Ruediger Volk suggested looking into the data flow from the RIPE NCC who administers the transfers to the parties who collect and distribute anti-abuse information. Elvis Valea mentions that they observed BGP hijacks taking place in the brief period a transfer takes place and the RIPE Database objects get deleted. Brian responded that they haven’t discussed BGP hijacks but this is worth looking into as it might require a policy change or change the way transfers are done. Brian Nisbet thanked the attendees for their participation and closed the session.

1 0