Re: [anti-abuse-wg] Abuse Report ignored. What to do as next?

[Ángel González Berdasco via anti-abuse-wg]

U.Mutlu wrote:
> Maybe there is a WHOIS or ASN error:
> Trying the following gives a different company for the said IP:
> 
> $ whois 80.94.94.254
> 
> % Abuse contact for '80.94.92.0 - 80.94.95.255' is 'ab...@bunea.eu'
> 
> I now have filed the AR also to that new address.

Asking for 80.94.94.x returns a contact for the /22 range 
80.94.92.0 - 80.94.95.255

But asking for 80.94.95.x returns the more specific /24 range
80.94.95.0 - 80.94.95.255


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] Abuse Report ignored. What to do as next?

[Ángel González Berdasco via anti-abuse-wg]

John Levine wrote:
> It appears that U.Mutlu  said:
> > So, what to do if the hoster is uncooperative, like in this case?
> > Where else to complain, what else to do?
> 
> If their ASN info is to be believed, they're in Bulgaria.  It's
> unlikely anyone there cares.
> 
> Just block their network 80.94.95.0/24 and forget about it.
> 
> FWIW I got a spam blast from 80.94.95.59 a few weeks ago
> so it's not just that IP.
> 
> R's,
> John

Yes, this range is a source of other types of malicious activity.

The country in RIPE for 80.94.95.0/24 says Moldova, but the company
address is in United Kingdom.


Their domain itself (bthoster.net) is suspiciously registered just a
few months ago (Creation Date: 2023-07-31T09:22:59.00Z), showing a
"This domain has recently been registered with Namecheap." parking page
with no website.


But, interestingly, the whois data was updated *after* that, so it's
not your typical case of a company that closes/bankrupts and their
domain expires.



% Abuse contact for '80.94.95.0 - 80.94.95.255' is 'internethosting-ltd [] 
yandex.ru'

inetnum:80.94.95.0 - 80.94.95.255
netname:Bthoster
country:MD
org:ORG-BA1515-RIPE
admin-c:BL7954-RIPE
tech-c: BL7954-RIPE
status: ASSIGNED PA
mnt-by: Internet-Transit-MNT
created:2019-09-10T20:41:19Z
last-modified:  2023-10-10T10:54:46Z
source: RIPE

organisation:   ORG-BA1515-RIPE
org-name:   BtHoster LTD
country:GB
org-type:   OTHER
address:26, New Kent Road, London, SE1 6TJ, UNITED KINGDOM
e-mail: internethosting-ltd [] yandex.ru
abuse-c:ACRO50561-RIPE
mnt-ref:BtHoster-LTD-MNT
mnt-by: BtHoster-LTD-MNT
created:2022-11-16T10:31:23Z
last-modified:  2023-10-10T19:59:24Z
source: RIPE

role:   Internet Transit
address:26, New Kent Road, London, SE1 6TJ, UNITED KINGDOM
e-mail: sales [] bthoster.net
nic-hdl:BL7954-RIPE
mnt-by: Internet-Transit-MNT
created:2022-11-16T10:29:38Z
last-modified:  2023-09-22T18:36:26Z
source: RIPE

% Information related to '80.94.95.0/24AS204428'

route:  80.94.95.0/24
origin: AS204428
mnt-by: UNMANAGED
mnt-by: ro-btel2-1-mnt
created:2022-11-15T14:14:48Z
last-modified:  2022-11-15T14:14:48Z
source: RIPE


-- 
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] Autoresponders

[Ángel González Berdasco via anti-abuse-wg]

On 2022-08-22 at 11:40 +0200, Alan Levin wrote:
> On Mon, 22 Aug 2022 at 07:50, someone <…@ripe.net> wrote:
> > I’m out of office till 22 August. Any RIPE Labs related queries can
> > be sent to l...@ripe.net and one of my colleagues 
> > will get back to
> > you.
>
> irony - three unsolicited messages on the same subject -  appropriate
> too

This list was lucky. db-wg received 477 copies of this Out of Office message.

It actually serves as a great example of what an autoresponder shall *not* be 
doing:

* It only ran when the user returned to the office
* It replied to every message, with no waiting period
* It replied to mailing lists¹
* It replied *to its own vacation message* distributed by the mailing list, 
creating a loop

And it happened from inside the same organization, so the delivery delay would 
have been minimal. It must have been a tiny Bedlam3 for RIPE.

RFC 3834 recommendations were not pointless musings.


Kind regards


¹ The list properly contained a Precedence: list header, so no fault of the 
mailing list software here.

--
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] Adding a "Security Information" contact?

[Ángel González Berdasco via anti-abuse-wg]

Gert Doering wrote:
> Hi,
> 
> "whois, as in 'this particular way users interface with the DB'" :-)
> 
> (I'm aware it's the server doing this - which makes changing the
> implementation easier, as it's "just one place" - but in the end, 
> "it needs to be done" which was the point I tried to make ;-) )
> 
> Gert Doering
> -- NetMaster

Indeed. And many other tools interacting with the RIPE DB to find abuse
contacts, I'm afraid. The uptake of those new attributes would
neccessarily be relatively slow.

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] Adding a "Security Information" contact?

[Ángel González Berdasco via anti-abuse-wg]

Cynthia Revström writes:
> I think this sounds like a good idea as someone who is also very much
> interested in security.
> 
> 
> However I think the implementation details should be discussed in the
> db-wg as opposed to the aa-wg.
> 
> 
> -Cynthia

It affects both anti-abuse and db-wg. If anti-abuse sees no merit in
that, there's no point in going further with it, but if this wg considers it 
worth pursuing, I guess it should then proposed it to the db-wg.

I am open to input on the steps that should be followed, as I'm not
familiar with what would be the proper process.

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] Adding a "Security Information" contact?

[Ángel González Berdasco via anti-abuse-wg]

Gert Doering writes:
> Hi,
> 
> On Tue, Jun 07, 2022 at 12:36:10PM +0000, Ángel González Berdasco via
> anti-abuse-wg wrote:
> > abuse-c: GROBECKER-ABUSE
> > 
> > and the GROBECKER-ABUSE object:
> > abuse-mailbox: gene...@abuse.grobecker.info
> > abuse-mailbox-vulnerable: 
> > vulnerability-repo...@abuse.grobecker.info
> > abuse-mailbox-fraud: fraudabu...@abuse.grobecker.info
> > 
> > where 'vulnerable', 'fraud', etc. are the machine readable tags
> > defined
> > in the RSIT for the values in the classification column.
> 
> [..]
> > Does something like this seem sensible to others?
> 
> 

> I think teaching this to CERTs would also be doable... ;-)

It should be. After all, that's based on the Reference Taxonomy used by
CERTs, which they should be relatively familiar with (even if they
aren't following it strictly). :)


> From a LIR perspective, this sounds like an interesting and quite 
> workable idea (... it would need some easily-findable help texts that
> explains what these terms stand for, and which one to use for what :-
> ) ).

I agree. By using an established taxonomy, this avoids having to create
a new categorization of abuse contact subtypes, and (for those of us
using RSIT) the need of mapping from RSIT to that one.

But I admit the explanations at 
https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/master/working_copy/humanv1.md
 are quite weak and should be improved.



> "whois" would need some help (as it today only returns one abuse e-
> mail), but that's implementation
> 
> $ whois 195.30.0.1
> % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'ab...@space.net'

That's not done by the whois binary, but by the whois server, see
 $ echo 195.30.0.1 | nc -C whois.ripe.net 4



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] Adding a "Security Information" contact?

[Ángel González Berdasco via anti-abuse-wg]

El mar, 07-06-2022 a las 13:14 +0200, Gert Doering escribió:
> Hi,
> 
> On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via
> anti-abuse-wg wrote:
> > I don't think the problem would be to add a new attribute if
> needed.
> > The problem would be to *define* what should go there (and then get
> > everyone downstream to use that new attribute)
> 
> This...  so, what would you suggest?
> 
> Gert Doering
> -- NetMaster
> --

I would use the Reference Security Incident Taxonomy (RSIT) as
the classification source, which is the taxonomy used by (most of) the
CSIRT community. See [1]

So the PTY-MAXGROBECKER network could have:

abuse-c: GROBECKER-ABUSE

and the GROBECKER-ABUSE object:
abuse-mailbox: gene...@abuse.grobecker.info
abuse-mailbox-vulnerable: vulnerability-repo...@abuse.grobecker.info
abuse-mailbox-fraud: fraudabu...@abuse.grobecker.info

where 'vulnerable', 'fraud', etc. are the machine readable tags defined
in the RSIT for the values in the classification column.

Thus, when CERT BUND wanted to report an unpatched Confluence, they
would have an incident of type: "Vulnerable → Vulnerable System", find
that there is a 'abuse-mailbox-vulnerable' attribute and report it
there.

Whereas if it was a phishing landing page (incident of type Fraud →
Phishing), that would go to fraudabu...@abuse.grobecker.info (from
'abuse-mailbox-fraud')

But if it was a host sending out spam, (incident classification Abusive
Content → Spam), having no "abuse-mailbox-abusive-content", it would
fall back to abuse-mailbox and direct it to 
gene...@abuse.grobecker.info.



Does something like this seem sensible to others?


Best regards



1- 
https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/master/working_copy/humanv1.md

-- 
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] Adding a "Security Information" contact?

[Ángel González Berdasco via anti-abuse-wg]

On 07-06-2022 12:42 +0200, Gert Doering wrote:
> Hi,
> 
> On Tue, Jun 07, 2022 at 12:35:47PM +0200, denis walker wrote:
> > You could add an optional attribute "security-mailbox:" alongside
> > the
> > "abuse-mailbox:". If present it could be returned in a query with
> > the
> > abuse-mailbox address by default, or with a specific query. Or
> > reference it separately with a "sec-c:" attribute.
> 
> Agree, this would be one of the options.
> 
> But then, what is admin-c: and tech-c: intended to be used for,
> today?
> 
> (Expecting no answers, just pointing out that there is lack of clear
> understanding)
> 
> Gert Doering
> -- NetMaster

I don't think the problem would be to add a new attribute if needed.
The problem would be to *define* what should go there (and then get
everyone downstream to use that new attribute)

The line is quite thin. And not every company will group things in the
same way.

"There's a vulnerable Confluence server on your network" → Vulnerable
"This IP has contacted a botnet C server" → Compromised
"This is sending emails with malware" → Attacking other networks 

And often it will go in that succession. There was a vulnerable system,
that got compromised, and then used to attack third parties.
In some cases the same team will handle all of those. Others may have a
different team for patching than for dealing with compromised hosts.
And others may only stat worrying only after it starts giving problems
to others.


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] addtess verification (was: personal data in the RIPE Database)

[Ángel González Berdasco via anti-abuse-wg]

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-resources/independent-resources/independent-assignment-request-and-maintenance-agreement

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
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] RIPE NCC Anti-Abuse Training: Next Steps & WG Input!

[Ángel González Berdasco]

> And now that you mention it, are you sure that CSAM is illegal in 100% of the 
> countries?

Of course it's not. Or, CSAM itself might be illegal but the definition of 
'CSAM', 'child' or 'abuse' varies, so the end result is still that X is illegal 
in country A but not in country B.

See the variations of the age of consent around the world, which is sometimed 
further conditioned by things such as if the parties are married, their age 
difference (with again different values), if their relationship started when 
both were underage and other Romeo and Juliet exceptions.


Almost every complication surrounding the definition of statutory rape will 
blur as well getting a common definition of CSAM.

Luckily, the standard for taking it down is not whether they would really be 
prosecuted under who-knows-which jurisdiction but a more general interpretation 
included in the Terms of Use of the service.


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] Proposal: Publish effective users' abuse-c

[Ángel González Berdasco]

> 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] Proposal: Publish effective users' abuse-c

[Ángel González Berdasco]

Alessandro Vesely wrote:
> > > And, if yes, would it be acceptable by the resource holder or are
> > > there
> > > contractual impediments? Finally, if feasibility is ok, would
> > > operators
> > > take advantage of it or is it only me? >
> > 
> > If you are talking about adding extra abuse addresses to assignment
> > objects by agreement with the resource holder, as I explained, that
> > is
> > possible now by simply adding an abuse-c to the assignment .
> 
> 
> Except that I don't have write access to the assignment object.
> 
> 
> Best
> Ale


I'm not an expert on all the supported RIPE db details, but I think you
could have an abuse contact object, that you could modify, with the
main resource linking to your abuse contact plus the ISP one.

I find that abuse contacts are fairly static ones (if not directly
following rfc2142), so the client need to write to it is probably not a
very relevant use case. Maybe some weird setup, such as if you wanted
to present a dynamic abuse contact that changed every day-

-- 
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] Proposal: Publish effective users' abuse-c

[Ángel González Berdasco]

Alessandro Vesely wrote:
> Hi all,
> 
> (...)
> 
> I propose that RIPE accepts abuse-c email addresses from verified effective 
> users of a range of IP numbers, stores them in the database, and serves them 
> in 
> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  
> Various 
> automated methods can be adopted to allow an effective user to be verified; 
> for 
> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way 
> can expire after a few months, forcing the effective user to renew them, so 
> as 
> to avoid stale entries.


Hello Ale

I think you should describe how this proposal differs from what is
available nowadays. Wouldn't they already be able to configure verified
effective users for the IP addresses (e.g. with an abuse-c of the
client and another of theirs) ?

They may be unwilling to do so or consider it a hurdle, requiring them
to create new objects and so on, but what makes you believe they would
be willing to use that new system?


Best

-- 
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] Potential New Co-Chair

[Ángel González Berdasco]

El jue, 20-01-2022 a las 10:04 +, Brian Nisbet escribió:
> So, as a first stage, does any object to this happening "out of
> cycle"? I'm very happy to say that silence indicates consent here,
> but if you have any objections then please state them here or to 
> aa-wg-cha...@ripe.net before 17:00 CET on Wednesday 26th January.
> 
> If that is all good, we'll proceed with the next phase.
> 
> Thank you all,
> 
> Brian
> Co-Chair, RIPE AA-WG


Hello Brian

No objections here to this "out of cycle" process. I support going
ahead with this.

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] Is there any analysis on root causes of mail account break-ins?

[Ángel González Berdasco]

Hans-Martin Mosner schrieb:

Hi folks,

I'm trying to understand the root causes and vulnerabilities that lead to 
hacked mailboxes. Currently, we can handle dynamic IP ranges pretty well, and 
we have an extensive list of network ranges whose owner are spammers or 
knowingly accept spammers as customers.

So what mainly remains as spam sources are hacked servers/websites, hacked mail 
accounts, and freemail accounts registered with the purpose of spamming (I'm 
looking at you, Google).

Here I want to focus on hacked mail accounts. I can think of two major root 
causes but I have no idea about their relative significance:

  *   Easily guessable passwords, with two subcauses for exploits:
 *   Brute force authentication attempts - I'm seeing them regularly, and 
the most egregious networks (e.g. 5.188.206.0/24) are fully blocked at our 
mailserver, but some mailops are less struct about blocking such abusers.
 *   Hashed password data exfiltration and cracking (for example using JtR) 
these lists - this would work better with weaker password hashing, but with 
weak passwords and some CPU power it is probably possible even for strong hash 
algorithms.
  *   Malware on client machines where passwords are either stored in a 
password vault, or entered manually.



I suspect a large amount would be caused by phishing. Users getting a malicious 
email (generally) leading them to a phishing page where they happily introduce 
their credentials. Some users fall even for "badly designed" phishing sites 
without any sophistication at all.
If after compromise the phishing uses the newly-minted credentials to send 
itself to their address-book (which on corporate systems can be the whole 
organization), that explains how there can be such clusters. Fresh students 
would not know the ins and outs of their new system (they may not even know how 
to properly use their email account, but that's a bigger issue) thus being easy 
prey when receiving a "Your mailbox is getting full" email. Corporate users 
(Government or otherwise) don't have such excuse, though.

Getting infected with malware would be less prevalent than this, one would 
hope. There are many more layers where it can be detected, both by the users 
themselves (would generally require more steps and show more warnings) and 
detection of the malware at the endpoint. Although users will nevertheless get 
themselves compromised no matter what.


A fourth recent source of compromised mailboxes are compromises of unpatched 
Exchange servers, albeit that's recent and will eventually disappear.


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] Anti-Abuse Training: Questions for the WG

[Ángel González Berdasco]

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.

And then, among the actions that can be taken, automatically forwarding
could be one of them (and probablye 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.
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.

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.


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.

Re: [anti-abuse-wg] Abuse address checking

[Ángel González Berdasco]

Lol, a vacation autoreply to pass RIPE email address validation. 來
It kinda misses the point if they don't read them as well.


--
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, 
limitation of 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.

Re: [anti-abuse-wg] False positive CSAM blocking attributed to RIPE

[Ángel González Berdasco]

El mar, 28-09-2021 a las 11:56 -0700, Jeremy Malcolm escribió:
Dear all,

I am new to this list, although I am not completely new to the Internet 
technical community, as I am a long-time IGF (and occasionally ICANN) 
participant.

I am writing about a case that has been referred to my organization involving 
global blocking (packet dropping, apparently) of IP addresses that have been 
reported as hosting CSAM by the Canadian Center for Child Protection (C3P). 
According to public information, the C3P runs a web crawler called Project 
Arachnid which searches for instances of CSAM on the clearweb, and sends 
automated takedown notices to providers.

However, in the case that was reported to me, rather than allowing the hosting 
provider to take down the offending image, the takedown notice was followed by 
global packet dropping of the hosting IP address, which took down the entire 
server and other websites along with it: the hosting provider has attributed 
this censorship to RIPE, although I cannot verify whether or not this is true. 
If I am able to obtain more details from RIPE staff, I will follow up with them.

Moreover the website in question was not a CSAM website, and neither was the 
image reported by the C3P a CSAM image. It was a scan of a 1960s postcard of an 
indigenous family, sent through the mail, which was included in a detailed 
ethnographic blog article about indigenous women and girls. In other words, 
this is an obvious false positive, and it should never have been reported as 
CSAM at all.

I'm writing to find out if anyone has more information that they can share 
about how this might have happened, and how it can be prevented from happening 
in the future. Many thanks in advance for any help that you can offer. Not sure 
if I should include the RIPE Cooperation ML on this, given that it relates to 
the actions of the C3P?

Hello Jeremy

RIPE did not block your site. What I can see happening is that when C3P found 
some "CSAM content" on your site, it looked up on the _RIPE database_ who was 
the appropriate contact to notify about this, and then either
a) Notified both you and $someone_else
or
b) Notified just $someone_else (which would have then forwarded it to you)

with $someone_else most likely being your hosting provider.
Note that if you don't know to have your details in the whois database, then 
most likely they are not there, and the details will be to your hosting 
provider.

Using the RIPE database to find out the owner of an IP address and the abuse 
contact for it is precisely the right thing to do here (assuming this is 
network range was allocated by RIPE).

Finally, $someone_else filtered your site first (shutdown the machine, 
firewalled it…) and then asked questions. It may be harsh, but it's an 
understandable policy. Specially since they may not be allowed to identify what 
is CSAM and what isn't, and should they misclassify it as not being CSAM, while 
legally fitting into that category, could lead to Real Trouble.™

It is also possible that the filtering was done by a different entity, like the 
upstream provider of your hosting, but I would bet it was done by the hosting 
itself. And it is the filtering entity you should request to remove such 
filtering. You may be able to use different traceroutes to pinpoint the place 
where your server is being blackholed.


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. 

Re: [anti-abuse-wg] Input request for system on how to approach abuse filtering on Route Servers - bad hosters

[Ángel González Berdasco]

Hans-Martin Mosner wrote:
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.

I agree. There are two points. First to agree on a list of 
observations/metrics, so that everyone categorises things the same way. This 
should be relatively simple.
And then, hopefully, some kind on agreement on a recommended threshold. Or a 
set of thresholds depending on the tolerance (which also allows initiatives 
like AAN to start gradually).



  *   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.

Cryptocurrency blockchains are not a good tool, but I completely agree.
Validation should be included from the beginning. It can be as simple as 
including signatures. Similar to Certificate Transparency servers.

Note you also need to define who is allowed to send there if you expect 
"everybody" to consume it. This is similar to your following point:


  *   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.

although I was thinking in a bad actor flooding the database with useless 
observations in order to make it inoperative.



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. 

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Ángel González Berdasco]

El jue, 04-03-2021 a las 17:16 +0100, Christian Teuschel wrote:
> Hi Elvis and Suresh, dear colleagues,
> 
> Putting exact numbers on how many operators are using UCEProtect is
> difficult, but through feedback from users, network operators and
> members we understand that it is in use and that the provisioning of
> this RBL on RIPEstat has value.
> 
> If I am reading the feedback in this discussion correctly, the
> sentiment
> is leaning towards adding more RBLs instead of less and if that is
> the
> case we are going to look into how and when we can achieve this.
> Please
> let me know if that is aligned with your requirements/expectations.
> 
> Best regards,
> Christian

Hello Christian

I think there are two issues at hand here.

First one is the realiability of uceprotect. A dnsbl SHOULD be neutral.
A blacklist which accepts payments for delisting seems shady by itself,
even if actually done with the best intentions. Due to this it has long
been considered as not a source to trust or care about (unlike their
policy with many other blacklists). But a network choosing to care (or
not) for a blacklist, or a BL deciding to seek payments, are their own
decisions.
However, what I find really worrying are the reports of uceprotect
intentionally increasing their to list more addresses, or even
inserting "hits" for ip addresses which cannot have produced
the alledged hits. This would make them misleading at best, if not
directly mischievous.
PLease note this is just from a technical point of view. Issues of
"non-professionalism" are a separate matter.
A blacklist operator should be able to know why and even justify, if
needed, why it listed an IP address. To a trusted third party, for
instance. If it is / became a predatory blacklist, that's enough reason
not to include it, as that would be a way of promoting it.


Second issue is the number of entries. I would consider that the more
(good) blacklists included, the better. I would still not include a
predatory blacklist there, as the mere listing gives them a sense of
legitimacy.
This can be conflated with the number of lists but is actually
different. If you include many blacklists (e.g. mxtoolbox checks 94),
it's easier to include lower-quality ones, as the exposure given to
them is more diluted. If you only list a couple of lists, that makes
them look like they are "the important ones". Even if it was never the
intent.


Best regards



PS: And yes, the NP-hard problem is telling apart the good from the
evil. In some cases it can be simple, but it often is not.

-- 
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.

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Ángel González Berdasco]

Cynthia Revström writes:
> > It seems to me that if your abuse@ email is being overloaded and
> you are unable to keep your network spam free, then you shouldn't be
> taking on any more customers until you figure things out.
> 
> As has been noted before in this thread, just because you are getting
> 200 abuse emails in a day doesn't necessarily mean you have a huge
> issue but it is a lot of emails to deal with.
> It might just be one customer who port scanned a /24 somewhere on the
> internet.

Right. However, as also mentioned, it shouldn't be that hard to group
them by IP (which would be a finer granularity than per customer), even
for unstructured mails.

And, if they are all actually the same issue, they should be very
quickly to process, as they all refer to the same incident (quickly per
report, I admit it may still take 2-3 hours to clean that inbox).


Plus, given the low value of abuse reported, for receiving 200
complaints I expect the actions from the customer account would be of
at least an order of magnitude more than that you received complaints
about. Probably much more.



Also important: how much time passed since first report to customer
abuse stopping? how many reports refer to that initial window when you
weren't aware of the abuse (by the customer itself, by those that
compromised your customer, etc.) until you got notice of that (either
from external reports or from your own monitoring) ?

Earlier you mentioned taking a week to handle the incident reports. If
the abuse continued for so long that would obviously affect more people
and cause more complaints.

It's true that not everyone reports immediately. Perhaps customer began
abuse at t₀, got suspended at t + 2 hours, and yet you receive some
complaints next day due to people aggregating their notifications daily
(this means less notifications for you, but more delay in receiving
them), but if the customer account continued rampant for days, that
would obviously make you receive a lot more reports.



> > Why do you think that because you tell yourself you are "too big"
> that you don't need to monitor your network?
> 
> I don't think anyone is saying that, but if you want a human to read
> your emails, you shouldn't automate the sending so you end up with
> potential situations like that.

No. You should actually love automated reports.
If Joe Abusehater automatically reported you every day a number of
phishing links on your systems (for example, suppose you are Twitter
and these are phishing links using your shortener), there's no problem
in automatically processing their emails with e.g. a regex:

> "Hello Cynthia,\nIt's Joe again. This time we detected a
> (?Pphishing|scam|child pornography|malware|...) link on your
> site at (?Phttps?://[^ ]+)) I would like you to take care of
> that.\nThanks, Joe"


A human read the email, then told the machine what it means and how to
handle it. If there's an email the machine doesn't know how to handle,
a human goes and takes a look.

Now suppose Joe didn't automate sending you the email. He instead hires
some sloppy operators. They sometimes use one text, sometimes a
different one. From time to time, they forget to include the url, or
don't specify the category (which, albeit probably not matching your
own categorization, probably is still helpful).

Note I'm not covering the quality of the information. In either cases,
Joe notifications could generally be either good or bad. If you find
Joe to provide reliable information, you may even want to trust their
reports automatically. If they have a lot of noise, you probably will
want to prioritize them at the bottom of your queue.




> Don't assume people are lacking in basic knowledge, rather consider
> that some people might have requirements other than yours, and that
> it might not be as simple as you suggest.
> 
> This also applies in most cases in this thread, just
> because something works for you or might seem easy for you doesn't
> mean it works for everyone in all situations. (I feel like this needs
> to be said)
> 
> -Cynthia

Sadly, problems often lie at the management level, out of the hands of
the technicians which suffer them.
Still, it would be helpful to know about the requirements that make
things so hard for your, as perhaps we could come up with some approach
simplifying your processes.


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 

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Ángel González Berdasco]

On 21-02-2021 03:44 +0100, Cynthia Revström writes:
> Ronald,
> 
> Can you please stop attacking ideas (such as web forms) implying that
> they only have malicious use cases.
> 
> > I hold them responsible because they obviously
> > fail to have in place contractual clauses that would persuasively
> > deter this behavior on the part of their customers.
> 
> In many cases it is practically impossible to know if your customers
> are sending legit emails or spam without having people reporting it.
> As TLS is used in many cases now, the provider can't look at the
> network data to see what the customer is sending even on a technical
> level, disregarding any trust/potential legal issues.


> > The provider in question is a perfectly lousy coder and is thus
> > unable and/or unwilling to write code to parse emailed abuse
> > reports.
> 
> Hi, I am actually primarily a software dev and not a network
> engineer, it is not even close to as easy as you make it out to be.
> Sure you can have a regex to extract IP addresses and other messy
> things like that, but you can't be sure what that address is, it
> might be your customer, it might be the address they say you
> attacked, etc.
> My point here is that parsing free form text in this way without
> having a clearly defined structure is far from trivial.
> Also please stop assuming bad faith by saying that providers are
> "unwilling" to do this.
> If they could drastically lower the amount of manual work needed here
> with a bit of code, they absolutely would in almost all cases.

Hello Cynthia

I would say it's not as hard. Having the right tools helps a ton, but
not all companies understand that.
First of all, you want to automatically parse those reports using
ARF/X-ARF, as those are already machine parseable.
Then, you will have a lot of other reports is a mix of formats, that
you could be parsing separatedky. Although I would say that a naive
approach of “parse all IP addresses, if there is a single one in our
range, associate the report to that IP address” works in most cases.
Scanning for a few keywords (spam, DDoS, telnet, ssh…) should also
allow for an initial classification.

This is all very rough, and (as mentioned in the thread), you should
still have a human *look* at it, but could easily cut the work needed
in more than half.

If you receive those 200 Incident Reports, but they are already
classified as 185 of them relating to 203.0.113.7, you will probably
not need to evaluate all of them to conclude that there is something
bad going on with that customer.

Also, another point would be the number of clicks needed to take action
(e.g. in some systems you might need just 2-3 clicks to suspend the
customer resource and send them a warning, wheras in others you may
need a slow manual process).




> > And anyway, don't actual human beings need to look at these things,
> > in the end, in order to be able to react to each of them properly
> > and in a professional fashion? 
> 
> Web forms can have pros and cons, I am just going to take the case of
> a VPS/Dedicated server hosting company.
> 
> If the hosting company provides a web form, they can have a field
> where they explicitly ask for the offending IP address.
> This report could then automatically also be sent to the customer in
> question, because we shouldn't assume the customer is malicious, they
> might just have a bad config that made them a relay for example.
> This could make it so the report is acted upon sooner potentially as
> the hosting company might take a few days to reply but maybe the
> customer can act sooner.

It depends. In some cases, the customer is another victim. In others,
such as the customer having bought "paypa1.com", well, I think you
_should_ assume he is malicious. :)

It's not hard to figure out by a human. Yet you still need someone to
ascertain them.



> > A provider that is routinely receiving so many abuse reports that
> > it can barely keep up with them all has bigger problems that just
> > the manner in which abuse reports are received.
> 
> Due to the automated procedure by some providers for abuse reports,
> if I have one bad host sending spam, I might get an abuse report for
> every single email they receive, so even if it is just one customer I
> might wake up to 200 emails.
> But if I had a way to group it by sender IP address, that would be a
> lot more manageable.
> (this was just a hypothetical example) 
> 
> Now I absolutely agree that having an abuse email address that is
> acted upon in a reasonable amount of time (maybe a week or so) is
> still essential as the web forms aren't standardised or might rely on
> technology like captchas.
> But if you send me 200 emails about the same host in one day, I am
> probably still going to be mildly annoyed and I could see how this is
> actually unmanageable for larger providers.


Larger providers should have more people dedicated to handle abuse
reports. Unfortunately, it's a task working too many times with 

Re: [anti-abuse-wg] Anti-social assholes

[Ángel González Berdasco]

First of all, can we please avoid insulting people here, particularly
on email subjects?

I understand how we are all fed up at times with the abuse handling of
certain providers (or lack thereof) but, even if it wasn't what rfg was
intending this could easily be construed as a personal attack by
certain people on this list (completely unrelated to HostDime, I should
note) which won't help having healthy discussions with everyone
involved.

Thanks


JJS JJS writes:
> To put it alternatively: 
> Imagine you walk down a street and there are lots of pubs (saloons?)
> that serve Alcohol and they all have drunken people swearing and
> trashing the place and you ask to report it to the manager but the
> bouncer of one premises says... "You have to put it in writing via
> email" and the next premises says "you have to telephone during
> business hours" and another says "you have to write a letter to an
> address".
> 
> That is their choice. Sometimes with forms, it pre-loads it into a
> system that formats it for them. Sometimes there are email systems
> that can extract that information and format it anyway. But if they
> want you to use a form, they are indicating that's the best way for
> them to know what is happening.

That's perfectly fine. They can prefer receiving abuse complaints via a
form. Or using separate reporting emails for phishing / spam / child
abuse… Or receiving everything in one big mail. Or as separate emails
for every url, even if it only differs in a trailing slash. Some would
like to get a call for urgent matters. Or they would prefer that you
were logged in on their system.

That's all fine, as far as they are *preferences*.

I have my preferences as well. I may accommodate them if it's easy for
me, but perhaps only if that doesn't make it too burdensome for me.
For instance, I may have to fill my own ticket with what was reported
to the provider. This is zero-cost for reports performed by email, but
may mean taking three times more if choosing to report instead via an
abuse form. Which may not always have available on a given day to 
jumping through hoops in order to please yet another provider that day
(and, sadly, the lack of response don't encourage taking the extra
effort of doing it _their way_. There are providers doing great, but
too many deaf ears out there).

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.

Re: [anti-abuse-wg] On the abuse handling policy of manitu.net (AS34240)

[Ángel González Berdasco]

JORDI PALET MARTINEZ writes:
> Even worst ...
> 
> You've read that, but automated systems will not do, just use the
> abuse mailbox.
> 
> Anyway, I think in general the information will get if an automated
> abuse report is sent, will be not personal, but from an organization.
> 
> In fact, if they send personal data to the "abuser", I think they
> will be breaking the GDPR, because you need an explicit consent to
> transfer personal data to third parties, right?
> 
> And of course, in front of law, all this text is "wet paper". If
> there is a claim because an abuse case, and their customer doesn't
> respond, they may be liable.
> 
> Regards,
> Jordi
> @jordipalet

It can make sense. When there's an abusive resource that
usually falls in one of these two cases:
a) The customer was compromised by the bad guy
b) The customer itself is the evil guy


For case a) it absolutely makes sense to notify the
customer. Moreso, the *should* notify them (independently
of other measures they may take). If the isn't aware of
the issue, they will hardly fix the vulnerabilities on
their site.

For case b) the customer SHALL NOT be notified. The
provider itself must handle the complaint, not the evil
guy.

Now, every company has its own procedures. A few will
directly delete the customer account, even in case a).
Some will suspend the website and let the customer
clean it themselves. Others will roll the site back
to a previous backup, or otherwise delete the extraneous
files themselves.
Some companies pass along the complaints to the customer.
Specially when the server is fully administered by the
customer, as seems to be offered by this company
("dedizierte Root-Server").

Some companies will overview that the customer do handle
such compliants in a satisfactory way. I'm afraid others
won't.

But I see no problem in that they forward _certain_
reports to the customer. Ideally,  the company itself
would have someone hadling the queue and classifying if
the report is spam and must be discarded, if it should
be passed to the customer to take actio (albeit not
necessarily providing the details of the sender!), or
investigated by the provider.
Using an automated mechanism does result in faster
processing, at the cost of lower quality.
I appreciate that they openly reveal their policy. We
reported some case explicitely stating not to send it
to the customer, just to receive a "We have passed
this to the customer" response.

I sorely miss that they included a slow way to contact
them in that banner (the hostmaster account, I guess?)
for the case you don't want it forwarded but, if
properly managed (which we don't know if they do), an
automated system which automatically handles most reports
could be acceptable. Not ideal, but still somewhat acceptable.

Note we don't know if it's a dumb system that forwards 
everything, or
if it's smart enough to identify the 
typology of most mails and decide
based on a number of
factors if it should be forwarded or not.
Nor how
this compares with the humans that would otherwise
be handling such
queue manually.


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.

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Ángel González Berdasco]

Hello all

First of all, I'm glad Cynthia opened this discussion, as it's a
typical complaint for requiring abuse mailboxes. It's good to have a
healthy discussion about that.

With regards to the query itself, I do think it is acceptable to block
the sending email. If after manual inspection those messages have
absolutely no reason to be there (automatically sent spamming mails), I
think it may be ok to block further messages from that sender.

You could do as Jordi suggests and notify the abuse contact of the
sender as well, warning them that you may proceed to block further
messages from that sender (so at least you warned them, even though
it's probably ignored).

As for the block itself, I can see reasons for doing it both at the
incoming MTA, so it shows a rejection reason on why they are not
allowed access to the abuse mailbox, or at the last level, where the
email is received and stored (so you have those evidences if needed)
but otherwise ignored.


Please note that blocking based on the sender (mail envelope or From:
header) after evidence of directly being spammed from them is quite
different than filtering based on *content*.
That one is much more problematic, since those filters would typically
match as well reports of such abuse coming from your network, which
is precisely the kind of thing you want to be reported. Not to mention
the irony that you send those mails but would avoid receiving them
yourself.
I'm not aware of a way of telling apart the real abusive message vs
someone reporting the abuse message (specially when sent by end-users). 
You could try to detect specific cases, but I suspect that would still
be prone to false positives.


Best regards


El jue, 18-02-2021 a las 13:57 +0100, JORDI PALET MARTINEZ escribió:
> In my experience, this is something you need to live with, and not
> filter anything in the spam folder.
>  
> Why? Because it can be real spam (and then you can use the abuse
> contact of the resource-holder for the addresses where the spam is
> coming from), when you report abuse cases, to facilitate the work of
> the involved parties, you should be allowed to attach or include
> headers, logs, etc. that probe that it is an abuse (from your
> perspective).
>  
> If you filter that, then you will not receive many abuse reports …
>  
> For example, some abuse mailboxes filter specific URLs or domains. If
> the header contains such domain, how are you going to be able to send
> that?
>  
> I use fail2ban and block automatically specific IP addresses or
> ranges once the abuse has been reported and keeps repeating.
> Depending on the frequency of the repetitions, how many, etc., etc.,
> I could increase automatically from a few hours to days or weeks the
> banning.
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 18/2/21 13:40, "anti-abuse-wg en nombre de Cynthia Revström via
> anti-abuse-wg"  anti-abuse-wg@ripe.net> escribió:
>  
> Hi aa-wg,
>  
> For some context, today and yesterday I have been receiving spam in
> the form of fake abuse notices to my abuse contact email address.
>  
> Is there a generally accepted standard for when it's okay to block an
> address or a prefix from emailing your abuse contact?
>  
> I consider being able to contact the abuse email address of a
> network a rather important function, so I prefer not to block it.
> But also as I have more relaxed spam filters for the abuse contact to
> make sure nothing gets lost, it feels like blocking the
> address/prefix is my only option other than manually filtering
> through these emails (10 so far in total, today and yesterday).
>  
> So back to the question, is there a generally accepted point at which
> blocking an address/prefix is fine?
>  
> Thanks,
> -Cynthia
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the exclusive
> use of the individual(s) named above and further non-explicilty
> authorized disclosure, copying, distribution or use of the contents
> of this information, even if partially, including attached files, is
> strictly prohibited and will be considered a criminal offense. If you
> are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original
> sender to inform about this communication and delete it.
> 

Re: [anti-abuse-wg] Report & Co-Chair's Decision on Proposal 2019-04

[Ángel González Berdasco]

El mié, 09-09-2020 a las 08:52 +0200, Alessandro Vesely escribió:
> On Tue 08/Sep/2020 16:33:20 +0200 Alex de Joode wrote:
> > A webform, for a regulator, most likely will be seen as an
> > 'upgrade'. Note that FB and Google also *only accept* complaints,
> > notices etc via webforms. So one can argue a webform is abuse@ 2.0
> > :) So I do not share you view that a webform 
> > is a second rate instrument for accepting abuse notifications.
> 
> 
> IME that's not true.  I notice Google's auto-responses.  Perhaps, I
> should set up a web form myself for receiving such replies...?
> 
> Best
> Ale

Google does indeed accept abuse notifications via email. In some cases
there is even an API that can be used for reporting (e.g. Safe
Browsing). Plus I think the handling for Google Cloud may be quite
different to one about a service directly owned by Google.

The extent and speed to which reports are actioned is of course unknown
but they do take down abuse.

Best regards

-- 









 
  
  
 
 
  
  
   

TU AYUDA EN
CIBERSEGURIDAD
   
  
 
 
  

 
 
  
  INSTITUTO NACIONAL  DE CIBERSEGURIDAD

  

  SPANISH NATIONAL CYBERSECURITY INSTITUTE
  
  Ángel González Berdasco
  Técnico de Ciberseguridad de INCIBE-CERT
INCIBE-CERT Cybersecurity Technician
  angel.gonza...@incibe.es
  
  
 
 
  

 
 
  
  incibe.es
  
@INCIBE
  
  
  ℡ +34 987 877 189

  Av. José Aguado 41 / 24005 León / Spain
  
 
 
  

 
 
  

 
 
  
  En cumplimiento del Reglamento General de Protección de
  Datos de la UE (Reglamento UE 2016/679, de 27 de abril de 2016) le
informamos
  que sus datos personales, corporativos (así como los incorporados a
  documentos adjuntos); y dirección de correo electrónico, podrán ser
  incorporados en nuestros registros con la finalidad derivada de
obligaciones
  legales, contractuales o precontractuales o bien, para responder a
sus
  consultas, pudiendo ejercitar sus derechos de acceso, rectificación,
  supresión, portabilidad, limitación del tratamiento y oposición en
los
  términos establecidos en la legislación vigente y de manera gratuita
mediante
  correo electrónico a d...@incibe.es. El responsable del tratamiento es
la
  S.M.E. Instituto Nacional de Ciberseguridad de España M.P., S.A. Más
  información en nuestra web: Política de
  Protección de Datos Personales y Registro de actividad de
  tratamiento de datos personales.
  
 
 
  

  
 
 
  

 
 
  
  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, limitation of 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: Personal Data
  Protection Policy and Personal
  data processing activity log.
  
 
 
  

 

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

El mié, 13-05-2020 a las 15:11 +0200, Marco Schmidt escribió:
> Hello Jordi,
> 
> Allow me to respond as this is a more an operational topic.
> 
> I agree with you that RIPE policies should provide the general 
> framework, while the RIPE NCC works out the best operational details
> to 
> apply the policies.
> 
> In the mentioned example the procedure has worked, as the contact
> was 
> identified and marked as invalid.
> Ed has clarified already that after the RIPE 80 meeting, we will work
> on 
> adding this information also to the RIPE RDAP service.
> 
> Thank you and Angel once more for bringing this to our attention.
> 
> Kind regards,
> Marco Schmidt
> RIPE NCC

You are welcome, Edward, Marco.
I only noticed that such note was missing from rdap when I was going to
show here that it an example of  contact marked as invalid by RIPE
process.

Long-term, Alessandro proposal of having a field for tagging the
contact status as (probably) not-working seems the way to go (not sure
who should propose that to IANA), but storing it in a comment would
allow for a quick solution in the interim.

Best regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti-
abuse-wg escribió:
> You misunderstood me.  I'm not advocating de-registration of IP
> resources.  I
> meant to remove just the abuse-c email address, since it does not
> work.  As an
> alternative, as Àngel noted, there could be a tag saying that the
> email address
> is not valid, without actually removing it.
> 
> [Jordi] I got your point now, thanks!
> 
> I think it is more useful instead of removing the address, marking
> the record as invalid, and this is being done if I recall correctly
> from RIPE NCC presentations.

5.135.48.50is one of such IP addresses.
It has as abuse-c ab...@for-ns.com, which is trivially invalid: for-
ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has
address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25

Port 43 access provides:
> % Information related to '5.135.48.48 - 5.135.48.51'
> 
> % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'ab...@for-ns.com'
> % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for
> further information.


I am unable to see such piece of information on the RDAP view, though:
https://rdap.db.ripe.net/ip/5.135.48.48


Best regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.



Disclaimer:
This message may contain confidential information, within the framework
of the corporate Security Management System.If you are not the intended
recipient, please notify the sender and delete this message without
forwarding or retaining a copy, since any unauthorized use is strictly
prohibited by law.

Re: [anti-abuse-wg] Spamming LIR accounts

[Ángel González Berdasco]

I have been told both things. That company email accounts wouldn't fall on its 
scope (even if they contained the full name) and that such usage would be 
improperly treating PII.

GDPR seems to mostly leave that part to Directive 2002/58/EC, which isn't 
completely clear:
Article 13

Unsolicited communications

1. The use of automated calling systems without human intervention (automatic 
calling machines), facsimile machines (fax) or electronic mail for the purposes 
of direct marketing may only be allowed in respect of subscribers who have 
given their prior consent.

2. Notwithstanding paragraph 1, where a natural or legal person obtains from 
its customers their electronic contact details for electronic mail, in the 
context of the sale of a product or a service, in accordance with Directive 
95/46/EC, the same natural or legal person may use these electronic contact 
details for direct marketing of its own similar products or services provided 
that customers clearly and distinctly are given the opportunity to object, free 
of charge and in an easy manner, to such use of electronic contact details when 
they are collected and on the occasion of each message in case the customer has 
not initially refused such use.

3. Member States shall take appropriate measures to ensure that, free of 
charge, unsolicited communications for purposes of direct marketing, in cases 
other than those referred to in paragraphs 1 and 2, are not allowed either 
without the consent of the subscribers concerned or in respect of subscribers 
who do not wish to receive these communications, the choice between these 
options to be determined by national legislation.

4. In any event, the practice of sending electronic mail for purposes of direct 
marketing disguising or concealing the identity of the sender on whose behalf 
the communication is made, or without a valid address to which the recipient 
may send a request that such communications cease, shall be prohibited.

5. Paragraphs 1 and 3 shall apply to subscribers who are natural persons. 
Member States shall also ensure, in the framework of Community law and 
applicable national legislation, that the legitimate interests of subscribers 
other than natural persons with regard to unsolicited communications are 
sufficiently protected.

It talks mainly about natural persons, but others should as well have adequate, 
protections. so... ¯\_(ツ)_/¯

https://gdpr-info.eu/issues/email-marketing/
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32002L0058=EN

The fact that in RIPE database all those role accounts emails are considered 
"personal data sets" in the RIPE db may or may not also influence how it should 
be treated w.r.t its treatments.


In any case, not complying with the RIPE Database Terms and Conditions may make 
such use unlawful even if it would be otherwise acceptable.


Best regards

Ángel


El mar, 12-05-2020 a las 23:41 +0200, JORDI PALET MARTINEZ via anti-abuse-wg 
escribió:
I’m not sure if this is true in all the cases, because a physical person can 
also have PI resources and then a personal email in the database.

There is one more point, which I’m discussing with the Spanish DPA in the 
constitutional court, and it is the classification between personal and company 
emails, when they have your name and family name, you use it for personal 
matters (even if the domain is  from a company – example, you can have separate 
 emails for business and personal, bus using the same domain), and if the 
collection of data was authorized or not, and if it was just data collection or 
also spam.

Is not easy. In Spain, the spam (even with business emails) is not allowed 
according to a further law (LSSI). I guess it varies from country to country.

Anyway, I think it has been said a few days ago, harvesting the databases for 
spam is against the AUP.

Regards,
Jordi

@jordipalet





El 12/5/20 23:27, "anti-abuse-wg en nombre de Alex de Joode" 
mailto:anti-abuse-wg-boun...@ripe.net> en 
nombre de a...@idgara.nl> escribió:

A good summary Sabri.

One of the points that has not been addressed (fully) is the fact that the 
mailing went out to 'role accounts' which are normally company accounts (if 
some used a personal email  address for that, than this will have suddenly 
become a business email address), so GDPR applicability would be remote, if at 
all.

Alex (LL.M)
--
IDGARA | Alex de Joode | a...@idgara.nl | +31651108221 | 
Skype:adejoode

On Tue, 12-05-2020 21h 12min, Sabri Berisha 
mailto:sa...@cluecentral.net>> wrote:
- On May 12, 2020, at 4:51 AM, Töma Gavrichenkov 
mailto:xima...@gmail.com>> wrote:



Peace,
Peace,

 On Tue, May 12, 2020 at 1:29 PM Arash Naderpour
 mailto:arash.naderp...@gmail.com>> wrote:

EU laws are for EU

 Perhaps sadly for some, but this is not how it works.  EU laws protect
 EU citizens wherever they are, or the EU citizens' personal and
 sensitive data wherever it is 

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

El vie, 08-05-2020 a las 22:57 +0100, Nick Hilliard escribió:
> > I'm happy if you believe that my wording
> > is not good, and we agree on that goal, to find an alternative one.
> > Any suggestion?
> 
> Firstly, if you propose to collect stats about anything, you need to 
> think about what sort of stats should be collected.
> 
> Secondly, you need to make a credible argument about why the RIPE NCC 
> should be obliged to spend membership funds collecting these stats and 
> why the RIPE NCC is a more appropriate vehicle for collecting these 
> stats than other organisations which specialise in online security and 
> abuse issues, particularly those which already collect statistics about 
> online abuse.
> 
> Nick

Hello Nick

These are not statistics about online abuse. These are statistics about
the contact information registered by RIPE being valid.

RIPE contact database is like a phone book.

It doesn't matter for that if the number which was looked up was the
hairdresser's (a customer relationship) or the number of the upstairs
neighbour which is flooding your home (abuse).

It may be that the fire department has statistics of non-working
numbers on the phone book (since, incidentally, they are using the same
phone book as the rest of the people), but it is much more logical that
the entity tracking the phone book quality was be the one compiling the
phone book (even though it is the one which would need to provide the
proper number should be the actual customer).


Kind regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

On 08-05-2020 20:17 +0200, Alessandro Vesely wrote:
> On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote:
> > Hi Alessandro,
> > 
> > As I've indicated already several times (and not just in this
> > discussion), all the RIRs have forms or other methods to escalate
> > any issues.
> > 
> > The proposal is only changing "let's have stats".
> 
> 
> I read:
> 
> The RIPE NCC will validate the “abuse-mailbox:” attribute at
> least
> annually. Where the attribute is deemed incorrect, it will follow
> up in
> compliance with relevant RIPE Policies and RIPE NCC procedures.
>
> https://www.ripe.net/participate/policies/proposals/2019-04
> 
> The anonymized statistics is mentioned afterward.  It seems to result
> from
> community escalation and reporting, rather than from the abuse-
> mailbox
> validation itself.  By my proposal, instead, the output of the
> validation process is borne out when the abuse address is removed
> from the database —and the corresponding IP ranges duly transmitted.
> 
> 
> Best
> Ale

Currently there are already abuse contacts marked as having failed
validation.
Maybe it should be tagged in a different way.
I do not think removing them would be the solution, as that would be
ambiguous with not having been set at all. Plus, it is also possible
that it is actually working, and the failure was just a transient
error.

Trying to suit everything, I would probably go for providing along the
abuse contact when was the first and last known date it worked, and -if
newer- they didn't.
An individual could contribute to the contact being marked as failed
(as it's already the case) by notifying RIPE. The rir owner could also
trigger a new check to show that it is working again.


And whatever you do with such information, is still up for local
policy. If am abuse contact is known to have been working last Monday,
but fails since yesterday, there's a good chance that it has been fixed
or it will be shortly. If it has never been verified to work and it has
been failing for seven years, well, there's probably no point in
notifying them through that address.

However, all of that would still be a local policy decision, which I
suspect would be better received. You would set your own arbitrary
thresholds there, rather than the discussion on after which X time
should RIPE pull that entry from the db. Plus, not all purposes would
treat them similarly.
In case you are reporting an abuse from two hours ago, you may only
care that it is working *right now*. However, if you were checking
whether their abuse contact status, as one of multiple points
evaluating a peering request, trying to guess how problematic your
prospective neighbour may be, you might prefer seeing that their abuse
mail has been reachable for the last 6 months.


Best regards

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

Richard Clayton wrote:
> >There will be an API for the system with an option for email notifications 
> >just 
> >like abuse complaints are received in email messages now, so there will be 
> >no 
> >overhead to your staff. Regarding the reporters - this overhead can protect 
> >from 
> >flood of automatic tools abuse complaints - if the reporter cannot fill a 
> >form 
> >and solve a captcha then the abuse complaint is not important enough to him.
> 
> I don't think you quite understand the scale at which many abuse
> detection systems identify activity which needs to be dealt with (and
> indeed will be dealt with in an extremely timely manner once a report
> has been made).
> 
> Solving CAPTCHAs gets old very quickly.
> 
> >Regarding the little to no value that you wrote, through this system there 
> >will 
> >be no spam of abuse, no spam to the abuse publicly visible email address, 
> >there 
> >will be an API to LIR's internal systems for them to better track and to 
> >better 
> >handle abuse complaints, there will be tracking if abuse complaints were 
> >handled 
> >and public visibility of the percentage (of unhandled abuse complaints) of 
> >each 
> >LIR, in Ripe website.
> 
> This paragraph make me think that you have never been the receiver of
> email which has been generated as a result of filling in a web
> form...
> spam (and indeed abuse such as mail-bombing) is remarkably common.


CAPTCHAs are indeed the wrong tool to such form. You would want instead
some kind or authentication token for reporters (ok, maybe you can
request a captcha if you are not logged in, but clicking on bicycles
until the data-mining captcha provider is satisfied you are not a bot
is not constructive at all).

Such form *could* work. One format in order to report to any LIR in
RIPE. The receiver could process the structured data automatically and
even take action without human intervention if the reporter reputation
(or the combined reputation of everyone that did so) is high enough.



> It is also extremely common for genuine reporters to fill in
> incorrect or incomplete information and making forms robust against
> this issue is extremely complex.

It would have to be properly structured with all the needed fields for
every case, and its API would need to support the multiple use cases,
and integrate with (or replace) the multiple ticketing tools used out
there for abuse handling.

Ironically, such tool would mean imposing a much bigger requirement on
the members and the way they handled abuse than every abuse-mailbox
proposal we have discussed on this list.


Regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Ángel González Berdasco]

Nick Hilliard wrote:
> > and must not force the sender to use a form.
> 
> It's not the job of the RIPE NCC to tell its members how to handle
> abuse reports, and it is beyond inappropriate for this working group
> to expect the RIPE NCC to withdraw numbering resources if member
> organisations don't comply with an arbitrary policy which forces the
> use of SMTP email like this.


This is not how to *handle* abuse reports, but how to *receive* them.
Given that the resource holder needs to provide an email mailbox for
abuse contact, it doesn't seem so unreasonable to ask that it is
possible to *gasp* send abuse reports using that abuse mailbox.

Many autoreplies suggest you to use a form, as a way to speedy the
request. However, if an abuse mailbox replies:
> Your abuse request has NOT been proceed amd mpt tramsitted to our
> team.
> This automatic answer is NOT an acknowledge.
> Your request MUST be report on httos;//...
(a real case from a RIPE member),

is it a working mailbox?


What if abuse-c: pointed to ab...@example.com, then an autoreply told
you to email instead b...@example.com, that j...@example.com, that one
j...@example.com, which replies that she is no longer and example.com
and please could you send that to m...@example.com...

Is that a "working mailbox"?



Note we could have instead a abuse-uri rather than a mailbox, so that
it could be reported via a mailto:, https://, gopher://...

Ultimately, though, the real problem is to standardise the
communication. That could be by using a mail compliant to x-arf (or
anything else we might come up with), stating a set of fields needed by
a REST abuse form, etc.
And getting everyone to agree on such set of fields would be difficult.
But once the information is structured, the next steps should be quite
straightforward. According to whatever procedures you may have to
handle these issues.


Also, I should note that handling abuse _should_ be desirable for a
member that *cares*. It may be a compromised host, an abusive
customer... but a timely report would avoid, rather than just finding
out when they find themselves on a third-party blacklist since nobody
bothered to jump through the needed jumps just to tell them they needed
to password reset a compromised account.


Regards

Re: [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")

[Ángel González Berdasco]

Well, I do see the value of an option (a magic email value?) meaning "this 
entity supports the use of its network for abusive purposes and will take no 
action on any abuse report".

That would save time for everyone involved, and would allow to easily block 
those networks from accesing ours!

Re: [anti-abuse-wg] Massive prefix theft in AFRINIC - attributed to an insider

[Ángel González Berdasco]

Let me join Suresh in congratulating you, Ron. It is very hard to obtain 
meaningful results in this kind of affairs. Yet here, the hard-earned results 
have been impressive. Hats off.

Best regards


De: anti-abuse-wg [anti-abuse-wg-boun...@ripe.net] en nombre de Ronald F. 
Guilmette [r...@tristatelogic.com]
Enviado: jueves, 05 de diciembre de 2019 0:50
Para: anti-abuse-wg@ripe.net
Asunto: Re: [anti-abuse-wg] Massive prefix theft in AFRINIC - attributed to an 
insider

I am obliged to thank my friend Suresh for his kind words.

I have indeed been trying, for lo these past 20+ years now, to chase
spammers and other miscreants off the Internet.  It has rarely been
easy, but there have been occasional gratifications.  Today is one such.
But this story is not yet complete, and I have miles to go before I
sleep.

I am also obliged to post one small but important correction to what
Suresh said.  Suresh said that Ernest Byaruhanga "has now separated
from AFRINIC."  That's not really entirely accurate.  He has resigned,
but as noted in the story on mybroadband.co.za, he is currently still
employed by AFRINIC and is currently serving out his notice period.

Neither I nor my co-pilot on this story, South African journalist
Jan Vermeulen, have any information about whether or nor, at this
moment, Mr. Byaruhanga still retains unfettered read/write access
to the AFRINIC data base.  (I think that it is not at all inaccurate
to say that multiple AFRINIC officials that we contacted in regards
to this story have been rather entirely less than forthcoming with
us as we tried to get to the bottom of all of these matters.)


Regards,
rfg

Re: [anti-abuse-wg] AI used for spam and abuse at Microsoft?

[Ángel González Berdasco]

They have many minions working there, Andre. And it's not a work they require 
much study.(they probably input that into a tool that says Yes/No).

If it wasn't blocked for your own mail, it may be due to mails sent from its 
neighbourhood.

Reply to their ticket and insist.

Cheers

Re: [anti-abuse-wg] 2019-04 New Policy Proposal (Validation of "abuse-mailbox")

[Ángel González Berdasco]

Marco Schmidt writes:
> Dear colleagues,
> 
> A new RIPE Policy proposal, 2019-04, "Validation of "abuse-mailbox"", 
> is now available for discussion.
> 
> This proposal aims to have the RIPE NCC validate "abuse-c:"
> information more often, and introduces a new validation process that
> requires manual input from resource holders.
> 
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2019-04
> 
(...)

Looks good.

A couple of notes. In addition to the first notice, it may be worth to
add 'reminders' instead of escalating directly to the LIR, such as
sending a reminder after one week (day 7), and another on the 14th day,
prior to escalation.

*This should not be necessary,* as the resource owner should have put
the means so that emails received on the abuse-c are not lost, and
someone actually reviews them, without having to insist on them.
But I foresee that would improve the response process.

Also, the resource holder should be able to manually request a new
mailbox validation if the provided code is expired (eg. the main person
in charge was on holiday and their backup did not handle it).

RIPE should log the time taken by the different holders to validate
their abuse-c, so that those statistics can be used in the future to
better understand the effectivity of this process.



Finally, I have been thinking how to improve the phrase
«Commonly, if a ticket number has been generated, it should be kept
(typically as part of the subject) through successive communications.»

I came out with replacing it with this new paragraph:
«It is quite common to have ticket numbers/identifiers associated to
abuse reports in order to be able to differentiate them, which
are typically included as part of the subject. Replies (either manual
or automated) by the resource holder should maintain any identifiers
used by the reporter, optionally adding their own one. And any reply by
the abuse reporter should keep as well the identifier holding the
ticket number on the resource holder system.»


Best regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.

Re: [anti-abuse-wg] standard for abuse reporting (was: VoIP)

[Ángel González Berdasco]

On 25-04-2019 16:45 +0200, JORDI PALET MARTINEZ wrote: 
> I will rather prefer an IETF standard for abuse reporting ... already thought 
> about starting it several times ... sooner or later I will write down 
> something, so may be some other people interested to co-author?
> 
> Regards,
> Jordi

Hello Jordi

I would also be interested in having a standard for reporting abuses.
There is X-ARF but it isn't able to encode certain information, such as
multiple log entries for the same incident, or the only way to do so
would be extremely verbose, to the point of being impractical if the
recipient is not a bot.

Best regards

-- 
INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute
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.



Disclaimer:
This message may contain confidential information, within the framework
of the corporate Security Management System.If you are not the intended
recipient, please notify the sender and delete this message without
forwarding or retaining a copy, since any unauthorized use is strictly
prohibited by law.

Re: [anti-abuse-wg] Mysteries of the Internet: AS65000

[Ángel González Berdasco]

Well, someone is announcing those prefixes as linked to AS65000. If he itself 
was using AS65000 internally with those prefixes, and that leaked to their 
public interface, it would be a false positive, but lacking some agreement 
between the receiver and their peer involving AS65000, imho those entries were 
used internally by some party, which then inadvertently shared them to peers 
that didn't filter it, etc. With the end result that such entries could made 
these prefixes unreachable.

Here, one side will be the owners of those ip ranges, but there's not an owner 
of the AS as such. Who should be complaining that they are 'advettising their 
AS' incorrectly?

What if a prefix was 10.0.0.0/8 ? Would IANA need to state that it didn't allow 
AS x to advertise a private range? Maybe that step should be skipped for  
reserved ranges.

Most likely, this case is a self-inflicted damage, though.

Best regards

Re: [anti-abuse-wg] 2019-03 New Policy Proposal (BGP Hijacking is a RIPE Policy Violation)

[Ángel González Berdasco]

Let's use a less loaded analogy than a gun store :-)

Suppose we are dealing with a logistics company that uses stolen lorries/trucks.
May their use of stolen vehicles potentially affect their carrier license?

Note that, even if after many months of processes the agreement with the rir 
was terminated and the AS taken back, still that does not preclude the company 
from having ip addresses or having access to the internet.

I expect the next draft not to rely on a single expert, but a panel of 3 
experts (plus then the appealing phase). Would that solve your concerns?



> Blocking content distribution methods is
> effectively blocking the content itself. If your
> newspaper was unable to print and distribute
> their news because their electricity had been
> shut off (for anything outside of nonpayment),
> it would still be considered censorship.

No. The newspaper may pay its electricity punctually, yet be required to have 
its electrical power shut off. A good example of that would be non-compliance 
with the local electricity regulation, which may range from an install so bad 
that could cause a fire to simply having an old meter which doesn't support 
real-time reading

Should the action against the above-mentioned logistics company differ if it 
was used for delivery by a newspaper?


You raise a good point that the allowance of reports by the general public 
could lead to attacks against 'unpopular' entities (such as a certain political 
party) by means of fake reports. However, given that it has to be based on 
technical facts, I'm not sure if that's already enough or there should be some 
additional speedy path in the proposal for them to be discarded (and where to 
put the line?).


Ángel

Re: [anti-abuse-wg] GDPR - positive effects on email abuse

[Ángel González Berdasco]

Volker Greimann wrote: 
> Hi Simon,
> 
> that is a common misconception, but sadly untrue.
> 
> > As things stand at the moment, the interpretations of GDPR and subsequent 
> > actions of some large organisations make it likely that fraud and other 
> > types of malpractice, largely aimed at individual users, will increase.
> On the other hand, the amount of spam and abuse directed at new 
> registrant will be greatly reduced. Balance will be the result.
> > The stated position "that tool was illegal to begin with as it violated the 
> > rights to privacy of millions of domain owners” is, at best, misleading. 
> > Assuming the “tool” being referred to is WHIOS, registrants of domains 
> > needed to provide information as part of their contract with the registrar. 
> > A contractual requirement. Perfectly OK pre GDPR, perfectly OK post GDPR.
> Sadly untrue, since consent to processing of data that is not strictly 
> necessary for the performance of the contract post GDPR must be freely 
> given. If the service is withheld unless consent is provided, that 
> consent is invalid.
> Even before GDPR, the consent for whois was iffy as best.

Don't you have real estate registration in your country that is publicly
accessible? If so, do you think it should now be banned under GDPR (if
in EU)?

I see your point, but it is not *that* clear.

Best regards


-- 
CERTSI (CERT de Seguridad e Industria) - Spanish Security and Industry Incident 
Response Team
https://www.certsi.es/

PGP Keys: https://www.certsi.es/en/what-is-certsi/pgp-public-keys

--

CERTSI (CERT de Seguridad e Industria) Spanish Security and Industry
Incident Response Team operates under the auspices of the Ministry of
Energy, Tourism and Digital Agenda through the State Secretariat for
Information Society and Digital Agenda, and the Ministry of Interior
through the Security State Secretariat of the Spanish government as a
national CERT.
Our main role is detection, coordination and response of security
incidents that take place on Spanish CI (Critical Infrastructure),
Research and Academic Network (RedIRIS), enterprises and/or citizens.
Also, we act as Spanish national CERT in the role of coordination with
other security teams.

--

Disclaimer:
This message, including any attachments, may contain confidential
information, within the framework of the corporate Security Management
System.
If you are not the intended recipient, please notify the sender and
delete this message without forwarding or retaining a copy, since any
unauthorized use is strictly prohibited by law.

--