Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
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@tristatelogic.com> Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: <nanog@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
Hi all, These are really interesting discussions so please keep me updated on progress against these rogue ASNs. Kind regards, Nick [personal information removed] On 5 Nov 2014, at 23:40, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
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@tristatelogic.com> Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: <nanog@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
In message <8F1040D0-94EA-47DC-97DD-027F186F2B12@nickshorey.com>, Nick Shorey <nick@nickshorey.com> wrote:
These are really interesting discussions so please keep me updated on progress against these rogue ASNs.
Progress?? I'll give you an update, but it hardly represents anything that could be called ``progress''. As of today, AS201640 is still squatting on these same 11 routes: 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 If you check back in a month or two, perhaps one or more of the networks that provides connectivity to AS201640's upstream, i.e. AS200002, may have finally taken its head out of its ass and done something about this ridiculously blatant case, but I wouldn't hold my breath if I were you. Regards, rfg P.S. Of course, it would be Nice if RIPE NCC eventually terminated the registration of AS201640. I think that's their only reasonable course of action, long term. But as is often noted, they are not the routing police, and even if they did so today or tomorrow, there would still be all these bogus route announcements being propagated to the far corners of the earth. The announcements would all then just be attached to an AS number that isn't in the RIPE DB anymore. But as far as I know, the announcements would still flow anyway. (I feel sure that somebody here will correct me if I'm wrong about that.) Its the network operators who need to put a stop to this over-the-top ludicrous situation. And so far, not a single one is stepping up to do that.
A quick update to an old thread. http://krebsonsecurity.com/2016/06/fbi-raids-spammer-outed-by-krebsonsecurit... —srs
On 07-Nov-2014, at 12:54 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <8F1040D0-94EA-47DC-97DD-027F186F2B12@nickshorey.com>, Nick Shorey <nick@nickshorey.com> wrote:
These are really interesting discussions so please keep me updated on progress against these rogue ASNs.
Progress??
I'll give you an update, but it hardly represents anything that could be called ``progress''.
As of today, AS201640 is still squatting on these same 11 routes:
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
If you check back in a month or two, perhaps one or more of the networks that provides connectivity to AS201640's upstream, i.e. AS200002, may have finally taken its head out of its ass and done something about this ridiculously blatant case, but I wouldn't hold my breath if I were you.
Regards, rfg
P.S. Of course, it would be Nice if RIPE NCC eventually terminated the registration of AS201640. I think that's their only reasonable course of action, long term. But as is often noted, they are not the routing police, and even if they did so today or tomorrow, there would still be all these bogus route announcements being propagated to the far corners of the earth. The announcements would all then just be attached to an AS number that isn't in the RIPE DB anymore. But as far as I know, the announcements would still flow anyway. (I feel sure that somebody here will correct me if I'm wrong about that.)
Its the network operators who need to put a stop to this over-the-top ludicrous situation. And so far, not a single one is stepping up to do that.
On Mon, 20 Jun 2016 10:46:57 +0530 Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
A quick update to an old thread.
http://krebsonsecurity.com/2016/06/fbi-raids-spammer-outed-by-krebsonsecurit...
to also add my 1c - 7 of the top ten spammers on the planet is from the USA https://www.spamhaus.org/statistics/spammers/ And currently the only spam getting through my new anti spam system is from Google, Hotmail, Outlook - huge US multi nationals and large email houses like Mimecast - that sends emails for Governments and also sends spam. The email abuse problem is a very simple and easy one to solve. Whomever sends or transmits spam must be blocked - until they have confirmed that there users infections, etc have been cleaned and/or they have reclaimed their IP ranges. I received my first email spam in 1988 and since then I have lived through so very very many opinions, systems, reading users emails to "predict" if what they are sending is spam or not and all sorts of fancy things. But the bottom line is that if people accept responsibility for what they transmit and if they maintain their networks and email sever IP numbers - there simply is no spam problem that cannot be solved. We make the email abuse problem complex ourselves by refusing to educate lazy users and to constantly try to fix the spam problem with spaghetti Current Spam Solutions = Spaghetti (or quicksand? and imnsho costs/wastes lots of money, resources and energy) Andre
—srs
On 07-Nov-2014, at 12:54 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <8F1040D0-94EA-47DC-97DD-027F186F2B12@nickshorey.com>, Nick Shorey <nick@nickshorey.com> wrote:
These are really interesting discussions so please keep me updated on progress against these rogue ASNs.
Progress??
I'll give you an update, but it hardly represents anything that could be called ``progress''.
As of today, AS201640 is still squatting on these same 11 routes:
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
If you check back in a month or two, perhaps one or more of the networks that provides connectivity to AS201640's upstream, i.e. AS200002, may have finally taken its head out of its ass and done something about this ridiculously blatant case, but I wouldn't hold my breath if I were you.
Regards, rfg
P.S. Of course, it would be Nice if RIPE NCC eventually terminated the registration of AS201640. I think that's their only reasonable course of action, long term. But as is often noted, they are not the routing police, and even if they did so today or tomorrow, there would still be all these bogus route announcements being propagated to the far corners of the earth. The announcements would all then just be attached to an AS number that isn't in the RIPE DB anymore. But as far as I know, the announcements would still flow anyway. (I feel sure that somebody here will correct me if I'm wrong about that.)
Its the network operators who need to put a stop to this over-the-top ludicrous situation. And so far, not a single one is stepping up to do that.
Just to get to the bottom of ripe-policy-addressable parts of this issue... are there any statistics on the legitimate and necessary usage of RIPE-NCC-RPSL-MNT? How reasonable would it be to do either one (or a combination) of these: a) deprecate this mechanism entirely b) devise a way to (manually and/or automagically) check if the respective usage in a certain case is legitimate c) check existing objects for likeliness of fraudulent usage (in coordination with the legitimate address space users) It seems that all route-objects in the ripe db that can be viewed via "whois -i or AS201640" were "authenticated" via RIPE-NCC-RPSL-MNT. From my point of view, this would be an obvious "it's about time"-thing to tackle by means of a policy change or change of operational procedures, employing the above mentioned measures, in order to combat the potential abuse of this aged and imperfect puzzle piece of RPSL goodness. A quick check however revealed that there is a humongous amount of objects affected. So any of those proposed options but a) will result in significant workload. Holy dingus, is this database a mess... -mh
Hi, On Fri, Nov 07, 2014 at 05:23:52AM +0100, Michael Horn wrote:
Just to get to the bottom of ripe-policy-addressable parts of this issue... are there any statistics on the legitimate and necessary usage of RIPE-NCC-RPSL-MNT?
I have no statistics. The legitimate and necessary usage is if you want to document your routing policy in the RIPE region but happen to have out of region networks "in your AS", for whatever reason. Now, enabling creation of database entries without authentication for the good guys (because we had no idea how to *do* authentication for these objects, the RPSL-dist-auth drafts didn't really fly) also enables this attack angle.
How reasonable would it be to do either one (or a combination) of these:
a) deprecate this mechanism entirely b) devise a way to (manually and/or automagically) check if the respective usage in a certain case is legitimate c) check existing objects for likeliness of fraudulent usage (in coordination with the legitimate address space users)
This mechanism needs to go away, and I think everybody agrees here. George Michaelson's idea to use RPKI to permit foreign-region entries into the RIPE DB ("if the ROA validates, route: objects may be created") might work out nicely (or not, for legacy resources that currently cannot get an ROA) - or Kaveh's approach to refuse creation of route: objects for those with a conflicting ROA. Sounds similar, isn't :-) c) might actually be not that hard ("just check the originating database if a route: or ROA exists") but will quite likely turn up a pile of old and non-maintained junk, so be a lot of work... 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
On Mon, Nov 10, 2014 at 12:14 AM, Gert Doering <gert@space.net> wrote:
Now, enabling creation of database entries without authentication for the good guys (because we had no idea how to *do* authentication for these objects, the RPSL-dist-auth drafts didn't really fly) also enables this attack angle.
And Krebs weighs in with episode #2 - now with additional statements from RIPE NCC, and documenting the scale of this hijack. http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-looph... --srs -- Suresh Ramasubramanian (ops.lists@gmail.com)
In message <CAArzuosqUe2K5eX6_3u0AWRCf-1Mbp7ingLLvjOetF=MeSSV_Q@mail.gmail.com> Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-looph...
I just want to apologize, publically, to everyone in RIPE NCC and the RIPE community generally, for some of the quotes attributed to me in the Krebs online article about this story/issue. Some of what he quoted me as saying was, I feel, taken out of context, and I'm not entirely happy that my comments about this situation came off as being overly critical of RIPE NCC and/or the RIPE community. I understand that there are difficult issues involved here, and that while technical measures (e.g. RPKI) might help to reduce the frequency of this sort of event, even those things are dependent upon a universal or nearly universal community acceptance and ratification of some hypothetical new requirement for that... an acceptance which is not in fact universal within the RIPE community at the present time. Regards, rfg
participants (6)
-
andre＠ox.co.za -
Gert Doering -
Michael Horn -
Nick Shorey -
Ronald F. Guilmette -
Suresh Ramasubramanian