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/[email protected]/
[anti-abuse-wg] Anti-Abuse Training: Questions for the WG
- Previous message (by thread): [anti-abuse-wg] Anti-Abuse Training: Questions for the WG
- Next message (by thread): [anti-abuse-wg] Anti-Abuse Training: Questions for the WG
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alessandro Vesely
vesely at tana.it
Sun Oct 24 11:08:49 CEST 2021
On Fri 22/Oct/2021 23:26:23 +0200 Ángel González Berdasco wrote: > Hello all > >> Shouldn't there be a standard for automatically forwarding messages >> destined to abuse-c following a path similar to that of RFC 2317 >> delegations? I'd love if AA training encouraged such behavior. > > I don't think the standard should be for automatically forwarding > messages. You would need a standard for *exchanging* the information. > Fields you would need should include IP address being reported, port > (optionally), timestamp, whether this may be shared with the customer > (default yes), RSIT taxonomy of the incident being reported, etc. Yeah, I didn't mean a capital 'S' Standard. Rather some common practice. > And then, among the actions that can be taken, automatically forwarding > could be one of them (and probably the less expensive for the abuse-c > owner), but they could choose to process them differently. > But the first step is to match the report with the machine/customer. If I were LIR.example, I'd set my abuse-c entries to something like: abuse-customer1 at LIR.example abuse-customer2 at LIR.example ... That way messages can be forwarded without parsing them; but there's still a chance to look at them, if the budget allows it. > Many abuse teams already do that automatically, although I don't know > the amount of guessing needed by the tools on their normal flows. > > The first idea that comes to mind when talking about communicating > this would be to create a solution based on X-ARF, but it's not without > its shortcomings, either, so maybe a different way is felt to be > preferable. plain text, X-ARF, ARF, IODEF, https://xkcd.com/927/ Another way is to send an autoresponse which asks to fill the provider's web form, whereby the number of different formats grows unconstrained. However, it'd be possible for a forwarding LIR.example to ask its clients to fill a web form, in order to summarize the complaint and its followup. Most providers only have one or two ISPs, so the number of formats would stay low. And that could ease LIR's monitoring. > This is an interesting discussion, although I feel it's a bigger design > issue, significantly more ambitious than the proposal of providing some > abuse training which opened this thread. Since the training is addressed to LIRs, a schema like the above could at least be aired. Best Ale
- Previous message (by thread): [anti-abuse-wg] Anti-Abuse Training: Questions for the WG
- Next message (by thread): [anti-abuse-wg] Anti-Abuse Training: Questions for the WG
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]