This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters
- Previous message (by thread): [anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters
- Next message (by thread): [anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hans-Martin Mosner
hmm at heeg.de
Wed May 19 08:29:37 CEST 2021
Am 18.05.21 um 21:52 schrieb Erik Bais: > > Hi, > > > > As I asked during the Connect WG today, there are discussions currently going on in the Dutch network community to see > if there is a way to get a cleaner feed from routeservers on internet exchanges. ( by default ) > > > > As you may know there is an Dutch Anti Abuse Network initiative ( AAN ) – abuse.nl > > > > The companies associated with AAN setup and all signed a manifest ( in Dutch - https://www.abuse.nl/manifest/ ) that > states that we will all do our best to provide a better and cleaner internet. > > > Nice initiative! > ... > > > > Topics that should be included on the rating for the list : > > > > * Phishing (hosting sites / domain registrations ) > * Malware hosting ( binaries and C&C’s ) > * DDOS traffic ( number of amplification devices in the network compared to the number of IP address ratio ) > * Login attacks / excessive port scanning > * Hosting of Child exploitation content > * Infected websites / Zeus Botnets > * Etc > > > One problem with the approach is that there isn't a single measure of badness, as the topic list already shows. It's a multi-dimensional vector, and its dimensions are not easily defined in a non-controversial way. The criteria for including a network in a top N list will therefore be unavoidably subjective. In the process of thinking about ways to tackle e-mail abuse (which doesn't even show in your list, probably because it's not really a problem for network operators but only for mail operators) I came up with some ideas about a distributed reputation network that might have some desirable properties: * Separation of network and resource owner observations and policy decisions: It would be very helpful to have multiple independent and reliable sources listing type and severity of network abuse in real time, but I'd like to define my own policy rules and use those abuse metrics as input for policy decisions. As a mail operator, I might be personally very concerned about malware hosting, but the things that would affect my blocking policy are spam volume and mail account bruteforce attacks (and to some extent, DDOS traffic). Network operators may have different policies to protect the integrity of their networks and implement legally required rules. * Distributed P2P database: I'm thinking about something like a cryptocurrency blockchain or the PGP web of trust, which avoids having a single point of failure and also avoids a single hierarchy of trust. Cryptography provides some excellent tools, but apart from the ubiquitous TLS (and the mentioned blockchain systems) it's used much too sparingly in securing information integrity. * Reputation metrics: It should be possible to assert not only observations of network behavior, but also reputation statements about the publishers of such observations. This makes evaluating the trustworthyness of a reporter possible, and with enough participants could provide a relatively unbiased view. Hope this provides some food for thought/discussion. I'm well aware that my viewpoint is necessarily limited, as I don't have any network operating experience, but some aspects may be transferrable to that area. Cheers, Hans-Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20210519/eaa50b62/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters
- Next message (by thread): [anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]