From ripencc-management at ripe.net Wed Jan 2 16:57:08 2013 From: ripencc-management at ripe.net (Axel Pawlik) Date: Wed, 02 Jan 2013 16:57:08 +0100 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues Message-ID: <50E458D4.8050808@ripe.net> [Apologies for duplicate emails] Dear colleagues, There has been discussion on various mailing lists regarding the status of the RIPE Database Proxy Service. Before I address the issues that arose, I'd like to give you some background information on the service itself that may help with the discussions. Technical Background -------------------- To prevent the automatic harvesting of personal information (real names, email addresses, phone numbers) from the RIPE Database, there are PERSON and ROLE object query limits defined in the RIPE Database Acceptable Use Policy. This is set at 1,000 PERSON or ROLE objects per IP address per day. Queries that result in more than 1,000 objects with personal data being returned result in that IP address being blocked from carrying out queries for that day. Users of the RIPE Database have unlimited access to Network Information Centre (NIC)-related objects. They can use the -r flag in order to filter out personal objects and query NIC objects without any limitations. The RIPE Database Proxy Service allows websites to provide a third party interface to the RIPE Database. Without the proxy service, the third parties would quickly run into the limits set on RIPE Database queries. With the proxy service, we whitelist the third party IP address and ask them to pass their user's IP address to us, so limits are only set on the user's IP address, not the third party's. There is no technical way to ensure that the user IP addresses passed to us by the third party are valid. Potentially, third party users of the proxy service could harvest all personal data in the RIPE Database (approximately 2 million objects) in a matter of hours. To ensure that the RIPE NCC's Terms and Conditions are followed, we require a contract between the third party and the RIPE NCC. Users of the Proxy Service -------------------------- In the past ten years, the RIPE NCC has had 31 requests for the proxy service and over the past year, there have been only four active users of the service. Of these four, one is already a RIPE NCC member. NIC Information --------------- All NIC information is still available without access to the proxy service. In the normal presentation of whois data, there is a redirect system that allows users with a normal whois client to deal directly with the RIPE Database whois service. There is no need for a proxy service in this scenario. The proxy service is only necessary if the data needs to be presented in alternative forms, such as on a third party's website. The limits imposed on RIPE Database queries only apply to personal data. Users can always access NIC data in any form they like if they are happy not to receive personal data. On 6 March 2012, the RIPE NCC proposed to change the default behaviour of the query system to instead return only "ALLOWED" results if a user had reached their daily personal data query limit, but there was disagreement over this on the mailing list so the change was not implemented. The proposal is available at: http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html Legal Considerations -------------------- The RIPE NCC operates under European Data Protection laws, so to avoid risk in this area we insist on having a contract with third parties who wish to use the proxy service. The RIPE NCC and its Executive Board believes that the proxy service should become a member service because it tightens the contractual relationship between the RIPE NCC and third parties. Currently, no such agreement that meets the EU Data Protection legislation is in place between the RIPE NCC and the proxy service users. In order to tighten the contractual relationship between the RIPE NCC and the Proxy service users, taking into account the recent approval of the Charging Scheme 2013 that caused a simplification of the contractual agreements between the RIPE NCC and its service users, the RIPE NCC offered to conclude the membership agreement for continuation of the service. Next Steps? ------------ The Executive Board approved changes to the draft version of the Activity Plan and Budget 2013, and the RIPE NCC published the final version on 13 December 2012: http://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-activity-plan-and-budget-2013 We do apologise, however, that the changes regarding the proxy service were not more explicitly communicated to the members and the RIPE community in advance of the final publication of the Activity Plan. The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place. This will give the membership and community the opportunity to discuss the best way forward for the proxy service in the coming months while ensuring a strong contractual bond between the RIPE NCC and users of this service. In the meantime, there will be no changes to the proxy service and no loss of functionality for the community. The RIPE NCC and its Executive Board will return to its members with proposals for ways to ensure that their wishes are met with regard to service developments while allowing the RIPE NCC to be operate efficiently and responsively. If you have any comments on this issue, please direct them to the RIPE NCC Services Working Group mailing list . Best regards, Axel Pawlik Managing Director RIPE NCC From shane at time-travellers.org Wed Jan 2 17:41:42 2013 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 2 Jan 2013 17:41:42 +0100 Subject: [anti-abuse-wg] Fwd: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: <20130102174142.6be4380b@shane-desktop> Suresh, On Monday, 2012-12-31 21:21:45 +0530, Suresh Ramasubramanian wrote: > Bad move. I find geektools very useful for abuse mitigation and it is > my hope that this is reconsidered FYI. there is a thread about this over on the ncc-services-wg: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-January/thread.html Included is what I guess is an official response from Axel Pawlik: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-January/001930.html Cheers, -- Shane From fw at deneb.enyo.de Wed Jan 2 19:50:23 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 02 Jan 2013 19:50:23 +0100 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: <50E458D4.8050808@ripe.net> (Axel Pawlik's message of "Wed, 02 Jan 2013 16:57:08 +0100") References: <50E458D4.8050808@ripe.net> Message-ID: <87623fbes0.fsf@mid.deneb.enyo.de> * Axel Pawlik: > Users of the RIPE Database have unlimited access to Network > Information Centre (NIC)-related objects. They can use the -r flag in > order to filter out personal objects and query NIC objects without any > limitations. Interesting. This does not work for me: fw at deneb:~$ printf '%s\r\n' "-r 193.0.14.129" | nc whois.ripe.net 43 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf %ERROR:201: access denied for 85.183.209.94 % % Queries from your IP address have passed the daily limit of controlled objects. % Access from your host has been temporarily denied. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied % This query was served by the RIPE Database Query Service version 1.47.5 (WHOIS1) fw at deneb:~$ Before that, I managed to blow my entire daily quota with a single query, namely "-r r" (typo for "?", requesting help). From thor at anta.net Wed Jan 2 20:04:28 2013 From: thor at anta.net (Thor Kottelin) Date: Wed, 2 Jan 2013 21:04:28 +0200 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: <87623fbes0.fsf@mid.deneb.enyo.de> References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Florian Weimer > Sent: Wednesday, January 02, 2013 8:50 PM > To: ripencc-management at ripe.net > Cc: anti-abuse-wg at ripe.net > * Axel Pawlik: > > > Users of the RIPE Database have unlimited access to Network > > Information Centre (NIC)-related objects. They can use the -r > flag in > > order to filter out personal objects and query NIC objects > without any > > limitations. > > Interesting. This does not work for me: > > fw at deneb:~$ printf '%s\r\n' "-r 193.0.14.129" | nc whois.ripe.net > 43 > %ERROR:201: access denied for 85.183.209.94 > % > % Queries from your IP address have passed the daily limit of > controlled objects. > % Access from your host has been temporarily denied. > Before that, I managed to blow my entire daily quota with a single > query, namely "-r r" (typo for "?", requesting help). But Axel Pawlik also wrote: > > On 6 March 2012, the RIPE NCC proposed to change the default behaviour > > of the query system to instead return only "ALLOWED" results if a user > > had reached their daily personal data query limit, but there was > > disagreement over this on the mailing list so the change was not > > implemented. He also referred to http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html, wherein it is stated: 'The current blocking mechanism works on the basis of all or nothing. If you are not blocked, you can successfully query for any data in the RIPE Database. If you are blocked (either temporarily or permanently), any query from you is rejected with a "Denied access" error message.' I assume that the above explains your predicament. -- Thor Kottelin http://www.anta.net/ From fw at deneb.enyo.de Wed Jan 2 20:43:36 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 02 Jan 2013 20:43:36 +0100 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: (Thor Kottelin's message of "Wed, 2 Jan 2013 21:04:28 +0200") References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> Message-ID: <87ip7f9xqv.fsf@mid.deneb.enyo.de> * Thor Kottelin: > But Axel Pawlik also wrote: > >> > On 6 March 2012, the RIPE NCC proposed to change the default behaviour >> > of the query system to instead return only "ALLOWED" results if a user >> > had reached their daily personal data query limit, but there was >> > disagreement over this on the mailing list so the change was not >> > implemented. > > He also referred to > http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html, wherein > it is stated: 'The current blocking mechanism works on the basis of all or > nothing. If you are not blocked, you can successfully query for any data in > the RIPE Database. If you are blocked (either temporarily or permanently), > any query from you is rejected with a "Denied access" error message.' > > I assume that the above explains your predicament. Oh, it seems so. I guess it would be nice to have an option which says, "please process this query in a way which does not cause blocking". I mistakenly assumed that "-r" would be that option, but it actually isn't. From thor at anta.net Wed Jan 2 22:00:05 2013 From: thor at anta.net (Thor Kottelin) Date: Wed, 2 Jan 2013 23:00:05 +0200 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: <87ip7f9xqv.fsf@mid.deneb.enyo.de> References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> <87ip7f9xqv.fsf@mid.deneb.enyo.de> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Florian Weimer > Sent: Wednesday, January 02, 2013 9:44 PM > To: Thor Kottelin > Cc: anti-abuse-wg at ripe.net > I guess it would be nice to have an option which > says, "please process this query in a way which does not cause > blocking". I mistakenly assumed that "-r" would be that option, > but > it actually isn't. I'm not sure why you were blocked initially despite using the -r switch. I was able to reproduce the problem: the IP address I used became blocked as well. Perhaps this was some kind of overload protection rather than the privacy-related restriction we have been discussing. -- Thor Kottelin http://www.anta.net/ From kranjbar at ripe.net Wed Jan 2 23:11:09 2013 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Wed, 2 Jan 2013 23:11:09 +0100 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> <87ip7f9xqv.fsf@mid.deneb.enyo.de> Message-ID: <79BC09BD-F282-4403-87D6-45C1D2F5BE9F@ripe.net> On Jan 2, 2013, at 10:00 PM, Thor Kottelin wrote: > > I'm not sure why you were blocked initially despite using the -r switch. I > was able to reproduce the problem: the IP address I used became blocked as > well. Perhaps this was some kind of overload protection rather than the > privacy-related restriction we have been discussing. Hello Thor, This should not happen, could you please kindly contact us through ripe-dbm at ripe.net and give us your client IP address so we can investigate the cause. You should not get blocked when using "-r" flag with a RESOURCE query and there should be no overload issue at all. Please note "-r" flag will turn off recursion for contact information after retrieving the objects that match a query. If the query is directly for personal data (like a person's name) using "-r' would have no effect as the direct query results will be objects with personal data. Kind Regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager From thor at anta.net Wed Jan 2 23:28:56 2013 From: thor at anta.net (Thor Kottelin) Date: Thu, 3 Jan 2013 00:28:56 +0200 Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: <79BC09BD-F282-4403-87D6-45C1D2F5BE9F@ripe.net> References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> <87ip7f9xqv.fsf@mid.deneb.enyo.de> <79BC09BD-F282-4403-87D6-45C1D2F5BE9F@ripe.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Kaveh Ranjbar > Sent: Thursday, January 03, 2013 12:11 AM > To: Thor Kottelin > Cc: anti-abuse-wg at ripe.net > On Jan 2, 2013, at 10:00 PM, Thor Kottelin wrote: > > > > I'm not sure why you were blocked initially despite using the -r > switch. I > > was able to reproduce the problem: the IP address I used became > blocked as > > well. Perhaps this was some kind of overload protection rather > than the > > privacy-related restriction we have been discussing. > Please note "-r" flag will turn off recursion for contact > information after retrieving the objects that match a query. If the > query is directly for personal data (like a person's name) using "- > r' would have no effect as the direct query results will be objects > with personal data. Thanks. This explains the phenomenon. -- Thor Kottelin http://www.anta.net/ From denis at ripe.net Thu Jan 3 06:57:39 2013 From: denis at ripe.net (denis at ripe.net) Date: Thu, 3 Jan 2013 06:57:39 +0100 (CET) Subject: [anti-abuse-wg] RIPE Database Proxy Service Issues In-Reply-To: <87ip7f9xqv.fsf@mid.deneb.enyo.de> References: <50E458D4.8050808@ripe.net> <87623fbes0.fsf@mid.deneb.enyo.de> <87ip7f9xqv.fsf@mid.deneb.enyo.de> Message-ID: <50581.61.90.113.32.1357192659.squirrel@webmail.ripe.net> Dear Florian As Kaveh pointed out, the -r flag simply says don't recusively search through the objects returned in response to the query and find referenced personal data. But if the query itself is for a personal data object the -r flag will have no effect. Your query "-r r" is looking for all objects in the RIPE Database where the primary key containes the letter 'r'. As most nic-handles end in '-ripe' you queried for all persoanl data directly. This is why your single query blocked you. Your idea for a 'non blocking' query option is along the lines of our technical suggestion from last year, which Axel referred to. Perhaps the community would like to take another look at that as there was no consensus last year. The current blocking mechanism is not optimal and could be improved. Regards Denis Walker Business Analyst RIPE NCC Database Group > * Thor Kottelin: > >> But Axel Pawlik also wrote: >> >>> > On 6 March 2012, the RIPE NCC proposed to change the default >>> behaviour >>> > of the query system to instead return only "ALLOWED" results if a >>> user >>> > had reached their daily personal data query limit, but there was >>> > disagreement over this on the mailing list so the change was not >>> > implemented. >> >> He also referred to >> http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html, >> wherein >> it is stated: 'The current blocking mechanism works on the basis of all >> or >> nothing. If you are not blocked, you can successfully query for any data >> in >> the RIPE Database. If you are blocked (either temporarily or >> permanently), >> any query from you is rejected with a "Denied access" error message.' >> >> I assume that the above explains your predicament. > > Oh, it seems so. I guess it would be nice to have an option which > says, "please process this query in a way which does not cause > blocking". I mistakenly assumed that "-r" would be that option, but > it actually isn't. > > > From ripencc-management at ripe.net Fri Jan 4 12:50:22 2013 From: ripencc-management at ripe.net (Axel Pawlik) Date: Fri, 04 Jan 2013 12:50:22 +0100 Subject: [anti-abuse-wg] Update - RIPE Database Proxy Service Issues Message-ID: <50E6C1FE.3070608@ripe.net> [Apologies for duplicate emails] Dear colleagues, Thank you for your comments on this issue. I would like to point out that the *DRAFT* Activity Plan and Budget is published around September of each year, allowing members ample time to read it before it is discussed at the Autumn General Meeting. The RIPE NCC Executive Board then takes the outcome of the discussions and any new developments into consideration before finalising and approving the definitive Activity Plan and Budget, which is then published before the end of the year. On 13 December 2012, we informed the membership of the definitive Activity Plan and Budget and listed the changes from the draft plan. Please note that the membership does not vote on either the draft or the final Activity Plan and Budget - this is one of the member-elected Executive Board's functions. One of the modifications that took place from the draft to the final Activity Plan was the addition of the RIPE Database Proxy Service as a member-only service. This was a follow-up on an action point that stemmed from the Data Protection Task Force and a need to strengthen our contractual relationship between the current users of the RIPE Database Proxy Service and the RIPE NCC ensuring compliance with Dutch and EU legislation. Partially based on the membership's vote of approval regarding the new Charging Scheme of "one LIR, one fee" and partially based on the fact that the RIPE Database Proxy Service is only actively used by less than a handful of entities (both members and non-members), the Executive Board made the decision, which they felt was in the members' interest, to ask the users of this service to sign both a specific RIPE Database Proxy Service Agreement and the Standard Service Agreement (Membership Agreement) that adheres to both EU and Dutch legislation, which would entail the users of this service paying the annual membership fee. Based on the recent mailing list discussions it seems apparent that this is a contentious issue that requires further membership and community discussion. Therefore, we will keep the RIPE Database Proxy Service running as it was in 2012 (i.e., no fee and no Membership Agreement) until we have completed these discussions. We will prepare a legal analysis of the options at hand for the contractual documentation required to use this service and gauge whether or not the membership feels that we should charge a fee for this service. Regards, Axel Pawlik Managing Director RIPE NCC From kjz at gmx.net Sat Jan 12 20:43:11 2013 From: kjz at gmx.net (Karl-Josef Ziegler) Date: Sat, 12 Jan 2013 20:43:11 +0100 Subject: [anti-abuse-wg] hosting with anonymous whois Message-ID: <50F1BCCF.5060407@gmx.net> Hello! Today I go a spam for pillz (CAPRXPHARMACY.RU) 'hosted' at IP 84.22.104.117. This IP is of course listed at Spamhaus: http://www.spamhaus.org/sbl/query/SBL99505 http://www.spamhaus.org/sbl/query/SBL99505 and this 'hoster' has a very long list (118 entries) at Spamhaus: http://www.spamhaus.org/sbl/listings/cb3rob.net and is on place no. 1 at Spamhaus: http://www.spamhaus.org/statistics/networks/ Whois says: address: Customer did not enter their own contact details yet A research says: Ministry of Telecommunications, One CyberBunker Avenue CB-10000 CyberBunker-1 Republic CyberBunker C/O CB3ROB LLTC. Company reg. #8 CyberBunker trade register. One CyberBunker Avenue CB-10000 CyberBunker-1 Republic CyberBunker So is it really possible to get an IP block with anonymous whois entries at RIPE? Best regards, - Karl-Josef Ziegler From furio+as at spin.it Sun Jan 13 11:13:35 2013 From: furio+as at spin.it (furio ercolessi) Date: Sun, 13 Jan 2013 11:13:35 +0100 Subject: [anti-abuse-wg] hosting with anonymous whois In-Reply-To: <50F1BCCF.5060407@gmx.net> References: <50F1BCCF.5060407@gmx.net> Message-ID: <20130113101335.GA31875@spin.it> On Sat, Jan 12, 2013 at 08:43:11PM +0100, Karl-Josef Ziegler wrote: > Hello! > > Today I go a spam for pillz (CAPRXPHARMACY.RU) 'hosted' at IP > 84.22.104.117. This IP is of course listed at Spamhaus: > > http://www.spamhaus.org/sbl/query/SBL99505 > > http://www.spamhaus.org/sbl/query/SBL99505 > > and this 'hoster' has a very long list (118 entries) at Spamhaus: > > http://www.spamhaus.org/sbl/listings/cb3rob.net > > and is on place no. 1 at Spamhaus: > > http://www.spamhaus.org/statistics/networks/ > > Whois says: > > address: Customer did not enter their own contact details yet > > A research says: > > Ministry of Telecommunications, > One CyberBunker Avenue > CB-10000 > CyberBunker-1 > Republic CyberBunker > > C/O > > CB3ROB LLTC. > Company reg. #8 > CyberBunker trade register. > One CyberBunker Avenue > CB-10000 > CyberBunker-1 > Republic CyberBunker > > So is it really possible to get an IP block with anonymous whois entries > at RIPE? The inetnum object for 84.22.104.112/29 was created by 'CUSTOMER-RESOURCES-MNT' which are the criminals themselves, so the question should probably be rephrased into: "How can it happen that a criminal group can keep resources allocated for such a long time, and how can it happen that they can still find companies allowing them to connect to the Internet?". The first question is probably more relevant for law enforcement than for RIPE NCC, the second seems related with greediness and corporate dumbness winning over ethics and reputation. See also: http://www.spamhaus.org/news/article/673/ , http://www.theregister.co.uk/2011/10/20/spamhaus_a2b_row/ . According to the Spamhaus article, transit providers connecting CB3ROB up to october 2011 included Ecatel.net, Grafix.nl, datahouse.nl and the famous a2b-internet.com who even fought back antiabuse organizations rather than thanking them. After those, it was the turn of Inteliquent (former TINET) and Tata Communications, still connecting them. CB3ROB is also connected through Idear4business which is another very questionable outfit. furio From shane at time-travellers.org Mon Jan 14 11:55:51 2013 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 14 Jan 2013 11:55:51 +0100 Subject: [anti-abuse-wg] hosting with anonymous whois In-Reply-To: <50F1BCCF.5060407@gmx.net> References: <50F1BCCF.5060407@gmx.net> Message-ID: <20130114115551.411a35b8@shane-desktop> Karl-Josef, On Saturday, 2013-01-12 20:43:11 +0100, Karl-Josef Ziegler wrote: > Today I go a spam for pillz (CAPRXPHARMACY.RU) 'hosted' at IP > 84.22.104.117. > So is it really possible to get an IP block with anonymous whois > entries at RIPE? The parent block refers to this organisation object: organisation: ORG-CA76-RIPE org-name: CB3ROB Ltd. & Co. KG org-type: LIR address: CB3ROB Ltd. & Co. KG Hostmaster Koloniestrasse 34 D-13359 BERLIN GERMANY phone: +31878747479 A quick Google search reveals what seems to be the home page: http://www.cb3rob.net/ According to the RIPE policy: All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained). They only have 2 assignments which are not obviously at a fictitious address, so they seem to be in violation here. I guess the best thing to do is ask for an audit? http://www.ripe.net/ripe/docs/audit Cheers, -- Shane From rfg at tristatelogic.com Mon Jan 14 23:52:49 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 14 Jan 2013 14:52:49 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs Message-ID: <73421.1358203969@tristatelogic.com> After a careful investigation, I am of the opinion that each of the following 18 ASNs was registered (via RIPE) with fradulent information purporting to represent the identity of the true registrant, and that in fact, all 18 of these ASNs were registered by a single party, apparently as part of a larger scheme to provide IP space to various snowshoe spammers. Evidence I have in hand strongly links this scheme and these ASNs and their associated IPv4 route announcements to Jump Network Services, aka JUMP.RO. Furthermore, all of these ASNs are apparently peering with exactly and only the same two other ASNs in all cases, i.e. GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737). These peers and the fradulent ASNs listed below are all apparently originated out of Romania. AS16011 (fiberwelders.ro) AS28822 (creativitaterpm.ro) AS48118 (telecomhosting.ro) AS49210 (rom-access.ro) AS50659 (grandnethost.com) AS57131 (speedconnecting.ro) AS57133 (nordhost.ro) AS57135 (fastcable.ro) AS57176 (bucovinanetwork.ro) AS57184 (kaboomhost.ro) AS57415 (highwayinternet.ro) AS57695 (effidata.ro) AS57724 (id-trafic.ro) AS57738 (mclick.ro) AS57786 (hosting-www.ro) AS57837 (romtechinnovation.ro) AS57906 (momy.ro) AS57917 (nature-design.ro) At present, the above 18 ASNs are currently announcing routes for a total amount of IP space equal to 1,022 /24s, which is the rough equivalent of an entire /14 block. These IPv4 route announcements are listed below, sorted by IPv4 (32-bit) start address. Additional potentially relevant background information: http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as44414-as44520-as49173-as49643 http://www.spamhaus.org/sbl/listings/jump.ro Current route announcements: 31.14.30.0/24 31.14.32.0/24 31.14.33.0/24 31.14.34.0/23 31.14.36.0/22 31.14.40.0/22 31.14.44.0/24 31.14.45.0/24 31.14.46.0/23 31.14.48.0/24 31.14.49.0/24 31.14.50.0/23 31.14.52.0/22 31.14.56.0/21 31.14.64.0/24 31.14.65.0/24 31.14.66.0/23 31.14.68.0/22 31.14.72.0/21 31.14.80.0/20 31.14.112.0/20 31.14.144.0/20 37.153.128.0/22 37.153.132.0/22 37.153.140.0/22 37.153.144.0/21 37.153.152.0/22 37.153.160.0/21 37.153.168.0/22 37.153.172.0/23 37.153.174.0/23 37.153.176.0/20 37.156.0.0/22 37.156.4.0/22 37.156.8.0/21 37.156.16.0/23 37.156.18.0/23 37.156.20.0/23 37.156.22.0/23 37.156.24.0/23 37.156.26.0/23 37.156.28.0/23 37.156.30.0/23 37.156.36.0/24 37.156.37.0/24 37.156.38.0/23 37.156.48.0/21 37.156.56.0/22 37.156.100.0/22 37.156.104.0/22 37.156.108.0/22 37.156.112.0/20 37.156.128.0/20 37.156.144.0/22 37.156.148.0/22 37.156.152.0/21 37.156.160.0/21 37.156.168.0/22 37.156.172.0/23 37.156.180.0/23 37.156.184.0/22 37.156.188.0/22 37.156.208.0/22 37.156.216.0/22 37.156.224.0/24 37.156.225.0/24 37.156.226.0/23 37.156.228.0/23 37.156.230.0/23 37.156.232.0/23 37.156.234.0/23 37.156.236.0/23 37.156.238.0/23 37.156.240.0/21 37.156.248.0/22 37.156.252.0/22 46.102.128.0/20 46.102.144.0/20 46.102.160.0/21 77.81.120.0/23 77.81.126.0/24 77.81.160.0/22 84.247.4.0/22 84.247.18.0/23 84.247.40.0/22 85.204.18.0/24 85.204.20.0/23 85.204.30.0/23 85.204.36.0/22 85.204.54.0/23 85.204.64.0/23 85.204.66.0/24 85.204.76.0/23 85.204.96.0/23 85.204.104.0/23 85.204.120.0/24 85.204.121.0/24 85.204.124.0/24 85.204.132.0/23 85.204.152.0/23 85.204.176.0/21 85.204.194.0/23 86.104.0.0/23 86.104.2.0/24 86.104.4.0/24 86.104.9.0/24 86.104.10.0/24 86.104.96.0/21 86.104.115.0/24 86.104.116.0/24 86.104.118.0/23 86.104.121.0/24 86.104.122.0/23 86.104.132.0/23 86.104.192.0/24 86.104.195.0/24 86.104.212.0/23 86.104.215.0/24 86.104.240.0/22 86.104.245.0/24 86.104.248.0/23 86.105.178.0/24 86.105.195.0/24 86.105.196.0/24 86.105.200.0/22 86.105.225.0/24 86.105.227.0/24 86.105.230.0/24 86.105.242.0/23 86.105.248.0/22 86.106.0.0/21 86.106.8.0/23 86.106.10.0/24 86.106.11.0/24 86.106.12.0/24 86.106.24.0/24 86.106.25.0/24 86.106.90.0/24 86.106.95.0/24 86.106.169.0/24 86.107.8.0/21 86.107.28.0/23 86.107.74.0/23 86.107.104.0/24 86.107.195.0/24 86.107.216.0/21 86.107.242.0/23 89.32.122.0/23 89.32.176.0/23 89.32.192.0/23 89.32.196.0/23 89.32.204.0/24 89.33.46.0/23 89.33.108.0/23 89.33.117.0/24 89.33.168.0/21 89.33.233.0/24 89.33.246.0/24 89.33.255.0/24 89.34.16.0/22 89.34.94.0/23 89.34.102.0/23 89.34.112.0/21 89.34.128.0/20 89.34.148.0/23 89.34.200.0/23 89.34.216.0/23 89.34.236.0/22 89.35.32.0/24 89.35.56.0/24 89.35.77.0/24 89.35.133.0/24 89.35.156.0/23 89.35.176.0/23 89.35.196.0/24 89.35.240.0/21 89.36.16.0/23 89.36.32.0/23 89.36.34.0/24 89.36.35.0/24 89.36.96.0/21 89.36.104.0/21 89.36.178.0/23 89.36.182.0/23 89.36.184.0/21 89.36.226.0/23 89.36.236.0/22 89.37.48.0/21 89.37.64.0/22 89.37.76.0/22 89.37.102.0/23 89.37.107.0/24 89.37.129.0/24 89.37.133.0/24 89.37.143.0/24 89.37.240.0/21 89.38.26.0/24 89.38.216.0/22 89.38.220.0/22 89.39.76.0/22 89.39.168.0/22 89.39.180.0/23 89.39.216.0/22 89.40.40.0/24 89.40.66.0/24 89.40.133.0/24 89.40.240.0/21 89.40.254.0/23 89.41.16.0/21 89.41.44.0/22 89.42.27.0/24 89.42.33.0/24 89.42.150.0/23 89.42.208.0/23 89.43.182.0/23 89.43.184.0/23 89.43.216.0/21 89.43.224.0/21 89.44.94.0/23 89.44.115.0/24 89.44.120.0/21 89.44.190.0/23 89.45.11.0/24 89.45.14.0/24 89.45.72.0/21 89.45.126.0/23 89.46.8.0/22 89.46.44.0/23 89.46.47.0/24 89.46.60.0/24 89.46.88.0/22 89.46.192.0/21 89.47.34.0/24 89.47.44.0/22 92.114.36.0/24 92.114.38.0/24 92.114.83.0/24 93.113.216.0/22 93.114.24.0/21 93.114.85.0/24 93.114.86.0/23 93.114.128.0/24 93.114.133.0/24 93.115.32.0/23 93.115.62.0/23 93.115.130.0/23 93.115.134.0/23 93.115.138.0/23 93.115.142.0/23 93.115.192.0/21 93.115.253.0/24 93.117.112.0/21 93.117.120.0/21 93.119.112.0/23 93.119.118.0/23 93.119.120.0/23 93.119.124.0/23 94.176.224.0/20 176.126.168.0/23 176.126.170.0/23 176.126.172.0/23 176.126.174.0/23 176.223.64.0/23 176.223.108.0/24 176.223.111.0/24 176.223.116.0/23 176.223.118.0/24 176.223.167.0/24 176.223.172.0/22 176.223.176.0/24 176.223.177.0/24 176.223.178.0/23 176.223.190.0/24 188.212.22.0/24 188.212.48.0/20 188.213.64.0/20 188.213.112.0/22 188.213.116.0/23 188.213.118.0/24 188.213.119.0/24 188.213.120.0/23 188.213.122.0/23 188.213.124.0/22 188.213.144.0/20 188.213.176.0/22 188.213.180.0/22 188.213.184.0/22 188.213.188.0/22 188.215.18.0/23 188.215.20.0/22 188.215.192.0/19 188.241.188.0/23 188.241.192.0/22 217.19.4.0/24 From ops.lists at gmail.com Tue Jan 15 01:12:56 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 15 Jan 2013 05:42:56 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <73421.1358203969@tristatelogic.com> References: <73421.1358203969@tristatelogic.com> Message-ID: The last time a romanian I know checked, most of these appear to be set up with business registration that was valid at the time the netblocks were registered but mostly lapsed a year or so later. Almost as if someone in bucharest walks into a bar, pays people there a few euro in drinking money if they will let their ID get used to register a shell company that can then register for a /16 or larger netblock. --srs (htc one x) On 15-Jan-2013 4:30 AM, "Ronald F. Guilmette" wrote: > > After a careful investigation, I am of the opinion that each of the > following 18 ASNs was registered (via RIPE) with fradulent information > purporting to represent the identity of the true registrant, and that > in fact, all 18 of these ASNs were registered by a single party, > apparently as part of a larger scheme to provide IP space to various > snowshoe spammers. > > Evidence I have in hand strongly links this scheme and these ASNs and > their associated IPv4 route announcements to Jump Network Services, > aka JUMP.RO. Furthermore, all of these ASNs are apparently peering > with exactly and only the same two other ASNs in all cases, i.e. > GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737). These > peers and the fradulent ASNs listed below are all apparently originated > out of Romania. > > AS16011 (fiberwelders.ro) > AS28822 (creativitaterpm.ro) > AS48118 (telecomhosting.ro) > AS49210 (rom-access.ro) > AS50659 (grandnethost.com) > AS57131 (speedconnecting.ro) > AS57133 (nordhost.ro) > AS57135 (fastcable.ro) > AS57176 (bucovinanetwork.ro) > AS57184 (kaboomhost.ro) > AS57415 (highwayinternet.ro) > AS57695 (effidata.ro) > AS57724 (id-trafic.ro) > AS57738 (mclick.ro) > AS57786 (hosting-www.ro) > AS57837 (romtechinnovation.ro) > AS57906 (momy.ro) > AS57917 (nature-design.ro) > > At present, the above 18 ASNs are currently announcing routes for a total > amount of IP space equal to 1,022 /24s, which is the rough equivalent of > an entire /14 block. These IPv4 route announcements are listed below, > sorted by IPv4 (32-bit) start address. > > Additional potentially relevant background information: > > > http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 > > http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as44414-as44520-as49173-as49643 > http://www.spamhaus.org/sbl/listings/jump.ro > > > Current route announcements: > > 31.14.30.0/24 > 31.14.32.0/24 > 31.14.33.0/24 > 31.14.34.0/23 > 31.14.36.0/22 > 31.14.40.0/22 > 31.14.44.0/24 > 31.14.45.0/24 > 31.14.46.0/23 > 31.14.48.0/24 > 31.14.49.0/24 > 31.14.50.0/23 > 31.14.52.0/22 > 31.14.56.0/21 > 31.14.64.0/24 > 31.14.65.0/24 > 31.14.66.0/23 > 31.14.68.0/22 > 31.14.72.0/21 > 31.14.80.0/20 > 31.14.112.0/20 > 31.14.144.0/20 > 37.153.128.0/22 > 37.153.132.0/22 > 37.153.140.0/22 > 37.153.144.0/21 > 37.153.152.0/22 > 37.153.160.0/21 > 37.153.168.0/22 > 37.153.172.0/23 > 37.153.174.0/23 > 37.153.176.0/20 > 37.156.0.0/22 > 37.156.4.0/22 > 37.156.8.0/21 > 37.156.16.0/23 > 37.156.18.0/23 > 37.156.20.0/23 > 37.156.22.0/23 > 37.156.24.0/23 > 37.156.26.0/23 > 37.156.28.0/23 > 37.156.30.0/23 > 37.156.36.0/24 > 37.156.37.0/24 > 37.156.38.0/23 > 37.156.48.0/21 > 37.156.56.0/22 > 37.156.100.0/22 > 37.156.104.0/22 > 37.156.108.0/22 > 37.156.112.0/20 > 37.156.128.0/20 > 37.156.144.0/22 > 37.156.148.0/22 > 37.156.152.0/21 > 37.156.160.0/21 > 37.156.168.0/22 > 37.156.172.0/23 > 37.156.180.0/23 > 37.156.184.0/22 > 37.156.188.0/22 > 37.156.208.0/22 > 37.156.216.0/22 > 37.156.224.0/24 > 37.156.225.0/24 > 37.156.226.0/23 > 37.156.228.0/23 > 37.156.230.0/23 > 37.156.232.0/23 > 37.156.234.0/23 > 37.156.236.0/23 > 37.156.238.0/23 > 37.156.240.0/21 > 37.156.248.0/22 > 37.156.252.0/22 > 46.102.128.0/20 > 46.102.144.0/20 > 46.102.160.0/21 > 77.81.120.0/23 > 77.81.126.0/24 > 77.81.160.0/22 > 84.247.4.0/22 > 84.247.18.0/23 > 84.247.40.0/22 > 85.204.18.0/24 > 85.204.20.0/23 > 85.204.30.0/23 > 85.204.36.0/22 > 85.204.54.0/23 > 85.204.64.0/23 > 85.204.66.0/24 > 85.204.76.0/23 > 85.204.96.0/23 > 85.204.104.0/23 > 85.204.120.0/24 > 85.204.121.0/24 > 85.204.124.0/24 > 85.204.132.0/23 > 85.204.152.0/23 > 85.204.176.0/21 > 85.204.194.0/23 > 86.104.0.0/23 > 86.104.2.0/24 > 86.104.4.0/24 > 86.104.9.0/24 > 86.104.10.0/24 > 86.104.96.0/21 > 86.104.115.0/24 > 86.104.116.0/24 > 86.104.118.0/23 > 86.104.121.0/24 > 86.104.122.0/23 > 86.104.132.0/23 > 86.104.192.0/24 > 86.104.195.0/24 > 86.104.212.0/23 > 86.104.215.0/24 > 86.104.240.0/22 > 86.104.245.0/24 > 86.104.248.0/23 > 86.105.178.0/24 > 86.105.195.0/24 > 86.105.196.0/24 > 86.105.200.0/22 > 86.105.225.0/24 > 86.105.227.0/24 > 86.105.230.0/24 > 86.105.242.0/23 > 86.105.248.0/22 > 86.106.0.0/21 > 86.106.8.0/23 > 86.106.10.0/24 > 86.106.11.0/24 > 86.106.12.0/24 > 86.106.24.0/24 > 86.106.25.0/24 > 86.106.90.0/24 > 86.106.95.0/24 > 86.106.169.0/24 > 86.107.8.0/21 > 86.107.28.0/23 > 86.107.74.0/23 > 86.107.104.0/24 > 86.107.195.0/24 > 86.107.216.0/21 > 86.107.242.0/23 > 89.32.122.0/23 > 89.32.176.0/23 > 89.32.192.0/23 > 89.32.196.0/23 > 89.32.204.0/24 > 89.33.46.0/23 > 89.33.108.0/23 > 89.33.117.0/24 > 89.33.168.0/21 > 89.33.233.0/24 > 89.33.246.0/24 > 89.33.255.0/24 > 89.34.16.0/22 > 89.34.94.0/23 > 89.34.102.0/23 > 89.34.112.0/21 > 89.34.128.0/20 > 89.34.148.0/23 > 89.34.200.0/23 > 89.34.216.0/23 > 89.34.236.0/22 > 89.35.32.0/24 > 89.35.56.0/24 > 89.35.77.0/24 > 89.35.133.0/24 > 89.35.156.0/23 > 89.35.176.0/23 > 89.35.196.0/24 > 89.35.240.0/21 > 89.36.16.0/23 > 89.36.32.0/23 > 89.36.34.0/24 > 89.36.35.0/24 > 89.36.96.0/21 > 89.36.104.0/21 > 89.36.178.0/23 > 89.36.182.0/23 > 89.36.184.0/21 > 89.36.226.0/23 > 89.36.236.0/22 > 89.37.48.0/21 > 89.37.64.0/22 > 89.37.76.0/22 > 89.37.102.0/23 > 89.37.107.0/24 > 89.37.129.0/24 > 89.37.133.0/24 > 89.37.143.0/24 > 89.37.240.0/21 > 89.38.26.0/24 > 89.38.216.0/22 > 89.38.220.0/22 > 89.39.76.0/22 > 89.39.168.0/22 > 89.39.180.0/23 > 89.39.216.0/22 > 89.40.40.0/24 > 89.40.66.0/24 > 89.40.133.0/24 > 89.40.240.0/21 > 89.40.254.0/23 > 89.41.16.0/21 > 89.41.44.0/22 > 89.42.27.0/24 > 89.42.33.0/24 > 89.42.150.0/23 > 89.42.208.0/23 > 89.43.182.0/23 > 89.43.184.0/23 > 89.43.216.0/21 > 89.43.224.0/21 > 89.44.94.0/23 > 89.44.115.0/24 > 89.44.120.0/21 > 89.44.190.0/23 > 89.45.11.0/24 > 89.45.14.0/24 > 89.45.72.0/21 > 89.45.126.0/23 > 89.46.8.0/22 > 89.46.44.0/23 > 89.46.47.0/24 > 89.46.60.0/24 > 89.46.88.0/22 > 89.46.192.0/21 > 89.47.34.0/24 > 89.47.44.0/22 > 92.114.36.0/24 > 92.114.38.0/24 > 92.114.83.0/24 > 93.113.216.0/22 > 93.114.24.0/21 > 93.114.85.0/24 > 93.114.86.0/23 > 93.114.128.0/24 > 93.114.133.0/24 > 93.115.32.0/23 > 93.115.62.0/23 > 93.115.130.0/23 > 93.115.134.0/23 > 93.115.138.0/23 > 93.115.142.0/23 > 93.115.192.0/21 > 93.115.253.0/24 > 93.117.112.0/21 > 93.117.120.0/21 > 93.119.112.0/23 > 93.119.118.0/23 > 93.119.120.0/23 > 93.119.124.0/23 > 94.176.224.0/20 > 176.126.168.0/23 > 176.126.170.0/23 > 176.126.172.0/23 > 176.126.174.0/23 > 176.223.64.0/23 > 176.223.108.0/24 > 176.223.111.0/24 > 176.223.116.0/23 > 176.223.118.0/24 > 176.223.167.0/24 > 176.223.172.0/22 > 176.223.176.0/24 > 176.223.177.0/24 > 176.223.178.0/23 > 176.223.190.0/24 > 188.212.22.0/24 > 188.212.48.0/20 > 188.213.64.0/20 > 188.213.112.0/22 > 188.213.116.0/23 > 188.213.118.0/24 > 188.213.119.0/24 > 188.213.120.0/23 > 188.213.122.0/23 > 188.213.124.0/22 > 188.213.144.0/20 > 188.213.176.0/22 > 188.213.180.0/22 > 188.213.184.0/22 > 188.213.188.0/22 > 188.215.18.0/23 > 188.215.20.0/22 > 188.215.192.0/19 > 188.241.188.0/23 > 188.241.192.0/22 > 217.19.4.0/24 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Tue Jan 15 01:57:49 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 15 Jan 2013 06:27:49 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <9AF9C3CA-29BE-4E41-8CD6-920C21A59C78@steffann.nl> References: <73421.1358203969@tristatelogic.com> <9AF9C3CA-29BE-4E41-8CD6-920C21A59C78@steffann.nl> Message-ID: Problems with excessively large allocations by romanian LIRs to spam operations has been a problem over the last few years at least, so that ripe ncc might want to take cognizance of all this information do a proactive audit of all allocations over a period of time done through a particular LIRs, rather than play whack a mole with manually reported netblocks. --srs (htc one x) On 15-Jan-2013 6:20 AM, "Sander Steffann" wrote: > Hi, > > > The last time a romanian I know checked, most of these appear to be set > up with business registration that was valid at the time the netblocks were > registered but mostly lapsed a year or so later. > > > > Almost as if someone in bucharest walks into a bar, pays people there a > few euro in drinking money if they will let their ID get used to register a > shell company that can then register for a /16 or larger netblock. > > Well, the allocations/assignments are only valid as long as the original > criteria are still met. In this case it seems obvious that this is no > longer the case as the entity for which they were requested no longer > exists. But to be certain there has to be work done by the RIPE NCC. They > can't just revoke resources because someone posted a message on a mailing > list :-) > > Submitting this information to http://www.ripe.net/report-form seems > appropriate. > > Cheers, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Tue Jan 15 01:50:37 2013 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Jan 2013 01:50:37 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: References: <73421.1358203969@tristatelogic.com> Message-ID: <9AF9C3CA-29BE-4E41-8CD6-920C21A59C78@steffann.nl> Hi, > The last time a romanian I know checked, most of these appear to be set up with business registration that was valid at the time the netblocks were registered but mostly lapsed a year or so later. > > Almost as if someone in bucharest walks into a bar, pays people there a few euro in drinking money if they will let their ID get used to register a shell company that can then register for a /16 or larger netblock. Well, the allocations/assignments are only valid as long as the original criteria are still met. In this case it seems obvious that this is no longer the case as the entity for which they were requested no longer exists. But to be certain there has to be work done by the RIPE NCC. They can't just revoke resources because someone posted a message on a mailing list :-) Submitting this information to http://www.ripe.net/report-form seems appropriate. Cheers, Sander From peter at hk.ipsec.se Tue Jan 15 08:35:03 2013 From: peter at hk.ipsec.se (peter h) Date: Tue, 15 Jan 2013 08:35:03 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <73421.1358203969@tristatelogic.com> References: <73421.1358203969@tristatelogic.com> Message-ID: <201301150835.04532.peter@hk.ipsec.se> On Monday 14 January 2013 23.52, Ronald F. Guilmette wrote: > > After a careful investigation, I am of the opinion that each of the > following 18 ASNs was registered (via RIPE) with fradulent information > purporting to represent the identity of the true registrant, and that > in fact, all 18 of these ASNs were registered by a single party, > apparently as part of a larger scheme to provide IP space to various > snowshoe spammers. Thanks you very much. Some of them is confirmed spammers, all of them now added to my blocklist. 217.19.4.0/24 > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From vasile.capdefier at yahoo.co.uk Tue Jan 15 18:13:39 2013 From: vasile.capdefier at yahoo.co.uk (Vasile Capdefier) Date: Tue, 15 Jan 2013 17:13:39 +0000 (GMT) Subject: [anti-abuse-wg] (Long) rant about some LIRs in RIPE region, most likely linked to RFG's earlier email Message-ID: <1358270019.95063.YahooMailNeo@web171606.mail.ir2.yahoo.com> Disclaimer: this is just my POV, I didn't investigate (too) much/deep. All the information bellow is public, easy to find and Google Translate seems to work most of the times. From what I know, Jump.RO's business model is to *sell* IP space from their ALLOCATED PA ranges received from RIPE. Not *sub-allocate*, not *assign* or similar terms. They don't ask too many questions. They give you IPs faster than other LIRs. They market this as being professional. All of the Jump.RO's sub-allocations (that I've seen in whois) have *ASSIGNED PA* status, which according to ripe-553 [1] is to be used when the range is assigned to an end user for services provided by the issuing LIR. This is probably not the case because except the (new) annual fee for the registration service there are no other services provided by that LIR to the end user. Most of Jump.RO's "end users" are in fact small ISPs that can't afford the RIPE membership fees and bypass the rules of not using PI space for customers by deaggregating Jump's IP space. I don't know about the 12k number, but they have a large client base in the country and neighboring countries. I also think that Jump is aware of their IPs being in use by spammers as they advertise on their website that new and unused IP blocks cost about 2 times more than "used" ones. They also note that the previously "used" PA space is checked with "MxToolBox" in 120 anti-spam lists [2]. Even though Jump.RO's business model isn't exactly in the spirit of the RIPE region rules or following best practices (no prefix aggregation, but their excuse is that they are not the only ones doing it), I don't think that they are willing to risk their LIR status by defending known spam operations, so reporting well documented cases of false information provided during registration first to RIPE and then to them would probably get them to withdraw the PA from that customer. The ranges found by you clearly suggest that fake information has been used. Only "under construction" sites, nobody ever heard of those companies, all using same ISPs. With all this said about ro.registry (Jump.RO's LIR id) i'd like to add the following. There are entire LIRs with very large IP allocations and suspicious activities. I'll just list here a few: (RIPE allocation list publicly available here [3]) The first candidate that pops up is ro.visnet (VisNetwork Media SRL). According to their web page [4] they are a pretty large ISP with over 300 experienced employees and over 30 vehicles used for interventions and installations. They provide no CIF (Romanian for Fiscal Identification Code) or other identifying information, but the company is valid and has CIF 25083281. According to the Romanian Trade Register [5], the company named VisNetwork Media SRL with Fiscal Identification Code 25083281 is registered since February 2009, has no employees (where did those 300 professionals go?) and has registered for the 2011 fiscal year expenses of roughly about 3000 EUR (this value is around the value of the RIPE maintenance fees) and an amazing income of 100 EUR. Also, they are not registerd with ANCOM [6] (Romanian National Agency for Management and Regulation in Communications), so they are not a real ISP. They have received from RIPE the following IP space: 20090624??? 188.170.0.0/16??? ALLOCATED PA 20100713??? 46.49.128.0/17??? ALLOCATED PA 20110404??? 31.173.0.0/16??? ALLOCATED PA 20110707??? 146.0.128.0/17??? ALLOCATED PA 20110707??? 146.0.32.0/19??? ALLOCATED PA 20111012??? 128.234.0.0/16??? ALLOCATED PA 20120113??? 37.56.0.0/16??? ALLOCATED PA 20120405??? 37.224.0.0/16??? ALLOCATED PA 20120730??? 5.163.0.0/16??? ALLOCATED PA 20121113??? 185.9.244.0/22??? ALLOCATED PA 20110331??? 2a03:4100::/29 With this much IP space I would think they must have at least a few LARGE cities covered, but nobody ever heard of them or their professional employees. Also, because apparently their IPs were not enough and their employees seem that they couldn't handle hosting their main website, their website is hosted on IP ranges from another LIR. visnet.ro has address 77.36.59.10 inetnum:??????? 77.36.59.0 - 77.36.59.255 netname:??????? ROSITE-EQUIPMENTS The second obvious candidate for our small investigation is, as you might have guessed, ro.rosite (RoSite Equipment SRL). Information about their deaggregation habits can be found here [7]. According to the Trade Register, ROSITE EQUIPMENT SRL has CIF 17352052 and is a registered company since march 2005. They are registered as an ISP at ANCOM, but with a different company name (ROSITE NET SRL). Their second company, the one registered as an ISP, ROSITE NET SRL has CIF 13669105 and is a registered company since january 2001. The larger company, not the ISP, received from RIPE a large number of IP addresses: 20090706??? 188.119.128.0/18??? ALLOCATED PA 20090813??? 188.74.128.0/18??? ALLOCATED PA 20091223??? 188.74.192.0/18??? ALLOCATED PA 20100325??? 62.216.64.0/19??? ALLOCATED PA 20100628??? 178.157.64.0/18??? ALLOCATED PA 20110712??? 146.158.128.0/17??? ALLOCATED PA 20110712??? 146.66.208.0/20??? ALLOCATED PA 20120105??? 37.35.128.0/17??? ALLOCATED PA 20120105??? 37.35.32.0/19??? ALLOCATED PA 20120724??? 5.157.128.0/17??? ALLOCATED PA 20101217??? 2a03:8800::/32 On the third place in our list we have ro.swift (now Media Trend Sistem SRL, formerly using the company Swift Marketing SRL). Swift Marketing SRL (nice name, huh?) was deleted from the Trade Registry in may 2011. During 2010 they had 0 employees. The new company, Media Trend Sistem SRL (CIF 26301830) is registered since december 2009 and was known under another name (not publicly available) until changing it's name to the current one in december 2010. They are also not registered as an ISP with ANCOM and had 0 employees in 2011. This didn't seem to stop them from receiving the following IP ranges from RIPE: 20070730??? 78.95.0.0/16??? ALLOCATED PA 20080319??? 93.168.0.0/15??? ALLOCATED PA 20090303??? 95.218.0.0/15??? ALLOCATED PA 20110518??? 2a00:aa80::/32 Another interesting Romanian LIR is ro.ssnet (SISTEM SOFT NETWORK SRL). The company is registered with the Trade Register with CIF 24496484 since september 2008, had in 2011 only 1 employee and is not a registered ISP with ANCOM. They became LIR just a few months before the final /8 was reached in RIPE region. They only got from RIPE this /15: 20120719??? 5.154.0.0/15??? ALLOCATED PA They also seem to like deaggregating very much [8], now originating 369 prefixes. Now with all this in sight I suppose the ro.registry issue of about an /14 block seems a rather small issue. [1] https://www.ripe.net/ripe/docs/ripe-553 [2] http://www.ip.ro/ip.html [3] ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt [4] http://www.visnet.ro/despre/ [5] http://www.mfinante.ro/agenticod.html [6] http://www.ancom.org.ro/furnizoricomunicatii-electronice_133 [7] http://bgp.he.net/AS49687#_prefixes [8] http://bgp.he.net/AS56465#_prefixes From michieldeweger at centuryconsulting.nl Tue Jan 15 18:39:09 2013 From: michieldeweger at centuryconsulting.nl (Dr Michiel de Weger) Date: Tue, 15 Jan 2013 18:39:09 +0100 Subject: [anti-abuse-wg] (no subject) Message-ID: <3C16D0C4B9D9451DBDE34CDF5D7284EE.MAI@hostingenregistratie.nl> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Invitation final symposium Clean IT (2).pdf Type: application/pdf Size: 80174 bytes Desc: not available URL: From peter at hk.ipsec.se Tue Jan 15 20:29:11 2013 From: peter at hk.ipsec.se (peter h) Date: Tue, 15 Jan 2013 20:29:11 +0100 Subject: [anti-abuse-wg] (Long) rant about some LIRs in RIPE region, most likely linked to RFG's earlier email In-Reply-To: <1358270019.95063.YahooMailNeo@web171606.mail.ir2.yahoo.com> References: <1358270019.95063.YahooMailNeo@web171606.mail.ir2.yahoo.com> Message-ID: <201301152029.12444.peter@hk.ipsec.se> On Tuesday 15 January 2013 18.13, Vasile Capdefier wrote: > Disclaimer: this is just my POV, I didn't investigate (too) much/deep. All the information bellow is public, easy to find and Google Translate seems to work most of the times. > > >From what I know, Jump.RO's business model is to *sell* IP space from their ALLOCATED PA ranges received from RIPE. Not *sub-allocate*, not *assign* or similar terms. They don't ask too many questions. They give you IPs faster than other LIRs. They market this as being professional. > > All of the Jump.RO's sub-allocations (that I've seen in whois) have *ASSIGNED PA* status, which according to ripe-553 [1] is to be used when the range is assigned to an end user for services provided by the issuing LIR. This is probably not the case because except the (new) annual fee for the registration service there are no other services provided by that LIR to the end user. > > Most of Jump.RO's "end users" are in fact small ISPs that can't afford the RIPE membership fees and bypass the rules of not using PI space for customers by deaggregating Jump's IP space. I don't know about the 12k number, but they have a large client base in the country and neighboring countries. > > I also think that Jump is aware of their IPs being in use by spammers as they advertise on their website that new and unused IP blocks cost about 2 times more than "used" ones. They also note that the previously "used" PA space is checked with "MxToolBox" in 120 anti-spam lists [2]. > > Even though Jump.RO's business model isn't exactly in the spirit of the RIPE region rules or following best practices (no prefix aggregation, but their excuse is that they are not the only ones doing it), I don't think that they are willing to risk their LIR status by defending known spam operations, so reporting well documented cases of false information provided during registration first to RIPE and then to them would probably get them to withdraw the PA from that customer. The ranges found by you clearly suggest that fake information has been used. Only "under construction" sites, nobody ever heard of those companies, all using same ISPs. > > With all this said about ro.registry (Jump.RO's LIR id) i'd like to add the following. There are entire LIRs with very large IP allocations and suspicious activities. I'll just list here a few: > > (RIPE allocation list publicly available here [3]) Thank you very much, another 1111040 addresses added to my spamblock list. -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From rfg at tristatelogic.com Tue Jan 15 22:15:36 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 15 Jan 2013 13:15:36 -0800 Subject: [anti-abuse-wg] (Long) rant about some LIRs in RIPE region, most likely linked to RFG's earlier email In-Reply-To: <1358270019.95063.YahooMailNeo@web171606.mail.ir2.yahoo.com> Message-ID: <90517.1358284536@tristatelogic.com> In message <1358270019.95063.YahooMailNeo at web171606.mail.ir2.yahoo.com>, Vasile Capdefier wrote: >Disclaimer: this is just my POV, I didn't investigate (too) much/deep... That's all very interesting information, however with the exception of the various fradulent ASNs that I reported, all tied in very substantial ways to JUMP.RO itself, the only other one of the Romanian entities that you named that I have been aware of, in the past, as being at the root of either security or spam issues is Swift Marketing SRL. Regards, rfg P.S. Someone (I don't know who) took it upon himself/herself to file a report... or perhaps several reports... relating to the report that I posted here yesterday, with RIPE NCC. As a result, my inbox this morning contained (in addition to a couple of messsgaes from friends and the usual smattering of spam) no fewer that SEVENTEEN separate automated messages from RIPE NCC, asking me to click on various URLs/links in order to confirm my report(s) to the RIPR NCC. It seems to me that there are only two plausible explanations for this: 1) Some unhelpful person filed a report with RIPE NCC regarding my allegations, but used my name and e-mail address when filing the report, and then RIPE NCC's automated system for responding to such reports went bonkers and decided to send me seventeen separate requests to confirm ``my'' report. (In this case, some programmer @ RIPE should really fix their broken report handling system.) 2) Some unhelpful person or set of persons elected to file seventeen separate reports relating to my allegations with RIPE NCC, using my name and my e-mail address in all cases in order to make it look like the reports came from me (which they didn't), thus causing me to receive a mini-mailbomb from RIPE NCC. In either case it would appear that someone is improperly filing reports while pretending to be me, and I would ask that whoever is doing this to please stop. Doing this is rather utterly pointless because I will *not* be responding in any way to RIPE's seventeen requests to me to confirm the validity of ``my'' report(s) to them. (Note that even if I was feeling generous, I would not do so because the automated messages to me from RIPE do not give any indication of what is actually in the reports that I am being asked to validate! For all I know, some miscreant may have filed a report with RIPE claiming that the moon is made of green cheese. If I validated that, using RIPE's automated system, then effectively *I* would be responsible for filing that preposterous and utterly irrelevant claim with RIPE.) If anyone wants to make a report to RIPE NCC about any of the material that I posted here yesterday, please be my guest. However please have the courtesy to use your own name and e-mail address when doing so, not mine. From peter at hk.ipsec.se Tue Jan 15 22:57:26 2013 From: peter at hk.ipsec.se (peter h) Date: Tue, 15 Jan 2013 22:57:26 +0100 Subject: [anti-abuse-wg] (no subject) In-Reply-To: <3C16D0C4B9D9451DBDE34CDF5D7284EE.MAI@hostingenregistratie.nl> References: <3C16D0C4B9D9451DBDE34CDF5D7284EE.MAI@hostingenregistratie.nl> Message-ID: <201301152257.26921.peter@hk.ipsec.se> On Tuesday 15 January 2013 18.39, Dr Michiel de Weger wrote: > Please forward this open invitation for a symposium on terrorist use of the Internet, organized by Clean IT, the much discussed European project. > > What mechanisms are available to reclaim these networks ? -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From ops.lists at gmail.com Sat Jan 19 16:57:48 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 19 Jan 2013 21:27:48 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: References: <73421.1358203969@tristatelogic.com> <9AF9C3CA-29BE-4E41-8CD6-920C21A59C78@steffann.nl> Message-ID: On Tue, Jan 15, 2013 at 6:27 AM, Suresh Ramasubramanian wrote: > Problems with excessively large allocations by romanian LIRs to spam > operations has been a problem over the last few years at least, so that > ripe ncc might want to take cognizance of all this information do a > proactive audit of all allocations over a period of time done through a > particular LIRs, rather than play whack a mole with manually reported > netblocks. This is a list of RIPE assigned pi / pa netblocks that are in spamhaus .. quite a few in the past few days, large ones too. Mostly romania / eastern europe, for one reason or the other.. http://www.spamhaus.org/sbl/listings/ripe -- Suresh Ramasubramanian (ops.lists at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat Jan 19 17:24:34 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 19 Jan 2013 17:24:34 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: References: <73421.1358203969@tristatelogic.com> <9AF9C3CA-29BE-4E41-8CD6-920C21A59C78@steffann.nl> Message-ID: <879A3743-07E6-411C-AE53-E3BC06C3585E@steffann.nl> Hi, > This is a list of RIPE assigned pi / pa netblocks that are in spamhaus .. quite a few in the past few days, large ones too. Mostly romania / eastern europe, for one reason or the other.. > > http://www.spamhaus.org/sbl/listings/ripe Being listed by Spamhaus is not a reason to revoke address space. There is no such policy in the RIPE region, and I think it is very unlikely that the whole RIPE community will agree to let one organisation veto anybody's right to address space. There have been incidents in the past where Spamhaus listings were very controversial. Now if anyone sees that there has been fraud, people lying to the RIPE NCC, people lying about their need for address space, etc. then that is in violation of the RIPE policies and the RIPE NCC Service Contract. In those cases the RIPE NCC can act and has the mandate of the members to act. With 8800+ members it is not possible to audit all of them all the time, so helpful information about fraud are very helpful for the RIPE NCC to target their audits. Cheers, Sander From peter at hk.ipsec.se Sat Jan 19 17:28:55 2013 From: peter at hk.ipsec.se (peter h) Date: Sat, 19 Jan 2013 17:28:55 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <879A3743-07E6-411C-AE53-E3BC06C3585E@steffann.nl> References: <73421.1358203969@tristatelogic.com> <879A3743-07E6-411C-AE53-E3BC06C3585E@steffann.nl> Message-ID: <201301191728.56389.peter@hk.ipsec.se> On Saturday 19 January 2013 17.24, Sander Steffann wrote: > Hi, > > > This is a list of RIPE assigned pi / pa netblocks that are in spamhaus .. quite a few in the past few days, large ones too. Mostly romania / eastern europe, for one reason or the other.. > > > > http://www.spamhaus.org/sbl/listings/ripe > > Being listed by Spamhaus is not a reason to revoke address space. There is no such policy in the RIPE region, and I think it is very unlikely that the whole RIPE community will agree to let one organisation veto anybody's right to address space. There have been incidents in the past where Spamhaus listings were very controversial. > > Now if anyone sees that there has been fraud, people lying to the RIPE NCC, people lying about their need for address space, etc. then that is in violation of the RIPE policies and the RIPE NCC Service Contract. In those cases the RIPE NCC can act and has the mandate of the members to act. With 8800+ members it is not possible to audit all of them all the time, so helpful information about fraud are very helpful for the RIPE NCC to target their audits. > To be listed as spammer may in itself not be a reason to revoke addresses. But it should be enough to start an investigation, for instance mail the address"owners" and ask for a comment. If they cannot be reached then revokation comes closer .... > Cheers, > Sander > > > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From ops.lists at gmail.com Sat Jan 19 17:48:35 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 19 Jan 2013 22:18:35 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <201301191728.56389.peter@hk.ipsec.se> References: <73421.1358203969@tristatelogic.com> <879A3743-07E6-411C-AE53-E3BC06C3585E@steffann.nl> <201301191728.56389.peter@hk.ipsec.se> Message-ID: Call it yet another data point for RIPE NCC to use, proactiely.. Spamhaus listings and controversy - well, there have been earlier cases where they have escalated to cover an ISP (say), where several ranges in that ISP's IP space were infested. Several of those assigned PI / PA netblocks appear to be cybercrime controlled though. With 8800 customers, well - it simply means RIPE NCC needs to learn from, say, a bank manager, on what'd happen to him if he sanctioned a bank loan on the strength of the same weird and wonderful paperwork with which RIPE NCC ocasionally sanctions a /16 or larger. "We are not the X police" doesn't quite gel with the fiduciary responsibility they have as trustees of a globally shared, finitely available resource. On Saturday, January 19, 2013, peter h wrote: > On Saturday 19 January 2013 17.24, Sander Steffann wrote: > > Hi, > > > > > This is a list of RIPE assigned pi / pa netblocks that are in spamhaus > .. quite a few in the past few days, large ones too. Mostly romania / > eastern europe, for one reason or the other.. > > > > > > http://www.spamhaus.org/sbl/listings/ripe > > > > Being listed by Spamhaus is not a reason to revoke address space. There > is no such policy in the RIPE region, and I think it is very unlikely that > the whole RIPE community will agree to let one organisation veto anybody's > right to address space. There have been incidents in the past where > Spamhaus listings were very controversial. > > > > Now if anyone sees that there has been fraud, people lying to the RIPE > NCC, people lying about their need for address space, etc. then that is in > violation of the RIPE policies and the RIPE NCC Service Contract. In those > cases the RIPE NCC can act and has the mandate of the members to act. With > 8800+ members it is not possible to audit all of them all the time, so > helpful information about fraud are very helpful for the RIPE NCC to target > their audits. > > > To be listed as spammer may in itself not be a reason to revoke addresses. > But it should be enough to > start an investigation, for instance mail the address"owners" and ask for > a comment. If they > cannot be reached then revokation comes closer .... > > Cheers, > > Sander > > > > > > > > > > -- > Peter H?kanson > > There's never money to do it right, but always money to do it > again ... and again ... and again ... and again. > ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) > > -- --srs (iPad) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Sat Jan 19 23:36:59 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 19 Jan 2013 14:36:59 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: Message-ID: <71369.1358635019@tristatelogic.com> In message Suresh Ramasubramanian wrote: >http://www.spamhaus.org/sbl/listings/ripe I frankly am inclined to wonder when/if Spamhaus will get around to listing all of the romanian ASNs and IPv4 ranges that I listed here a couple of days ago. As far as I can see, it is all 100% fradulent and all 100% being used for snowshoe support. Furthermore, I do not believe that this fact is really all that hard to discern/verify, once the ASNs have been identified. Regards, rfg From rfg at tristatelogic.com Sat Jan 19 23:49:30 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 19 Jan 2013 14:49:30 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <879A3743-07E6-411C-AE53-E3BC06C3585E@steffann.nl> Message-ID: <71630.1358635770@tristatelogic.com> In message <879A3743-07E6-411C-AE53-E3BC06C3585E at steffann.nl>, Sander Steffann wrote: >Now if anyone sees that there has been fraud, people lying to the RIPE >NCC, people lying about their need for address space, etc. then that is >in violation of the RIPE policies and the RIPE NCC Service Contract. In >those cases the RIPE NCC can act and has the mandate of the members to >act. For the benefit of someone... me, in particular... who is not only not a RIPE member, but who is also even physically located outside of the RIPE region, could you elaborate a bit on this "mandate" you speak of? I'm really just curious about one thing. For its region, ARIN actually has an explicit policy that in the event of any person or entity being caught deliberately defrauding ARIN, ARIN will (allegedly[1]) make contact with law enforcement authorities, inform them of the fraud, and (I believe) ask those authorities to take action against the perpetrator(s). It is certainly pleasing to know that RIPE NCC already has in its hand an explicit mandate from the membership to take action to undo the effects of any fraud or frauds that have been perpetrated against it, however I cannot help but be curious as to whether or not that is the outer limit of RIPE NCC's mandate with regards to such incidents. Regards, rfg =-=-=-=-=-=-=-=-=-=-= [1] I am forced to insert the qualifier "allegedly" here because... much to my dismay... I personally am not aware of any actual instance where any fraud artist who has cleverly managed to defaud ARIP out of number resources have ever faced any sort of arrest, let alone any sort of actual prosecution. (Not that there have not been numerous worthy candidates.) From rfg at tristatelogic.com Sun Jan 20 00:03:43 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 19 Jan 2013 15:03:43 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <201301191728.56389.peter@hk.ipsec.se> Message-ID: <71920.1358636623@tristatelogic.com> In message <201301191728.56389.peter at hk.ipsec.se>, peter h wrote: >To be listed as spammer may in itself not be a reason to revoke addresses. >But it should be enough to >start an investigation, for instance mail the address"owners" and ask for a > comment. If they >cannot be reached then revokation comes closer .... Having investigated a number of these kinds of things over a period of time I'd just like to say that responses obtained via either e-mail or via snail-mail are entirely less than definitive when one is trying to determine the truth. A reply e-mail can say anything, can contain any sort of a made up story that the sender wishes to fabricate, and can easily be made to appear to come from pretty much any domain that the responding party has control over. Likewise, snail-mails may spin any desired legend, and can (and have) included utterly made-up letterheads and envelopes and such other things as may seem to support the overall deception. Usually however, there is a finite and small number of individuals behind this sort of thing, so that requiring contact, at some mutually convenient time, via telephone can most likely flush out the fraud most efficiently. If it is always the exact same voice on the other end of the line... even when one is speaking to a number of allegedly separate and independent companies, then, to paraphrase William Shakespeare, it should be altogether apparent that something is rotten in Romania. Regards, rfg From sander at steffann.nl Sun Jan 20 00:50:11 2013 From: sander at steffann.nl (Sander Steffann) Date: Sun, 20 Jan 2013 00:50:11 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <71630.1358635770@tristatelogic.com> References: <71630.1358635770@tristatelogic.com> Message-ID: <2C4F5FA7-C670-4253-AE43-0C4BF5DE1A21@steffann.nl> Hi, > For the benefit of someone... me, in particular... who is not only not > a RIPE member, but who is also even physically located outside of the > RIPE region, could you elaborate a bit on this "mandate" you speak of? Well, all resource holders must sign a contract these days, and there is an official procedure called 'Closure of Member and Deregistration of Internet Number Resources': https://www.ripe.net/ripe/docs/ripe-578. All members signed the Standard Service Agreement, of which ripe-578 is an integral part. RIPE-578 contains the following text about fraudulent LIRs: ---8<--- Untruthful information ====================== The RIPE NCC concludes the SSA and provides services to Members in good faith. The Member is in breach of good faith in the following cases: - Falsified/incorrect information If the Member repeatedly provides falsified data or information, or purposefully and/or repeatedly provides incorrect data or information (for example, falsified registration documents or IDs, incorrect/inaccurate contact details, etc.) - Fraudulent requests If the Member submits repeatedly fraudulent requests for Internet number resources (for example, providing incorrect purpose/need or falsified information about the network, etc.) Procedure ========= The RIPE NCC will: - Send an email to the registered contact(s) indicating: - The reason for termination of the SSA - The immediate termination of the SSA - Terminate the progress of any open requests for RIPE NCC services The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member?s account) to all registered postal and email addresses of the Member. ---8<--- And terminating the SSA (Standard Service Agreement) means: "Upon termination of the SSA, Members lose all rights to RIPE NCC services and their RIPE NCC member status." That section contains the text "The RIPE NCC will deregister the relevant Internet number resource records. The procedure for deregistration is described in section B.2. The RIPE NCC will also revoke any certificates generated by the RIPE NCC Certification Service." And that also includes independent (PI) resources they hold: "The RIPE NCC will send an official notification to all registered contacts stating that the Independent Internet number resources will be deregistered, explaining the reasons for this deregistration and the procedure for the deregistration. The Member must immediately inform the End User about the imminent deregistration." So yes: the NCC can act on fraud and deregister the resources. > I'm really just curious about one thing. For its region, ARIN actually > has an explicit policy that in the event of any person or entity > being caught deliberately defrauding ARIN, ARIN will (allegedly[1]) > make contact with law enforcement authorities, inform them of the > fraud, and (I believe) ask those authorities to take action against > the perpetrator(s). The RIPE documents don't say anything about the RIPE NCC contacting law enforcement AFAIK. With all the different countries and all their different laws that might be harder to do for the RIPE NCC than in the ARIN region. But if it's possible: good idea. > It is certainly pleasing to know that RIPE NCC already has in its hand an > explicit mandate from the membership to take action to undo the effects > of any fraud or frauds that have been perpetrated against it, however > I cannot help but be curious as to whether or not that is the outer > limit of RIPE NCC's mandate with regards to such incidents. I think it's all in RIPE-578. Cheers, Sander From richih.mailinglist at gmail.com Sun Jan 20 00:40:16 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sun, 20 Jan 2013 00:40:16 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <71920.1358636623@tristatelogic.com> References: <201301191728.56389.peter@hk.ipsec.se> <71920.1358636623@tristatelogic.com> Message-ID: On Sun, Jan 20, 2013 at 12:03 AM, Ronald F. Guilmette wrote: > Usually however, there is a finite and small number of individuals > behind this sort of thing, so that requiring contact, at some mutually > convenient time, via telephone can most likely flush out the fraud > most efficiently. If it is always the exact same voice on the other > end of the line... even when one is speaking to a number of allegedly > separate and independent companies, then, to paraphrase William > Shakespeare, it should be altogether apparent that something is > rotten in Romania. > I have done the complete paperwork and RIPE interfacing for several of our customers who we are sponsoring PI space and AS numbers for. Matter of fact, this is the default mode of operation for us. This is _precisely_ what tech-c is for and quite common. The same applies to any customer wanting to become a LIR themselves and buying consultation from us. Assuming a phone-in system was introduced and ignoring the obvious issues with recognizing voices that any hostmaster may or may not have heard at some time before, I would introduce myself as tech-c, tell the hostmaster that I would hand over to admin-c who is not very deep into understanding the matter at hand, and they would basically confirm everything I said. Exactly the same process and outward appearance for valid and fraudulent requests. Even though I may disagree with your proposed solution, talking about specific concerns and/or suggestions as per above is vastly preferable over what amounts to grandstanding and refusing to fill out a simple form, and quite vocally so. This is especially puzzling since you already did the detective work and provided apparently useful information. It's a pity to get side-tracked, really. I suggest focusing on actual WG discourse on this list. Thank you for said detective work, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Sun Jan 20 02:37:12 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 19 Jan 2013 17:37:12 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: Message-ID: <72974.1358645832@tristatelogic.com> In message Richard Hartmann wrote: >Assuming a phone-in system was introduced and ignoring the obvious issues >with recognizing voices that any hostmaster may or may not have heard at >some time before, I would introduce myself as tech-c, tell the hostmaster >that I would hand over to admin-c who is not very deep into understanding >the matter at hand, and they would basically confirm everything I said. > >Exactly the same process and outward appearance for valid and fraudulent >requests. First, allow me to be clear that I was not suggeting any long-term or generally applicable "system" for verifying/validating RIPE resource registrants. My simple "phone contact" suggestion was only put forward with reference to this one rather entirely unusual situation where the true ownership of numerous resources is now in doubt. Leaving that point aside however, I gather you are trying to say that my simple phone validation idea/suggestion would not work, however I'm not at all sure that I see your reasoning. I guess that the admin-c person is supposed to represent the true registrant of the resource. If so, and if all of the admin-c persons reached by phone had exactly the same voice (e.g baratone), exactly the same manner of speech, and exactly the same accent, wouldn't that tend to strongly confirm that something is amiss? >Even though I may disagree with your proposed solution, talking about >specific concerns and/or suggestions as per above is vastly preferable >over what amounts to grandstanding and refusing to fill out a simple form, >and quite vocally so. I hereby apologize for any grandstanding that I may have engaged in. Please put it down to my fervent desire that the matter I reported on should be investigated, throughly and promptly. As regards my reluntance to engage with RIPE NCC on any kind of a formal basis, although that too may be unforgivable, allow me to point out what I feel is a relevant point, specifically that the free flow of information is, as we here in the states would say, a two-way street... or should be anyway. Since my original post on this matter, a RIPE NCC staff member has reached out to me, and in an informal manner I have appraised her throughly of the various lines of evidence that formed the basis of my suspicions about these specific 18 ASNs. In a follow-up to this, I inquired as to how much I might be told, and when, with regards to RIPE NCC's investigation of this matter, stating up-front that I understood that RIPR NCC staff might possibly labor under some of the same con- straints as ARIN staff do with regards to this kind of investigation, and their ability for be forthcoming, either publically or privately, about either investigation results, or actions taken. I was then politely informed that yes indeed, RIPE secrecy rules are not materially different from those of ARIN with respect to these kinds of investigations. In short, it appears that none of us will ever know anything, either about how this happened, why it happened, who was responsible (within Romania) for causing it to happen, or what actions, if any, RIPE NCC will take in response to this matter. (I sort of feel like I want to use the term "this incident" rather than "this matter", but it appears that this has not been so much an "event" as it has been a process. The data seem to indicate that the fraudlent scheme I reported on has been ongoing for over two years now.) Anyway, it may come as no surprise when I say that this information flow "one way street" is less than satisfying. In fact that would be an understatement. And if one thinks about it, this cloak of secrecy that hides all... all noble actions and all skullduggery, without discrimination... may be a part of the reason that other people of generosity and good intent, unlike me, do not waste their time on looking to deeply into funny stuff on this Internet, let alone reporting any such. Why bother when it is a forgone conclusion that the whole thing will be hushed up in the end anyway, and, as far as anyone of the outside knows, neither any drop of justice nor any dollop of disipline is ever dispensed. Thinking about it, just in the last day or two I've realized that RIPE, ARIN, IANA, ICANN, and all such authorities are in many ways quite analogous to our Federal Reserve here in the United States. In both cases, the entities have much authority and are widely perceived as having charters that somehow commit them to pursuit of the public good. But in both cases, the reality is rather different... these entities are in fact merely commercial associations of business interests that are pledged, if not by law then by contract, to never reveal even a smidgeon of their commercial member's dirty laundry to any "outsider", and their iron-clad commitment to this goal always takes precedence over any other consideration. In the United States, and because of our Freedom of Information Act, Bloomberg News was ultimately able to extract from the Feredal Reserve the various dirty secrets of the largess that the Fed had doled out to its members during the financial crisis. The airing of this dirty laundry shocked the nation, and led to many aspects of the final Dodd-Frank financial reform act aimed at disallowing any future screwings of the Amercian public for the benefit of the various large Federal Reserve member banks (and in particular the ones that were most directly responsible for having created the crisis in the first place). All I can say is that I wish that I had as much money as Bloomberg News. If I did, I would most definitely seek the juducious application of our federal FOIA, both to the Commerce Department generated entity known as ICANN, and thence also to the lower level entities that it has spawed or sponsored, namely IANA, ARIN, RIPE, APNIC, LACNIC, and AFRINIC. (Although I'm sure that even the mere suggestion will likely outrage all of you europeans, it is my contention that ultimately, and for anyone with enough money to pursue it, all of these entities would ultimately be found to be subject to U.S. law generally, and to FOIA, specifically.) I think this is the only way the counterproductive shroud of secrecy will ever be lifted, and by extension, I think that this is the only way that any of these entities might ever actually be called upon to serve the public good, in preference to the private commercial good of their respective memberships, unlike the present situation where the private commercial interests trump the public's need to know at every turn. My apologies for the length of this posting. Regards, rfg From rfg at tristatelogic.com Sun Jan 20 02:43:35 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 19 Jan 2013 17:43:35 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <2C4F5FA7-C670-4253-AE43-0C4BF5DE1A21@steffann.nl> Message-ID: <73019.1358646215@tristatelogic.com> In message <2C4F5FA7-C670-4253-AE43-0C4BF5DE1A21 at steffann.nl>, Sander Steffann wrote: >The RIPE documents don't say anything about the RIPE NCC contacting law >enforcement AFAIK. With all the different countries and all their >different laws that might be harder to do for the RIPE NCC than in the >ARIN region. But if it's possible: good idea. It is not only possible... as the ARIN example would seem to indicate it is even _advisable_. What is the disincentive for these same crooks coming back and doing the same thing all over again next month, using a brand new set of fradulent documents, signatures, company charters, etc. ? Regards, rfg From kjz at gmx.net Sun Jan 20 12:55:09 2013 From: kjz at gmx.net (Karl-Josef Ziegler) Date: Sun, 20 Jan 2013 12:55:09 +0100 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 17, Issue 11 Message-ID: <50FBDB1D.4070301@gmx.net> > Thinking about it, just in the last day or two I've realized that > RIPE, ARIN, IANA, ICANN, and all such authorities are in many ways > quite analogous to our Federal Reserve here in the United States. In > both cases, the entities have much authority and are widely perceived > as having charters that somehow commit them to pursuit of the public > good. But in both cases, the reality is rather different... these > entities are in fact merely commercial associations of business > interests that are pledged, if not by law then by contract, to never > reveal even a smidgeon of their commercial member's dirty laundry to > any "outsider", and their iron-clad commitment to this goal always > takes precedence over any other consideration. I agree. The main goal of these organisations for me seems to be not protecting public goods but protecting the commercial interests of their members. So they aren't nonprofit organizations? Best regards, - Karl-Josef Ziegler From sander at steffann.nl Sun Jan 20 22:37:44 2013 From: sander at steffann.nl (Sander Steffann) Date: Sun, 20 Jan 2013 22:37:44 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <72974.1358645832@tristatelogic.com> References: <72974.1358645832@tristatelogic.com> Message-ID: Hi Ronald, > As regards my reluntance to engage with RIPE NCC on any kind of a formal > basis, although that too may be unforgivable, allow me to point out > what I feel is a relevant point, specifically that the free flow of > information is, as we here in the states would say, a two-way street... > or should be anyway. > > Since my original post on this matter, a RIPE NCC staff member has reached > out to me, and in an informal manner I have appraised her throughly of > the various lines of evidence that formed the basis of my suspicions > about these specific 18 ASNs. In a follow-up to this, I inquired as > to how much I might be told, and when, with regards to RIPE NCC's > investigation of this matter, stating up-front that I understood > that RIPR NCC staff might possibly labor under some of the same con- > straints as ARIN staff do with regards to this kind of investigation, > and their ability for be forthcoming, either publically or privately, > about either investigation results, or actions taken. I was then > politely informed that yes indeed, RIPE secrecy rules are not materially > different from those of ARIN with respect to these kinds of investigations. > > In short, it appears that none of us will ever know anything, either > about how this happened, why it happened, who was responsible (within > Romania) for causing it to happen, or what actions, if any, RIPE NCC > will take in response to this matter. (I sort of feel like I want to > use the term "this incident" rather than "this matter", but it appears > that this has not been so much an "event" as it has been a process. > The data seem to indicate that the fraudlent scheme I reported on has > been ongoing for over two years now.) > > Anyway, it may come as no surprise when I say that this information > flow "one way street" is less than satisfying. In fact that would > be an understatement. And if one thinks about it, this cloak of > secrecy that hides all... all noble actions and all skullduggery, > without discrimination... may be a part of the reason that other > people of generosity and good intent, unlike me, do not waste their > time on looking to deeply into funny stuff on this Internet, let > alone reporting any such. Why bother when it is a forgone conclusion > that the whole thing will be hushed up in the end anyway, and, as > far as anyone of the outside knows, neither any drop of justice > nor any dollop of disipline is ever dispensed. Now *this* is something that might be solved by a policy proposal. How about a policy that states that a list of all resources reclaimed by/returned to/delegated to the RIPE NCC must be published? I don't know about the legal implications of also publishing the company name etc of the last holder, but how about a list containing: - Resource - Reclaimed date - Reason (received from IANA, returned by holder, violation of policy, bankruptcy, court order, non-payment, fraud/untruthful information, etc) - Returned to pool date I am trying to find the balance between avoiding legal trouble for the RIPE NCC (IANAL etc, so I don't know what is acceptable under Dutch law) and giving feedback and showing the community what is being done. The NCC already publishes the resources it allocates/assigns (output list). What I propose is that they also publish what they receive (input list). Showing both sides of the story would be part of good stewardship etc. /me looks at the worms crawling out of the can... What do you (=AAWG) think? Sander From shane at time-travellers.org Mon Jan 21 10:39:15 2013 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 21 Jan 2013 10:39:15 +0100 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 17, Issue 11 In-Reply-To: <50FBDB1D.4070301@gmx.net> References: <50FBDB1D.4070301@gmx.net> Message-ID: <20130121103915.0b101a64@shane-desktop> Karl-Josef, On Sunday, 2013-01-20 12:55:09 +0100, Karl-Josef Ziegler wrote: > > Thinking about it, just in the last day or two I've realized that > > RIPE, ARIN, IANA, ICANN, and all such authorities are in many ways > > quite analogous to our Federal Reserve here in the United States. In > > both cases, the entities have much authority and are widely > > perceived as having charters that somehow commit them to pursuit of > > the public good. But in both cases, the reality is rather > > different... these entities are in fact merely commercial > > associations of business interests that are pledged, if not by law > > then by contract, to never reveal even a smidgeon of their > > commercial member's dirty laundry to any "outsider", and their > > iron-clad commitment to this goal always takes precedence over any > > other consideration. > > I agree. The main goal of these organisations for me seems to be not > protecting public goods but protecting the commercial interests of > their members. So they aren't nonprofit organizations? My take on it is that there are basically two kinds of nonprofit organizations: 1. Organizations that vaccinate orphans, dig wells to provide clean water, investigate corruption, and so on. These are non-profit because they are fundamentally engaged in activities that cost money instead of earning it. 2. Organizations that provide a needed "neutral ground" for businesses to operate, such as standards making bodies or consortia managing when and where cables can be laid down. These are non-profit because the profit motive would create a conflict of interest with the businesses they were created to serve. There are other organizations that don't fit this, like credit unions (non-profit banks), but I think it covers the majority. In general the first type of non-profit is poor and the second type is well-off. The thing about the RIPE NCC and the other RIRs is that the world has for some reason assumed that they fit into category #1 ("they exist for the good of the Internet!"). I would argue that the RIPE NCC and the other RIRs are very firmly in category #2 ("we are an industry association"). It is a pity that none of the RIRs have never done anything to change this idea, but I can understand why not. Would you rather be an organization that shuffles paperwork or one that is there to make the world a better place? :) Anyway, I'll reply to the notion of opening up abuse investigations in a mail to Sander's specific proposal. Cheers, -- Shane From ops.lists at gmail.com Mon Jan 21 10:49:58 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 21 Jan 2013 15:19:58 +0530 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 17, Issue 11 In-Reply-To: <20130121103915.0b101a64@shane-desktop> References: <50FBDB1D.4070301@gmx.net> <20130121103915.0b101a64@shane-desktop> Message-ID: The thing is, if such an association as you describe is given a fiduciary role, as a trustee of IP addresses, not caring whether the member it enforces policy against is an extra large LIR or some small outfit with a /20 PI / PA space should be a given. As should a readiness to enforce their policies instead of declining to become the "Internet police", which itself is one of the worst cliches ever. On Monday, January 21, 2013, Shane Kerr wrote: > Karl-Josef, > > On Sunday, 2013-01-20 12:55:09 +0100, > Karl-Josef Ziegler > wrote: > > > Thinking about it, just in the last day or two I've realized that > > > RIPE, ARIN, IANA, ICANN, and all such authorities are in many ways > > > quite analogous to our Federal Reserve here in the United States. In > > > both cases, the entities have much authority and are widely > > > perceived as having charters that somehow commit them to pursuit of > > > the public good. But in both cases, the reality is rather > > > different... these entities are in fact merely commercial > > > associations of business interests that are pledged, if not by law > > > then by contract, to never reveal even a smidgeon of their > > > commercial member's dirty laundry to any "outsider", and their > > > iron-clad commitment to this goal always takes precedence over any > > > other consideration. > > > > I agree. The main goal of these organisations for me seems to be not > > protecting public goods but protecting the commercial interests of > > their members. So they aren't nonprofit organizations? > > My take on it is that there are basically two kinds of nonprofit > organizations: > > 1. Organizations that vaccinate orphans, dig wells to provide clean > water, investigate corruption, and so on. These are non-profit > because they are fundamentally engaged in activities that cost money > instead of earning it. > > 2. Organizations that provide a needed "neutral ground" for businesses > to operate, such as standards making bodies or consortia managing > when and where cables can be laid down. These are non-profit because > the profit motive would create a conflict of interest with the > businesses they were created to serve. > > There are other organizations that don't fit this, like credit unions > (non-profit banks), but I think it covers the majority. In general the > first type of non-profit is poor and the second type is well-off. > > The thing about the RIPE NCC and the other RIRs is that the world has > for some reason assumed that they fit into category #1 ("they exist for > the good of the Internet!"). I would argue that the RIPE NCC and the > other RIRs are very firmly in category #2 ("we are an industry > association"). > > It is a pity that none of the RIRs have never done anything to change > this idea, but I can understand why not. Would you rather be an > organization that shuffles paperwork or one that is there to make the > world a better place? :) > > Anyway, I'll reply to the notion of opening up abuse investigations in > a mail to Sander's specific proposal. > > Cheers, > > -- > Shane > > -- --srs (iPad) -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Mon Jan 21 10:52:43 2013 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 21 Jan 2013 10:52:43 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: References: <72974.1358645832@tristatelogic.com> Message-ID: <20130121105243.04109468@shane-desktop> Sander, On Sunday, 2013-01-20 22:37:44 +0100, Sander Steffann wrote: > > Anyway, it may come as no surprise when I say that this information > > flow "one way street" is less than satisfying. In fact that would > > be an understatement. And if one thinks about it, this cloak of > > secrecy that hides all... all noble actions and all skullduggery, > > without discrimination... may be a part of the reason that other > > people of generosity and good intent, unlike me, do not waste their > > time on looking to deeply into funny stuff on this Internet, let > > alone reporting any such. Why bother when it is a forgone > > conclusion that the whole thing will be hushed up in the end > > anyway, and, as far as anyone of the outside knows, neither any > > drop of justice nor any dollop of disipline is ever dispensed. > > Now *this* is something that might be solved by a policy proposal. I agree. > How about a policy that states that a list of all resources reclaimed > by/returned to/delegated to the RIPE NCC must be published? I don't > know about the legal implications of also publishing the company name > etc of the last holder, but how about a list containing: > - Resource > - Reclaimed date > - Reason (received from IANA, returned by holder, violation of > policy, bankruptcy, court order, non-payment, fraud/untruthful > information, etc) > - Returned to pool date It does not seem to me that merely recording reclaimed resources is really going to get to the heart of the transparency problem. Perhaps something more like a couple of checkboxes on the complaint form which say: [ ] I wish this complaint to be public. [ ] I wish my name to be included in the public report. This way we could have an opt-in public archive of all abuse reports that the RIPE NCC has received. Consider it a sort of RIPE NCC version of the Google Transparency Report. :) http://www.google.com/transparencyreport/ Cheers, -- Shane From sander at steffann.nl Mon Jan 21 11:21:58 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 21 Jan 2013 11:21:58 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <20130121105243.04109468@shane-desktop> References: <72974.1358645832@tristatelogic.com> <20130121105243.04109468@shane-desktop> Message-ID: <40A6A1EE-5F5B-46A3-ACFE-17F69F24EDB1@steffann.nl> Hi, > It does not seem to me that merely recording reclaimed resources is > really going to get to the heart of the transparency problem. Well, the person who filed the complaint/report gets some feedback on whether action has been taken. And the rest of the world can see that the RIPE NCC does act on fraudulent behaviour, which hopefully encourages others to file reports as well. > Perhaps something more like a couple of checkboxes on the complaint form > which say: > > [ ] I wish this complaint to be public. > [ ] I wish my name to be included in the public report. > > This way we could have an opt-in public archive of all abuse reports > that the RIPE NCC has received. Even better! Then we also have an input/output view on the RIPE NCC fraud/complaint handling procedure. Thanks, Sander From rfg at tristatelogic.com Mon Jan 21 12:44:57 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 21 Jan 2013 03:44:57 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <20130121105243.04109468@shane-desktop> Message-ID: <95029.1358768697@tristatelogic.com> In message <20130121105243.04109468 at shane-desktop>, Shane Kerr wrote: >It does not seem to me that merely recording reclaimed resources is >really going to get to the heart of the transparency problem. Well, it would be a good start. Better than nothing. As should be apparent, now, to anyone who seriously investigates the report I made here recently, there are fraudsters on the Internet. (DUH!) And some of them have found, and clearly do find (present tense) that RiRs are enormously easy marks. Some might be inclined to rage against the various RiR staffs for this, but not me. I understand why hyper-vigilance against this sort of thing is probably not the best way for RiRs to spend their limited resources. (Nor is it particularly likely that they will.) Still, there ought to be some way to making this particular sort of crime ether less easy or else less attaractive. Assuming that the former is not really in the cards, I would suggest that more thought be put into the latter. I can't remember where anymore, but somewhere, a long time ago, I read something about crime & punishment that basically said that for crimes that are particularly easy to pull off, it can be easily seen that those specific types of crimes will run rampant _unless_ the punishment for those few who get caught is made extremely harsh... you know, so that anyone in their right mind would really have to think twice before trying it, even in the odds are only one in a hundred of ever actually getting caught. Based on various situations, past and present, that I have brought to light, in the ARIN region, and now in the RIPE region, although I mean no offense to any RiR staff member(s), I have to say that from where I am sitting it appears to me that defrauding an RiR sure looks like it is as easy as pie, _and_ that the probability of ever even getting caught is extremely small. The implications of those facts for any policy that seeks to deter such abuses is, in my mind at least, self evident. The punishment for this sort of hanky panky should be severe, and a head or two on pikes would go a long way towards reducing the likelihood of these events in the future. Public naming and shaming of any and all parties involved should be a part of that, in my opinion, and furthermore I think that a pro- vision which explicitly allows this should be written into all RIPE contracts from now on.... as in "If we catch you doing this, then no, you DON'T get to hide behind any confidentiality provisions within this contract that might otherwise apply." (This would be a good thing to add, going forward, but actually, depending on the wording of existing contracts, that might not even be necessary, i.e. in order for RIPE to be able to name and shame anybody who has an existing contract with RIPR NCC _today_, because any fraud on their part, or any failure... e.g. on the part of an LIR, to properly vet the lower level entities they dole out resources to... is, I would guess, a material breach of contract. And a breach of contract by the other party means, I think, that RIPE NCC is no longer legally obliged to hold up its end of the contract... specifically with respect to confidentiality of the other party.) With respect to this fraudulent scheme I outted the other day, it is possible that one or more LIRs were either behind it or at the very least were happy to collude with the real perps in order to make it possible... as long as they also go a cut of the profits to be made out of this scheme. (And make no mistake about it... spamming is _highly_ profitable.) Me personally? I would like to see the perps named and shamed, _and_ I'd also like to see any LIR that didn't do its job... to properly vet applications for reasources according to established guidelines... or that actively colluded with the real perps... named and shamed, publically, also. To me, this is the absolute least that both prudence and an ordinary sense of justice and fair play would demand. But if it were up to me, I would certainly go further... making criminal referrals, wherever possible and filing civil suits for breach of contract (and the con- cominant damage to RIPE NCC's reputation). Of course, in my ideal universe, one could achieve much the same ends, but much more efficiently, economically, and expediently simply by revoking a up-front performance bond that all parties contracting with RIPE NCC would be required to post before being allocated resources. (Having said that however, let me assure all that I _do_ understand that most probably a majority of all current RIPE members would howl at even the suggestion of what I just said, and that thus, it would never fly, politically, in practice. Nontheless, that doesn't mean it is a bad idea. RIPE has resources which it loans out to other parties to use for a time, and those resources can be damaged, or can be made off with fradulently. Don't they demand a credit card number from you before you drive off in a rental car?) >Perhaps something more like a couple of checkboxes on the complaint form >which say: > >[ ] I wish this complaint to be public. > [ ] I wish my name to be included in the public report. Color me flumoxed. I _thought_ that we were talking about the (unfortunate) confidentiality now being routinely and contractually provided to RIPE members... even, apparently, utterly fictitious and fradulent ones... who make off with resources, counter to current allocation policies, via fraud, deceit, or artifice. All of a sudden you seem to be worried about _my_ confi- dentiality, or lack thereof, or forfiture thereof. Allow me to be clear. I never asked for, nor ever expected that anything about my report... including but not limited to my name... would be held in any sort of confidence. Indeed quite the opposite. Ever since I found that big fat Romanian spam empire/cesspit I have been staying awake at nights, trying to figure out how to get news of it publicised and circulated even more widely than what I have so far been able to accomplish on my own. (And I _do_ hope that any reporting on this will mention my name somewhere, in a favorable light, as the guy who discovered this mess.) I suspect that most folks making reports to RIPE about abusive/deceptive violations of RIPE allocation policies, like me, will be only too happy to have the information they report... and their names... trumpted on every streetcorner. In short, your suggested checkboxes are, I think, utterly superfluous and unnecessary. >This way we could have an opt-in public archive of all abuse reports >that the RIPE NCC has received. See above. You have a solution in search of a problem. Has _any_ person who has _ever_ reported any kind of fraud or "abuse" to RIPE NCC _ever_ seriously desired _any_ anonymity and/or confidentialty in connection with any such report? I rather doubt it. The people who need to hide in the shadows are the abusers... not the public spirited samaritans who merely report their skulduggery. Speaking for myself, I can assure you that _I_ don't feel any need to hide. Regards, rfg From rfg at tristatelogic.com Mon Jan 21 12:53:02 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 21 Jan 2013 03:53:02 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <40A6A1EE-5F5B-46A3-ACFE-17F69F24EDB1@steffann.nl> Message-ID: <95085.1358769182@tristatelogic.com> In message <40A6A1EE-5F5B-46A3-ACFE-17F69F24EDB1 at steffann.nl>, Sander Steffann wrote: >> Perhaps something more like a couple of checkboxes on the complaint = >form >> which say: >> >> [ ] I wish this complaint to be public. >> [ ] I wish my name to be included in the public report. >> >> This way we could have an opt-in public archive of all abuse reports >> that the RIPE NCC has received. > >Even better! Then we also have an input/output view on the RIPE NCC >fraud/complaint handling procedure. Ummmm... no. Apparently there is some confusion here. Let me try to clear that up. As I understand it, RIPE has contractual confidentiality commitments that are of such a nature that RIPE will _never_ say _anything_ about _any_ aspect of its handling of _any_ abuse report. Period full stop. For that reason, you will *not* ``get an input/output view'' on the process. No person outside of RIPE staff will _ever_ see _any_ ``output''. That's the problem. Putting an extra check box on a report form isn't going to change that. I hope that we are clear on this now. Regards, rfg From sander at steffann.nl Mon Jan 21 13:06:25 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 21 Jan 2013 13:06:25 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <95085.1358769182@tristatelogic.com> References: <95085.1358769182@tristatelogic.com> Message-ID: Hi, >> Even better! Then we also have an input/output view on the RIPE NCC >> fraud/complaint handling procedure. > > Ummmm... no. I meant 'even better when this is added to what I already suggested'. Publishing which resources have been revoked/reclaimed/etc (when possible including the name of the last holder) would be the most important part. Publishing both sides would make it possible for everyone to see which resources got complaints and which resources got revoked. Cheers, Sander From erik at bais.name Mon Jan 21 13:39:53 2013 From: erik at bais.name (Erik Bais) Date: Mon, 21 Jan 2013 12:39:53 +0000 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <95029.1358768697@tristatelogic.com> References: <20130121105243.04109468@shane-desktop> <95029.1358768697@tristatelogic.com> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C0940BB25@e2010-mbx-c1n2.exchange2010.nl> Hi Ronald, > Has _any_ person who has _ever_ reported any kind of fraud or "abuse" > to RIPE NCC _ever_ seriously desired _any_ anonymity and/or confidentialty in connection with any such report? > I rather doubt it. > The people who need to hide in the shadows are the abusers... not the public spirited samaritans who merely report their skulduggery. Speaking for myself, I can assure you that _I_ don't feel any need to hide. There could be very good reasons not to put a target on themselves. Especially with certain crime, like running Botnets for hire or selling online pharmacy pills in huge quantities, those involve a lot of cash and mafia type practices are very likely, it is far better to be able to be able to report information without your name having published publicly. Some of the people in this community are also running their own network/business and just because you find a huge issue or you were part of a large botnet takedown, doesn't mean you want to risk your network/business to be a target of repercussions. Regards, Erik Bais From rfg at tristatelogic.com Mon Jan 21 21:20:09 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 21 Jan 2013 12:20:09 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C0940BB25@e2010-mbx-c1n2.exchange2010.nl> Message-ID: <98240.1358799609@tristatelogic.com> In message <862A73D42343AE49B2FC3C32FDDFE91C0940BB25 at e2010-mbx-c1n2.exchange201 0.nl>, Erik Bais wrote: >Hi Ronald, > >> Has _any_ person who has _ever_ reported any kind of fraud or "abuse" >> to RIPE NCC _ever_ seriously desired _any_ anonymity and/or confidentialt >y in connection with any such report? > >> I rather doubt it. > >> The people who need to hide in the shadows are the abusers... not the pub >lic spirited samaritans who merely report their skulduggery. Speaking for >myself, I can assure you that _I_ don't feel any need to hide. > >There could be very good reasons not to put a target on themselves. > >Especially with certain crime, like running Botnets for hire or selling onl >ine pharmacy pills in huge quantities, those involve a lot of cash and mafi >a type practices are very likely, it is far better to be able to be able to > report information without your name having published publicly. Yes, I probably should have realized that someone would raise that argument. I reluctantly must grant that you are correct, and that it is theoretically possible that someone desires to make a report but desires to remain anonymous. The solution could be a checkbox on the form, or to simply make those fields of the reporting form in which one could enter personal identity information optional. The harder problem is the one that I was trying to raise, and that I think crys out far more for a solution, i.e. the fact that once some resource allocation funny business is reported to RIPE (or to ARIN for that matter) that's the last that anybody ever hears of it. As I've tried to point out, I think that this is distinctly counter- productive, both because is discourages everybody from making any such reports in the future and also because it absolutely minimizes the disincentive for both the current perp and future perps to try again to defaud RIPE. Regards, rfg From sander at steffann.nl Tue Jan 22 00:16:38 2013 From: sander at steffann.nl (Sander Steffann) Date: Tue, 22 Jan 2013 00:16:38 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <98240.1358799609@tristatelogic.com> References: <98240.1358799609@tristatelogic.com> Message-ID: <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> Hi, > The harder problem is the one that I was trying to raise, and that I > think crys out far more for a solution, i.e. the fact that once some > resource allocation funny business is reported to RIPE (or to ARIN > for that matter) that's the last that anybody ever hears of it. As > I've tried to point out, I think that this is distinctly counter- > productive, both because is discourages everybody from making any > such reports in the future and also because it absolutely minimizes > the disincentive for both the current perp and future perps to try > again to defaud RIPE. I agree. Showing which resources the NCC has received complaints about would be good for transparency. They would have to show the outcome after investigation as well though. An example: you complain about my IP space, this gets published on the RIPE website. Of course I'm innocent so the RIPE NCC will investigate the case and conclude that there is nothing wrong. I wouldn't want the complaint to disappear from the website because that would not be very transparent. But I would really object to the complaint being visible on the website without a note saying: "investigated, found nothing wrong"... I don't mind people complaining, but I do want my name cleared if I'm innocent! ;-) Cheers, Sander From ops.lists at gmail.com Tue Jan 22 02:50:26 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 22 Jan 2013 07:20:26 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> References: <98240.1358799609@tristatelogic.com> <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> Message-ID: I think we are missing the main point rfg raised and going around in circles about transparency. How do we give enough teeth to ripe ncc's audit processes, and it's ip allocation processes, especially through LIRs, so that the issue we are concerned about is mitigated? --srs (htc one x) On 22-Jan-2013 4:47 AM, "Sander Steffann" wrote: > Hi, > > > The harder problem is the one that I was trying to raise, and that I > > think crys out far more for a solution, i.e. the fact that once some > > resource allocation funny business is reported to RIPE (or to ARIN > > for that matter) that's the last that anybody ever hears of it. As > > I've tried to point out, I think that this is distinctly counter- > > productive, both because is discourages everybody from making any > > such reports in the future and also because it absolutely minimizes > > the disincentive for both the current perp and future perps to try > > again to defaud RIPE. > > I agree. Showing which resources the NCC has received complaints about > would be good for transparency. They would have to show the outcome after > investigation as well though. An example: you complain about my IP space, > this gets published on the RIPE website. Of course I'm innocent so the RIPE > NCC will investigate the case and conclude that there is nothing wrong. I > wouldn't want the complaint to disappear from the website because that > would not be very transparent. But I would really object to the complaint > being visible on the website without a note saying: "investigated, found > nothing wrong"... I don't mind people complaining, but I do want my name > cleared if I'm innocent! ;-) > > Cheers, > Sander > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Tue Jan 22 10:03:35 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 Jan 2013 10:03:35 +0100 Subject: [anti-abuse-wg] Attempting to provide some transparency to RIPE NCC abuse handling (was Notice: Fradulent RIPE ASNs) In-Reply-To: <95085.1358769182@tristatelogic.com> References: <40A6A1EE-5F5B-46A3-ACFE-17F69F24EDB1@steffann.nl> <95085.1358769182@tristatelogic.com> Message-ID: <20130122100335.443507cf@shane-desktop> Ronald, On Monday, 2013-01-21 03:53:02 -0800, "Ronald F. Guilmette" wrote: > > In message <40A6A1EE-5F5B-46A3-ACFE-17F69F24EDB1 at steffann.nl>, > Sander Steffann wrote: > > >> Perhaps something more like a couple of checkboxes on the > >> complaint = > >form > >> which say: > >> > >> [ ] I wish this complaint to be public. > >> [ ] I wish my name to be included in the public report. > >> > >> This way we could have an opt-in public archive of all abuse > >> reports that the RIPE NCC has received. > > > >Even better! Then we also have an input/output view on the RIPE NCC > >fraud/complaint handling procedure. > > Ummmm... no. > > Apparently there is some confusion here. Let me try to clear that up. > > As I understand it, RIPE has contractual confidentiality commitments > that are of such a nature that RIPE will _never_ say _anything_ about > _any_ aspect of its handling of _any_ abuse report. Period full stop. > > For that reason, you will *not* ``get an input/output view'' on the > process. No person outside of RIPE staff will _ever_ see _any_ > ``output''. > > That's the problem. > > Putting an extra check box on a report form isn't going to change > that. > > I hope that we are clear on this now. Actually we are not. The RIPE NCC does have confidentiality clauses. This makes sense, as they ask companies to provide proprietary information like their business plans, which could be harmful to their operations if made public. However, I don't believe that this means that *all* interactions between the RIPE NCC and the outside world is necessarily confidential. In fact, we know that some things are not, because we can see dates when addresses were allocated to specific LIR. An even more important point is that the proposed check box on abuse reports is NOT FOR THE LIRs. It is for the ABUSE REPORTER, and allows them to declare their desire to have their complaints made public. The idea is to create a system which allows continued confidentiality, but makes public possible abuses. It prevents the RIPE NCC from getting 50 reports about an abusive LIR and ignoring them... which is what you are concerned about, right? If you think that improving transparency is a reasonable goal, but that the check box idea is silly... excellent! Please propose an alternate way to improve things! If you think that the goal is unreasonable, because the RIPE NCC will never, ever provide any transparency to its operations... then your objection is of the sort, "it won't help". In that case, perhaps you should at least let us try? Cheers, -- Shane From shane at time-travellers.org Tue Jan 22 10:28:02 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 Jan 2013 10:28:02 +0100 Subject: [anti-abuse-wg] Certainty vs. Severity as a deterrent (was Notice: Fradulent RIPE ASNs) In-Reply-To: <95029.1358768697@tristatelogic.com> References: <20130121105243.04109468@shane-desktop> <95029.1358768697@tristatelogic.com> Message-ID: <20130122102802.72514639@shane-desktop> Ronald, On Monday, 2013-01-21 03:44:57 -0800, "Ronald F. Guilmette" wrote: > I can't remember where anymore, but somewhere, a long time ago, I > read something about crime & punishment that basically said that > for crimes that are particularly easy to pull off, it can be easily > seen that those specific types of crimes will run rampant _unless_ > the punishment for those few who get caught is made extremely harsh... > you know, so that anyone in their right mind would really have to > think twice before trying it, even in the odds are only one in a > hundred of ever actually getting caught. Contemporary research tends to suggest that increasing harshness won't help: While the criminal justice system as a whole provides some deterrent effect, a key question for policy development regards whether enhanced sanctions or an enhanced possibility of being apprehended provide any additional deterrent benefits. Research to date generally indicates that increases in the *certainty* of punishment, as opposed to the *severity* of punishment, are more likely to produce deterrent benefits. http://www.sentencingproject.org/doc/deterrence%20briefing%20.pdf Cheers, -- Shane p.s. There is a _Star Trek_ episode which posits that we only need the death penalty to achieve utopia though: http://en.wikipedia.org/wiki/Justice_%28Star_Trek:_The_Next_Generation%29 From shane at time-travellers.org Tue Jan 22 10:45:48 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 Jan 2013 10:45:48 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <95029.1358768697@tristatelogic.com> References: <20130121105243.04109468@shane-desktop> <95029.1358768697@tristatelogic.com> Message-ID: <20130122104548.4406e7d9@shane-desktop> Ronald, On Monday, 2013-01-21 03:44:57 -0800, "Ronald F. Guilmette" wrote: > Public naming and shaming of any and all parties involved should be > a part of that, in my opinion, and furthermore I think that a pro- > vision which explicitly allows this should be written into all RIPE > contracts from now on.... as in "If we catch you doing this, then > no, you DON'T get to hide behind any confidentiality provisions > within this contract that might otherwise apply." I agree. I even don't think we should wait until the end of the process! :) There are reasons that trials are matters of the public record, and basically I think they all apply here. > >Perhaps something more like a couple of checkboxes on the complaint > >form which say: > > > >[ ] I wish this complaint to be public. > > [ ] I wish my name to be included in the public report. > > Color me flumoxed. I can't find "flummoxed" in my crayon box, but maybe I need to get one with more colors. ;) > I _thought_ that we were talking about the (unfortunate) > confidentiality now being routinely and contractually provided to > RIPE members... even, apparently, utterly fictitious and fradulent > ones... who make off with resources, counter to current allocation > policies, via fraud, deceit, or artifice. All of a sudden you seem > to be worried about _my_ confi- dentiality, or lack thereof, or > forfiture thereof. No, I'm not worried about your confidentiality, however I was trying to think of potential misuse of the system. For example, I might falsely report abuse by a competitor, in order to tarnish their name, and cost them time & money dealing with the report. Because of this, it is in people's interest to have the identity of the abuse reporter public to avoid this issue. HOWEVER, there is also a place for anonymous abuse reporting. People may notice something "funny", but not really be interested in spending a lot of their own effort resolving it. Consider it like an anonymous tip-line that some police departments set up. So when evaluating reports of an LIR's abuse, one could see anonymous reports but view with an additional level of skepticism. > You have a solution in search of a problem. Well, the main point of the proposal is to have a public archive of abuse reports to the RIPE NCC, not anonymity. The problem that I was attempting to solve is the utter lack of transparency in abuse handling. I readily admit it is probably not the best! Please suggest something else! Cheers, -- Shane From shane at time-travellers.org Tue Jan 22 10:53:08 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 Jan 2013 10:53:08 +0100 Subject: [anti-abuse-wg] Publication of abuse reports (was Notice: Fradulent RIPE ASNs) In-Reply-To: <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> References: <98240.1358799609@tristatelogic.com> <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> Message-ID: <20130122105308.6cf84928@shane-desktop> Sander, On Tuesday, 2013-01-22 00:16:38 +0100, Sander Steffann wrote: > Hi, > > > The harder problem is the one that I was trying to raise, and that I > > think crys out far more for a solution, i.e. the fact that once some > > resource allocation funny business is reported to RIPE (or to ARIN > > for that matter) that's the last that anybody ever hears of it. As > > I've tried to point out, I think that this is distinctly counter- > > productive, both because is discourages everybody from making any > > such reports in the future and also because it absolutely minimizes > > the disincentive for both the current perp and future perps to try > > again to defaud RIPE. > > I agree. Showing which resources the NCC has received complaints > about would be good for transparency. They would have to show the > outcome after investigation as well though. An example: you complain > about my IP space, this gets published on the RIPE website. I agree. That was what I tried to suggest. :) > Of course I'm innocent so the RIPE NCC will investigate the case and > conclude that there is nothing wrong. I wouldn't want the complaint to > disappear from the website because that would not be very > transparent. But I would really object to the complaint being visible > on the website without a note saying: "investigated, found nothing > wrong"... I don't mind people complaining, but I do want my name > cleared if I'm innocent! ;-) Also nice to have. It would also help give some indication of how long investigation takes. Cheers, -- Shane From shane at time-travellers.org Tue Jan 22 10:57:54 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 Jan 2013 10:57:54 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: References: <98240.1358799609@tristatelogic.com> <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> Message-ID: <20130122105754.193afac4@shane-desktop> Suresh, [ using your top-posting style in this reply, to avoid "crossing the streams" ] We can have transparent processes, that have no "teeth" as you say. We can also have strict policies that are enforced in secret. Both transparency and effectiveness are important. I do think ISPs are more likely to support a fair and transparent policy that will punish abusers than they will to support a fair and secretive policy that will punish abusers, because they will have no guarantees that they will be safe under such a system. Cheers, -- Shane On Tuesday, 2013-01-22 07:20:26 +0530, Suresh Ramasubramanian wrote: > I think we are missing the main point rfg raised and going around in > circles about transparency. > > How do we give enough teeth to ripe ncc's audit processes, and it's ip > allocation processes, especially through LIRs, so that the issue we > are concerned about is mitigated? From ops.lists at gmail.com Tue Jan 22 12:40:30 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 22 Jan 2013 17:10:30 +0530 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <20130122105754.193afac4@shane-desktop> References: <98240.1358799609@tristatelogic.com> <2D66A3EF-FD58-4AB0-9682-1A5D52609177@steffann.nl> <20130122105754.193afac4@shane-desktop> Message-ID: Shane - please. Have you actually done any abuse desk work as opposed to DNS, routing, IP allocation etc? Any process, transparent or not - has to have teeth. And any transparency need exist only between RIPE NCC and the LIR or other party with whom they have a contract (and an AUP, and various other policies). Nobody expects RIPE NCC to immediately revoke any IP allocation without its own due diligence. And whether or not a complainer opts in, I would not expect RIPE NCC to publish any complaint data (unless specifically anonymized, and aggregated). The issue here is not whether RIPE NCC reports the largely redundant proposed statistics back to the community - reclaimed IP space is already reported out. The issue is whether RIPE NCC's policies, especially in LIR allocated IP space, are effective to prevent fraudulent registrations, and to weed them out when detected. And whether RIPE NCC staff has the will to enforce these policies, regardless of the size of the customer involved. The only transparency that is actually required (given that data on available and reclaimed v4 space is already reported) is that any new receiver of this reclaimed space would have to be told upfront that the space is poisoned for any further use thanks to its previous ownership. SMTP blocks only, if all there was, was bulk mail .. but IP space reclaimed from a botnet operation would very probably be nullrouted all over the place. --srs On Tuesday, January 22, 2013, Shane Kerr wrote: > Suresh, > > [ using your top-posting style in this reply, to avoid "crossing the > streams" ] > > We can have transparent processes, that have no "teeth" as you say. > > We can also have strict policies that are enforced in secret. > > Both transparency and effectiveness are important. > > I do think ISPs are more likely to support a fair and transparent > policy that will punish abusers than they will to support a fair and > secretive policy that will punish abusers, because they will have no > guarantees that they will be safe under such a system. > > Cheers, > > -- > Shane > > On Tuesday, 2013-01-22 07:20:26 +0530, > Suresh Ramasubramanian > wrote: > > I think we are missing the main point rfg raised and going around in > > circles about transparency. > > > > How do we give enough teeth to ripe ncc's audit processes, and it's ip > > allocation processes, especially through LIRs, so that the issue we > > are concerned about is mitigated? > > -- --srs (iPad) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Tue Jan 22 17:09:03 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 22 Jan 2013 17:09:03 +0100 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <95029.1358768697@tristatelogic.com> References: <95029.1358768697@tristatelogic.com> Message-ID: <50FEB99F.70605@CC.UniVie.ac.at> Ronald F. Guilmette wrote: [...] > Of course, in my ideal universe, one could achieve much the same ends, > but much more efficiently, economically, and expediently simply by > revoking a up-front performance bond that all parties contracting > with RIPE NCC would be required to post before being allocated > resources. Assuming that everybody has read Shane's description regarding the 2 types of non-profit :-) While it is certainly true that a considerable numer of RIPE NCC Members and beneficiaries of it's services are (big) commercial companies, we have to keep in mind that the NCC also distributes resources (directly or by way of a sponsoring LIR), to Non-Profits of Type#1, NGOs, very small or start-up companies, even small associations and individuals. What you are suggesting would certainly harm primarily (or even exclusively?) the wrong parties, as the bad guys would certainly have the deep pockets to just pay and forget. :-( [...] > Regards, > rfg Wilfried. From rfg at tristatelogic.com Thu Jan 24 00:26:04 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 23 Jan 2013 15:26:04 -0800 Subject: [anti-abuse-wg] Attempting to provide some transparency to RIPE NCC abuse handling (was Notice: Fradulent RIPE ASNs) In-Reply-To: <20130122100335.443507cf@shane-desktop> Message-ID: <39822.1358983564@tristatelogic.com> Sorry for the late reply. I have been off working on other things. In message <20130122100335.443507cf at shane-desktop>, Shane Kerr wrote: >The idea is to create a system which allows continued confidentiality, >but makes public possible abuses. It prevents the RIPE NCC from getting >50 reports about an abusive LIR and ignoring them... which is what you >are concerned about, right? No, not actually. I am concerned about RIPE NCC getting _one_ highly _accurate_ report, like the one I posted here recently, and then sweeping it under the rug (aka "hushing it up"), in one way or another. That could be by just ignoring it, and letting the thief keep what he stole, or it could be by taking back what was stolen, and possibly imposing some sort of penalty/sanction against the thief, but all done quietly, behind the scenes, without any public notice which would take the general form "So-and-so was determined by RIPE NCC staff to have comitted a fraud, thereby obtaining thus-and-such number resource in a manner inconsistant with current RIPE policy." The number of reports shouldn't matter. As far as I know, I am the only one who either found or reported that big mess/fraud in Romania, so RIPE NCC now has in hand exactly and only _one_ report about that. That's not the issue. The issue is, what happens when RIPE NCC verifies what I've said, i.e. that all those ASNs.... and, not coincidently, all of the IPv4 space they have been allocated and/or that they are routing... was all obtained via fraud, deceit, or artifice? Will the perpetrators *and* those who aided and abetted them be publically outted? Or will the results of RIPE NCCs investigation all just be hushed up, you know, so that the exact same crooks can just come back and do it all over again in a month or two? >If you think that improving transparency is a reasonable goal... I do. >but that >the check box idea is silly... excellent! Please propose an alternate >way to improve things! Well, in the first place, the specific "transparency" that I would like to see improved... or rather that I would like to see come into existance (because right now, it seems, there isn't _any_ of it) is RIPE NCC's transparency... not _my_ transparency. I'm not the one keeping secrets. Secondarily however, let me say that I _am_ mulling over an idea that I have had which may perhaps be useful in getting more eyes focused on at least the externally provided _reports_ of these kinds of issues, if not also RIPE NCC's (secretive) response(s) to same. >If you think that the goal is unreasonable, because the RIPE NCC will >never, ever provide any transparency to its operations... If?? I have been informed that RIPE NCC works under the same sorts of confi- dentiality arrangement as ARIN. I have some experience with ARIN's handling of these sorts of things, and I can assure you that they behave entirely like the proverbial "black box", "brick wall", name your metaphor. So, um, yes. I believe that "RIPE NCC will never, ever provide any transparency to its operations" with respect to these sorts of incidents. In fact I have been point blank told as much by a RIPE NCC staff member. >then your >objection is of the sort, "it won't help". In that case, perhaps you >should at least let us try? Try what, exactly? I'm sorry. I'm not following. Could you please elaborate? Regards, rfg From rfg at tristatelogic.com Thu Jan 24 00:39:09 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 23 Jan 2013 15:39:09 -0800 Subject: [anti-abuse-wg] Certainty vs. Severity as a deterrent (was Notice: Fradulent RIPE ASNs) In-Reply-To: <20130122102802.72514639@shane-desktop> Message-ID: <39920.1358984349@tristatelogic.com> In message <20130122102802.72514639 at shane-desktop>, Shane Kerr wrote: >Ronald, > >On Monday, 2013-01-21 03:44:57 -0800, >"Ronald F. Guilmette" wrote: >> I can't remember where anymore, but somewhere, a long time ago, I >> read something about crime & punishment that basically said that >> for crimes that are particularly easy to pull off, it can be easily >> seen that those specific types of crimes will run rampant _unless_ >> the punishment for those few who get caught is made extremely harsh... >> you know, so that anyone in their right mind would really have to >> think twice before trying it, even in the odds are only one in a >> hundred of ever actually getting caught. > >Contemporary research tends to suggest that increasing harshness won't >help: > > While the criminal justice system as a whole provides some > deterrent effect, a key question for policy development regards > whether enhanced sanctions or an enhanced possibility of being > apprehended provide any additional deterrent benefits. Research to > date generally indicates that increases in the *certainty* of > punishment, as opposed to the *severity* of punishment, are more > likely to produce deterrent benefits. > >http://www.sentencingproject.org/doc/deterrence%20briefing%20.pdf We can agree to disagree about the deterrent value of "harshness", however one part of the overall point I've been making is actually supported by what you have quoted above. Right now, if anything, the only iron-clad 100% certainty that party who effectively defrauds either ARIN or RIPE out of number resources can have is the 100% certainty that they will NOT by punished in any way.... that they will not pay any sort of a penalty whatsoever and that they will not even be publically named and shamed... unless that is accomplished independently, by someone entirely outside of RIPE and/or ARIN, i.e. by an independent researcher or journalist such as myself. As I have suggested, it is my belief that it is precisely this widespread certainty regarding the utter lack of punishment for such crimes and misdemeanors that effectively insures their continued proliferation. Regards, rfg From rfg at tristatelogic.com Thu Jan 24 01:14:27 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 23 Jan 2013 16:14:27 -0800 Subject: [anti-abuse-wg] Notice: Fradulent RIPE ASNs In-Reply-To: <20130122104548.4406e7d9@shane-desktop> Message-ID: <40195.1358986467@tristatelogic.com> In message <20130122104548.4406e7d9 at shane-desktop>, Shane Kerr wrote: >No, I'm not worried about your confidentiality, however I was trying to >think of potential misuse of the system. > >For example, I might falsely report abuse by a competitor, in order to >tarnish their name, and cost them time & money dealing with the report. >Because of this, it is in people's interest to have the identity of the >abuse reporter public to avoid this issue. We agree, and you make an excellent point. Here is this country we have (at least) two entirely notorious sagas, both part of our national collective consciousness, that eternally remind us of how accusations by unnamed accusers (or little children) can lead to tragic consequences. One is the Salem Witch Trials. The other is the political era of Senator Joseph McCarthy. Personally, I've been on the Internet for roughly 29 years now, and unlike many others, I've always held the belief that if I want to say anything that might be in the least controversial, that I should have the guts to do so using my own name and my own e-mail address, and that I should _not_ hide behind an alias, a handle, a pseudonym, or a throw-away e-mail address. And I have always stuck to that rule. I just believe that men should take responsibility for their words, as well as for their actions. Call me old-fashioned, anachronistic, or antiquated. I don't care. This is one of my own personal bedrock principals. >HOWEVER, there is also a place for anonymous abuse reporting. People >may notice something "funny", but not really be interested in spending >a lot of their own effort resolving it. Consider it like an anonymous >tip-line that some police departments set up. See above, re The Salem Witch Trials and/or Sen. Joe McCarthy. In this country we have also experienced more recent but similar traumas revolving around theripist-induced "recoved memories" of children being used to indict many totally innocent caregivers on charges of child abuse (including sexual abuse). http://www.pbs.org/wgbh/pages/frontline/shows/innocence/ All, things considered, I personally am not in favor of the whole notion of anonymously lodged complaints. But that's just my personal opinion, and I understand that others do not share this view. >> You have a solution in search of a problem. > >Well, the main point of the proposal is to have a public archive of >abuse reports to the RIPE NCC That would be good. However that issue is unrelated to, and orthogonal to the question of whether issue reporters should or should not be encouraged or allowed to remain anonymous. >The problem that I was >attempting to solve is the utter lack of transparency in abuse handling. Please proceed. You have my complete support. Getting all the reports online would certainly be a Good Thing. Regards, rfg From thilo.bangert at gmail.com Thu Jan 24 13:29:52 2013 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Thu, 24 Jan 2013 13:29:52 +0100 Subject: [anti-abuse-wg] Please unblock 80.71.128.0/20 Message-ID: <1562429.nF0c6dWI2O@marsupilami> Hi, we were, a little more than 2 years ago, allocated above subnet and have since struggeled with it, since apparently its previous owner had not treated it well. While it appears that many of the GeoIP issues have been fixed -- its surprising how many sites are out there which NEVER update their maxmind or other databases -- we still have reachability issues, especially into Israeli networks. It has been communicated to us that the past owner had notoriously attacked Israeli websites, which is why the netblok 80.71.128.0/20 had been null routed. One of the websites our customers complain about not being able to view is http://www.english.machonmeir.net/ were we cant get to the DNS server which lives at 62.219.11.42. Trying to reach someone from the other network has thus far not been fruitful. Any help in establishing communication is greatly appreciated. If you null route, could you pleae check whether you are blocking our subnet, and if so kindly reevaluate that decision. Thank you for your help. kind regards Thilo From ops.lists at gmail.com Thu Jan 24 13:49:40 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 24 Jan 2013 18:19:40 +0530 Subject: [anti-abuse-wg] Please unblock 80.71.128.0/20 In-Reply-To: <1562429.nF0c6dWI2O@marsupilami> References: <1562429.nF0c6dWI2O@marsupilami> Message-ID: Someone got a whole /20 with the justification that he wanted to ddos Israeli websites? --srs (htc one x) On 24-Jan-2013 6:05 PM, "Thilo Bangert" wrote: > Hi, > > we were, a little more than 2 years ago, allocated above subnet and have > since > struggeled with it, since apparently its previous owner had not treated it > well. > > While it appears that many of the GeoIP issues have been fixed -- its > surprising how many sites are out there which NEVER update their maxmind or > other databases -- we still have reachability issues, especially into > Israeli > networks. It has been communicated to us that the past owner had > notoriously > attacked Israeli websites, which is why the netblok 80.71.128.0/20 had > been > null routed. > > One of the websites our customers complain about not being able to view is > http://www.english.machonmeir.net/ were we cant get to the DNS server > which > lives at 62.219.11.42. Trying to reach someone from the other network has > thus > far not been fruitful. Any help in establishing communication is greatly > appreciated. > > If you null route, could you pleae check whether you are blocking our > subnet, > and if so kindly reevaluate that decision. > > Thank you for your help. > > kind regards > Thilo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thilo.bangert at gmail.com Thu Jan 24 14:24:48 2013 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Thu, 24 Jan 2013 14:24:48 +0100 Subject: [anti-abuse-wg] Please unblock 80.71.128.0/20 In-Reply-To: References: <1562429.nF0c6dWI2O@marsupilami> Message-ID: <2261395.H2IVVjAnxO@gaston> On Thursday, January 24, 2013 06:19:40 PM you wrote: > Someone got a whole /20 with the justification that he wanted to ddos > Israeli websites? ah, sorry - it wasnt RIPE telling us that the subnet had been used for hacking. how would they know? We received such information from networks where we were successfull in removing the null route. so, no - nobody got a /20 with the justification that he wanted to ddos Israeli websites. thanks Thilo > > --srs (htc one x) > > On 24-Jan-2013 6:05 PM, "Thilo Bangert" wrote: > > Hi, > > > > we were, a little more than 2 years ago, allocated above subnet and have > > since > > struggeled with it, since apparently its previous owner had not treated it > > well. > > > > While it appears that many of the GeoIP issues have been fixed -- its > > surprising how many sites are out there which NEVER update their maxmind > > or > > other databases -- we still have reachability issues, especially into > > Israeli > > networks. It has been communicated to us that the past owner had > > notoriously > > attacked Israeli websites, which is why the netblok 80.71.128.0/20 had > > been > > null routed. > > > > One of the websites our customers complain about not being able to view is > > http://www.english.machonmeir.net/ were we cant get to the DNS server > > which > > lives at 62.219.11.42. Trying to reach someone from the other network has > > thus > > far not been fruitful. Any help in establishing communication is greatly > > appreciated. > > > > If you null route, could you pleae check whether you are blocking our > > subnet, > > and if so kindly reevaluate that decision. > > > > Thank you for your help. > > > > kind regards > > Thilo From ops.lists at gmail.com Thu Jan 24 14:35:59 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 24 Jan 2013 19:05:59 +0530 Subject: [anti-abuse-wg] Please unblock 80.71.128.0/20 In-Reply-To: <2261395.H2IVVjAnxO@gaston> References: <1562429.nF0c6dWI2O@marsupilami> <2261395.H2IVVjAnxO@gaston> Message-ID: Not you of course. Whoever the previous owner of the netblock was. And a heads up that what you are receiving is damaged goods so to speak would have been great.. --srs (htc one x) On 24-Jan-2013 6:54 PM, "Thilo Bangert" wrote: > On Thursday, January 24, 2013 06:19:40 PM you wrote: > > Someone got a whole /20 with the justification that he wanted to ddos > > Israeli websites? > > ah, sorry - it wasnt RIPE telling us that the subnet had been used for > hacking. how would they know? > We received such information from networks where we were successfull in > removing the null route. > > so, no - nobody got a /20 with the justification that he wanted to ddos > Israeli websites. > > thanks > Thilo > > > > > --srs (htc one x) > > > > On 24-Jan-2013 6:05 PM, "Thilo Bangert" wrote: > > > Hi, > > > > > > we were, a little more than 2 years ago, allocated above subnet and > have > > > since > > > struggeled with it, since apparently its previous owner had not > treated it > > > well. > > > > > > While it appears that many of the GeoIP issues have been fixed -- its > > > surprising how many sites are out there which NEVER update their > maxmind > > > or > > > other databases -- we still have reachability issues, especially into > > > Israeli > > > networks. It has been communicated to us that the past owner had > > > notoriously > > > attacked Israeli websites, which is why the netblok 80.71.128.0/20 had > > > been > > > null routed. > > > > > > One of the websites our customers complain about not being able to > view is > > > http://www.english.machonmeir.net/ were we cant get to the DNS server > > > which > > > lives at 62.219.11.42. Trying to reach someone from the other network > has > > > thus > > > far not been fruitful. Any help in establishing communication is > greatly > > > appreciated. > > > > > > If you null route, could you pleae check whether you are blocking our > > > subnet, > > > and if so kindly reevaluate that decision. > > > > > > Thank you for your help. > > > > > > kind regards > > > Thilo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-anti-spam-wg at powerweb.de Thu Jan 24 14:44:21 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 24 Jan 2013 14:44:21 +0100 Subject: [anti-abuse-wg] Please unblock 80.71.128.0/20 In-Reply-To: <2261395.H2IVVjAnxO@gaston> References: <1562429.nF0c6dWI2O@marsupilami> <2261395.H2IVVjAnxO@gaston> Message-ID: <51013AB5.9000402@powerweb.de> Thilo Bangert wrote: Hi, > On Thursday, January 24, 2013 06:19:40 PM you wrote: >> Someone got a whole /20 with the justification that he wanted to ddos >> Israeli websites? > > ah, sorry - it wasnt RIPE telling us that the subnet had been used for > hacking. how would they know? That made me really laugh (5 seconds later it nearly made me cry) ... RIPE NCC should be the FIRST organization to know about misuse of any network in their region and not the last ... Thats what our group should work on. BTW: the German government thinks about a regulation, that any hack on an organization server HAS to be reported to the government, when personal data has been lost. Whats about a regulation than misuse of RIPEs resources HAS to be reported to RIPE NCC ? Sounds like a similar approach. At least brnic does something like this by adding a % Security and mail abuse issues should also be addressed to % cert.br, http://www.cert.br/, respectivelly to cert at cert.br % and mail-abuse at cert.br to all there whois output. Kind regards, Frank > We received such information from networks where we were successfull in > removing the null route. > > so, no - nobody got a /20 with the justification that he wanted to ddos > Israeli websites. > > thanks > Thilo > >> >> --srs (htc one x) >> >> On 24-Jan-2013 6:05 PM, "Thilo Bangert" wrote: >>> Hi, >>> >>> we were, a little more than 2 years ago, allocated above subnet and have >>> since >>> struggeled with it, since apparently its previous owner had not treated it >>> well. >>> >>> While it appears that many of the GeoIP issues have been fixed -- its >>> surprising how many sites are out there which NEVER update their maxmind >>> or >>> other databases -- we still have reachability issues, especially into >>> Israeli >>> networks. It has been communicated to us that the past owner had >>> notoriously >>> attacked Israeli websites, which is why the netblok 80.71.128.0/20 had >>> been >>> null routed. >>> >>> One of the websites our customers complain about not being able to view is >>> http://www.english.machonmeir.net/ were we cant get to the DNS server >>> which >>> lives at 62.219.11.42. Trying to reach someone from the other network has >>> thus >>> far not been fruitful. Any help in establishing communication is greatly >>> appreciated. >>> >>> If you null route, could you pleae check whether you are blocking our >>> subnet, >>> and if so kindly reevaluate that decision. >>> >>> Thank you for your help. >>> >>> kind regards >>> Thilo > > From rezaf at mindspring.com Mon Jan 28 14:19:48 2013 From: rezaf at mindspring.com (Reza Farzan) Date: Mon, 28 Jan 2013 08:19:48 -0500 Subject: [anti-abuse-wg] proberry.de Message-ID: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> Hello All, In recent days, I have received numerous Spamvertised messages from this domain, "proberry.de" which is hosted by (STRATO-RZG-KA). Here is a copy of the latest such messages, without its header: From: Rupert Sterling To: rezaf at mindspring.com Subject: Sicherheit im Beerenanbau Date: Jan 27, 2013 4:25 AM Die Homepage "ProBerry" ist eine branchenbezogene Informationsseite zu einem Fachthema, fur Beerenobstanbauer in der BRD: http://proberry.de/ Does anyone knows who is behind this domain, "proberry.de" i.e. who owns it, and what this German text says on this message. So far, and despite my repeated complaints to STRATO-RZG-KA's Abuse Department, 'abuse at stratoserver.net' and 'hostmaster at strato.de' and 'hostmaster at strato-rz.de' this domain remain active, and has not been suspended. To be fair, I have copied Andreas Hartnacke, Provisioning/Hostmaster, so that he would be aware of the this matter. I appreciate any assistance that you may offer in this matter. Thank you, Reza Farzan rezaf at mindspring.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From esa.laitinen at iki.fi Mon Jan 28 15:09:00 2013 From: esa.laitinen at iki.fi (Esa Laitinen) Date: Mon, 28 Jan 2013 15:09:00 +0100 Subject: [anti-abuse-wg] proberry.de In-Reply-To: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> Message-ID: Dear Reza, basically the owner says the emails don't originate from them, they have no use for those messages, they don't know who sent it, they don't even have e-mail accounts in that domain, and they've contacted the police about the matter on the 24th of January. They also direct the recipients to contact police in case they're so inclined. On Mon, Jan 28, 2013 at 2:19 PM, Reza Farzan wrote: > ** > > Hello All,**** > > ** ** > > In recent days, I have received numerous Spamvertised messages from this > domain, ?proberry.de? which is hosted by (STRATO-RZG-KA).**** > > ** ** > > Here is a copy of the latest such messages, without its header:**** > > ** ** > > ** ** > > From: Rupert Sterling **** > > To: **rezaf at mindspring.com****** > > Subject: Sicherheit im Beerenanbau**** > > Date: Jan 27, 2013 4:25 AM**** > > **** > > Die Homepage "ProBerry" ist eine branchenbezogene Informationsseite zu *** > * > > einem Fachthema, fur Beerenobstanbauer in der BRD:**** > > **** > > http://proberry.de/**** > > ** ** > > ** ** > > ** ** > > Does anyone knows who is behind this domain, ?proberry.de? i.e. who owns > it, and what this German text says on this message.**** > > ** ** > > So far, and despite my repeated complaints to STRATO-RZG-KA?s Abuse > Department, '**abuse at stratoserver.net**' and '**hostmaster at strato.de**' > and '**hostmaster at strato-rz.de**' this domain remain active, and has not > been suspended.**** > > ** ** > > To be fair, I have copied **Andreas Hartnacke**, Provisioning/Hostmaster, > so that he would be aware of the this matter.**** > > ** ** > > I appreciate any assistance that you may offer in this matter.**** > > ** ** > > Thank you,**** > > Reza Farzan > *rezaf at mindspring.com ***** > -- Mr. Esa Laitinen Tel. +41 76 200 2870 skype/yahoo: reunaesa Blog: http://happiloppuuahistaa.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rezaf at mindspring.com Mon Jan 28 16:56:58 2013 From: rezaf at mindspring.com (Reza Farzan) Date: Mon, 28 Jan 2013 10:56:58 -0500 (GMT-05:00) Subject: [anti-abuse-wg] proberry.de Message-ID: <33162267.1359388618868.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Hello All, In recent days, I have received numerous Spamvertised messages from this domain, "proberry.de" which is hosted by (STRATO-RZG-KA). Here is a copy of the latest such messages, without its header: ----- From: Rupert Sterling To: rezaf at mindspring.com Subject: Sicherheit im Beerenanbau Date: Jan 27, 2013 4:25 AM Die Homepage "ProBerry" ist eine branchenbezogene Informationsseite zu einem Fachthema, fur Beerenobstanbauer in der BRD: proberry.de -------- Does anyone knows who is behind this domain, "proberry.de" i.e. who owns it, and what this German text says on this message. So far, and despite my repeated complaints to STRATO-RZG-KA's Abuse Department, 'abuse at stratoserver.net' and 'hostmaster at strato.de' and 'hostmaster at strato-rz.de' this domain remain active, and has not been suspended. To be fair, I have copied Andreas Hartnacke, Provisioning/Hostmaster, so that he would be aware of the this matter. I appreciate any assistance that you may offer in this matter. Thank you, Reza Farzan rezaf at mindspring.com From lp at shlink.de Mon Jan 28 20:15:41 2013 From: lp at shlink.de (Lutz Petersen) Date: Mon, 28 Jan 2013 20:15:41 +0100 Subject: [anti-abuse-wg] [SPAM] proberry.de In-Reply-To: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> Message-ID: <20130128191541.GA16005@work-lp.shlink.de> Simply ignore these mails. They are no classical spam and completely senseless. At http://www.proberry.de/ is a statement of the domain-owner (in german, use google or something else to translate). From kjz at gmx.net Mon Jan 28 20:32:15 2013 From: kjz at gmx.net (Karl-Josef Ziegler) Date: Mon, 28 Jan 2013 20:32:15 +0100 Subject: [anti-abuse-wg] anti-abuse-wg Digest, Vol 17, Issue 18 In-Reply-To: References: Message-ID: <5106D23F.9080803@gmx.net> > Does anyone knows who is behind this domain, "proberry.de" i.e. who owns it, > and what this German text says on this message. It's a Joe Job against this domain and the owner has informed the police. Best regards, - Karl-Josef Ziegler From wiegert at telus.net Mon Jan 28 20:52:27 2013 From: wiegert at telus.net (Arnold) Date: Mon, 28 Jan 2013 11:52:27 -0800 Subject: [anti-abuse-wg] *TELUS Detected Spam* proberry.de In-Reply-To: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> Message-ID: <5106D6FB.8030305@telus.net> On 28/01/2013 5:19 AM, Reza Farzan wrote: > > Hello All, > > In recent days, I have received numerous Spamvertised > messages from this domain, "proberry.de" which is hosted > by (STRATO-RZG-KA). > > Here is a copy of the latest such messages, without its > header: > Hi, reviewing the header source might give you enough information about who actually sent the SPAM. The best thing to do is to forward the complete message, possibly with some sensitive addresses obliterated if necessary, to the owners so that they can collect enough information for the police. Blowing my own horn, my SPAM reporter wxSR - see my signature- might help you resolve some of your questions. Arnold -- Fight Spam - report it with wxSR 0.5 - ready for Vista & Win7 http://www.columbinehoney.net/wxSR.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Mon Jan 28 23:47:47 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 28 Jan 2013 23:47:47 +0100 Subject: [anti-abuse-wg] *TELUS Detected Spam* proberry.de In-Reply-To: <5106D6FB.8030305@telus.net> References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> <5106D6FB.8030305@telus.net> Message-ID: <51070013.8050001@CC.UniVie.ac.at> Arnold wrote: > On 28/01/2013 5:19 AM, Reza Farzan wrote: > >> >> Hello All, >> >> In recent days, I have received numerous Spamvertised messages from >> this domain, "proberry.de" which is hosted by (STRATO-RZG-KA). >> >> Here is a copy of the latest such messages, without its header: >> > Hi, > > reviewing the header source might give you enough information about > who actually sent the SPAM. ...and looking at the message in text mode, instead of the "fancy" html rendering, may give you a clue about the real URL you are supposed to visit. ;-) If this is different than the "obvious source", well, then you're barking up at the wrong tree... > The best thing to do is to forward the complete message, possibly with > some sensitive addresses obliterated if necessary, to the owners so that > they can collect enough information for the police. > > Blowing my own horn, my SPAM reporter wxSR - see my signature- > might help you resolve some of your questions. > > Arnold -ww From fw at deneb.enyo.de Tue Jan 29 08:34:25 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Jan 2013 08:34:25 +0100 Subject: [anti-abuse-wg] *TELUS Detected Spam* proberry.de In-Reply-To: <51070013.8050001@CC.UniVie.ac.at> (Wilfried Woeber's message of "Mon, 28 Jan 2013 23:47:47 +0100") References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> <5106D6FB.8030305@telus.net> <51070013.8050001@CC.UniVie.ac.at> Message-ID: <87y5fcv3we.fsf@mid.deneb.enyo.de> * Wilfried Woeber: > Arnold wrote: >> reviewing the header source might give you enough information about >> who actually sent the SPAM. It's some sort of botnet with readily apparent coordination across multiple egress IP addresses. > ...and looking at the message in text mode, instead of the "fancy" html > rendering, may give you a clue about the real URL you are supposed to > visit. ;-) These messages are plain text (even ASCII), and the URL is unobfuscated. They really do not make much sense. From brian.nisbet at heanet.ie Tue Jan 29 12:36:44 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 29 Jan 2013 11:36:44 +0000 Subject: [anti-abuse-wg] AA-WG Minutes, RIPE 65 Message-ID: <5107B44C.6080008@heanet.ie> Colleagues, Here are the minutes of the WG session at RIPE 65. Please let Tobias or I know if you have any comments or corrections. Thanks, Brian ******************************************** Anti-Abuse Working Group Minutes ? RIPE 65 Thursday, 27 September 2012, 14:00-15:30 WG co-Chairs: Brian Nisbet, Tobias Knecht Scribe: Alex le Heux Brian welcomed the audience and introduced himself and Tobias Knecht, Anti-Abuse Working Group co-Chairs. A. Administrative Matters ? Welcome ? Scribe, Jabber, stenography ? Microphone etiquette ? Approve minutes from RIPE 64 No comments on RIPE 64 minutes, declared final. Finalise agenda: https://ripe65.ripe.net/presentations/108-AA-WG_RIPE_65.pdf No changes proposed to the agenda. B. Update B1. Recent List Discussion These are all covered by the agenda. B2. CleanIT Project Update - But Klaasen The presentation is available at: https://ripe65.ripe.net/presentations/230Clean_IT_presentatie_27_09_2012.pdf Anto Veldre, Estonian Information System Authority, said it was unclear how is it possible that some club will decide on fundamental rights that must be defined by law. He said he didn?t understand prohibiting the usage of some languages, Arabic or Estonian, or how But succeeded in involving people in making such proposals But Klassen replied that he didn?t understand the question. Brian Nisbet, Anti-Abuse WG co-Chair, replied that he discussed this previously with Anto and will try to help him understand the question. He said they have some examples from brainstorming discussions and that some of them were about enforcing language use on the Internet. Some of the suggestions were on the outer edge of what this community would consider technically feasible. Brian said the question is: how did the people making such suggestions get involved and are these the bulk of the people involved. But Klaassen replied that they don't keep track of who comes up with ideas. This could come from the public or a small discussion group. These are ideas that are under consideration, they came to them and they want to have discussion about them. If it's not legally feasible, it will not get to the end stage. Daniel Karrenberg, RIPE NCC, commented that the problem he has is that on one hand, it's "just ideas", and on the other hand "you are EU". Daniel commented that what he?s hearing from the audience is ?first they tried child porn, now they?re trying terrorists?. He added that there was a discussion with someone from Denmark who was explaining how he ran a grassroots thing to help people get around the filtering that has been implemented there. During the discussion someone asked if he wasn't doing something illegal. He was not, the filtering was sort of voluntarily done by the ISPs. He added that in this room, you sometimes have people from the technical community who have successfully resisted things like this in their own countries. He added that it was good But came to engage with them but taking the ?it?s all informal? stance doesn?t build confidence. But Klaassen replied that it wasn?t all informal. The issue is that they want to have an open dialog. He said the project proposal states that it?s a process for having a dialogue between different stakeholders in a multi-stakeholder environment and it happens rarely. He said that they?re trying to do this with a balanced group and have an open and constructive dialogue and doesn?t see why that?s a problem. He said he understood there was a lot of misunderstanding around the blue and yellow flag, the document that says they will filter, and this will confuse people so that?s why they didn?t publish it. Arjan Kamphuis, Bits of Freedom, thanked But for coming. He commented that if he would have followed the process and all the steps would have been communicated, that would have been great. He said that many of them had seen stuff like this before, like with ACTA and patents, and that when people first get a hold of documents and get worried, they get answers like ?we?re still discussing this? and then suddenly something happens and it gets locked in. This worries many people. He asked But to be proactive about communicating the dates. Arjan then commented about the text. He said he contacted some former intelligence people and got two different responses. The first was that there is no definition of ?terrorism?, it could be anything. The second person said that if you took the opening piece of text and replace ?Al Qaeda? with ?Pentagon?, the sentence still works because the Pentagon killed a hundred times more people over the last ten years. He asked what was the problem that But was trying to solve. But replied that Arjan?s comments are not too late and not too early. He said they ask participants to comment every time they publish it. They get many comments, many useful, and they have a lot of work. It?s been like that from the beginning. He added they were not like ACTA and they have their own process. But said that terrorism websites are not weapons but support terrorists? daily operations. They are looking for propaganda and radicalisation, that?s what they face in counter-terrorism. They use the EU?s definition in the document. They are trying to take an open approach and make the definition as clear as possible. Jim Reid said they must be careful doing things in this area with the processes in place. Everyone agrees that something needs to be done but wondered how the processes are used on a daily basis. He said there was a concern about mission creep and that noble things like counter-terrorism laws can be deliberately used for other things when the scope and boundary conditions are not clearly laid out. But replied that it was about trust and whether you could trust the government. Jim replied that it?s party about trust, but wondered where the audits and controls were. But said he wanted to change the public image of trust in the government but he can?t. He said that they needed to gain more trust to do the project as openly as they can and publish every two months. Alexander Isavnin, ZAO NetLine, wondered how many terrorism acts have been prevented in the Netherlands. He said he was from a country that But didn?t think was open and free and he was glad to see that slide because it shows an example of counter-terrorism in Russia. He said some students were jailed for preparing a terrorist act against Putin and they were caught on a forum on the Internet. They did make an explosive device. Interestingly, the person pushing them to do it and showing them how was never found. No one believes it. He added that the tradition in Russia is for law enforcement to provoke. He added that people shouldn?t trust the counter-terrorism organisations in Europe that are trying to overrule the Internet. Arjan, XS4ALL, via chat, asked if But could list some of the participants that have been ?reached out too? in the creation of the document. But replied that all partners and participants are listed on the website. Brian added that he linked to that page last week. The participants don?t state that they agree with the document. But agreed and said that the process of commitments starts after the last conference. B3. RIPE NCC Data Protection Legal Advice Update ? Athina Fragkouli, RIPE NCC The presentation is available at: https://ripe65.ripe.net/presentations/274-Data_Protection_Report.pdf Athina Fragkouli Shane Kerr, ISC, commented on slide 20. He agreed it was a hard problem but wasn?t sure that MNT-BY inputs the data, but he wasn?t sure that person determines the processing. Athina replied that MNT-BY is not the "responsible party", the RIPE NCC is that by default. Denis Walker, RIPE NCC, said by definition the ABUSE-C would not be personal data, that's why they provide bulk access to it. B4. ?Requesting feedback about abuse-finder widget in RIPEstat? - Christian Teuschel, RIPE NCC The presentation is available at: https://ripe65.ripe.net/presentations/272-antiabuse_info_ripe65.pdf Christian asked if it would be useful for the RIPEstat team to put more effort into the abuse contact. Three people raised their hands about abuse contact, no one raise their hand about more false positives, about five people raised their hand about more restricted, no one raised their hand about more checks like geolocation and two people raised their hand about distance in RIPE Database objects. Wilfried Woeber, UniVie, commented that the distance only gives an indication about the cluefulness about the people who put in the entries. Leo Vegoda, ICANN, said he looked through the anti-abuse stuff and popped in his private address and it said: "private address, no contact information". He said he looked at what they had in whois.iana.org, and would like to offer to work with you to offer the quality of info to the average user. Christian thanked Leo and said that the abuse widget is very new and they haven?t had much time to improve it yet. Peter Koch, DeNIC, asked for the policy for selecting blacklists. He said you register facts in the RIPE Database and here they extend it to a reputation system. He said the scrutiny is questionable and that the target audience is not qualified to judge this. He added that a line had been crossed and it made him nervous. Daniel Karrenberg replied that this was not their database: it?s RIPEstat. RIPEstat aims to get any data about a resource and present it. He said he shared Peter's concern about presenting it totally unqualified and they?re working on that. Their policy is ?anything they can get?. He added that the problem is that most blacklists don't permit re-publication and showing of history. These may not be the greatest ones, but to the knowledgeable person, the current state and history is useful thing to know. He said clearly it?s not part of the registry, but part of the information services that the RIPE NCC provides. They want to put this into context for consumers that aren?t usually geeks. Christian asked the audience to send further feedback by email. Wout de Natris, a consultant, commented that what they?re seeing here is Internet governance how it should be. He advised to gather information from as many independent places as they can. He added that there are a lot of botnet centres and ISPs cooperating with that. There is a lot of data to be gathered of what is going wrong there and they?re making it visible, which is a start. B5. ?Re-allocation of address blocks? ? Ingrid Wijte, RIPE NCC The presentation is available at: https://ripe65.ripe.net/presentations/264-Reallocation_of_address_blocks.pdf There were no questions. B6. Operation of ?Copy Shops? - Peter Forsman, .SE The presentation is available at: https://ripe65.ripe.net/presentations/73-counterfeitwebsites.pdf Daniel Karrenberg asked what the RIPE community could do to help? Peter said he couldn?t say exactly. He was just there to raise awareness because the Swedish law enforcement asked him to help find the websites that target Swedes. He said it couldn?t be done, there are new ones next week. Daniel asked why he thought that the new gTLDs made a difference. It makes no difference what the domain is, they went for the cheapest ones. Peter replied that they go through .cn ones mostly. If ICANN has a problem with registrant data today, there won't be less of a problem with the new TLDs. Daniel replied that the ones listed on his slide were GoDaddy and ENUM, not Chinese. Peter said those were examples. If they see 1,000 new TLDs in the future, the price would be lower than .com today. Daniel added that they would go for the cheapest ones and the ones that are not really good at publishing registrant data. C. Policies RIPE Policy 2011-06 Brian Nisbet announced that 2011-06 has reached consensus. He thanked the task force and Tobias who wrote the bulk of it and push it through. He said they?d speak to the RIPE NCC about implementation. Daniel commented that he loved it and asked how he proposed not having it remain wishful thinking. He added that you can mandate all sorts of things but getting people to populate it is the hard part. Brian said they?d work with the RIPE NCC on the basic information and looking at 2007-01, those are big jobs. He added that they?ve already talked about what?s next in terms of policies such as data verification. He acknowledged that people would continue to do bad things but hoped this would be a first step in creating a framework to improve that. Daniel commented that he?s detecting antagonism about the RIPE NCC doing stuff without asking the community. He added that if they had to make people do something, the community should be directly involved. The community guidance should be very clear. Brian agreed and said that he and Tobias have undertaken that work. He said he did not want the RIPE NCC to get blamed for what?s clearly a community request. D. Interactions Brian Nisbet said there haven?t been many since RIPE 64 but 2011-06 might bring up some so they?ll see what happens. D1. Working Groups D3. RIPE NCC Gov/LEA Interactions Update Brian commented that it?s been a quiet summer and that there?s a certain amount of management by exception done by the LEAs. He said that he?s spoken with Jochem de Ruig, RIPE NCC, and was informed about planned interactions with the LEAs. X. A.O.B. There were no AOBs. Z. Agenda for RIPE 66 Brian Nisbet asked the audience to email input for the RIPE 66 Anti-Abuse Working Group agenda to the mailing list, to Brian and Tobias. Brian thanked the audience and closed the session. From wiegert at telus.net Tue Jan 29 19:46:09 2013 From: wiegert at telus.net (Arnold) Date: Tue, 29 Jan 2013 10:46:09 -0800 Subject: [anti-abuse-wg] *TELUS Detected Spam* proberry.de In-Reply-To: <87y5fcv3we.fsf@mid.deneb.enyo.de> References: <8E6EFC2FBC0747FEACDEBFAC12984891@admin36565265a> <5106D6FB.8030305@telus.net> <51070013.8050001@CC.UniVie.ac.at> <87y5fcv3we.fsf@mid.deneb.enyo.de> Message-ID: <510818F1.2060905@telus.net> On 28/01/2013 11:34 PM, Florian Weimer wrote: > * Wilfried Woeber: > >> Arnold wrote: >> >> ...and looking at the message in text mode, instead of the "fancy" html >> rendering, may give you a clue about the real URL you are supposed to >> visit. ;-) > These messages are plain text (even ASCII), and the URL is > unobfuscated. They really do not make much sense. That is evidently what it is supposed to look like.They want you to simply reply to the address that appears in plain text. By inspecting the actual source code of the message one can typically find out much more - most importantly the actual IP address of the infected machine used to send the SPAM. The message must have been sent from a valid account somewhere and the idea of wxSR & other SPAM reporters is to make it easy to identify that address, find out the ISP who is responsible for the address and then forward the message to the ISP for action. Forwarding the complete message to them will allow them to find out which of their machines are infected by the bots and hopefully 'squash the bot' and take that source of SPAM out of circulation - at least for a while Arnold -- Fight Spam - report it with wxSR 0.5 - ready for Vista & Win7 http://www.columbinehoney.net/wxSR.shtml From brian.nisbet at heanet.ie Thu Jan 31 12:55:10 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 31 Jan 2013 11:55:10 +0000 Subject: [anti-abuse-wg] CleanIT Update Message-ID: <510A5B9E.9000201@heanet.ie> Colleagues, (And cross posted to the Cooperation WG as it may be something interesting for them also.) You may be aware of the the CleanIT project http://www.cleanitproject.eu/ This project has presented to the AA-WG at two RIPE meetings and Tobias and I said we would keep the working group up to date. The final document of the project was officially published yesterday in Brussels and handed over to the EU Counter Terrorism Coordinator Gilles de Kerchove. More information, including a download link for the document can be found here: http://www.cleanitproject.eu/final-document-clean-it-published/ It is unclear at present whether there will be any follow-up to the project, but various parties wish to investigate possibilities. If there are any further moves or projects to come out of this, we will let the AA-WG know. Brian