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

Fwd: RIPE NCC Anti-Abuse Training: Next Steps & WG Input!
by Alex de Joode 10 Feb '22

10 Feb '22

There are many things to consider (some semi random topics to consider). * what do you consider abuse? * only technical abuse (portscanes, spam, brute force attacks etc) * or also 'content abuses' (doxxing, hate speech, csam etc) * what about harmful content, will that be considered abuse * what about unwanted content? * how does this all relate to freedom of expression? * what rights do your customers have * to what extent are you willing to act as the sheriff ? * there should be a dedicated working address for receiving abuse notices/complaints. (we have that covered for the most part) * do you issue a ticket number as a reference? * how can a complainer escalate? * making a abuse complaint should be made as easy as possible * however, (for streamlinening puposes) a webform, or registration in a support system should be acceptable (some complainers are really stupid) * if a complaint does not include the minimal information to assess the validity, a request for more information could be sent, while the original complaint is closed * every company is different, has different policies, procedures and customers, educating frequent complainers is needed to ensure to most efficient way of dealing with abuse. * you have to make a decision about the information you forward to your client so they are able to resolve the issue * full message, always? only to reseller? also to enduser? * does a complainer have a reasonable expectation of privacy? * is this different for the automated copyright abuse sending mills? * what if the 'proof' of an abuse, would reviel the means? (ie spamtrap address) * how much proof do you need to forward this as an issue to your client? * you should have a process to contact the customer * directly by the abuse desk, * via sales (so they know their client generates 'issues') * you should have a process to restrict or limit usage of resources * directly by the abuse desk, * via networking > > * > * Abuse handling is not the same as support handling. Abuse reporters don't want help, they expect that it is in your own interest as a network operator to curb abuse originating from your network, and their reports are intended to help you reach that goal. This results in some Don'ts (I'm seeing all of these in reponse to abuse reports): * don't reject their messages because they are not your customers, > * don't require them to register with some support system, > * don't send meaningless auto-replies, > * don't try to teach them (unless they are really doing something wrong). * Although there may be conflicts with protecting your user's privacy, reporters really appreciate to know whether their reports have a meaningful effect as they sometimes spend considerable amounts of time. Positive feedback ("we've terminated that customer", or "we've worked with the customer to fix their exploitable software/account") is a huge encouragement to continue reporting abuse. If there is no detectable reaction (either in form of an answer or an observable stop of abuse) then an abuse reporter might determine that blocking your network is a more effective use of their time. * Many types of abuse originating from your network are signs of substandard security and warnings of possibly more damaging future exploits. Work proactively with your customers when you find systemic problems. For example, on one of the services that I look after, we had one or two mail account password compromises which led to spam bursts. We established a strict password policy, checking the password database for easily breakable passwords, and contacting all users with weak passwords so they changed them to secure passwords. Similarly, we proactively check customer's websites for exploitable plugins. What kinds of proactive abuse prevention works in your case might be vastly different, but not doing anything is gross negligence. * Abuse desk workers need authority to contact customers and to restrict their use of your resources. One basic prerequisite for contacting customers is that you know them. If your operation does not establish appropriate KYC rules you're bound to be an attractive provider for abusers. Of course, the amount of info you need for an e-mail account and for renting out a server are different, and you may be limited by privacy laws, but if you simply refuse to take responsibility while not disclosing information on who *is* actually responsible you're in for blocking. Cheers, > Hans-Martin >

1 0

Fwd: [dns-wg] EU: DNS abuse study
by Markus de Brün 10 Feb '22

10 Feb '22

For those who are not following the DNS wg list: The European Commission has published a quite comprehensive study on DNS abuse. (One could also call it enormous.) It study itself be found here: https://op.europa.eu/en/publication-detail/-/publication/7d16c267-7f1f-11ec… There is an additional document containing the appendix: https://op.europa.eu/en/publication-detail/-/publication/d9804355-7f22-11ec… -- Markus de Brün -------- Forwarded Message -------- Subject: Re: [dns-wg] EU: DNS abuse study Date: Fri, 4 Feb 2022 10:52:53 +0100 From: Petr Špaček <pspacek(a)isc.org> To: dns-wg(a)ripe.net On 01. 02. 22 9:32, Hank Nussbacher wrote: > The EU has published is 173 page opus on DNS abuse: > > https://op.europa.eu/en/publication-detail/-/publication/7d16c267-7f1f-11ec… I have had a peak when waiting for other things to happen and it might be interesting read. Here is a gist from chapter Executive summary: The study adopts the following definition of DNS abuse: Domain Name System (DNS) abuse is any activity that makes use of domain names or the DNS protocol to carry out harmful or illegal activity. The main findings of the measurements are: a) In relative terms, new generic Top-Level Domains (new gTLDs), with an estimated market share of 6.6%, are the most abused group of TLDs (Appendix 1 – Technical Report, Section 5, p. 26). b) Not all new gTLDs suffer from DNS abuse to the same extent. The two most abused new gTLDs combined account for 41% of all abused new gTLD names (Appendix 1 – Technical Report, Section 9.2, p. 32). c) European Union country code TLDs (EU ccTLDs) are by far the least abused in absolute terms and relative to their overall market share (Appendix 1 – Technical Report, Section 5, p. 26). d) The vast majority of spam and botnet command-and-control domain names are maliciously registered (Appendix 1 – Technical Report, Section 10.3, p. 41). e) About 25% of phishing domain names and 41% of malware distribution domain names are presumably registered by legitimate users, but compromised at the hosting level (Appendix 1 – Technical Report, Section 10.3, p. 41). f) The top five most abused registrars account for 48% of all maliciously registered domain names (Appendix 1 – Technical Report, Section 11.2, pp. 43-44). g) Hosting providers with disproportionate concentrations of spam domains reach 3,000 abused domains per 10,000 registered domain names (Appendix 1 – Technical Report, Section 12.3, pp. 48-49). h) The overall level of DNS security extensions (DNSSEC) adoption remains low. (Appendix 1 – Technical Report, Section 15.3, pp. 62-63). i) There are 2.5 million open DNS resolvers worldwide that can be effectively used as amplifiers in distributed denial-of-service attacks (Appendix 1 – Technical Report, Section 16.4, p. 70). The numbers above sound interesting. -- Petr Špaček -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg

6 5

Confirmation of New Co-Chair
by Brian Nisbet 08 Feb '22

08 Feb '22

Colleagues, As the deadline for commenting was 17:00 CET on the 7th of February and only positive comments were received, I think I'm safe in declaring consensus for our new Co-Chair, Markus! Markus, thank you for volunteering and Tobias and I look forward to working with you! Brian 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

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 23 Jan '22

23 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