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

Potential New Chair: Introduction & Next Steps
by Brian Nisbet 31 Jan '22

31 Jan '22

Colleagues, Thank you for being happy with the notion of a potential new Co-Chair. The person in question is Markus de Brün, who I'm sure some of you will already know. The next step is that I he will introduce himself and then the WG will have some time to express opinions, ask questions and either reach consensus or not. Please hold off on any comments or replies (unless you have an issue with the process) until after Markus has sent his intro mail. Ideally we would do this on this mailing list, but, as ever, if you need to email the Co-Chairs directly you can do that on aa-wg-chairs(a)ripe.net Let's say this period of time will end at 17:00 CET on Monday 7th February. Thanks again, Brian Co-Chair, RIPE AA-WG Brian Nisbet (he/him) Service 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

5 4

Proposal: Publish effective users' abuse-c
by Alessandro Vesely 22 Jan '22

22 Jan '22

Hi all, we all know abuse-c data is to be filled by the IP assignee, which I call ISP in the following. I understand that, since ISPs own IP space it is their job to ensure that it isn't abused. If they give up the receiving of abuse complaints and give it to their customer instead, and they don't receive the complaints as a result, then they won't be aware if their customer is violating important policies. However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP than the actual owner. I propose that RIPE accepts abuse-c email addresses from verified effective users of a range of IP numbers, stores them in the database, and serves them in RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP. Various automated methods can be adopted to allow an effective user to be verified; for example publishing an HTTP URL or a DNS entry. Abuse contacts added that way can expire after a few months, forcing the effective user to renew them, so as to avoid stale entries. I'm unsure if the above requires proposing a new policy or what else. For the time being, it would be interesting to gauge if this WG likes the idea and if there are effective users, apart from me, who would be interested in publishing their abuse-c. Best Ale --

4 10

Potential New Co-Chair
by Brian Nisbet 20 Jan '22

20 Jan '22

Colleagues, As you're all aware Alireza stepped down as Co-Chair at the end of his term at RIPE 83. As nobody put themselves forward for the third position at that time it was not filled, which is fine. Since then a community member contacted Tobias and I, expressing an interest in helping to Chair the WG. They were rather engaged with important life matters last autumn and did not have the chance to put themselves forward at that point. What we are now proposing is that this person is introduced to the WG as a potential Co-Chair (likely with a term technically starting at RIPE 83) and the WG can either accept them or not. This is your choice, of course. So, as a first stage, does any object to this happening "out of cycle"? I'm very happy to say that silence indicates consent here, but if you have any objections then please state them here or to aa-wg-chairs(a)ripe.net before 17:00 CET on Wednesday 26th January. If that is all good, we'll proceed with the next phase. Thank you all, Brian Co-Chair, RIPE AA-WG Brian Nisbet (he/him) Service 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

8 7

New on RIPE Labs: Why Are Authentication and Authorisation So Difficult?
by Alun Davies 01 Dec '21

01 Dec '21

Dear colleagues, Where do you begin when tasked with selecting a strong authentication solution for your organisation? In this guest post on RIPE Labs, Kathleen Moriarty provides an introduction and resources on this issue, kicking off a series of articles on authentication and authorisation technologies in the context of recent exploits and developing trends: https://labs.ripe.net/author/kathleen_moriarty/why-are-authentication-and-a… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE 83: Anti-Abuse Working Group Minutes
by Tobias Knecht 30 Nov '21

30 Nov '21

Hello, first of all thanks again to all attendees of the Anti-Abuse Working Group Session and a special thanks to the presenters and the amazing people that put our Minutes together. Speaking of Minutes, please find attached the Minutes of last week's Working Group Session and let us know if you have any additions or clarifications before December the 7th. Thanks, Tobias

1 0

FYI: a new anti-abuse automation project will be starting soon
by L. Aaron Kaplan 23 Nov '21

23 Nov '21

Dear Anti-Abuse WG, As already mentioned to Brian and the WG chairs in a private mail, I would like to raise your attention towards a new initiative that I will be pursuing in 2022: an open source abuse handling automation tool for smaller network operators. Thanks to the RIPE CPF it got some initial funding. Here is the RIPE CPF summary: Project abstract ---------------- ``` Open Source Automatic Incident Report Handling and Response Tool for RIPE Members RIPE members range from large network operators to small or even very small networks (the “long tail”). Common to all of them, is that they have publicly routed and active IP addresses and devices which are reachable from the Internet. With Internet-wide scanning tools (shodan, etc.), any vulnerable device is discoverable with a click of a button for any malicious actor. While large network operators can spend a lot on IT security-incidence response (IR), network hygiene and incident report handling, smaller ones can’t. In our experience, these smaller networks very selectively deal with IR. Many of the reports sent by national CERTs are ignored due to the lack of personnel, skills or resources. The effect being that Internet hygiene is suboptimal in the long tail. Which in turn, creates more hacked devices, DDoS amplifiers, etc. and poses more threats to the global network. Our project aims at bringing the best of breed open-source technology as a turn-key package to the “long tail” networks to plug into their customer contacts database (CRM) system on the one side and to the global feeds of threat intelligence and scanning alerts (such as shadowserver.org). Automate the IR, improve network hygiene! ``` (Source: https://www.ripe.net/support/cpf/funding-recipients-2021) Rest assured, I am aware of all the good work done at this WG and at abuse.io and abusix. Not trying to re-invent the wheel, no worries :) About myself and motivation for this project -------------------------------------------- I have been working at a European national CERT for 12 years and am one of the two co-founders of the https://intelmq.org Incident Response (IR) automation project. IntelMQ is mainly geared towards the "information router" role of national CERTs. Less so for network operators. What struck me during that time at the national CERT is that there is a wide variation between how some network operators clean up after abuse reports, and some do the bare minimum (no accusation here!). Even though good tools such as abusix would exist for them. So, the question is: *why* is that so? There must be a good reason for it. And this leads me to the project motivation. The first part of this project shall analyse, *why* and *how many* of the abuse notifications are not done. Is it the network operator? Is it the end-customer? Is it culture? Is it lack of resources? Is it the (economic) network externalities? Is it all of the above? I believe, once we identify some of the blockers, we can *improve* existing solutions, add to the portfolio of existing solutions and/or combine them into a packages which might actually do the next step without much effort. Ideally, abusix, abuseio, intelmq, n6, warden, ... (all these tools which help in IR for network operators) would get a boost by this project AND the network operators get improved tools.[1] Request for your help --------------------- Since this is an open source project, I would like to reach out to anyone here who is interested and start collecting some initial quantitative interviews with you on the questions (the "why?" questions) above (interviews will start in mid-Dec). In parallel, I'll be doing some lit.research on the topic. I'd be thrilled to have the combined knowledge of the WG as part of this project. After all, the problem we are trying to solve is similar to tackling pollution or climate change (just - for the internet): it's a super hard problem. Lots of externalities, lots of hard nuts to crack and for sure no-one can solve this problem on his/her own. Thanks for your time, reading this. Aaron Kaplan. PS: I probably can't make it to tomorrow's Anti-Abuse WG session (I have parallel calls which I can't skip). But I'd appreciate you reaching out to me via email. In in the WG session tomorrow you could mention this little project of mine, I'd be quite happy about that. [1] I am very aware that with limited funding and an infinitely, arbitrarily large problem, we won't be able to tackle all of it in this small project. But we can try and add the our global anti-abuse capabilities. Hence, I am reaching out to this WG for input and advice.

1 0

RIPE Database Purposes - Video presentation
by denis walker 23 Nov '21

23 Nov '21

Colleagues In advance of my presentations tomorrow, if you have a spare 15 minutes please watch the pre-recorded presentation: https://ripe83.ripe.net/wp-content/uploads/presentations/DB_WG-Denis_Walker… cheers denis co-chair DSB-WG

1 0

Agenda Update - RIPE 83
by Brian Nisbet 22 Nov '21

22 Nov '21

Colleagues, A small addition to our agenda for Wednesday 24th (session starting at 10:30 CET) about the RIPE DB. And while the closing date for nominations has passed, if anyone has a sudden interest in putting themselves forward as a potential Co-Chair of the WG, then please do email me before Wednesday morning! A. Administrative Matters * Welcome * Scribe, Chat, Stenography * Chat Etiquette * Ratings Where Appropriate * Approve Minutes from RIPE 82 * Finalise agenda * Working Group Chair Selection B. Update * B1. Recent List Discussion C. Policies - *C.1. D. Interactions - *D.1. RIPE NCC Abuse Handling Training (15' - 20') *D.2. RIPE RIPE Database Purposes in the 2020s and Beyond - Denis Walker E. Presentation - *E.1. *E.1. "The Hijackers Guide to the Galaxy: Off-path Taking over Internet Resources" - Tianxiang Dai, Technische Universität Darmstadt X. A.O.B. Z. Agenda for RIPE 84 Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet (he/him) Service 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

Re: [anti-abuse-wg] Is there any analysis on root causes of mail account break-ins?
by Natale Maria Bianchi 18 Nov '21

18 Nov '21

Almost 10 years ago I wrote this short blog article with some ideas arising from the examination of a fairly large numbers of incidents: https://www.spamhaus.org/news/article/681/spam-through-compromised-password… I think that it is basically still quite current, except for some GDPR-related aspects, and although the last sentence was clearly, well, a little too optimistic. Unfortunately MSAs did not evolve as fast as we hoped, and several organisations continue to allow compromised accounts to start sending with astounding intensities. Natale M Bianchi

1 0

Is there any analysis on root causes of mail account break-ins?
by Hans-Martin Mosner 17 Nov '21

17 Nov '21

Hi folks, I'm trying to understand the root causes and vulnerabilities that lead to hacked mailboxes. Currently, we can handle dynamic IP ranges pretty well, and we have an extensive list of network ranges whose owner are spammers or knowingly accept spammers as customers. So what mainly remains as spam sources are hacked servers/websites, hacked mail accounts, and freemail accounts registered with the purpose of spamming (I'm looking at you, Google). Here I want to focus on hacked mail accounts. I can think of two major root causes but I have no idea about their relative significance: * Easily guessable passwords, with two subcauses for exploits: o Brute force authentication attempts - I'm seeing them regularly, and the most egregious networks (e.g. 5.188.206.0/24) are fully blocked at our mailserver, but some mailops are less struct about blocking such abusers. o Hashed password data exfiltration and cracking (for example using JtR) these lists - this would work better with weaker password hashing, but with weak passwords and some CPU power it is probably possible even for strong hash algorithms. * Malware on client machines where passwords are either stored in a password vault, or entered manually. My gut feeling is that some organizations are especially prone to hacked mail accounts. We're seeing lots of south american government agency users, and many accounts at educational institutions. The latter are often hosted using Microsoft O365 services, and I highly suspect that weak passwords for all the freshly created student accounts may be a major cause, although exfiltrated password data may be a possibility, too. So does anyone have pointers to studies analyzing these (and probably more) causes of exploited mail accounts? Cheers, Hans-Martin

4 3