Draft Anti-Abuse Working Group Minutes - RIPE 60
Colleagues, Apologies for the delay in circulating these minutes for your consideration. Thanks, Brian. ------------------------- Draft Anti-Abuse Working Group Minutes - RIPE 60 Thursday, 6 May 2010, 16:00 – Prague Marriott Hotel, Czech Republic Co-Chairs: Brian Nisbet, Richard Cox Scribe: Fergal Cunningham Jabber: Emile Aben A. Administrative Matters Working Group Co-Chair Brian Nisbet opened the session at 16:00 and welcomed attendees. The minutes from RIPE 59 were approved without comment. B Update B1. Network Abuse Update - Richard Cox Working Group Co-Chair Richard Cox gave an update on current abuse trends and recent relevant technical developments. He started by differentiating between cybercrime and abuse, both of which he said come within the scope of the Anti-Abuse Working Group but which need to be treated differently. He began by talking about snow shoe spam, which rotates the IP address of sent mail through up to a /20 or /19, and is being carried out by a small number of US-based organisations that are active in Europe. He explained that this type of spam is causing big problems at the moment because it has so far managed to avoid detection. He said there was a new detector for this type of spam at Spamhaus but he thought it would eventually find a way around this. Moving on to abuse, Richard talked mainly about domain abuse, where domains are registered using fake credit cards and malware is then transmitted through those domains. He said through use of this malware, which employs keyloggers, the criminals can transfer money to their accounts and because it comes from the user’s standard IP address it does not appear to the banks to be a fraudulent transaction. He mentioned that one problem is that police tend to pass responsibility for this type of crime to the banks. Richard mentioned the problem of IPv6 and traceability, which he said was not too visible yet but it would be and is the type of problem that will affect other working groups, such as the Address Policy and Database Working Groups. He concluded by talking about the UK-specific problem of large organisations and their customer bases being sold from one company to another without providing any precautions regarding the latest exploits. There were no questions and Brian thanked Richard for his update. B2. Recent List Discussion - Abuse contacts, Sanctions, etc. Brian started by mentioning the recent discussion on the Anti-Abuse mailing list, initiated by Frank Gadegast in April 2010, concerning implementation of an abuse monitor system. Brian explained that the proposal was to be able to mail an email address based on an abusive IP address, which would then be passed through a clearing house to the relevant LIR or IP holder. Brian said there was no formal policy proposed on this and there did not seem to be much support for it on the mailing list. Brian said they would wait for comments or further proposals on the mailing list. Brian said the second item to be discussed was from Tobias Knecht, Abusix, on an abuse contact information policy proposal. Brian said that the proposal is to introduce a mandatory reference to IRT objects in the inetnum, inet6num and aut-num objects in the RIPE Whois Database to provide a more accurate and efficient way for abuse reports to reach the correct network contact and help reporting institutions to find the correct abuse contact information more easily. Brian explained that the proposal was sent to the list and is a copy of proposals sent to AfriNIC and APNIC. He said the plan was to work with Tobias on creating a formal RIPE proposal but he would like to gather responses from the room before doing so. Niall O’Reilly, University College Dublin, said that discussion on irrelevant references in such objects took place some years ago and it would be a good idea to look at these discussions so as not to cover old ground. Brian agreed that this was a good idea and he would compile the relevant sections of the older discussions and post them to the list. Peter Koch, DENIC, agreed with Niall and asked if there were some restrictions on getting an irt object in the RIPE Database. Wilfried Woeber, Vienna University, said there were restrictions but these were removed a long time ago. Brian said another topic that came up on the mailing list was sanctions on people who abused networks. He said that Jochem de Ruig from the RIPE NCC would present on this later in the session that would address this area. Brian said that at this point it was worth mentioning that there was no big red button that anyone can press to legally remove someone from the Internet. Brian concluded by reminding people that this Anti-Abuse Working Group has replaced the Anti-Spam Working Group. He said this was to widen the focus of the working group. C. Technical Measures C1. RIPE NCC Tools update - Paul Palse, RIPE NCC Paul’s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Palse-RIPE_Labs_-_Th... Paul’s presentation included a live demonstration of the prototype Abuse Finder tool, which is available on RIPE Labs at: http://labs.ripe.net/content/abuse-finder Paul asked for feedback on the tool and looked for questions. Co-Chair Richard Cox thanked Paul and asked said there is a need to find out exactly what investigators are looking for and tune the system accordingly so they can get answers quickly. He suggested talking about this and perhaps involving APNIC so a universal system can be developed that will provide the answers needed by investigators. He said one question asked if he had a problem with a resource, could the tool return results for resources with similar attributes that might be causing problems. Paul said the RIPE NCC could definitely look at that and try to improve the system based on this type of extremely helpful feedback. Richard said, as an example, he could look at announced ASN numbers but not see what is assigned, and this would be very helpful. He also suggested that if you found a certain maintainer, it would be useful to see what else that maintainer was maintaining. Wilfried Woeber said it would be useful to have a discussion about this on RIPE Labs, because this is what RIPE Labs is for and people could suggest a number of similar ideas to improve the tool. Wilfried said the tool sounds like a freetext search across all data in the database. He said he was not convinced it was a good idea to offer something like that publicly. He also said that 80% to 90% of what you want to do is available already through methods such as inverse lookups, but the problem lies in combining query X with query X+1. Paul said this was basically what the tool did. Denis Walker from the RIPE NCC commented that the Database Group in the RIPE NCC could run a script for whatever needed to be found. He said that if users told them what they wanted to find and gave use cases, then the Database Group could write a script that return exactly what they want. Brian supported this and asked that people come to the Anti-Abuse Working Group with examples of what they would like to see. Niall O’Reilly said the beauty of a RESTful wrapper is that you can make a single query of anything in whatever way you wish. Paul said the Abuse Finder tool has a bit more to it and can present material in a very concise way. D. Interactions D1. Working Groups Brian noted that the interactions with other working groups are covered by other agenda items in this session. Brian also noted that all law enforcement interaction and cooperation would now reside in the Anti-Abuse Working Group rather than the Cooperation Working Group, where such interactions originated. D2. RIPE NCC LEA Interactions Update - Jochem de Ruig, RIPE NCC Jochem’s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/De_Ruig-RIPE_NCC_and... There were no questions. D3. Law Enforcement Interaction - Wout de Natris, London Action Plan Wout’s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/deNatris-Industry-LE... Brian reiterated that the Anti-Abuse Working Group would be the channel for communication between LEAs and the RIPE community. He said this interaction could take place on the mailing list and at future RIPE Meetings, or people could contact himself or Richard. A member of the Serious Organised Crime Agency in the UK said that revocation is one of the major issues for law enforcement agencies. He added that a major part of this was the question of how to stop the routing of revoked resources. Brian said there was some discussion in the Address Policy Working Group about certified routing and revocation of certificates. He said that at the moment there was no real way to stop routing in this way because people route what they want to route. Wilfried Woeber said that interfering with the routing layer could have an impact on completely unrelated parties across the globe. He asked law enforcement representatives to be aware that if you have a mechanism for removing people from the Internet, it will be used to do so for political purposes. He said it was difficult to determine right and wrong in this situation because right and wrong can mean different things in different places. RIPE Chair Rob Blokzijl wanted to bring attention to Geoff Huston of APNIC’s presentation earlier in the week on measuring traffic on the Internet from network number 1. Rob said this network has never been announced but there is a huge amount of traffic on the Internet claiming to come from that network. He said that removing an address block from the registry would not stop anything, so it would be more profitable to think about actions that would help. He said he would be reluctant to have a mechanism that allows third parties tell the RIPE community what they can register and what they can’t. He concluded that law enforcement should be concerned with having the best registry data possible available. Richard Cox said it can be very difficult to identify the origin of a packet that caused harm on the Internet, so the important thing is to identify who contributed to the harm. He said there needs to be a mechanism to identify what problems are associated with a particular routing and get that information to people who are handling the traffic. He said the community can then decide to accept a route or not, and if 90% of the Internet decides not to accept a route then its harm will be limited. He concluded by reminding people that it is better to regulate yourself before government steps in to do it for you. X. AOB Alex le Heux from the Registration Services Department in the RIPE NCC outlined a proposal about address space reclaimed by the RIPE NCC. He said after an appropriate quarantine period the address space is re-allocated, but it might previously have been used by people who were not the best Internet citizens and the resources are on anti-abuse and anti-spam lists across the Internet. He explained that these addresses go back into the free pool after the quarantine period but the people who receive them can be unhappy they are not receiving brand new addresses, and replacing the addresses with new ones does not really solve the problem. He said this problem would only get worse as the last phase of RIPE Policy Proposal 2007-01 approached. He proposed that during the quarantine period, which typically lasts three months, the addresses could be published so that anti-spam groups could remove them from their lists. He asked the community to give feedback on this proposal. Richard Cox said Spamhaus has been arguing for something like this for some time. He said people operating anti-abuse lists take the view that if people are working towards solving a problem like this, then it is sensible to try to help them. He suggested creating an RFC that will define a standard by which the information can be published by all the RIRs on a standard webpage within their website that can be downloaded by those maintaining the anti-abuse lists. He said this could be used to reset the status of resources on a regular basis. He said there just needs to be an assurance that the resources are not handed back and then reclaimed by the same organisation, which is happening in some cases at the moment. Alex said that the RIPE NCC does not allow people to come in and choose the address space they want. Brian said it would be good for the RIPE NCC and other RIRs to publish such information with the caveats that Richard mentions. Rob Blokzijl said he was talking about this issue with John Curran, CEO of ARIN, about this specific problem. Rob said ARIN has procedures in place and he recommended that Alex look at these. He said it would also be good if all RIRs have the same procedure in place so the anti-abuse lists would be more up to date with reality. Carsten Scheifner, DENIC, said perhaps that list already exists through the RIPE Database and by doing an indirect search on unallocated space. Alex replied that the proposal applies to address space that was allocated and then reclaimed and which is waiting to be allocated to someone else. He said it was possible to do as Carsten suggested and look for holes in the database but this proposal might be an easier way to accomplish the same thing. Peter Koch, DENIC, said if the RIPE NCC uses a white list to override blacklists then that sounds fishy. He asked if it was possible that it would be a case of asking anti-abuse groups to do the same thing as those groups who take multiple addresses from the database. He asked who would be the target audience. Alex said groups like Spamhaus would be the target audience. He said the proposed list would make the assertion that the addresses were in use by someone else previously and will be used by someone else in the future. Paul Vixie, ARIN Board of Trustees, said there is a lot of space mentioned on black hole operator lists and he said this space is like toxic waste and there can only be clean-up efforts if there is no revolving door whereby the people who created the toxic waste cannot simply get another block of resources they can contaminate. He said many black list operators would say this is the RIPE NCC’s fault and it should resolve this. Brian said this issue is to do with reclamation and clean-up, and this proposal aims to make it easier to do that and to make best use of the remaining IPv4 address space rather than solve all problems. Richard Cox said, in response to the assertion from Peter Koch, that it takes a lot of time to conduct a clean-up. He said an RFC-defined list at a designated place would be a big help. He said there needs to be agreement, including among RIRs, and there are certain definitions that need to apply. He said people cause abuse of address space and the RIPE NCC has to ask if it is right to allocate space in certain situations to certain LIRs. Alex said he would talk to the relevant parties as soon as possible. Richard Cox presented two proposals that he said would inevitably be discussed on the working group mailing list. He said that RIPE needs to make some changes to make it less easy for cybercriminals who specifically come to RIPE because they see RIPE as more of a pushover than ARIN. Richard’s first proposal was to ask the DB WG to make available in the RIPE Database two additional fields so that a standard query with no switches will get data on the LIR that assigned a block and data on the most recent change of that block. He said for good reasons the existing fields cannot be altered so the date of change would need to go out under a different object to avoid breaking anything that currently exists. He said providing the LIR data would allow investigators to see patterns, and if the data is available in the RIPE Database, people will know immediately who to go to resolve a problem. Richard’s second proposal suggestion was on allocations. He asked if the process in the RIPE NCC is optimal for dealing with problems and he asked that the RIPE NCC make provision for dealing faster with allocation problems. He said it would be helpful if there was a published RIPE NCC address that people could use when people get a dodgy allocation. He suggested a small group of people from community could work on this under a non-disclosure agreement (NDA). Wilfried asked Richard to elaborate on the NDA aspect of this because he wasn’t sure if the NDAs were suitable for the RIPE environment. Brian said the proposals were not fully formed yet. He asked Richard to write them up and bring them to the mailing list, and he asked the community to comment on them when they were posted to help make them fully formed proposals. There was no further business. Brian thanked the presenters and the attendees and said he hoped to see everyone at the next Anti-Abuse Working Group session in Rome in November 2010. The session adjourned at 17:47. A full recording of this Anti-Abuse Working Group session is available at: http://rosie-arch.ncc.ripe.net/webcast/ripe-60/mp3/Anti-Abuse-WG.mp3
Hi all,
Draft Anti-Abuse Working Group Minutes - RIPE 60
Brian said there was some discussion in the Address Policy Working Group about certified routing and revocation of certificates. He said that at the moment there was no real way to stop routing in this way because people route what they want to route.
This might be true, but removing networks from RIPEs databased will also remove all reverse mapping and nameserver entries, right ? No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping. So, if RIPE ever wants to punish network abusers, thats an easy way of doing it ... Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Brian said there was some discussion in the Address Policy Working Group about certified routing and revocation of certificates. He said that at the moment there was no real way to stop routing in this way because people route what they want to route.
This might be true, but removing networks from RIPEs databases will also remove all reverse mapping and nameserver entries, right?
It certainly should.
No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping. So, if RIPE ever wants to punish network abusers, thats an easy way of doing it
RIPE has no role to punish network abusers. RIPE should have a role to take appropriate action against those who abuse RIPE's resources. That would include providing false identity or configuration details in connection with a request for network resources. Those are the cases where revocation of those resources is needed - and of course the routing data would then have to be removed as a result. What is worth bearing in mind is that a revoked allocation should show up in IP-WHOIS as REVOKED for a given period of time after revocation. Otherwise we get the vexing situation where an abuser asks an ISP to route his IP block and tells the ISP, when they check RIPE's WHOIS and see "not found", "Oh dear, looks like the RIPE database isn't working. "Revoked" must be clearly visible. For example, nobody really knows why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET in Moldova and bringing you all the lovely Zeus malware and similar. Network Next Hop Path *> 193.109.246.0/23 208.74.64.40 3257 31252 43074 i Unfortunately removing rDNS etc won't stop that malware spreading. -- Richard
On 9 Aug 2010, at 4:19, Richard Cox wrote: [...]
What is worth bearing in mind is that a revoked allocation should show up in IP-WHOIS as REVOKED for a given period of time after revocation. Otherwise we get the vexing situation where an abuser asks an ISP to route his IP block and tells the ISP, when they check RIPE's WHOIS and see "not found", "Oh dear, looks like the RIPE database isn't working.
"Revoked" must be clearly visible.
I disagree. I do not think the registry should publish a comment on why a registration exists or does not exist and the word REVOKED is clearly intended to imply that the registration was removed against the desires of the registrant. Publishing a registration (a positive act) but giving it a negative status is likely to cause confusion, especially with automated network-centric systems that ignore the status attribute value. I also think the example you give is unrealistic. If the ISP can see its own object and a bunch of other objects then the problem is unlikely to be that to be that the whois database is broken. And if they were genuinely concerned about a problem with the database they could always contact the RIPE NCC. If some kind of mechanism is needed to allow network operators to check that a prefix is not currently registered, then we should ask the RIPE NCC to publish an easy to parse list of prefixes and the date on which they were removed from the database. Presumably a prefix would remain on the list until it had completed any quarantine period and is ready to be re-issued. Regards, Leo Vegoda
Leo Vegoda <leo.vegoda@icann.org> wrote
"Revoked" must be clearly visible.
I disagree. I do not think the registry should publish a comment on why a registration exists or does not exist and the word REVOKED is clearly intended to imply that the registration was removed against the desires of the registrant.
On those - increasing number of - occasions when an RIR discovers that information it was given in support of a registration, was untruthful or invalid then it seems to me entirely reasonable that the RIR should make it clear that what it had previously published, should not be relied upon.
Publishing a registration (a positive act) but giving it a negative status is likely to cause confusion, especially with automated network-centric systems that ignore the status attribute value.
There will surely be technical solutions to that technical problem.
I also think the example you give is unrealistic. If the ISP can see its own object and a bunch of other objects then the problem is unlikely to be that to be that the whois database is broken.
It's very realistic. Nobody would be suggesting that the "whole database is broken". What would be suggested is that some records are missing or the database has not been updated. That would not necessarily affect the records of the ISP querying the database, as its own record would probably be significantly older.
If some kind of mechanism is needed to allow network operators to check that a prefix is not currently registered, then we should ask the RIPE NCC to publish an easy to parse list of prefixes and the date on which they were removed from the database. Presumably a prefix would remain on the list until it had completed any quarantine period and is ready to be re-issued.
We have been asking for exactly that for some years now, partly to allow reputational records to be reset as and when an allocation is recovered. -- Richard
* Richard Cox:
It's very realistic. Nobody would be suggesting that the "whole database is broken". What would be suggested is that some records are missing or the database has not been updated.
And I think not all RIRs run route registries, so there are cases where no reliable documentation for the prefix can be found, yet an announcement would still be legitimate. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 10 Aug 2010, at 3:44, Richard Cox wrote: Leo Vegoda <leo.vegoda@icann.org> wrote
"Revoked" must be clearly visible.
I disagree. I do not think the registry should publish a comment on why a registration exists or does not exist and the word REVOKED is clearly intended to imply that the registration was removed against the desires of the registrant.
On those - increasing number of - occasions when an RIR discovers that information it was given in support of a registration, was untruthful or invalid then it seems to me entirely reasonable that the RIR should make it clear that what it had previously published, should not be relied upon.
Publishing a registration (a positive act) but giving it a negative status is likely to cause confusion, especially with automated network-centric systems that ignore the status attribute value.
There will surely be technical solutions to that technical problem.
Why create a technical problem just so that you can create a technical solution? The actual problem is social and I suggest that that is where you should focus solutions.
I also think the example you give is unrealistic. If the ISP can see its own object and a bunch of other objects then the problem is unlikely to be that to be that the whois database is broken.
It's very realistic. Nobody would be suggesting that the "whole database is broken". What would be suggested is that some records are missing or the database has not been updated. That would not necessarily affect the records of the ISP querying the database, as its own record would probably be significantly older.
Here and above you seem to be arguing two things: firstly, that the RIPE NCC's procedures or staff are considered so error prone that the removal of a registration from the database would automatically be assumed to be a mistake, rather than intentional. That seems unlikely to me but maybe I have missed the hollering and alarm at the frequent reports of errors. Secondly, you seem to believe that the RIPE NCC should not just maintain a registry of what is but should also annotate the registry with commentary about the organisations whose data are published there. I recognise that there is a group of people who abuse the system. However, I think that commentary about that group should be confined to communication between them and the RIPE NCC and if necessary the courtroom. I do not believe it is appropriate for the RIPE NCC to publish reasons for its actions in the database. In fact, I believe that to do so would breach the current IPv4 policy: 3.1 Confidentiality Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality. I should probably also point out that this is a requirement of section 10 of ICP-2, too: http://www.icann.org/en/icp/icp-2.htm Of course, policy can be changed but I am not convinced that I have seen a convincing case to change the current policy yet.
If some kind of mechanism is needed to allow network operators to check that a prefix is not currently registered, then we should ask the RIPE NCC to publish an easy to parse list of prefixes and the date on which they were removed from the database. Presumably a prefix would remain on the list until it had completed any quarantine period and is ready to be re-issued.
We have been asking for exactly that for some years now, partly to allow reputational records to be reset as and when an allocation is recovered.
Has the RIPE NCC responded to these requests? If so, what has it said? Regards, Leo Vegoda
Richard Cox wrote:
RIPE has no role to punish network abusers. RIPE should have a role to take appropriate action against those who abuse RIPE's resources. That would include providing false identity or configuration details in connection with a request for network resources. Those are the cases where revocation of those resources is needed - and of course the routing data would then have to be removed as a result.
And there we are again. If we do not extend RIPEs responsibility and the RIPE regulations so that the members are responsible for using RIPE resources without abuse and RIPE NCC has therefor no responsibility to monitor abuse, there will be no revocation. And because we will never have a definition of abuse, there will be no change in the regulations and no demand to RIPE NCC handle this. Conclusion: because RIPEs members are not willing to take responsibility and abuse will continue forever. And we only can work here to make protection easier for those, who want to do something for themselv. But thats only a cure, not a solution ...
What is worth bearing in mind is that a revoked allocation should show up in IP-WHOIS as REVOKED for a given period of time after revocation. Otherwise we get the vexing situation where an abuser asks an ISP to route his IP block and tells the ISP, when they check RIPE's WHOIS and see "not found", "Oh dear, looks like the RIPE database isn't working.
"Revoked" must be clearly visible. For example, nobody really knows
Good idea.
why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET
Well, thats clearly a mistake of STARNET then. You should talk to them, if STARNET is one of your upstream providers. The should really filter there routes against route objects. None, of our upstream providers does route this network.
in Moldova and bringing you all the lovely Zeus malware and similar.
Network Next Hop Path *> 193.109.246.0/23 208.74.64.40 3257 31252 43074 i
Unfortunately removing rDNS etc won't stop that malware spreading.
True, but revocation of route objects does. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
frank@powerweb.de wrote:
Conclusion: because RIPEs members are not willing to take responsibility and abuse will continue forever.
We don't know what the members think, or are prepared to do. Sure, we are told in no uncertain terms what the NCC thinks the members think - but the members I have spoken to certainly don't think that way. So is it that the members don't effectively voice their opinions - or could it be that just one member of the NCC staff wants us all to believe that everyone thinks what he wants everyone to think?
why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET Well, thats clearly a mistake of STARNET then.
Such mistakes are often associated with appropriate revenue adjustments.
You should talk to them, if STARNET is one of your upstream providers. The should really filter there routes against route objects.
Starnet connect (to the UK) at LINX. LINX policies are clearly stated - their members can do whatever they like (as far as LINX is concerned)
Unfortunately removing rDNS etc won't stop that malware spreading. True, but revocation of route objects does.
Only for some communities. Route objects are only relevant in parts of the RIPE service region. And certainly not in North America etc. See: http://www.robtex.com/as/as31252.html -- Richard
Hi all,
Denis Walker from the RIPE NCC commented that the Database Group in the RIPE NCC could run a script for whatever needed to be found. He said that if users told them what they wanted to find and gave use cases, then the Database Group could write a script that return exactly what they want. Brian supported this and asked that people come to the Anti-Abuse Working Group with examples of what they would like to see.
"I simply want a daily dump of all networks and their abuse email address, public available via FTP for mirroring." I do not see, how these email addresses should be privat, because they are inserted into the object by effort. Network owners that do not want this published, do not put them in anyway. And making a dump is much easier than programming the finder tool any further. So please, simply dump that list containing all or just the most important email addresses(however they are found from the finder tool via the tech-c email, an abuse-field email, some email in the remarks or an IRT object) for every network daily. This will help all blacklist maintainers and all ISPs, that do fight against spam, to automate their reports without having to fight against limited whois lookup resources. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Frank Gadegast Sent: Monday, August 09, 2010 3:00 PM To: Brian Nisbet Cc: anti-abuse-wg@ripe.net
removing networks from RIPEs databased will also remove all reverse mapping and nameserver entries, right ?
No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping.
So, if RIPE ever wants to punish network abusers, thats an easy way of doing it ...
I agree that this may be a somewhat effective approach.
However, I doubt that most mail exchanges are configured in such a categorical manner. I apologise for not having any hard data to present, but my experience is that missing or dysfunctional reverse mappings often are used to increase spam scores (such as in SpamAssassin) rather
Thor Kottelin wrote: than to reject mail outright.
Thats right ... The default setting for most MTAs these days is to complain about mails from servers without any reverse mapping and to complain in a different manner about a not matching reverse mapping (at least sendmail, postfix, qmail and Exchange CAN do this). Most anti spam solutions surely raise the score, if there is no reverse mapping or if the reverse mapping does not match the hostname or HELO command. My personal experience is, that most provider do not accept email from servers without a reverse mapping but accept email from servers with a not matching reverse mapping and use this for further spam scoring. Some even put mailserver without a working reverse mapping on their blacklists ... So: its up to the server administrator to configure the final solution and thats perfect, everybody can decide what to do. A totally missing reverse mapping will surely help the receiver a lot and harm the spammer ... And removing route object will surely help even more. Most transit provider and exchange points usually generate their BGP filters from whois records and match them against customers known ASes and peering partner ASes (when accepting routes) daily. No route objects means no peering, no routing and no announcement. And transit provider or exchange points that are not working this way, have a serious security problem anyway ... All this is technically easy, the only thing missing is a discussion, who decides, what objects need to be remove and why. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Frank Gadegast said on Monday 09 August 2010 :
Thor Kottelin wrote:
removing networks from RIPEs databased will also remove all reverse mapping and nameserver entries, right ?
No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping.
So, if RIPE ever wants to punish network abusers, thats an easy way of doing it ...
I agree that this may be a somewhat effective approach.
All this is technically easy, the only thing missing is a discussion, who decides, what objects need to be remove and why.
This is the best idea that I have heard in a long time and there could be proper structures in place (similiar to spamcop) to prevent abuse Andre
andre@ox.co.za wrote:
Frank Gadegast said on Monday 09 August 2010 :
Thor Kottelin wrote:
removing networks from RIPEs databased will also remove all reverse mapping and nameserver entries, right ?
No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping.
So, if RIPE ever wants to punish network abusers, thats an easy way of doing it ...
I agree that this may be a somewhat effective approach.
All this is technically easy, the only thing missing is a discussion, who decides, what objects need to be remove and why.
This is the best idea that I have heard in a long time and there could be proper structures in place (similiar to spamcop) to prevent abuse
Even if I really want that, its nearly impossible. There are always some members, thats are not willing to restrict regulations, that are happy like it is. This can have a lot of reasons: - because their culture or country regulations do not allow that - because they want a free internet, even with free abuse - they make money with abuse (maybe even only with flooding others with mail offers or make money by selling upstream, hosting and services. I was talking to a spam solution provider lately, the most he fears, is that the RIRs are finally doing something ! you see: he is not eval himself, in fact his company is doing something really good, but he still makes money from spam) - or because they simply do not want to take care about their resources, because its work and therefor costs money We are talking about a definition of abuse for a couple of years now, without any result, because those members always find "a hair in the soup" (a saying in Germany). And you cannot change RIPEs regulations without a definition and he will to do something from the community. And RIPE NCC will never do anything thats not defined in the regulations. THATS the problem. Maybe we should make a rehersal, vote or proposal to answer a simply question: "should RIPE create regulations to remove resources because of abuse ?"
Andre
Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Maybe we should make a rehersal, vote or proposal to answer a simply question: "should RIPE create regulations to remove resources because of abuse ?"
The RIPE Policy Development Process is at your disposal. The AAWG is just as entitled to propose and agree a policy as any of the other RIPE WGs. You seem to have a lot of sympathetic ears here, so over to you. In the interests of Full Disclosure, I should mention that I will be submitting some of my own proposals very shortly (I referred to them briefly in Prague); they include providing registration- / changed-dates for IP and ASN allocations in all WHOIS responses (ie without requiring the -b switch) and also providing information in the standard WHOIS data on which LIR (if any) was involved in allocating a specific resource -- Richard
participants (7)
-
andre@ox.co.za
-
Brian Nisbet
-
Florian Weimer
-
Frank Gadegast
-
Frank Gadegast
-
Leo Vegoda
-
Richard Cox