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

2022-01 V2 Resource Holders Address
by denis walker 16 Jun '22

16 Jun '22

Colleagues After publishing a second version of the policy proposal I have started a new conversation on the DB WG mailing list about resource holders addresses. As this is a topic of interest to this Anti Abuse community please feel free to contribute to the new discussion here https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007460.html <https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007458.html> As it is a Database policy it would be good if we can keep the discussion in one place on the DB WG mailing list. cheers denis policy proposer

1 1

Busted!
by Ronald F. Guilmette 11 Jun '22

11 Jun '22

https://krebsonsecurity.com/2022/06/adconion-execs-plead-guilty-in-federal-…

1 0

Re: [anti-abuse-wg] addtess verification (was: personal data in the RIPE Database)
by Ángel González Berdasco 08 Jun '22

08 Jun '22

denis wrote: > This defeats your own argument. You were arguing you need to know the > addresses of these natural persons so you can link separate resources > having the same address. Using the IDs of random people and drunks > from a bar will give them all different addresses. Knowing these > addresses doesn't help you in any way. Maybe they would use the address of the bar where they met the drunkard? :) Having many persons registered with that address. Or even multiple registrations whose addresses all match with pubs in Y area, would certainly be an interesting pattern worth to be discovered. Or even just a pattern of addresses not existing in that city or with no buildings. Sadly, filters designed to block obvious fake data will generally only lead malicious actors to produce better lies, not to provide their real details. In a previous mail you mentioned: > When these people apply to be a member I am sure the RIPE NCC requires proof of identity and proof of address. but -being slightly more skeptic- I would like to know what kind of address verification is performed. Document ripe-770 do mention the first part: "Each agreement signed with either the RIPE NCC or with a sponsoring LIR must be accompanied by supporting documentation proving the existence (and validity) of the legal or natural person (see below)." but no mention is made of verifying the physical address. https://www.ripe.net/publications/docs/ripe-770#111 As for the identity proof, it suggests "Valid identification documents (e.g., identification card, passport)" I guess one might go to RIPE NCC office to show them their passport and assert that they do exist and match it. That's probably the most secure way of verification. But I doubt many people would do that (maybe, during the assembly...). Sending the passport or id card to RIPE NCC would not be be acceptable. The exact way to do that is not described there, but the model agreement says "the End User shall include a photocopy of a valid identity card." and I suspect that's what will be done on almist every case. https://www.ripe.net/manage-ips-and-asns/resource-management/number-resourc… Obviously, someone who tricked another one (drunk or not) into getting a copy of their id card could easily fulfill this requisite. Maybe those on this list that are resource holders could tell us if their physical address was ever validated by RIPE in any way? 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. ====================================================================

3 2

General List Behaviour & "personal data in the RIPE Database"
by Brian Nisbet 07 Jun '22

07 Jun '22

Colleagues, I believe that the current conversation on "personal data in the RIPE Database" has reached a point of a lot more heat than light. I would ask that people step away from the topic and consider how to engage with the proposal, rather than the people involved in the conversation. If a return to more light than heat can be managed then an entirely new thread may be a good idea. If it can't, and if there are any more personal attacks, hyperbole or similar then the Co-Chairs will be asking the NCC to moderate relevant people. Discussion on list is great, of course, but time and again we have to remind people of how to behave in a professional environment and the Co-Chairs will not simply let the list become a toxic environment, or perhaps a more toxic environment? Please consider this email both a request and a warning. Thank you, Brian, Markus, Tobias Co-Chairs, 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

personal data in the RIPE Database
by denis walker 07 Jun '22

07 Jun '22

Colleagues I have raised an issue on the DB WG mailing list about publishing in the database the identity of natural persons holding resources. So far no one has been willing or able to support any public interest value in doing so. As things stand all personal data in the RIPE Database will have to be removed, or hidden from public view. If you have an opinion about this the conversation is here https://www.ripe.net/ripe/mail/archives/db-wg/2022-May/007432.html cheers denis 2022-01 proposal author

10 45

Mailing List Etiquette
by Markus de Brün 03 Jun '22

03 Jun '22

Colleagues, while we encourage any discussion on the list, please keep in mind that we have a code of conduct [1]. Accusing individuals is neither helpful nor acceptable. So please, keep the discussion matter-of-factly and consider your language and phrasing. Kind regards, Markus Co-Chair, RIPE Anti-Abuse WG [1] https://www.ripe.net/publications/docs/ripe-766

1 0

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

Draft Agenda - AA-WG Session @ RIPE 84
by Brian Nisbet 16 May '22

16 May '22

Colleagues, Here is the very draft agenda for our working group session happening both in Berlin and online next month. The session is due to take place at 09:00 CEST on Thursday 19th May. We still have time in the agenda for discussions, work items, policy proposals or presentations. If you have anything in mind please email aa-wg-chairs(a)ripe.net A. Administrative Matters * Welcome * Scribe, Chat, Stenography * Mic & Chat Etiquette * Ratings Where Appropriate * Approve Minutes from RIPE 83 * Finalise agenda * Code of Conduct B. Update * B1. Recent List Discussion C. Policies - *C.1. D. Interactions - *D.1. RIPE NCC Abuse Handling Training *D.2. DNS Abuse Institute Reporting Tool *D.3. RIPE DB TF Report E. Presentation - *E.1. DDoS First Aid - Matthias Wichtlhuber, DE-CIX X. A.O.B. Z. Agenda for RIPE 85 Regards, 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

2 1

Reminder: AA-WG Session @ RIPE 84
by Brian Nisbet 11 May '22

11 May '22

Colleagues, Just a reminder about our hybrid session at RIPE 84 next week in Berlin and online. The current agenda is here: https://ripe84.ripe.net/programme/meeting-plan/aa-wg/ but there is still some time available, so if you would like to add something to the agenda, please let us know! Remember, this can be a couple of minutes of a point to raise, an idea for a policy or work item, a note of concern, anything related to the WG's work. It certainly doesn't have to be a full presentation with slides and all! Please let us know at aa-wg-chairs(a)ripe.net or find one of us in person in Berlin if you're at the meeting. Looking forward to seeing many of you next week! 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

Another incompetent ISP - Signet, B.V. - transip.net / signet.nl
by Ronald F. Guilmette 29 Apr '22

29 Apr '22

I recently attempted to report spam that was sent to me from [136.144.219.231]. This address is being routed by AS20857 (ORG-SI6-RIPE / Signet B.V.) and the containing IP block (136.144.128.0/17) is registered to TransIP B.V. (NOTE: no associated ORG record) which appears to be just a different face of the same Dutch company (Signet). My spam report was sent to the abuse reporting address contained in the RIPE WHOIS record for the revevant ASN (AS20857) i.e. <abuse(a)signet.nl>. Of course, I included in the report a complete copy of the spam message I received so that the people on the other end could have a clear picture of the nature of this incident and those responsible for it. Unfortunately, Signet/transIP appears to be yet another in a succession of ISPs that have failed to grasp the seemingly obvious fact that enabling spam filtering on your own inbound spam reporting email address is counterproductive. Thus, for my trouble I received back: <support(a)signet.blue> (expanded from <abuse(a)signet.nl>): host mx.transip.email[86.105.244.9] said: 550 5.7.1 Our system has detected that this message is likely unsolicited mail (SPAM). To reduce the amount of spam, this message has been blocked. (4Kpghy5Bcvz1J9nY) (in reply to end of DATA command) Based on this rejection it is now my intention to locally blacklist all IPv4 blocks assigned to this ISP. A partial list of these is included below. Unfortunately, due to ongoing and longstanding issues with the RIPE data base (which I will be mentioning yet again on the RIPE db-wg mailing list, for all the good it will do) it is not easily possible to derive a full list of all of the IP address blocks assigned to this company, at least not in a simple automated fashion. Blocks assigned to ORG-SI6-RIPE (fully aggregated): 31.3.8.0/21 31.3.96.0/21 31.14.96.0/22 31.223.160.0/20 37.17.208.0/20 37.34.48.0/20 37.97.128.0/17 37.230.96.0/21 46.21.224.0/20 46.226.56.0/21 77.72.144.0/21 78.108.128.0/20 79.170.88.0/21 80.69.64.0/19 80.84.224.0/19 80.246.192.0/20 80.255.240.0/20 81.4.64.0/19 81.4.96.0/22 81.4.112.0/21 81.21.136.0/21 81.30.32.0/20 83.96.128.0/17 84.247.8.0/21 85.10.128.0/18 85.158.248.0/21 85.222.224.0/21 86.105.244.0/22 87.253.128.0/19 89.31.96.0/21 89.41.168.0/22 91.142.240.0/20 91.205.32.0/22 91.216.162.0/24 93.119.0.0/20 93.191.128.0/21 94.142.208.0/21 95.170.64.0/19 141.138.136.0/21 141.138.192.0/20 141.255.176.0/21 149.210.128.0/17 171.33.128.0/21 176.74.224.0/19 178.18.80.0/20 185.3.208.0/22 185.10.48.0/22 185.15.248.0/22 185.21.188.0/22 185.65.52.0/22 185.69.232.0/22 185.76.236.0/22 185.84.72.0/22 185.89.152.0/22 185.95.68.0/22 185.96.4.0/22 185.105.204.0/22 185.105.216.0/22 185.108.112.0/22 185.110.172.0/22 185.110.200.0/22 188.240.52.0/22 188.241.148.0/22 193.93.172.0/22 193.138.204.0/22 193.242.119.0/24 194.60.207.0/24 195.8.195.0/24 195.135.195.0/24 213.187.240.0/21 217.21.240.0/20 217.149.128.0/20

2 2