[anti-abuse-wg] RIPE NCC Anti-Abuse Training: Next Steps & WG Input!

[Brian Nisbet]

Colleagues,

Since we last spoke about the proposed training the NCC have been working with 
various community members to put a draft syllabus in place for further 
discussion.

This is a link to the feedback document for this draft:

https://docs.google.com/document/d/1M9Wrqu-VKGGwMfJQGK0NlTs5UzH6xJ2_HR2MkTBVR2w/edit?usp=sharing

What the NCC and the Co-Chairs would love is if everybody could just comment 
what they think they understand from the learning goals as they’re written and 
suggest any changes or additions and obviously ask any questions. We’d also 
like the feedback on the webinar flow design.

It’s important for everybody to understand that the learning objectives are the 
basis for the training. These are the skills that the learner must acquire. 
With these skills we also expect a change of attitude towards abuse handling 
(which is we think the purpose of this training).

While discussion on the list is welcomed and encouraged, we've also planned a 
Zoom session for any interested parties to discuss this further. This will take 
place on Wednesday 23rd February at 14:00 CET:

https://ripe.zoom.us/j/8221791822?pwd=ZFY0MnNQeWJsTkhQSFlyeEZlUkNJQT09

Meeting ID: 822 179 1822
Passcode: 1277

Hopefully with discussion on list and at the session on the 23rd we can move 
this into a final draft and progress from there.

Thanks,

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.nis...@heanet.ie www.heanet.ie

Registered in Ireland, No. 275301. CRA No. 20036270
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Re: [anti-abuse-wg] Fwd: [dns-wg] EU: DNS abuse study

[Michele Neylon - Blacknight via anti-abuse-wg]

Exactly
And unfortunately this is a trend with a lot of the EC’s activities that push 
towards more and more regulation of digital

I also find the ridiculously broad definition of abuse so broad that it renders 
any output without much merit.


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
---
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845


From: anti-abuse-wg  on behalf of Farzaneh 
Badiei 
Date: Wednesday, 9 February 2022 at 15:16
To: Markus de Brün , anti-abuse-wg@ripe.net 

Subject: Re: [anti-abuse-wg] Fwd: [dns-wg] EU: DNS abuse study

[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised 
sources.
I probably should say this on the DNS mailing list but I find it quite curious 
that the study surveyed such limited stakeholders, and mainly the intellectual 
property crowd.

"We gathered the data and inputs from stakeholders with two questionnaires: 1) 
the first one surveyed registries, registrars, hosting providers, other DNS 
operators, and 2) the second one surveyed intellectual property rightholders, 
practitioners, associations, business intelligence, and brand protection 
companies. The study also collected data from third parties and publicly 
available reports (secondary research), as well as evaluated the impact of DNS 
abuse." (Page 7)


Intellectual property is not the best way to combat abuse and it will lead to 
protectionism and intellectual property overreach. Same applies to this space.  
They use "illegal" and "harmful"  in their definition of DNS abuse which are 
ambiguous at best and expand the definition of DNS abuse so much that of course 
can result in concluding that we are all drowning in harmful activities online 
and it's all the DNS fault.




On Sun, Feb 6, 2022 at 10:50 AM Markus de Brün 
mailto:mar...@mxdomain.de>> wrote:

For those who are not following the DNS wg list:

The European Commission has published a quite comprehensive study on DNS
abuse. (One could also call it enormous.)

It study itself be found here:
https://op.europa.eu/en/publication-detail/-/publication/7d16c267-7f1f-11ec-8c40-01aa75ed71a1/language-en/

There is an additional document containing the appendix:
https://op.europa.eu/en/publication-detail/-/publication/d9804355-7f22-11ec-8c40-01aa75ed71a1/language-en

--
Markus de Brün

 Forwarded Message 
Subject: Re: [dns-wg] EU: DNS abuse study
Date: Fri, 4 Feb 2022 10:52:53 +0100
From: Petr Špaček mailto:pspa...@isc.org>>
To: dns...@ripe.net

On 01. 02. 22 9:32, Hank Nussbacher wrote:
> The EU has published is 173 page opus on DNS abuse:
>
> https://op.europa.eu/en/publication-detail/-/publication/7d16c267-7f1f-11ec-8c40-01aa75ed71a1/language-en/

I have had a peak when waiting for other things to happen and it might
be interesting read. Here is a gist from chapter Executive summary:

The study adopts the following definition of DNS abuse:
Domain Name System (DNS) abuse is any activity that makes use of domain
names or the DNS protocol to carry out harmful or illegal activity.

The main findings of the measurements are:
a) In relative terms, new generic Top-Level Domains (new gTLDs), with an
estimated market share of 6.6%, are the most abused group of TLDs
(Appendix 1 – Technical Report, Section 5, p. 26).
b) Not all new gTLDs suffer from DNS abuse to the same extent. The two
most abused new gTLDs combined account for 41% of all abused new gTLD
names (Appendix 1 – Technical Report, Section 9.2, p. 32).
c) European Union country code TLDs (EU ccTLDs) are by far the least
abused in absolute terms and relative to their overall market share
(Appendix 1 – Technical Report, Section 5, p. 26).
d) The vast majority of spam and botnet command-and-control domain names
are maliciously registered (Appendix 1 – Technical Report, Section 10.3,
p. 41).
e) About 25% of phishing domain names and 41% of malware distribution
domain names are presumably registered by legitimate users, but
compromised at the hosting level (Appendix 1 – Technical Report, Section
10.3, p. 41).
f) The top five most abused registrars account for 48% of all
maliciously registered domain names (Appendix 1 – Technical Report,
Section 11.2, pp. 43-44).
g) Hosting providers with disproportionate concentrations of spam
domains reach 3,000 abused domains per 10,000 registered domain names
(Appendix 1 – Technical Report, Section 12.3, pp. 48-49).
h) The overall level of DNS security extensions (DNSSEC) adoption
remains low. (Appendix 1 – Technical Report, Section 15.3, pp. 62-63).
i) There are 2.5 million open DNS resolvers worldwide that can be
effectively used as amplifiers in distributed denial-of-service atta

Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c

[Michele Neylon - Blacknight via anti-abuse-wg]

That’s not entirely true.

It’ll depend on how granular the LIR is with their allocations to their clients.

Speaking on behalf of my company we do assign blocks and abuse-c contacts to 
quite a few of our clients.
However we wouldn’t do that for every single IP address and due to the nature 
of some of the services we provide a single IP address is going to be linked to 
multiple clients.

The main issue we run into is with some reporters using a scatter gun approach 
with reporting abuse, which is just a waste of everyone’s time. (Basically 
sending notices to every single contact they can find – not just the abuse-c)

Regards

Michele



--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
---
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845


From: anti-abuse-wg  on behalf of Ángel 
González Berdasco 
Date: Saturday, 22 January 2022 at 23:12
To: denis walker 
Cc: anti-abuse-wg@ripe.net 
Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c

[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised 
sources.
> 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
d...@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.









-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Re: [anti-abuse-wg] Fwd: [dns-wg] EU: DNS abuse study

[Nick Hilliard]

Michele Neylon - Blacknight via anti-abuse-wg wrote on 10/02/2022 10:49:
I also find the ridiculously broad definition of abuse so broad that it 
renders any output without much merit.


"It's always DNS!"

A comparable style of analysis could find that TCP was a good root cause 
candidate for abuse because almost all of this abuse happens over TCP.


Plenty of the recommendations are sensible, mostly for reasons unrelated 
to abuse.  Otherwise, the supporting document would be dramatically 
improved by reducing the page count by an order of magnitude, and 
focusing on real life threats which relate directly to DNS.


Nick

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Re: [anti-abuse-wg] RIPE NCC Anti-Abuse Training: Next Steps & WG Input!

[Hans-Martin Mosner]

Am 10.02.22 um 10:25 schrieb Brian Nisbet:

Colleagues,

Since we last spoke about the proposed training the NCC have been working with various community members to put a 
draft syllabus in place for further discussion.


This is a link to the feedback document for this draft:

https://docs.google.com/document/d/1M9Wrqu-VKGGwMfJQGK0NlTs5UzH6xJ2_HR2MkTBVR2w/edit?usp=sharing


Nice!
What the NCC and the Co-Chairs would love is if everybody could just comment what they think they understand from the 
learning goals as they’re written and suggest any changes or additions and obviously ask any questions. We’d also like 
the feedback on the webinar flow design.


It’s important for everybody to understand that the learning objectives are the basis for the training. These are the 
skills that the learner must acquire. With these skills we also expect a change of attitude towards abuse handling 
(which is we think the purpose of this training).


While discussion on the list is welcomed and encouraged, we've also planned a Zoom session for any interested parties 
to discuss this further.


I'll most likely not be able to join the Zoom session, so here are some thoughts. The document draft shows the structure 
(which is good and as far as I can see covers the important areas) but not much detail. My suggestions (from the POV of 
an abuse reporter) go straight into the details, please forgive me if that is out of scope.


 * Abuse handling is not the same as support handling. Abuse reporters don't 
want help, they expect that it is in your
   own interest as a network operator to curb abuse originating from your 
network, and their reports are intended to
   help you reach that goal. This results in some Don'ts (I'm seeing all of 
these in reponse to abuse reports):
 o don't reject their messages because they are not your customers,
 o don't require them to register with some support system,
 o don't send meaningless auto-replies,
 o don't try to teach them (unless they are really doing something wrong).
 * Although there may be conflicts with protecting your user's privacy, 
reporters really appreciate to know whether
   their reports have a meaningful effect as they sometimes spend considerable 
amounts of time. Positive feedback
   ("we've terminated that customer", or "we've worked with the customer to fix 
their exploitable software/account") is
   a huge encouragement to continue reporting abuse. If there is no detectable 
reaction (either in form of an answer or
   an observable stop of abuse) then an abuse reporter might determine that 
blocking your network is a more effective
   use of their time.
 * Many types of abuse originating from your network are signs of substandard 
security and warnings of possibly more
   damaging future exploits. Work proactively with your customers when you find 
systemic problems. For example, on one
   of the services that I look after, we had one or two mail account password 
compromises which led to spam bursts. We
   established a strict password policy, checking the password database for 
easily breakable passwords, and contacting
   all users with weak passwords so they changed them to secure passwords. 
Similarly, we proactively check customer's
   websites for exploitable plugins. What kinds of proactive abuse prevention 
works in your case might be vastly
   different, but not doing anything is gross negligence.
 * Abuse desk workers need authority to contact customers and to restrict their 
use of your resources. One basic
   prerequisite for contacting customers is that you know them. If your 
operation does not establish appropriate KYC
   rules you're bound to be an attractive provider for abusers. Of course, the 
amount of info you need for an e-mail
   account and for renting out a server are different, and you may be limited 
by privacy laws, but if you simply refuse
   to take responsibility while not disclosing information on who *is* actually 
responsible you're in for blocking.

Cheers,
Hans-Martin-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

[anti-abuse-wg] Fwd: RIPE NCC Anti-Abuse Training: Next Steps & WG Input!

[Alex de Joode]

There are many things to consider (some semi random topics to consider).

 * what do you consider abuse? 
 * only technical abuse (portscanes, spam, brute force attacks etc)
 * or also 'content abuses' (doxxing, hate speech, csam etc)
 * what about harmful content, will that be considered abuse
 * what about unwanted content?
 * how does this all relate to freedom of expression?
 * what rights do your customers have
 * to what extent are you willing to act as the sheriff ?
 * there should be a dedicated working address for receiving abuse 
notices/complaints. (we have that covered for the most part)
 * do you issue a ticket number as a reference?
 * how can a complainer escalate?
 * making a abuse complaint should be made as easy as possible
 * however, (for streamlinening puposes) a webform, or registration in a 
support system should be acceptable (some complainers are really stupid)
 * if a complaint does not include the minimal information to assess the 
validity, a request for more information could be sent, while the original 
complaint is closed
 * every company is different, has different policies, procedures and 
customers, educating frequent complainers is needed to ensure to most efficient 
way of dealing with abuse.
 * you have to make a decision about the information you forward to your client 
so they are able to resolve the issue
 * full message, always? only to reseller? also to enduser?
 * does a complainer have a reasonable expectation of privacy?
 * is this different for the automated copyright abuse sending mills?
 * what if the 'proof' of an abuse, would reviel the means? (ie spamtrap 
address)
 * how much proof do you need to forward this as an issue to your client?
 * you should have a process to contact the customer
 * directly by the abuse desk,
 * via sales (so they know their client generates 'issues')
 * you should have a process to restrict or limit usage of resources
 * directly by the abuse desk,
 * via networking
> 

>  * 
> 
 * Abuse handling is not the same as support handling. Abuse
reporters don't want help, they expect that it is in your own
interest as a network operator to curb abuse originating from
your network, and their reports are intended to help you reach
that goal. This results in some Don'ts (I'm seeing all of these
in reponse to abuse reports):
  

 * don't reject their messages because they are not your
  customers, 
> 


 * don't require them to register with some support system, 
> 


 * don't send meaningless auto-replies, 
> 


 * don't try to teach them (unless they are really doing
  something wrong).
  
  
 * Although there may be conflicts with protecting your user's
privacy, reporters really appreciate to know whether their
reports have a meaningful effect as they sometimes spend
considerable amounts of time. Positive feedback ("we've
terminated that customer", or "we've worked with the customer to
fix their exploitable software/account") is a huge encouragement
to continue reporting abuse. If there is no detectable reaction
(either in form of an answer or an observable stop of abuse)
then an abuse reporter might determine that blocking your
network is a more effective use of their time.
  
 * Many types of abuse originating from your network are signs of
substandard security and warnings of possibly more damaging
future exploits. Work proactively with your customers when you
find systemic problems. For example, on one of the services that
I look after, we had one or two mail account password
compromises which led to spam bursts. We established a strict
password policy, checking the password database for easily
breakable passwords, and contacting all users with weak
passwords so they changed them to secure passwords. Similarly,
we proactively check customer's websites for exploitable
plugins. What kinds of proactive abuse prevention works in your
case might be vastly different, but not doing anything is gross
negligence.
  
 * Abuse desk workers need authority to contact customers and to
restrict their use of your resources. One basic prerequisite for
contacting customers is that you know them. If your operation
does not establish appropriate KYC rules you're bound to be an
attractive provider for abusers. Of course, the amount of info
you need for an e-mail account and for renting out a server are
different, and you may be limited by privacy laws, but if you
simply refuse to take responsibility while not disclosing
information on who *is* actually responsible you're in for
blocking.

Cheers,
> 
Hans-Martin
> 
  


-- 

To unsubscribe from this mailing list, get a passwo

Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c

[denis walker]

Hi Michele

Yes you can allow any customer with an assignment to have their own
abuse-c contact. But the database query will only return a single
abuse contact for any IP address. If the assignment object has an
abuse-c then a query on any IP address in the range of that assignment
will only return the customer's abuse contact details. If an
assignment does not have an abuse-c then such a query will return the
resource holder's abuse-contact details. A query will not return both
the customer's and the resource holder's details.

However, this can be changed if the community wants something
different. We can make abuse-c a multiple attribute so the resource
holder can add the customer's and their own abuse-c to an assignment.
Or we can change the default behaviour of the query so when an abuse-c
is found in an assignment it always returns the resource holder's
abuse-c as well. Or we can add a new query flag to return both abuse-c
details when available. Or we can modify the abuse-c attribute in some
way so the resource holder can choose what a query returns.  Any
behaviour is possible as long as you define what behaviour you want
and the community finds it useful.

chears
denis
co-chair DB-WG

On Thu, 10 Feb 2022 at 11:54, Michele Neylon - Blacknight
 wrote:
>
> That’s not entirely true.
>
>
>
> It’ll depend on how granular the LIR is with their allocations to their 
> clients.
>
>
>
> Speaking on behalf of my company we do assign blocks and abuse-c contacts to 
> quite a few of our clients.
>
> However we wouldn’t do that for every single IP address and due to the nature 
> of some of the services we provide a single IP address is going to be linked 
> to multiple clients.
>
>
>
> The main issue we run into is with some reporters using a scatter gun 
> approach with reporting abuse, which is just a waste of everyone’s time. 
> (Basically sending notices to every single contact they can find – not just 
> the abuse-c)
>
>
>
> Regards
>
>
>
> Michele
>
>
>
>
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> https://www.blacknight.com/
>
> https://blacknight.blog/
>
> Intl. +353 (0) 59  9183072
>
> Direct Dial: +353 (0)59 9183090
>
> Personal blog: https://michele.blog/
>
> Some thoughts: https://ceo.hosting/
>
> ---
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845
>
>
>
>
>
> From: anti-abuse-wg  on behalf of Ángel 
> González Berdasco 
> Date: Saturday, 22 January 2022 at 23:12
> To: denis walker 
> Cc: anti-abuse-wg@ripe.net 
> Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
>
> [EXTERNAL EMAIL] Please use caution when opening attachments from 
> unrecognised sources.
>
> > 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 c