Re: [anti-abuse-wg] Decision on Proposal 2017-02
FYI: Some longer-term statistics on this: Since January 2018, we have identified 157 invalid abuse contacts (our abuse reports bounced) for network objects registered with country code "DE" which we reported to RIPE NCC. RIPE NCC reached out to their members responsible for the respective objects. 150 cases have been solved by updating the abuse contact or correcting the mail server configuration - usually within only a few days. There are only 2 cases older than four weeks still unresolved. Thanks again to RIPE NCC for their great assistance! - Thomas CERT-Bund Incident Response & Malware Analysis Team On 23.03.18 10:39, Thomas Hungenberg wrote: > We had to deal with 40+ invalid abuse contacts only for resources > registered to German holders in the past three months. > Most messages bounced with "user unknown". > > We tried to reach out to the resource holders to get the invalid > abuse contacts fixed. If that failed, we reported the case to > RIPE NCC. With their assistance, a lot of additional cases could > be solved (thanks!). > > It turned out that most of the contacts were not invalid because > the resource holders wanted to ignore reporting of abuse but due to > technical problems or the contact set to a personal mailbox of > someone who had left the organization. Many resource holders were > glad to be notified of the problem. > > So while I'd still prefer a validation process that requires > human interaction to make sure messages sent to the abuse contacts > are actually read and processed, an automated check if the mailbox > exists at all would already help a lot. > I'd be glad if this automated check just for the existence of the > abuse mailbox could be done not only annually but probably even > twice or four times a year. > > > - Thomas > > CERT-Bund Incident Response & Malware Analysis Team > > > On 20.03.2018 13:54, Gert Doering wrote: >> Hi, >> >> On Tue, Mar 20, 2018 at 01:23:18PM +0100, Janos Zsako wrote: >>> At the same time, I do see some benefit in checking regularly the provided >>> e-mail address, because I am convinced that there will always be cases where >>> people simply forget to update the database. If they are reminded, they will >>> be happy to correct it. >> >> This is actually some benefit I see here - the NCC already does the >> ARC in regular intervals, so including abuse-c: in "please check that >> these are still correct" would be useful to help "those that do care but >> overlooked a necessary update". >> >> (Right now, the NCC will already ensure that contacts are correct if they >> receive a complaint from someone that contact data is wrong) >> >> So, still not really able to make up my mind whether I support or oppose >> this - staying neutral. >> >> Gert Doering >> -- NetMaster >> >
Re: [anti-abuse-wg] Decision on Proposal 2017-02
On 19.02.19 13:23, Carlos Friaças wrote: > Regarding the non-"DE" the figures are worse, right? The statistics are based on our automated reports only. Our automated system is sending 8,000+ reports per day - but only addresses abuse contacts for networks registered with country code "DE" directly. Data for networks registered with other country codes is sent with aggregated reports to the respective national CSIRTs. I don't have any statistics on bounces for reports manually sent to abuse contacts for networks in other countries directly. But yes, it looks like the number of invalid contacts for networks in other countries is (much) higher, in particular for Eastern Europe. - Thomas CERT-Bund Incident Response & Malware Analysis Team
[anti-abuse-wg] Non-ASCII characters in abuse-mailbox addresses
Hi, some abuse contacts registered with RIPE use non-ascii characters with the abuse-mailbox addresses, e.g. % Abuse contact for '195.78.76.0 - 195.78.77.255' is 'abuse@zürich.email' However, the corresponding MTA does not support SMTPUTF8: 7B579403C6: to=, relay=mail.xn--zrich-kva.email[109.95.241.50]:25, delay=0.33, delays=0.01/0/0.32/0, dsn=5.6.7, status=bounced (SMTPUTF8 is required, but was not offered by host mail.xn--zrich-kva.email[109.95.241.50]) (In this particular case, sending email to the IDNA representation of the email address works.) In our experience, using umlauts and other non-ascii characters in (the host part of) email addresses still cause a lot of problems in general. Even if the recipient's MX supports SMTPUTF8 correctly, MTAs on the transport way may fail to handle SMTPUTF8 messages. To prevent such problems and make sure all abuse mailboxes can be addressed, I wonder if the values of abuse-mailbox attributes should be restricted to ASCII characters only. What do you think? - Thomas
Re: [anti-abuse-wg] Non-ASCII characters in abuse-mailbox addresses
On 19.11.19 15:21, Michele Neylon - Blacknight wrote: > If your email client or server can’t handle UTF-8 then doing the punycode > conversion is unlikely to help Based on our experience, it does help. If messages bounce because the recipient's MTA does not support SMTPUTF8, sending the message to the IDNA representation of the recipient address usually works. But I have also seen cases where the recipient's MTA supported SMTPUTF8 correcty but some MTAs or services like spam filters on the transport way did not and thus screwed up delivery of the message. - Thomas CERT-Bund Incident Response & Malware Analysis Team
[anti-abuse-wg] abuse-c attributes in resource objects
The "FAQs for abuse-c" says: You can have an "abuse-c:" attribute on both your ORGANISATION object AND your RESOURCE object (inetnum, inet6num and aut-num). The "abuse-c:" reference on applicable RESOURCE objects will override the value in the "abuse-c:" of your ORGANISATION object. [https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse-c] However, in the RIPE documentation, the list of all possible attributes allowed in AUT-NUM and INETNUM objects does *not* include "abuse-c": [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/ rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object] [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/ rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object] There are currently some RESOURCE objects in the RIPE database having abuse-c attributes (which should not be allowed according to the documentation). For example: inetnum:62.27.57.0 - 62.27.57.255 netname:TIS-D406483-NET descr: Cheetah Digital Germany GmbH country:DE admin-c:NET12312-RIPE tech-c: NET12312-RIPE abuse-c:CDAC23-RIPE status: ASSIGNED PA mnt-by: AS12312-MNT So we wonder what is correct? We would prefer sticking to the documentation allowing abuse-c attributes only in ORGANISATION objects but not in RESOURCE objects as this makes maintaining a local abuse contact database (for CERTs sending thousands of abuse reports per day) much easier. For example, for our local contact database, we import all ORGANISATION objects with "country: DE" and use "org-name" for the contact's name. Then, we link all RESOURCE objects referencing this ORG to the respective contact in our database. Also evaluating abuse-c attributes directly included in RESOURCE objects would make building a local contact database much more complex. - Thomas CERT-Bund Incident Response & Malware Analysis Team
Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
I second Jordi's opinion that validation of the abuse-mailbox should require human interaction of the resource holder. In addition to solving a captcha the resource holder might need to confirm (click a checkbox) that he will monitor the abuse-mailbox account on a regular basis and take appropriate action to solve reported abuse cases. - Thomas CERT-Bund Incident Response & Malware Analysis Team On 18.01.2018 19:44, JORDI PALET MARTINEZ via anti-abuse-wg wrote: > I fully agree with this proposal and should be implemented ASAP. > > HOWEVER, I’ve a question regarding the impact analysis, and specially this > sentence: > > “To increase efficiency, this process will use an automated solution that > will allow the validation of “abuse-mailbox:” attributes without sending an > email. No action will be needed by resource holders that have configured > their “abuse-mailbox:” attribute correctly.” > > Reading the policy proposal, how the NCC concludes that it should be “without > sending an email”? > > I will say that the right way to do a validation (at creation/modification > and yearly) is, in a way that makes sense (having an email that nobody is > processing is exactly the same as not having the abuse attribute at all): > 1) Send an email with a link that must be clicked by a human (so some kind of > captcha-like mechanism should be followed) > 2) If this link is not clicked in a period of 48 hours (not including > Saturday-Sunday), an alarm should be generated so the NCC can take the > relevant actions and make sure that the mailbox is actively monitored by the > LIR > > Regards, > Jordi
Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
On 19.01.2018 13:08, Marco Schmidt wrote: > The way that abuse reports are handled by the receiving party is > usually defined by the internal procedures of the providers and not by RIPE > Policies. If the abuse-mailbox is valid but the resource holder constantly ignores abuse complaints sent to this mailbox for a longer time (no response, no action taken, phishing sites or botnet c2s etc. not taken down) - what is the process to escalate this (probably finally leading to the resource being withdrawn)? - Thomas CERT-Bund Incident Response & Malware Analysis Team
Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
On 22.01.2018 14:19, Gert Doering wrote: > I do see the need for a working abuse contact, and I do see the need of > sanctions in case a policy is violated, but "deregister all resources, > because your mail server was broken when we tested" is too extreme > (exaggeration for emphasis). I fully agree a resource should not be withdrawn just because the abuse-mailbox is (temporarily) invalid or the holder once misses to complete the verification process in time - if he otherwise takes care of malicious activity emerging from his resources. However, I think RIPE-563 (and related policies) should state that resource holders have to provide a valid abuse-mailbox which is monitored on a regular basis and have to take care of complaints regarding malicious activity reported to this mailbox. An autoresponder asking people to fill out a webform should not be accepted as a valid solution as this does not work for CERTs and other security teams reporting hundreds of abuse cases per day to the responsible resource owners (in an automated fashion). Also, irrespective of how the abuse-c verification process will be implemented, IMHO there is a need for a defined process on how resources can be withdrawn (as a last resort) if the holder is constantly ignoring abuse complaints or even wittingly accepts malicious activity emerging from his resources (e.g. bullet proof hosting). - Thomas CERT-Bund Incident Response & Malware Analysis Team
Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
On 23.01.2018 13:52, Name wrote: > Autoresponders/webforms should actually be encouraged, because a stand alone > email address means that all a spammer/attacker has to do to is flood that > email > account with bogus data and the valid reports will either get lost amongst > the > genuine ones, or the inbox will become full. A CAPTCHA can increase the > reliability of reports. As explained in my last email, manually filling out webforms does not work for CERTs and other security teams sending hundreds of abuse complaints per day in a (semi-)automated fashion. The reports are usually sent with a ticket number in the subject line to track the status/responses in a ticketing system. > A ticket/web-form solution also removes the possibility of what i spoke about > before, where administrators install spam filters on their email system and > don't exclude the abuse email box from the spam filter, resulting in spam > complaints being rejected. This problem should probably be addressed in the policy as well (make sure your spam filters don't reject legit complaints). - Thomas CERT-Bund Incident Response & Malware Analysis Team
Re: [anti-abuse-wg] 2017-02 Review Phase Reminder
On 20.02.2018 16:16, Richard Clayton wrote: > It assists the diligent (but too lazy to run their own check) in > learning that their abuse address is not working. This will allow them > to receive more abuse reports and thereby (through their diligence) > ensure that the Internet becomes a slightly safer place. > > in my experience, even the diligent sometimes have outdated and non- > functional email contact addresses -- the Internet is getting old and > things rot and decay, including email addresses and their domains I second this. Over the past months, we reached out to many (German) resource owners with invalid abuse contacts (user unknown, mailbox full, ...) In most cases, the owners were very thankful for our notification as they were not aware of the problem (responsible admin left the company, etc.). - Thomas
Re: [anti-abuse-wg] Decision on Proposal 2017-02
We had to deal with 40+ invalid abuse contacts only for resources registered to German holders in the past three months. Most messages bounced with "user unknown". We tried to reach out to the resource holders to get the invalid abuse contacts fixed. If that failed, we reported the case to RIPE NCC. With their assistance, a lot of additional cases could be solved (thanks!). It turned out that most of the contacts were not invalid because the resource holders wanted to ignore reporting of abuse but due to technical problems or the contact set to a personal mailbox of someone who had left the organization. Many resource holders were glad to be notified of the problem. So while I'd still prefer a validation process that requires human interaction to make sure messages sent to the abuse contacts are actually read and processed, an automated check if the mailbox exists at all would already help a lot. I'd be glad if this automated check just for the existence of the abuse mailbox could be done not only annually but probably even twice or four times a year. - Thomas CERT-Bund Incident Response & Malware Analysis Team On 20.03.2018 13:54, Gert Doering wrote: > Hi, > > On Tue, Mar 20, 2018 at 01:23:18PM +0100, Janos Zsako wrote: >> At the same time, I do see some benefit in checking regularly the provided >> e-mail address, because I am convinced that there will always be cases where >> people simply forget to update the database. If they are reminded, they will >> be happy to correct it. > > This is actually some benefit I see here - the NCC already does the > ARC in regular intervals, so including abuse-c: in "please check that > these are still correct" would be useful to help "those that do care but > overlooked a necessary update". > > (Right now, the NCC will already ensure that contacts are correct if they > receive a complaint from someone that contact data is wrong) > > So, still not really able to make up my mind whether I support or oppose > this - staying neutral. > > Gert Doering > -- NetMaster >
