November 2014 - anti-abuse-wg

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

20 Jun '16

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

6 8

Re: [anti-abuse-wg] RIPE WHOIS blocked
by Edward Shryane 18 Nov '14

18 Nov '14

Hi Ronald, After looking into legal requirements for protection of personal data in RIPE NCC's service region, our community decided that there should be a limit on the number of queries with personal data served to each IP Address. Person and role objects are considered to contain personal data (email address, phone number(s), postal address), and queries for these objects are subject to a daily limit. Once this daily limit for querying personal data is reached, the IP address is temporarily blocked for the rest of that day. If an IP address repeatedly reaches its daily limit, then it is permanently blocked. By default when querying whois, related objects are also returned (including person and role objects). The '-r' flag can be used to not return related objects, or the '--no-personal' flag to not return person or role objects. For bulk access to the RIPE Database, split files (per object type) are published on the RIPE FTP site: ftp://ftp.ripe.net/ripe/dbase/split/ Regards, Ed Shryane RIPE NCC > > > Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. > > How long should it take for this error to go away? > > ============================================================================= > % 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 69.62.255.118 > % > % 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-… > > % This query was served by the RIPE Database Query Service version 1.76 (DB-2) > ============================================================================= > > > I have already written to ripe-dbm(a)ripe.net asking about this and have > received no reply. > > And anyway, can anyone here explain to me what the point is of limiting > WHOIS queries based on the source IP address? > > As far as I can see, this only has the effect of slowing down or blocking > the work of legitimate researchers, such as myself. Anybody who knows > anything about the Internet should know that an IP-address based throttling > system would be almost entirely ineffective against anyone who was seriously > determined to perform bulk harvesting of the RIPE data base via port 43 > (or via port 80 for that matter). > > It seems that I am being slowed down, blocked, and penalized for the sin > of having a static IP address, even while any other fool on the planet > who has a dynamically-assigned broadband IP, or even a dial-up line, > and who knows how to disconnect an reconnect can easily slurp all of > the RIPE data they want, with no real limits. > > In what universe is this non-stupid? > > More to the point, who is it, specifically, within RIPE NCC, that has > the authority to fix this? > > > Regards, > rfg > > > P.S. More stupidity: Based on the text at the URL provided in the > error mesage (see above) the goal of the rate limiting seems to be to > prevent harvesters from collecting too much "contact information". > OK. Fine. But the text on that web page also says that using the > -r option with the WHOIS queries will prevent such contact information > from being returned, thus eliminating the issue... or so one would > think. > > But why then is it the case that once my IP address has hit its head > against this daily limit, I am not even allowed anymore to even make > any more ``safe'' queries with the -r option? I am now locked out > completely. Why? > > Sigh. I guess that I need to go and drag my old 96Kb modem down out > of the closet, dust it off, and get myself a free dial-up AOL account > so that I can work around all of this stupidity. >

3 3

Re: [anti-abuse-wg] [routing-wg] AS43890
by Edward Shryane 18 Nov '14

18 Nov '14

Hello, Correct, here is a nice RIPE Labs article explaining those exceptions: https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-hold… Also, in case of transfer of holder-ship, as long as a user has access to maintainer password, or can recover it using the standard password recovery -meaning they are the rightful holder of the resource- they should be able to follow above mentioned procedure. Regards, Ed Shryane RIPE NCC > > Gert Doering wrote: > >> Hi, > [...] >>> Can any arbitrary RIPE member remove route objects that were created >>> by any other RIPE member? >> >> >> Generally speaking, no. > > Generally speaking, in order to delete an objecct, you need the same (set of) > credentials you would need to create or modify the object. > > As you correctly point out, there are a couple of exceptions to prevent dead- > lock situations when one party fails to cooperate. Removing a route object is > one of those, iirc; deleting a revDNS delegation entry is another. > >> Gert Doering >> -- NetMaster > > Wilfried > >

1 0

RIPE WHOIS blocked
by Ronald F. Guilmette 18 Nov '14

18 Nov '14

Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. How long should it take for this error to go away? ============================================================================= % 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 69.62.255.118 % % 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-… % This query was served by the RIPE Database Query Service version 1.76 (DB-2) ============================================================================= I have already written to ripe-dbm(a)ripe.net asking about this and have received no reply. And anyway, can anyone here explain to me what the point is of limiting WHOIS queries based on the source IP address? As far as I can see, this only has the effect of slowing down or blocking the work of legitimate researchers, such as myself. Anybody who knows anything about the Internet should know that an IP-address based throttling system would be almost entirely ineffective against anyone who was seriously determined to perform bulk harvesting of the RIPE data base via port 43 (or via port 80 for that matter). It seems that I am being slowed down, blocked, and penalized for the sin of having a static IP address, even while any other fool on the planet who has a dynamically-assigned broadband IP, or even a dial-up line, and who knows how to disconnect an reconnect can easily slurp all of the RIPE data they want, with no real limits. In what universe is this non-stupid? More to the point, who is it, specifically, within RIPE NCC, that has the authority to fix this? Regards, rfg P.S. More stupidity: Based on the text at the URL provided in the error mesage (see above) the goal of the rate limiting seems to be to prevent harvesters from collecting too much "contact information". OK. Fine. But the text on that web page also says that using the -r option with the WHOIS queries will prevent such contact information from being returned, thus eliminating the issue... or so one would think. But why then is it the case that once my IP address has hit its head against this daily limit, I am not even allowed anymore to even make any more ``safe'' queries with the -r option? I am now locked out completely. Why? Sigh. I guess that I need to go and drag my old 96Kb modem down out of the closet, dust it off, and get myself a free dial-up AOL account so that I can work around all of this stupidity.

5 5

AS43890
by Ronald F. Guilmette 18 Nov '14

18 Nov '14

Based upon the information I am currently looking at (see below) I now believe that it was perhaps a mistake for myself, and possibly others, to have become focused on the issue of insuring the correctness and/or validity of route objects within the RIPE data base only in those cases where the IP blocks in question are under the dominion of other (non-RIPE) RiRs. It now seems certain to me that the absence of anything even remotely approximating proper validation of RIPE route objects is not, in fact, a problem which is limited to just inter-RiR situations. Apparently, RIPE member LIRs can just as easily hijack the IP blocks of other RIPE members as they can in the case of IP blocks belonging to parties in other regions. Also, RIPE-resident hijackers can just as easily place validating route objects for these hijacked RIPE-issued IP blocks into the RIPE DB as they can for any other hijacked blocks taken from any other region(s). Readily available public data indicates that approximately three weeks ago, on or about October 25th, AS197207, an Iranian ISP, began announcing the following routes to the following chunks of its own properly registered IP space: 31.2.128.0/17 46.51.0.0/17 95.64.0.0/17 164.138.128.0/18 188.229.0.0/17 Prior to AS197207's decision to begin announcing the above routes (which they did, starting on Oct. 25th), it appears that the proprietors of AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected to announce their own set of routes to some or all of the above Iranian IP blocks, using lots and lots of little deaggregated /24 announcements to do so. Evidence in my possession indicates that some of the /24 blocks in question were in fact used by so-called ``snowshoe spammers'' during the time when AS43890 (aka "Netserv Consult SRL") was routing these blocks. This fact leads me to believe that the proprietor(s) of AS43890 most probably did not in fact have anything like real authorization from AS197207 to announce routes to any of the Iranian AS197207's legitimately registered IP space. Further and additionally, as in the recent case involving (Bulgarian) AS201640, it appears that (Romanian) AS43890 also and likewise created multiple route objects within the RIPE data base as a way of legitimizing what appears to me to have been several substantial IP space hijackings. Lastly, many, most, or all of the fradulent route objects created by AS43890 are still present within the RIPE data base, as of today. I am including a list of all 61 of these below. As was the case with the fradulent route objects created within the RIPE DB by AS201640, these 61 apparently fradulent route objects which were created by the proprietor(s) of AS43890 have likewise also been imported into the MERIT RADb, from the RIPE DB, thus spreading the bogus ``authorization'' to route these blocks even further, in a manner not unlike a viral contaminant. Regards, rfg ======================================================================= route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.2.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.3.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.9.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.11.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.17.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.18.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.19.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.20.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.21.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.22.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.23.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.33.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.35.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.36.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.38.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.39.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.49.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.50.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.51.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.52.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.53.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.54.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.55.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.66.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.89.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.90.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.91.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.92.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.93.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.94.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.95.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.96.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.97.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.98.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.99.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.100.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.101.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.102.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.103.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.104.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.105.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.106.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.107.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.108.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.109.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.110.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.111.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.113.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.114.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.117.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.118.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.119.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.120.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.121.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.122.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.123.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.124.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.125.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.126.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered

8 10

New on RIPE Labs: Who's Watching
by Mirjam Kuehne 13 Nov '14

13 Nov '14

Dear colleagues, For those of you who missed Geoff Huston's "Who's Watching" lightning talk during RIPE 69, the write-up is now on RIPE Labs: https://labs.ripe.net/Members/gih/whos-watching Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: ECDSA and DNSSEC by Geoff Huston
by Mirjam Kuehne 11 Nov '14

11 Nov '14

Dear colleagues, Please find another security related article by Geoff Huston on RIPE Labs: Elliptic Curve Digital Signature Algorithm (ECDSA) and DNSSEC https://labs.ripe.net/Members/gih/ecdsa-and-dnssec Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Gert Doering 09 Nov '14

09 Nov '14

Hi, On Thu, Nov 06, 2014 at 02:55:52PM +0000, anfernandez(a)lavanguardia.es wrote: > When RIPE is actually a judge that decided to protecting internet piracy. You can be sure that RIPE will open an expedient to any LIR that do not pay its fee, but you can keep waiting to see RIPE opening an expedient to investigate bad use of internet by one of their associated LIRs. It should be made totally clear that spamming, pirating movies, and so on is a legitimate usage of IP addresses IF THE JURISDICTION OF THE LIR IN QUESTION PERMITS IT. We might not *like* it, but if it's legal in, say, Romania to send out large amounts of e-mail, attacking the RIPE NCC for providing IP addresses to a LIR in .ro is not the way to fix it. Now, we all might agree that SPAM is evil, and pirating moviez is also evil. What about encouraging political debate? China might have a stance here. What about pictures of men kissing men? Russia might not like that. Things that are totally inacceptable for some parties are things that other parties want protected by freedom of speech, or freedom of doing business. So, the NCC can, will and *should* not act on "things people do not like" - it will (and does) act if being lied to, or if a judge decides that a LIR's business is illegal. In this particular case, I wonder why nobody is yelling at the upstream who is happily forward packets for that AS... due dilligence at accepting customer prefixes would have easily caught the announcements. (Yes, I understand that I'm now officially part of the problem, as I'm obviously not willing to do everything technically possible to stop particular sorts of badness) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

7 25

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Ronald F. Guilmette 06 Nov '14

06 Nov '14

<anfernandez(a)lavanguardia.es> wrote: >Don't waste your time. RIPE is not going to do anything about piracy... I already took my turn, years ago now, howling my disappointment that neither RIPE, nor RIPE NCC, nor any other RiR is willing to play the role of the Internet Police. I'm over that adolecent phase now, and have come to accept what they are, and the fact that no howling on my part is in the least bit likely to change what they are. The RiRs are fundamentally data base companies. I don't intend by saying that to slight them, or anybody associated with them in any way. I am quite completely sure that they also do quite a lot of other very fine work also... making all sorts of logistical arrange- ments for regular meetings, and all that goes with that, and RIPE Labs produces some fine tools and excelent technical reports. In short, they do a _lot_ of fine work. But at base, their first order task... RIPE NCC anyway... is the orderly allocation of resources and the maintenance of the data base. Anybody who knows anything about the history of the United States, as I do, can grasp the notion that RIPE is just a sort of ``federal'' system... a federation of a bunch of sometimes waring tribes/states, each with its own separate agenda, and a federation with intentionally limited powers over its constituents. So I'm not really either expecting or even asking them to ``do'' anything about ``piracy''. I will however ask them to look into some of the things that seem wrong to me and that appear in their data base. And I have faith that they will do so, because that _is_ their job. Regards, rfg

3 2

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Ronald F. Guilmette 06 Nov '14

06 Nov '14

anfernandez(a)lavanguardia.es you wrote: >Let me ask you a question: Which is the mision of RIPE? You didn't ask _me_, but I will answer anyway. The first order mission of RIPE NCC is to make and oversee number re- source allocations, insuring that they are done in an orderly fashion, and to maintain the data base of said allocations. The first order mission of RIPE is to fund and maintain RIPE NCC. >RIPE's web site say: We serve our members by delivering a high quality regi >stry and supporting the core Internet infrastructure. Connecting people wit >hin and beyond the technical community through our inclusive, multi-stakeho >lder approach, we contribute to an innovative and reliable Internet. > >Do you really think RIPE is serving its mission? I do, yes. >Do you really think RIPE is providing a reliable internet? I do, yes. Every time I go to visit, for example, www.bbc.com, it just works. Younger people sometimes don't appreciate what a minor miracle this seemingly simple thing is, and what a colossally large number of different things *all* have to work, and work correctly, in order to make it happen. (I've been working on computers since the mid 1970's, and let me tell you, back then it was _really_ a minor miracle when anything did in fact work.) Regards, rfg

1 0