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

Hijacked netblocks - any SOP for these?
by Suresh Ramasubramanian 09 Aug '11

09 Aug '11

Freshly added to spamhaus - SBL114471 83.223.224.0/19 RIPE 28-Jul 02:24 GMT zombies : hijkacked ip block / spam ip block SBL114472 94.250.128.0/18 RIPE 28-Jul 02:24 GMT zombies : hijacked IP block / spammer IP block SBL114473 46.96.0.0/16 RIPE 28-Jul 02:22 GMT zombies : hijacked IP block / spammer IP block SBL114470 188.164.0.0/16 RIPE 28-Jul 02:21 GMT zombies : hijacked ip block / spammer ip block -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

13 30

RIPE NCC Procedure Regarding LIR Information in the RIPE Database
by Athina Fragkouli 08 Aug '11

08 Aug '11

Dear Pierre, all, In response to your emails, here is some general information on this matter. The RIPE NCC requests that the LIRs provide the RIPE NCC with truthful information, as well as correctly maintain their registration in the RIPE Database at all times. If an LIR fails to do so, the RIPE NCC will terminate the service agreement with this LIR and deregister the Internet number resources allocated to it. More information about this procedure can be found in the RIPE NCC procedural document "Closure of LIR and Deregistration of Internet Number Resources", available at: https://www.ripe.net/ripe/docs/ripe-517 The RIPE NCC handles abuse complaints sent by third parties. Anyone can send a complaint to abuse(a)ripe.net. As well as the procedures already in place, the RIPE community recently formed the Abuse Contact Management Task Force (ACM-TF), which is examining policy proposals around the issue of managing the abuse contact field in the RIPE Database. More information about the task force can be found at: https://www.ripe.net/ripe/groups/tf/abuse-contact Hope this clarifies the existing procedures, if you have any further questions, please do not hesitate to contact us. Kind regards, Athina Fragkouli RIPE NCC

9 21

Re: [anti-abuse-wg] RIPE NCC Procedure Regarding LIR Information in the RIPE Database
by Athina Fragkouli 28 Jul '11

28 Jul '11

Dear all, Thank you very much for your feedback. Regarding the abuse(a)ripe.net <mailto:abuse@ripe.net> auto-reply: ---------------------------------------- The RIPE NCC provides the abuse(a)ripe.net <mailto:abuse@ripe.net> email address for third parties to direct abuse complaints to. The abuse complaints that we receive are usually not related in any way to any of the RIPE NCC's activities. The auto-reply from the abuse mailbox clarifies: - What the RIPE NCC is responsible for - What kind of abuse complaints cannot be handled by the RIPE NCC (i.e. complaints related to the use of Internet number resources) - How the RIPE Database can be used to find the appropriate person/organisation to direct the complaint to - How to file a further complaint in case the information provided does not cover the particular situation. The abuse complaints handling procedure is currently being documented and will be published on www.ripe.net <http://www.ripe.net> . Regarding the requested figures: --------------------------------- The RIPE NCC receives a large number of abuse complaints. In the period since the RIPE NCC's procedural document, "Closure of LIR and Deregistration of Internet number resources", became effective on 7 March, 2011, only six out of 140 complaints received were related to the RIPE NCC's responsibilities. These six complaints referred to cases of non-compliance with RIPE policies. From the relevant audits we performed two of these complaints are still under investigation, two of the abuse cases complied with the audit's instructions and two of them did not comply. As a result the RIPE NCC de-registered seven PI assignments, one PA allocation. Kind regards, Athina Fragkouli RIPE NCC

1 0

1St bogus RIPE reggies fact:=>
by abuse＠localhost.com 26 Jul '11

26 Jul '11

Take note! The present is BCC'ed to concerned persons. We first go with the original SPAM. Take note that I still possess the original in a given mailbox. After, below that spam datas will come the "Questions", Ok?... ========================================== Received: from simonbutcher73(a)aol.com by (64.135.83.95:25) via ims-m14.mx.aol.com (64.12.207.147:58265) with [InBox.Com SMTP Server] id 1107232150020.WH95 for XXXX(a)inbox.com; Sat, 23 Jul 2011 21:50:06 -0800 Received: from oms-db01.r1000.mx.aol.com (oms-db01.r1000.mx.aol.com [205.188.58.1]) by ims-m14.mx.aol.com (8.14.1/8.14.1) with ESMTP id p6O5nQQt023644; Sun, 24 Jul 2011 01:49:26 -0400 Received: from mtaomg-ma03.r1000.mx.aol.com (mtaomg-ma03.r1000.mx.aol.com [172.29.41.10]) by oms-db01.r1000.mx.aol.com (AOL Outbound OMS Interface) with ESMTP id B2A751C000081; Sun, 24 Jul 2011 01:49:26 -0400 (EDT) Received: from core-mua004b.r1000.mail.aol.com (core-mua004.r1000.mail.aol.com [172.29.237.141]) by mtaomg-ma03.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 73A6EE000081; Sun, 24 Jul 2011 01:49:26 -0400 (EDT) To: bradanddebs(a)blueyonder.co.uk, greg(a)hartworks.go-plus.net, fonida(a)tiscali.it, alessandralabate(a)hotmail.com, hugandas(a)hotmail.com, gansklos(a)gmail.com, wyn(a)doke.fsnet.co.uk, lyricals(a)hotmail.com, aholden1(a)blueyonder.co.uk, XXXXX(a)inbox.com Content-Transfer-Encoding: 8bit Subject: X-MB-Message-Source: WebUI X-AOL-IP: 110.55.218.190 X-MB-Message-Type: User MIME-Version: 1.0 From: Simon Heale <simonbutcher73(a)aol.com> Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Webmail 33996-STANDARD Received: from 110.55.218.190 by webmail-m061.sysops.aol.com (64.12.158.161) with HTTP (WebMailUI); Sun, 24 Jul 2011 01:49:26 -0400 Message-Id: <8CE17DC94DC726E-BB8-20321(a)webmail-m061.sysops.aol.com> X-Originating-IP: [110.55.218.190] Date: Sun, 24 Jul 2011 01:49:26 -0400 (EDT) x-aol-global-disposition: S X-SPAM-FLAG:YES X-AOL-SCOLL-SCORE: 0:2:142936448:93952408 X-AOL-SCOLL-URL_COUNT: 0 X-AOL-REROUTE: YES x-aol-sid: 3039ac1d290a4e2bb2662c2a X-Spam-Ratio: 3.41 http://0331c66.netsolhost.com/nopl.php ========================================== Anybody can tell me please what "X-Originating-IP: [110.55.218.190]" means? Could it ever means what I can read on that website:=> http://network-tools.com/default.asp?prog=network&host=110.55.218.190 Quite a "Standard Usual" SPAM emaning from abuse(a)bayan.com.ph who gave a right valid abuse email address! No problem! Next... What was that SPAM advertise about? I'd be curious to know if the SPAM was sent by human being or a trojan? Thus, the SPAM requested me to visit this specific website:=> 0331c66.netsolhost.com/nopl.php for which my browser was redirected toward the website: adurgomas.com... Ok! "Who" are these persons? -adurgomas.com = [95.64.61.92] Romanian netserv.ro & hostingfrenzy.org. Registered at RIPE by Mr."Noreply Mozzart SRL" residing in Bucurest. Let's now have a look how this "RIPE" network behave on the Internet:=> http://www.senderbase.org/senderbase_queries/detailip?search_string=95.64.6… Every IPs are blacklisted for "X" reasons! Ahum! Ok! Let's help the poor guy by advising him that most if not all of his computers are obviously infected by trojans! Mail to : abuse-mailbox:=> noc(a)hostingfrenzy.org as specified by "RIPE" registrations of that network... You know what?... This under:=> -----Original Message----- From: recycle(a)inbox.com Sent: Mon, 25 Jul 2011 08:28:52 +0000 To: XXXXX(a)inbox.com Subject: Error sending message [1107240655006.WM29] from [WM29.inbox.com] Error sending message [1107240655006.WM29] from [WM29.inbox.com]. Mail From: <XXXXXX(a)inbox.com> Rcpt To: <noc(a)hostingfrenzy.org> Repeated: <7> Last Try: <7/25/2011 8:28:31 AM> The reason of the delivery failure was: Can not connect to SMTP server <hostingfrenzy.org>. Here is listed the initial part of the message: Received: from inbox.com (127.0.0.1:25) by inbox.com with [InBox.Com SMTP Server] id <1107240655006.WM29> for <noc(a)hostingfrenzy.org> from <XXXXX(a)inbox.com>; Sun, 24 Jul 2011 06:55:39 -0800 Mime-Version: 1.0 Date: Sun, 24 Jul 2011 06:55:39 -0800 Message-ID: <7E5D5003F8E.00000119XXXXX(a)inbox.com> From: Mail Delivery System <XXXXX(a)inbox.com> Reply-To: abuse(a)localhost.com Subject: AOL trojan Origin = Skyinet.net on redirecting toward romanian (RIPE) customer?:=> To: reportspam(a)networksolutions.com Cc: abuse(a)skyinet.net, ripe(a)netserv.ro, noc(a)hostingfrenzy.org, aa-wg-chairs(a)ripe.net X-Mailer: INBOX.COM X-Originating-IP: 66.158.156.184 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IWM-ACU: REl3BNnDDtYo_Gixnf_X636zN3IcUjM7X2Uq_c5rDLG6_-tGybg_57M_8HqL GIO69kAPSNwT-VbpnNWH3dXO-aLNWa-8bs2_dHluQcZwtHdRl0OrdcPgL81j kSGLDlBA59M-5Y78y Tagalog bersyon ay dito sa ibaba: =3D> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ================================= In conclusion, I repeat my question:=> Is it a fact that anybody can give any false and misleading informations to RIPE about registration of IP# block numbers? Because if RIPE do not have any rule of conduct, that becomes an ideal tool to carry all kind of criminal activities. Second question, does any IP# block number recipient who paid fees ($) to obtain a given block number is authorized to resell subnets (Part of block numbers) to evade his responsibilities toward any RIPE regulations if any does exist in fact? In closing this e-mail, I would like to mention that I have in archive quite a few SPAM for which the given network provided forged & misleading datas to RIPE. What is worst is that RIPE do not appear to have a webpage where such forgeries can be reported. That was that! antispam.report(a)inbox.com ____________________________________________________________ Publish your photos in seconds for FREE TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4

3 3

A simple question about RIPE registrations:=>
by Pierre Tanguay 24 Jul '11

24 Jul '11

When we see that one network who got its IP block numbers through RIPE, and has obviously false and misleading informations and datas such as bogus email addresses, bogus civic address as well as for any other data informations, does RIPE have any regulation concerning the datas that their customers agree upon when give them those infos and datas through any means which includes Internet based emails? Because, if anybody located in the Internet territory mananaged by RIPE may represent a much lower value. In the sense: -What's the interest for RIPE to cumulate and manage false & misleading datas? Second, how many times either per second, per minutes, per days or per month can any RIPE IP# block assigned person or corporate can change his/her datas on RIPE registration? Otherwise said, can it be done "On line"? Thank in advance. Pierre. ____________________________________________________________ Share photos & screenshots in seconds... TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if1 Works in all emails, instant messengers, blogs, forums and social networks.

2 1

Draft Minutes - RIPE 63
by Brian Nisbet 04 Jul '11

04 Jul '11

Colleagues, These are the draft minutes from RIPE 53, apologies for the delay, the lovely folk from the NCC had them a while ago, I was just slow in reviewing them and passing them on. As always, please let me know if you have any comments or corrections: RIPE Anti-Abuse Working Group: Draft Minutes – RIPE 62 Thursday, 4 May 2011 14:00-15:30 Co-Chairs: Brian Nisbet and Tobias Knecht Scribe: Fergal Cunningham Chat Monitor: Sandra Brás A. Administrative Matters –Welcome Working Group co-Chair Brian Nisbet welcomed attendees. He thanked the scribe, chat monitor and stenographer, and he asked that those asking questions clearly state their name and affiliation. –Approve Minutes from RIPE 61 Brian noted that there were some initial comments and the minutes were updated accordingly. He asked if there were any further comments. There were none and Brian deemed the minutes from RIPE 61 to be formally approved. –New Working Group Co-Chair Tobias Knecht was formally approved as the new Anti-Abuse Working Group co-Chair. Brian said that Tobias would help to resurrect the best common practice document process. Brian said two documents would be produced – an administrative document and a technical document. –Finalise agenda There were no additions to the agenda. B. Update B1. Recent List Discussion Brian noted that there was a lot of discussion in the past few months. He said the Abuse Contact Task Force was addressing some issues and some were being addressed by the ripe-517 Closure and Deregistration document. He proposed that the working group not delve into those issues at that time. B2. Admin Tools for Blackhole Administration - Ingvar Mattsson, Google The presentation is available at: http://ripe62.ripe.net/presentations/155-blackholeslides.pdf David Freedman from Claranet said this approach was to be commended. He said he had a similar in-house tool and if anyone wanted to know more about that he could show them afterwards. He said the main problem is if prefixes are not reaped and remain in blackholing. He said the support team needs to be aware of what’s going on and it must be done in an intelligent way. Ignvar asked if it was more pleasant to use blackholing and David said it was. B3. Arbor 2010 Infrastructure Security Report - Darren Anstee, Arbor Networks The presentation is available at: http://ripe62.ripe.net/presentations/88-Darren-Anstee-AA-RIPE-2011-DDoS_Tre… Ian Meikle, RIPE Measurement, Analysis and Tools (MAT) Working Group co-Chair, noted that Darren would talk about the ATLAS initiative at the MAT Working Group session. Wout de Natris, Chair of the Cybercrime Working Party, asked if the rise of DDoS attacks was down to criminal or political reasons. Darren said he was not sure. He thought there might be a fair mixture of both, but he said people could look and draw their own conclusions. Wout said he attended a meeting on botnets, where it was noted that attacks from mobile devices were not a problem yet. He asked if this was becoming a problem. Darren said more attack traffic was coming from mobile devices. He said Symantec have seen a growth in malware targeted at smart devices and it is probably only a matter time before we see attacks coming from smart devices. Wout asked if Darren had tips for developing countries. Darren said diagnostic ACLs and flow tools could be used if these countries did not want to use commercial products to detect DDoS attacks. Daniel Karrenberg, Chief Scientist at the RIPE NCC, asked if on the Port 53 attacks there was any differentiation on whether the attack traffic was queries or responses. Darren said there was not. Daniel asked for more details, saying it would be interesting to see how the relative proportion was reflected in the attacks. He said he suspected a fair amount of reflection was going on. Darren said he would be asking what people wanted to see from the Atlas initiative, and he said this is one area they would be looking at. Paul Germano, Google, asked if the data received was just megabits per second and Darren said this was indeed the case. C. Policies –Abuse Contact Management Task Force Brian said that the three proposals (2010-08, 2010-09 and 2010-10) that were presented at RIPE 61 were withdrawn and that the Abuse Contact Management Task Force was formed to look at the issues or concerns in the three proposals. Brian gave an update from the task force, which is available at: http://ripe62.ripe.net/presentations/175-acm_tf_ripe62.ppt Brian asked if there were any questions. There were no questions, and Brian took this to be approval to continue with the work of the task force. D. Interactions D1. Working Groups Brian said the Database Working Group was the one the Anti-Abuse Working Group interacted with the most. He said that the main interaction with that group currently was concerned with the work of the Abuse Contact Management Task Force. D2. Cybercrime Working Party Update - Wout de Natris (No presentation was uploaded) Wout de Natris, Chair of the Cybercrime Working Party (CCWP), described the meetings he attended and presented at on behalf of the CCWP. He said that the main area the CCWP was looking into was training law enforcement agencies (LEAs) on the use of tools and databases that would help them in their work. He said a template for information requests would be created to send requests to the RIPE NCC. He said a list of LEA contacts would enable LEA officials to easily contact each other and share experiences. He said LEAs would look at coming up with a list of topics that they would want to discuss with the RIPE community. Wout asked the RIPE community what it would like to discuss with LEAs. He said people should bring issues to the CCWP if they wanted clarification from LEAs. Wout concluded by noting that the CCWP was making progress, and he reiterated that the process was a two-way street. He said LEAs could use the group to bring forward their concerns and the RIPE community could do likewise. Frank Salanitri, APNIC, said APNIC’s IRT object contact address received up to 30,000 abuse mails and that it was impossible to check these on an individual basis. He suggested they might be used for IP reputation services. He said, potentially, they could show the most abused allocations and the countries the abuse came from. He said this information could be logged in a database that could be made available to researchers. Wout asked if APNIC had contacted the Australian and New Zealand active anti-spam LEAs. Pablo Hinojosa, APNIC Public Affairs Officer, said APNIC was corresponding with these groups and was actively looking for ways to increase cooperation. D3. RIPE NCC Government/LEA Interactions Update Brian said a number of things have happened to give encouragement to RIPE and the RIPE NCC’s interactions with LEAs. He said the engagement of LEAs with the RIPE community has increased, and they have shown a greater understanding of the issues at hand. He said LEAs recognised the need to keep a good registry database. Brian said LEAs were happy with RIPE Policy Proposal 2010-06 on registration of IPv6 in the RIPE Database. He said the RIPE NCC procedural document, ripe-517, on closure and deregistration of LIRs was a positive step because it reduces the ability to abuse mechanisms there. Brian added that they also talked about what is likely to happen following the exhaustion of the IPv4 address pool. He said interaction with both LEAs and government agencies would continue. Brian noted that there are issues being discussed on the RIPE Address Policy Working Group mailing list that the Anti-Abuse Working Group should look at. He said the RPKI discussion should be of particular note and he asked everyone to pay close attention to these issues. X. AOB There was no other business to attend to. Brian asked for items for RIPE 63. He noted that Tobias would talk about the best common practice documents at RIPE 63 and he promised to have those documents posted to the mailing list. Brian thanked the attendees and said he looked forward to the next meeting in Vienna. Recordings of all presentations and discussion in the RIPE Anti-Abuse Working Group session at RIPE 62 are available at: http://ripe62.ripe.net/archives#Thursday

2 2