- anti-abuse-wg - mailman.ripe.net

Re: [anti-abuse-wg] Privacy requirements, was Spam FAQs
by Joe St Sauver 19 Dec '11

19 Dec '11

Niall commented: #There's also services like http://www.radb.net who mirror the data from #all the IRRs who you might like to deal with! Unfortunately, at least in my experience, the routing registry data is often stale or inaccurate, even for things as basic as ASN information. This is not the fault of the RADB folks, it's simply that many users don't take the time to keep their routing registry objects up-to-date. Therefore, while some whois clients query the RADB for ASN information, in my experience, you really want to always check the RIRs for the "last word" when it comes to who controls a given resource (and of course, the sort of data that the RADB offers doesn't have the same coverage as the RIRs, anyhow). That's the main reason why I'm always concerned when I bump into, or I hear about others who've bumped into, well-intentioned but operationally-problematic whois rate limits or anti-harvesting provisions. If systems are old and underprovisioned for modern loads, my recommendation would be to make upgrading them an operational priority, or work on plans to mirror/replicate the data so that normal operational traffic isn't going to result in systems becoming slow or overloaded. Regards, Joe

1 0

Privacy requirements, was Spam FAQs
by Karl-Josef Ziegler 18 Dec '11

18 Dec '11

> And if you want to access a European database then you are going to > have to deal with us nasty Europeans. Just 2 things: - Privavy laws in Europe seem to have much stronger restrictions compared to US laws. - And: a contract between ICANN/IANA and RIPE can't break European laws. European law is stronger than such a contract. If this should be changed it needs a mutual agreement between EU and US government. Is such an agreement in place? Just my 2 cents and IANAL, - Karl-Josef

1 0

whois access
by russ＠consumer.net 16 Dec '11

16 Dec '11

Hi. I am a problem with RIPE mis-applying it anti-abuse procedures for the RIPE database. I have operated Network-Tools.com for 13 years. The site is often used by people tracing spam or other security issues that includes IP address block lookups so people can send in a complaint or otherwise contact the network they have an issue with. I find my web site is suddenly blocked from accessing the RIPE database and I cannot get answers to my questions from contacting the database administrator or IANA. First - I am being accused of wanting "bulk access" to the database. That is not true. My system is a pass-through system where many different people make requests through network-tools.com. The web site is merely a pass-through. I have asked many times how I can pass the requestor's IP address through so my web site won't be "penalized." I never get an answer from RIPE. ARIN told me they don't support such a scheme. One purpose of the whois is so that individuals can contact abuse contacts, verfify who owns address blocks, etc. so blocking pass-through systems thwarts the whole purpose of the RIPE database. Second- RIPE keeps claims the requests are for "personal information." IP address and abuse contacts are business contacts and role accounts meant for the public. this is nor "personal information" (ARIN calls it "sensitive" data). These are business contacts meant for the public, not "personal information" or "sensitive." If if were "sensitive" it would not be available to the public. In any case I do not want to display sensitive data or personal information, I want to display the abuse contacts. As for blocking IP from accessing the database I do not see the purpose anyway. Most harvesters use a distributed system of IP addresses so blocking IP only serves to disrupt pass-through systems doing legitimate tasks while harvesters continue to freely collect their data. For the most part the only thing it does is disrupt legitimate users and cause expense to those users for no purpose. How can I get answers to these questions? Thank you

8 19

Re: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision)
by Joe St Sauver 14 Dec '11

14 Dec '11

Shane commented: #What a great method for finding networks that are poorly monitored and #maintained! Simply check ARIN's Whois database until you find networks #with POC that are marked as invalid! # #I hope that RIPE does not adopt this address-hijacking-friendly #technique. :( If I were a person inclined toward hijacking netblocks, I think I'd likely use data from Routeviews (or a similar routing table analysis project) to identify IP address ranges that consistently are absent from the global routing table. You could certainly use whois database queries in an effort to verify or validate potential target IP address ranges, but I don't really see stale data flags in whois as materially worsening the existing problem of abusers scavening apparently unused (or underused) network resources. After all, if a bad guy or bad gal sees a "juicy" likely-"abandoned" /16 or whatever, it really isn't that hard for them to try emailing the points of contact, or to try calling the listed phone POCs, etc. If the goal is to seriously deter address hijacking, I think we need to talk about things like RPKI (folks who may be interested may want to see Bush and Austein's NANOG RPKI Tutorial from June 2011, http://www.nanog.org/meetings/nanog52/abstracts.php?pt=MTc3MyZuYW5vZzUy&nm=… or for those who find URL shorteners more convenient, try http://tinyurl.com/rpki-tutorial for that same page). Or, if you're skeptical of RPKI, encourage your friends to carefully monitor their space and how it's being announced. But I digress :-; Regards, Joe

4 6

Re: [anti-abuse-wg] Spam FAQs need revision
by Wout de Natris 13 Dec '11

13 Dec '11

Hi, > -- "Should I just ignore spam?" On the spam should be ignored discussion. It's time people realised and acted upon the fact that by reporting spam and all the content/fraud/phishing/malware related with spam to spam reporting centres and/or authorities, maybe just something will change. Somewhere in this data the identity of the spammers lies hidden, including the data of all involved, whether consciously or unconsciously. Also countries or agencies less active will be revealed. Transparency is what this discussion needs and that may just prove half of the much needed silver bullet. Without reporting there is no analyses of data. So please change the topic to report spam actively where possible. And perhaps even add that if there is no spam reporting centre in a country, to lobby to your local government to start one. Regards, Wout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De Natris Consult Raaphorst 33 Tel: +31 648388813 2352 KJ Leiderdorp Skype: wout.de.natris denatrisconsult(a)hotmail.nl http://www.denatrisconsult.nl Blog http://woutdenatris.wordpress.com ******** Due to privacy concerns, part of this message has been removed as per the sender's request ********

2 1

Re: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy
by Joe St Sauver 13 Dec '11

13 Dec '11

Hi, When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/ I'd probably write something that looks quite a bit different than what's currently there. For example, just starting at the top: -- "What is spam? FAQ currently says: "Spam is junk email, usually offering bogus products and invitations to pornography sites. Sometimes, spam email is used to spread viruses. You may also receive 'phishing' emails. These are emails that look like they have been sent by a legitimate organisation and attempt to fraudulently acquire sensitive information, such as passwords and credit card details." I'd suggest that the definition of "spam" that's available at http://www.spamhaus.org/definition.html is significantly stronger. -- "Should I just ignore spam?" FAQ currently says: "Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5." I'd suggest that's a passive/defeatist approach that spammers absolutely adore since it fails to put any back pressure on spammers. By NOT reporting spam, service providers hosting spam-related sites (and service providers with botted customers) get no feedback that will allow them to clean up their issues. That really needs to change. I'd suggest: "No. Consider reporting spam via a well-established spam reporting channel. This might be a "this is spam" button offered as part of your provider's web email interface, or via a third party spam reporting service such as Spamcop (http://spamcop.net/), which is free. If you want to report spam directly, you may find it helpful to see the abuse reporting addresses available from http://abuse.net/" I'd like to suggest that users report spam to appropriate government agencies, see for example: http://spamlinks.net/track-report-addresses.htm#country I would also note that encouraging user reporting is consistent with the explanation that's provided later in the FAQ under "What can I do to stop spam emails?" which goes into some detail when it comes to how to actually do manual spam reporting. -- "What can the RIPE NCC do about the spam email I have received?" FAQ currently says: "Unfortunately, the RIPE NCC can do nothing about spam email or 'phishing' email. The RIPE NCC does not send, or facilitate the sending of, spam email. Nor is it responsible for any spam you receive. It is also unable to investigate any complaints about spamming." Again, that's not the answer to this FAQ item that I'd like to see. I would like to see RIPE NCC acknowledge that it *does* have a role in combatting network abuse, particularly when it comes to ensuring that the resources it manages are not abused. For example, if RIPE NCC learns that a network resource has been acquired under fraudulent pretenses for the purpose of engaging in network abuse, or a network resource has bogus point of contact information, those behaviors are not acceptable and will result in a review by RIPE NCC and, if that abuse is confirmed, those resources will be reclaimed. Obviously that would also imply a change to "Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on?" which states "The records in the Regional Internet Registries'(RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records." If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see: -- https://www.arin.net/policy/nrpm.html#three6 "3.6 Annual Whois POC Validation "3.6.1 Method of Annual Verification "During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." -- http://www.apnic.net/apnic-info/whois_search/abuse-and-spamming/invalid-con… "Use this form to report invalid contact details found in the APNIC Whois Database. APNIC will take appropriate steps to try to have the database objects updated." See also http://www.apnic.net/policy/policy-environment#processing at 7.1 ("Validity of IP address delegations") -- http://lacnic.net/en/politicas/manual7-1.html ("Resource Recovery") See also http://lacnic.net/en/politicas/manual7-1.html "The organizations receiving IPs addresses from LACNIC have the commitment to keep their registration information updated. "But, in the case it is noticed that some information is invalid we ask you to communicated the fact to hostmaster(a)lacnic.net informing the IP address with invalid registration information." So, RIPE may not have processes for keeping their part of the global databases accurate, but other RIRs do... There are also many redundancies in the FAQ, e.g., see the "Can I stop spam?" item vis-a-vis "Should I just ignore spam?" Or "I want to know more about spam" vs. "Where can I find more information about spam" Or "How do I found out who's behind a suspect message?" vs. the tutorial on reading headers that's in "What can I do to stop spam emails?" And there are other duplications of that sort in the FAQ... I think it probably grew over time, but as stuff got slotted into the document, no deconfliction and reconciliation ever took place. I think that work to do that would strengthen the document and make it considerably stronger. Regards, Joe

7 6

[Moderated]
by Moderated 13 Dec '11

13 Dec '11

This message has been removed from the archive.

1 0

[Moderated]
by Moderated 12 Dec '11

12 Dec '11

This message has been removed from the archive.

1 0

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by chrish＠consol.net 08 Dec '11

08 Dec '11

Hi! [...] > but business rules will require it to be [...] I didn't find any "business rules" document at RIPE. >From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target. Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;) [though not explicitly stated, the following seems to be meant as justification of the proposal] > Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred. When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all. In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!? But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation... Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue. Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say) Regards, Chris

4 6

Call for participation in IETF WG on abuse reporting
by Alessandro Vesely 08 Dec '11

08 Dec '11

The MARF WG http://datatracker.ietf.org/wg/marf/ issued RFC 5965 for the abuse reporting format (ARF). RFC 6449, Complaint Feedback Loop Operational Recommendations, is an informational document that originated in MAAWG. The activity of MARF WG recently decreased and it apparently needs to get invigorated with the participation of newcomers who are willing to devolve their interest and experience in abuse reporting to the community. If that's your case, please review one or more drafts in that page and post comments on the MARF mailing list. In particular, draft-ietf-marf-reporting-discovery is an alternative to whois lookups, while draft-ietf-marf-as is an application statement for RFC 6449, which may modify or complement any operational recommendation contained therein, e.g. by merging in draft-vesely-marf-abuse-reporting. The participation called for here is an occasion to standardize how abuse reporting is to be done, thereby complementing the work carried out by this WG and ACM-TF. TIA

1 0