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

UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget
by Kristijonas Lukas Bukauskas 19 May '22

19 May '22

Hello, I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. There have been controversial positions about this blacklist recently: 1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-… [1] 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html [2] UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '_Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'_) [http://www.uceprotect.net/en/rblcheck.php [3]]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called _Cart00ney_ (http://www.uceprotect.net/en/index.php?m=8&s=0 [4]; http://www.uceprotect.org/cart00neys/index.html [5]). And the other type of threatening: http://www.uceprotect.org/ Does RIPE NCC have any position on this specific blacklist? Thank you! Links: ------ [1] https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-… [2] https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html [3] http://www.uceprotect.net/en/rblcheck.php [4] http://www.uceprotect.net/en/index.php?m=8&s=0 [5] http://www.uceprotect.org/cart00neys/index.html

16 42

Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
by Ángel González Berdasco 14 Feb '22

14 Feb '22

> This bit is not possible. The "abuse-c:" attribute is 'single'. So the > resource object can only ever reference one abuse contact. Thanks Denis. abuse-c arity is a point I was dubious about. Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired. In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd(a)incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================

4 4

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