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

Adding a "Security Information" contact?
by Max Grobecker 06 Jul '22

06 Jul '22

Moin-Moin and hello, TL;DR: Should there be an optional contact for sending security information to (i.e. about vulnerable services), which can be different from the abuse contact? Background: We get a reasonable amount of security information sent to our abuse mailbox about things like "There's a vulnerable Confluence server on your network" and "This IP has contacted a botnet C&C server". Technically, this is not an abuse related issue, but still relevant to know and forward to the respective customer. Most of these e-mails originate from our local CERT (in my case CERT-BUND in Germany) but there are some other senders which are informing about these vulnerable services. I guess, most other providers know about these from their local CERTs or other organizations. Our abuse mailbox is not overflowing with these, of course, but it makes semi-automated handling a bit painful. For example, we would like to forward these information to our customers, but we wont need to take further action on this, because we refuse to break into the offices of our customers at night and patch their software. Also, sometimes these reports contain outdated data and the vulnerability has been removed in the time between collecting these information and sending the e-mail. On the other hand, for real abuse like sending spam or participating in DDoS, we also want to forward this information as quick as possible (automated), but also we want to know about and escalate so we can pull the plug if needed. So I wondered, if there (c|sh)ould be an optional contact/role for sending security related information to? This could be a different mailbox which does another automated handling of forwarding this notifications. What is your opinion on this? Greetings Max

10 22

RIPE 84 minutes
by Markus de Brün 29 Jun '22

29 Jun '22

Hi all, our colleagues from RIPE NCC provided minutes for the AA WG session at RIPE 84. Please have a look at them and let us know by 07.07.22 if you have any additions, clarifications or comments. Thanks, Markus

1 0

Proposal 2022-01
by Ronald F. Guilmette 23 Jun '22

23 Jun '22

Just curious... How many of you folks have actually read sections 4.0, 5.0, and 6.0 of this pending proposal from the Database Working Group? https://www.ripe.net/participate/policies/proposals/2022-01 I suspect that many of you are going to want to read those sections before you have your memberships revoked for non-compliance. Regards, rfg

2 2

What todo when a registrar doe snot respond to babuse form an IP
by Angel P 23 Jun '22

23 Jun '22

Hello there, I have reported to a registrar an IP that has been doing a bunch of wordpress attacks one one of my sites and also using a fake referrer by impersonating itself a www.bing.com What can be done? Regards

4 3

Unanimity
by Ronald F. Guilmette 21 Jun '22

21 Jun '22

Just a brief point. I previously noted here that RIPE's rules requiring unanimity or near unanimity in order to declare "consensus" with respect to any given proposal has recently been recognized, by some EU politicians at least, as being a material impediment to forward movement on various issues. I only just noted that this growing sentiment has now apparently extended even to the Chancellor of Germany: https://twitter.com/EuromaidanPress/status/1538637496124317704 My hope, of course, is that RIPE and its various WGs are taking notes. Regards, rfg

4 5

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 07 Jun '22

07 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