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

Agenda Items - RIPE 77
by Brian Nisbet 10 Sep '18

10 Sep '18

Colleagues, As you're hopefully aware the next RIPE meeting, and so the next meeting of the AA-WG, is just a month away! The AA-WG will be meeting on Thursday 18th October at 11:00 CEST. While I plan to publish a draft agenda shortly, I would ask if anyone has any items they would like to feature at the meeting. This can be policy discussions or proposals, work items, items for general discussion or presentations. Please do let me know if you have anything in mind. Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

New on RIPE Labs: Let's Connect!
by Mirjam Kuehne 04 Sep '18

04 Sep '18

Dear colleagues, Please find an update of Let's Connect! on RIPE Labs. The main aim of the Let's Connect! project is to develop a secure, fast and usable open-source VPN solution that can be used by anybody on all types of devices. It is one of the projects that has been funded through the RIPE NCC Community Projects Fund: https://labs.ripe.net/Members/rogier_spoor/lets-connect Kind regards, Mirjam Kühne RIPE NCC

1 0

The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
by Ronald F. Guilmette 23 Aug '18

23 Aug '18

The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of whoever or whatever is MNT-SERVERSGET. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently hiding behind the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/bro… I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.

7 10

Automatische Antwort: New on RIPE Labs: Honeypot-based Monitoring of Amplification DDoS Attacks
by Heger, Christian 03 Aug '18

03 Aug '18

Ich bin zurzeit nicht im Hause. Bitte wenden Sie sich in dringenden Fällen an meine Kollegen. Diese Mail wird nicht weitergeleitet! Mit freundlichem Gruß DATEV eG Christian Heger SOC | P14 90329 Nürnberg Telefon +49(911)319-42250 | Telefax +49(911)14706182 E-Mail christian.heger(a)datev.de<mailto:christian.heger@datev.de> | www.datev.de<http://www.datev.de/> Standort: Paumgartnerstr. 6 - 14 ________________________________ DATEV eG 90329 Nürnberg Telefon +49 911 319-0 Telefax +49 911 147-43196 E-Mail: info(a)datev.de Internet: https://www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14 Registergericht Nürnberg, GenReg Nr. 70 Vorstand Dr. Robert Mayr (Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Julia Bangerth Prof. Dr. Peter Krug Diana Windmeißer Vorsitzender des Aufsichtsrates: Nicolas Hofmann

1 0

New on RIPE Labs: Honeypot-based Monitoring of Amplification DDoS Attacks
by Mirjam Kuehne 03 Aug '18

03 Aug '18

Dear colleagues, Amplification DDoS attacks are one of the most prevalent forms of denial-of-service attacks. The SISSDEN project operates a network of honeypots designed to detect these attacks, observing 10,000 per day. Please find some interesting observations in this RIPE Labs article by Johannes Krupp: https://labs.ripe.net/Members/johannes_krupp/honeypot-based-monitoring-of-a… Kind regards, Mirjam Kühne RIPE NCC

2 1

Re: [anti-abuse-wg] When email verification behavior is abusive
by Michele Neylon - Blacknight 18 Jul '18

18 Jul '18

If you framed your issues or questions more clearly and succinctly it would be helpful. In relation to your specific "ask" I don't think it's the right one. You could, potentially, come up with a best practice eg. That providers should verify that account holders / users have access to an email address before letting them add it to a service. But I've no idea how you'd decided on rate limiting the verification emails. Based on my own experiences with mail servers, spam filters, grey listing etc., you can easily end up spamming yourself when those emails don't come through quickly enough. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 On 18/07/2018, 12:30, "anti-abuse-wg on behalf of ac" <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: Thank you for asking that very valid question! Whether something is Abuse or not abuse and when Internet behavior is abuse or not has everything to do with this WG. And, discussing what constitutes abuse (or not), how (or even if) it affects RIR etc is very relevant as it leads to a clearer understanding of many things. One very basic thing would be resource abuse reporting. How can anyone report abuse if it is not even considered to be abuse? I can go on and on, but that would be counter productive. Why do you not help and tell me what arbitrary number of verify your email address, emails would you consider to be abuse - and in/over which period? That would be super helpful to everyone, as I do not think any of us actually knows what we all consider the arbitrary number to be? Or are you saying it is not abuse at all? Actually, sorry I may not understand why you are asking about relevance? Regards Andre On Wed, 18 Jul 2018 11:03:47 +0000 Michele Neylon - Blacknight <michele(a)blacknight.com> wrote: > What's any of this got to do with RIPE and this WG? > Is there a policy proposal or something else forthcoming? > > Regards > > Michele > > -- > Mr Michele Neylon > Blacknight Solutions > Hosting, Colocation & Domains > https://www.blacknight.com/ > https://blacknight.blog/ > Intl. +353 (0) 59 9183072 > Personal blog: https://michele.blog/ > Some thoughts: https://ceo.hosting/ > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business > Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: > 370845 >

2 1

Re: [anti-abuse-wg] When email verification behavior is abusive
by Michele Neylon - Blacknight 18 Jul '18

18 Jul '18

What's any of this got to do with RIPE and this WG? Is there a policy proposal or something else forthcoming? Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845

3 5

When email verification behavior is abusive
by ac 18 Jul '18

18 Jul '18

Hi All, ESP and email relay services should verify recipient email addresses prior to sending bulk emails to any random email address. ESPs that simply start dumping bulk emails on victims often end up listed on RBLs for abusive behavior. But, when is verification emails themselves, spamvertising or email abuse? Our own email policy defines verification abuse as "more than 3 verify your email account" emails in the same 24 hour period and verify your email account emails lasting longer than five 24 hour periods. Do you think this is reasonable? Too reasonable? More? Less? If you receive say 4 "verify your email account" emails in 5 minutes, is this abuse? Andre

1 0

I'm sure this is totally accurate :-)
by Ronald F. Guilmette 13 Jul '18

13 Jul '18

Bummer. www.ripe.net is distributing malware. https://quttera.com/detailed_report/www.ripe.net :-)

3 2

Re: [anti-abuse-wg] Google & Cisco
by ac 10 Jul '18

10 Jul '18

Hi, So, I have received some off list email, about my post. The trouble with off list email is that sometimes things are discussed that is of value to the community. These are my additional comments: Abuse systems can also be abusive, for example: http://multirbl.valli.org - warning all about a 'fake' rbl Abuse systems can be used as weapons - both for war as well as for corporate war. Abuse systems and platforms can be used to the detriment of the EU Where corporations club together and could be used to influence the growth/decline of services of a country or group of countries. Anyway, included is an extract of headers where SpamCop ignores date: Tue, 10 Jul 2018 03:08:27 -0700 (and the Google Relay ipv4 - which for the record was: mail-oi0-f44.google.com(a)209.85.218.44 and on Tue, 10 Jul 2018 03:08:27 -0700) and fails the report on date (older than 48 hours) as SpamCop trusts the Google relay and wants to report about: 2002:a4a:4841:0:0:0:0:0 with HTTP; Sat, 7 Jul 2018 19:37:11 -0700 (PDT) Which usually would have been the TELECOM company IP number (of the telecom user/company) The 'Telecom' company IP number is not an email server and therefore SpamCop reports that many abuse admins on this list receives, are not really worth much any longer as any spamcop report that is not about your email servers, can be safely deleted. Cisco basically says that they do not have any deal with Google and that they are not protecting Twitter, Facebook, Amazon and Microsoft I am wondering what the benefit is to Cisco by devaluing the value of SpamCop for abuse admins? Or is it more a case of protecting the big 5 and keeping everyone else on their toes? Is this bullying? Is it nefarious? It is not good. It is not ethical and it is plainly EVIL. +++++++++++++ Received: by mail-oi0-f44.google.com with SMTP id n84-v6so41513085oib.9 for <victim>; Tue, 10 Jul 2018 03:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jenreviews-email.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=EFkdASUSCy3UwqSvm2EX4abetipkteFp5j+2Y9kJF0c=; b=SUrZKZxQlMfl7LPwx6nTHoGJ9KnOH7k/7XJq80zGpkGERu4ogQnOIjJvbWC2NN3CK/ QwKh9JcBgnkdOHgnHcLlaoogt7o3+arGGjmNUBB9AP7jif35Hz74gurZ8vprFSO0mvjG sggWkN3rFq/wp+FuNKChWY4lT4PrsVbqo27UEvstouEsuMsH4OfBSAHpc7bb4QsuKvAd 0UglZIUWMxHGYYlFJB14SElmm4ILXXPEEZZky7JQa6OOpzvCV9Ak6cd+L6o1EuK04Npk A8+uM27v6UWsZLvX10+7D5CwL4t8oK97FG46cELHQE58nWlIVDm9PvAF5E970W46Pihy zceA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EFkdASUSCy3UwqSvm2EX4abetipkteFp5j+2Y9kJF0c=; b=tJ0aM+VgmcMNhkOPlpYnhGNlP0/V0hWzttKZWMQxd9FZDEDbx5YbxGZn3dIrghNZY6 LOKdbKk5NUU61oqV/B0a/1ecm8mqFV4hP/qlDcFuu9HXeYsxgwZ9ieGF7EpBycnzJqLT 3n9ldMJuNL9RiKWJr1L4o4+JySpJ8Dp4zsuRfm4rn4V2cQQP8LT763r2sKXG1jEXG6Yy VQUL8eEdnsWgN4ON4LQA34MqHTejtHnTNTFYrWQUX8VjqIImedNl58Gx8RNW7nHSwt/F eaGw/xl3umn4bkONz8UVkpYVqgTI8nqVehhJlynKTPyTKxLFS9waGPieOOM9hLkeb+eA 2JeQ== X-Gm-Message-State: APt69E3m7PhKks5zjFEwDCJkBQzeDd3nggWlzc1bT0LzBBFYHQMSDN5F toEVWauopOgYRWJ7JSCN637aGLXOvTSpggI1GKu4aw== X-Google-Smtp-Source: AAOMgpdxfMce9VRJy0i9imFEwrYn4NZwGbhBzGfmH1WTfcicyUEVdX7DJIykmii9WZ7wnhUCy93cLp/a7T/At+cVdJE= X-Received: by 2002:aca:430b:: with SMTP id q11-v6mr28734957oia.127.1531217285617; Tue, 10 Jul 2018 03:08:05 -0700 (PDT) Received: from 776393159873 named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 03:08:05 -0700 MIME-Version: 1.0 Received: by 2002:a4a:4841:0:0:0:0:0 with HTTP; Sat, 7 Jul 2018 19:37:11 -0700 (PDT) From: Jenn Miller <jenn(a)jenreviews.email> Date: Tue, 10 Jul 2018 03:08:05 -0700 Message-ID: <CALvVF876A17shGKhFmXEU2hD4Z0CNsY4mHy1=Sj1rASQStYDAQ(a)mail.gmail.com> ++++++++++++++++++++++++ On Thu, 5 Jul 2018 13:23:08 +0200 ac <ac(a)main.me> wrote: > Hello All, > > As we all know, Google and Microsoft dominates email relay in many > places and they are getting even larger with each passing year. > > They are not getting larger because they are offering great email > service but because they are ever more aggressive and sometimes under > handed and do not behave decently or in an ethical way. > > if the present trends continue, there will be almost no email relay > that does not operate through either Microsoft or Google. > > Interesting thing that all of us (and Microsoft) should take careful > note of is that Google has done a deal with Cisco (Talos SpamCop) > whereby reports about abuse (including spear phish, spam, scams, etc) > - are no longer sent to Google (abuse(a)google.com) but directly to the > relay ipv4/ipv6 abuse ISP contact. When there is no ipv4/ipv6 abuse > contact the complaints are discarded and in a minority of cases, > still go to abuse(a)google.com > > Microsoft of course has two attack vectors. One the 'custom' protocols > of their exchange servers and the other is that they mix legit email > and spear phish, payday loan scams from the same servers. Google has > now also started doing the same thing. Before Google used to be > more responsive to abuse complaints and there were fewer actual > criminal activity relayed by Google. So, it is becoming more frequent > and common to find spear phish attack on a client, from Google and > Microsoft and this motivates clients to move services to Microsoft or > Google. > > I do not think that there is much an abuse wg can discuss around this, > as there is not much or anything that any of us can actually do about > the present situation as both Google and Microsoft has simply become > too large and year on year they are getting larger. > > Any comments? > > > > > >

1 0