Hi all,
I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful.
Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list?
Matt
On Mon, September 28, 2020 5:04 pm, Matt Corallo wrote:
Hi all,
I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful.
Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list?
I believe you should bring this question to the mailops and/or SDLU mailing lists. It's contentious to start blocking people who are trying to do the right thing or who have even built collective services (sourced from more than just one operator) around doing so, but your experience is an important one to take into consideration. Certainly the abuse of abuse desks is something that larger organizations know all too well and overall it actually decreases the effectiveness of fighting spam and other abuse.
Different folks have different views on abuse reports, and that's perfectly OK. But "taking it up with list XYZ" isn't going to change that (see discussion on NANOG a few months ago on this very topic =D) - people are always going to have their own views on who's responsibility it is to solve "abuse" (under their current definition). My personal abuse policy is "I reach try to help you, but if you keep sending the same automated stuff over and over and don't reply when I reach out, I drop your mails". I figure there are several Tor exit node operators with similar policies and collaborating on such blocklists would save all of us with similar policies time.
Matt
On 9/28/20 2:18 PM, Tortilla wrote:
On Mon, September 28, 2020 5:04 pm, Matt Corallo wrote:
Hi all,
I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful.
Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list?
I believe you should bring this question to the mailops and/or SDLU mailing lists. It's contentious to start blocking people who are trying to do the right thing or who have even built collective services (sourced from more than just one operator) around doing so, but your experience is an important one to take into consideration. Certainly the abuse of abuse desks is something that larger organizations know all too well and overall it actually decreases the effectiveness of fighting spam and other abuse.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 9/28/20 1:54 PM, Matt Corallo wrote:
Different folks have different views on abuse reports, and that's perfectly OK. But "taking it up with list XYZ" isn't going to change that (see discussion on NANOG a few months ago on this very topic =D) - people are always going to have their own views on who's responsibility it is to solve "abuse" (under their current definition). My personal abuse policy is "I reach try to help you, but if you keep sending the same automated stuff over and over and don't reply when I reach out, I drop your mails". I figure there are several Tor exit node operators with similar policies and collaborating on such blocklists would save all of us with similar policies time.
Absolutely. I suspect the problem is ideological. The abuse resolution camp seems to be largely subscribe to the "force ISPs to identify abusers and ban them" model. They do not want to hear about mitigation strategies or alternatives, other than their banhammer and abuse notice spamming approaches. Making a banlist of banhammer spammers like that is a brilliant move.
I grew so tired of my personal email sever constantly ending up in DNSRBLs for no reason (even with DKIM and SPF), that after 20 years of DIY email, I was forced to moved to paid provider.
This model is broken, its assumptions are contrary to our values, and it serves to support the business interests of tech oligarchs that believe that the world should be run by a handful of oligarchical ISPs and email providers, with government-issued identity for all.
Fuck that.
Good luck, Matt! Thanks for being awesome!
P.S. Your mails ended up in my provider's spam filter. Dug them out for great justice ;)
On 9/28/20 1:54 PM, Matt Corallo wrote:
Different folks have different views on abuse reports, and that's perfectly OK. But "taking it up with list XYZ" isn't going to change that (see discussion on NANOG a few months ago on this very topic =D) - people are always going to have their own views on who's responsibility it is to solve "abuse" (under their current definition).
What are you defining it as here? I can't see that there is going to be much disagreement that abuse such as what these reports are probably about can only be solved at the hosting provider or ISP level where it originates. No one else has the ability to do anything about it. The problem you are identifying is that there are a lot of over-zealous or poorly written automated scripts that like to notify abuse sources without much intelligence in regard to rate limiting or response handling, etc. I think if you create a thoughtful message to include in your rejection text, it is absolutely within reason to try and let them know that they are becoming part of the problem if they don't engage with you.
Of course, it's important to note in this context that there's still a lot of education that has to happen about what Tor is and/or reminding operators of those automated systems that they should skip Tor relays.
My personal abuse policy is "I reach try to help you, but if you keep sending the same automated stuff over and over and don't reply when I reach out, I drop your mails".
It's hard to create a globally applicable blocklist for something like this of any size, since by definition, you have to try to work with them manually before adding anyone to the list. I certainly don't blame you for keeping and sharing such a list, though.
On Fri, October 9, 2020 7:13 pm, Mike Perry wrote:
Absolutely. I suspect the problem is ideological. The abuse resolution camp seems to be largely subscribe to the "force ISPs to identify abusers and ban them" model. They do not want to hear about mitigation strategies or alternatives, other than their banhammer and abuse notice spamming approaches. Making a banlist of banhammer spammers like that is a brilliant move.
What is this problematic ideology you are pointing out? What is your alternative? Why do you think it's so terrible to alert ISPs and hosting providers about abuse originating from their systems? I find those alerts immensely helpful as opposed to finding out some time later that a system I manage is on some RBL or other block list. Not that many want to share their intelligence gathering (especially spamtrap data), so getting alerts can be highly valuable and quite welcome to a lot of operators.
Just because there are some systems that send out notices relentlessly with poor rate limiting and no knowledge of Tor relays/exits does not mean the model itself is wrong-headed. It just means some people wrote some naive notification systems (and as Matt found, they may be poor at actual engagement or do not provide a means to opt out). ISPs and hosting providers can and should be notified about abuse activity and they should be held responsible for shutting down abusive actors on their networks. Whether or not the recipient of the abuse mitigates its effects is beside the point.
I grew so tired of my personal email sever constantly ending up in DNSRBLs for no reason (even with DKIM and SPF), that after 20 years of DIY email, I was forced to moved to paid provider.
I hear personal frustration rather than pointing out any problem. Keeping an email server clear of RBLs is real work, but also not that hard if you try (make sure you aren't renting in a cheap neighborhood where spammers are allowed to flourish, don't run it on the same IP as a Tor node (especially if you exit port 25), enforce good password policy, rate limit or monitor your outgoing mail flow, etc.). I doubt anyone "forced" you... rather, you didn't have the expertise or time and felt the tradeoff was worth paying someone else to take on that work.
This model is broken, its assumptions are contrary to our values
What, that abuse should never be pointed out and we "just deal with it" and let it proliferate? Are "our values" that everyone should have perfectly hardened systems against all possible forms of attack and ignore all responsibility of the originating side... because anyone should be free to do what they want with their device on the network??
Tor is of great value, but you have to see that it is in a unique position and that the standard Tor operator's response of "it didn't originate here and I don't know where it did, so no one can help you with this" is a bitter pill to swallow for people who are trying to chase down abusive actors. That's the way it is - a trade-off we have to accept for a certain freedom and anonymity on the net, but you are conflating ill-informed and ill-constructed notification bots acting on Tor nodes (and your unfortunate experience trying to run a mail server?) with a good and necessary model for use on the clearnet.
and it serves to support the business interests of tech oligarchs that believe that the world should be run by a handful of oligarchical ISPs and email providers, with government-issued identity for all.
This conclusion is quite a reach.
In the Tor world, abuse talk is usually centered on education for the reporting party that the source isn't where they think it is. That is going to be an ongoing battle. But because everyone running a Tor node gets to throw up their hands at the abuse reports and pass the buck does not at all mean tracking down abuse is a poor endeavor. Of course, if everyone fixed their DNS servers, amplification attacks would be a thing of the past. If everyone had better security chops in general, you wouldn't have so many easily cracked abuse sources. But the reality is that there is a variety of experience level for operators on the net and a lot of vulnerable systems... unfortunately, those people are going to need help, and prodding them or blocklisting them is one of the most effective ways to get their attention. If your clearnet service keeps ending up on blocklists, the best conclusion is that maybe you are in the wrong line of work rather than griping about blocklist operators.
No one should argue that certain notifying parties shouldn't make themselves more Tor-aware or provide better engagement, rate limiting or opt-out mechanisms. But it's hard to hear personal annoyance be leveraged to conclude that fighting abuse is not a necessary endeavor. Abuse at any level, be it attacks against Tor's anonymity or abuse carried out over Tor network and sucking up relay operators' resources or the myriad of attacks on the clearnet are a major headache for everyone. Operators who are unaware of its existence on their systems deserve (and often desire) notification of such.
My ISP (Hurricane Electric) forwards me support tickets with abuse emails they receive, and asks that I respond to their ticket with information so they can show that they did their duty as an ISP in informing me.
Because I typically get floods of this abuse-SPAM from only a few dedicated companies, I created procmail rules to autorespond to my ISP (so they can close their ticket as requested) and CC the sender of that junk every single time. I'm sure my email to them goes into a black hole, but their email to me goes into one as well, so it's just robots emailing robots. A waste of resources, but at least no longer a waste of my time.
--------- procmailrc rule ----------- :0 B: * antipiracy@p2p.opsecsecurity.com | (formail -r \ -A "Cc: antipiracy@p2p.opsecsecurity.com" \ -A "X-Loop: tor-abuse@MYDOMAIN" \ cat /home/tormail/.procmail/opsecsecurity-autoresponse ) | $SENDMAIL -t -oi -------------------------------------
-------- text content --------- Hello;
I am the operator of the server using the IP in question. That server is a Tor exit node, and keeps no records of who is using it for any particular purpose or connection. More information is available at http://74.82.47.194/
I recommend you obtain the official list of Tor nodes ( https://dist.torproject.org/tordnsel/) and use them to filter automated notices in the future, or to block exits from accesing whatever content you'd like accessed via automated ingestion of firewall rules. -------------------------------------
On Mon, Oct 12, 2020 at 1:35 AM Tortilla tortilla@mantablue.com wrote:
On 9/28/20 1:54 PM, Matt Corallo wrote:
Different folks have different views on abuse reports, and that's perfectly OK. But "taking it up with list XYZ" isn't going to change that (see discussion on NANOG a few months ago on this very topic =D) - people are always going to have their own views on who's responsibility it is to solve "abuse" (under their current definition).
What are you defining it as here? I can't see that there is going to be much disagreement that abuse such as what these reports are probably about can only be solved at the hosting provider or ISP level where it originates. No one else has the ability to do anything about it. The problem you are identifying is that there are a lot of over-zealous or poorly written automated scripts that like to notify abuse sources without much intelligence in regard to rate limiting or response handling, etc. I think if you create a thoughtful message to include in your rejection text, it is absolutely within reason to try and let them know that they are becoming part of the problem if they don't engage with you.
Of course, it's important to note in this context that there's still a lot of education that has to happen about what Tor is and/or reminding operators of those automated systems that they should skip Tor relays.
My personal abuse policy is "I reach try to help you, but if you keep sending the same automated stuff over and over and don't reply when I reach out, I drop your mails".
It's hard to create a globally applicable blocklist for something like this of any size, since by definition, you have to try to work with them manually before adding anyone to the list. I certainly don't blame you for keeping and sharing such a list, though.
On Fri, October 9, 2020 7:13 pm, Mike Perry wrote:
Absolutely. I suspect the problem is ideological. The abuse resolution camp seems to be largely subscribe to the "force ISPs to identify abusers and ban them" model. They do not want to hear about mitigation strategies or alternatives, other than their banhammer and abuse notice spamming approaches. Making a banlist of banhammer spammers like that is a brilliant move.
What is this problematic ideology you are pointing out? What is your alternative? Why do you think it's so terrible to alert ISPs and hosting providers about abuse originating from their systems? I find those alerts immensely helpful as opposed to finding out some time later that a system I manage is on some RBL or other block list. Not that many want to share their intelligence gathering (especially spamtrap data), so getting alerts can be highly valuable and quite welcome to a lot of operators.
Just because there are some systems that send out notices relentlessly with poor rate limiting and no knowledge of Tor relays/exits does not mean the model itself is wrong-headed. It just means some people wrote some naive notification systems (and as Matt found, they may be poor at actual engagement or do not provide a means to opt out). ISPs and hosting providers can and should be notified about abuse activity and they should be held responsible for shutting down abusive actors on their networks. Whether or not the recipient of the abuse mitigates its effects is beside the point.
I grew so tired of my personal email sever constantly ending up in DNSRBLs for no reason (even with DKIM and SPF), that after 20 years of DIY email, I was forced to moved to paid provider.
I hear personal frustration rather than pointing out any problem. Keeping an email server clear of RBLs is real work, but also not that hard if you try (make sure you aren't renting in a cheap neighborhood where spammers are allowed to flourish, don't run it on the same IP as a Tor node (especially if you exit port 25), enforce good password policy, rate limit or monitor your outgoing mail flow, etc.). I doubt anyone "forced" you... rather, you didn't have the expertise or time and felt the tradeoff was worth paying someone else to take on that work.
This model is broken, its assumptions are contrary to our values
What, that abuse should never be pointed out and we "just deal with it" and let it proliferate? Are "our values" that everyone should have perfectly hardened systems against all possible forms of attack and ignore all responsibility of the originating side... because anyone should be free to do what they want with their device on the network??
Tor is of great value, but you have to see that it is in a unique position and that the standard Tor operator's response of "it didn't originate here and I don't know where it did, so no one can help you with this" is a bitter pill to swallow for people who are trying to chase down abusive actors. That's the way it is - a trade-off we have to accept for a certain freedom and anonymity on the net, but you are conflating ill-informed and ill-constructed notification bots acting on Tor nodes (and your unfortunate experience trying to run a mail server?) with a good and necessary model for use on the clearnet.
and it serves to support the business interests of tech oligarchs that believe that the world should be run by a handful of oligarchical ISPs and email providers, with government-issued identity for all.
This conclusion is quite a reach.
In the Tor world, abuse talk is usually centered on education for the reporting party that the source isn't where they think it is. That is going to be an ongoing battle. But because everyone running a Tor node gets to throw up their hands at the abuse reports and pass the buck does not at all mean tracking down abuse is a poor endeavor. Of course, if everyone fixed their DNS servers, amplification attacks would be a thing of the past. If everyone had better security chops in general, you wouldn't have so many easily cracked abuse sources. But the reality is that there is a variety of experience level for operators on the net and a lot of vulnerable systems... unfortunately, those people are going to need help, and prodding them or blocklisting them is one of the most effective ways to get their attention. If your clearnet service keeps ending up on blocklists, the best conclusion is that maybe you are in the wrong line of work rather than griping about blocklist operators.
No one should argue that certain notifying parties shouldn't make themselves more Tor-aware or provide better engagement, rate limiting or opt-out mechanisms. But it's hard to hear personal annoyance be leveraged to conclude that fighting abuse is not a necessary endeavor. Abuse at any level, be it attacks against Tor's anonymity or abuse carried out over Tor network and sucking up relay operators' resources or the myriad of attacks on the clearnet are a major headache for everyone. Operators who are unaware of its existence on their systems deserve (and often desire) notification of such.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
A few replies inline, but, in general, I only run two small exits, so the level of effort and amount of spam I get is very low (my blocklist currently only has three entries :) ). If any other exit operators have a similar "I try to help educate you, if you don't bother responding I'll start dropping your emails" policies, I'm happy to figure out a way to grow this, but for now I'll note that probably want to just blackhole anything from autogenerated@blocklist.de :).
Matt
On 10/11/20 4:28 AM, Tortilla wrote: - snip -
Of course, it's important to note in this context that there's still a lot of education that has to happen about what Tor is and/or reminding operators of those automated systems that they should skip Tor relays.
- snip -
It's hard to create a globally applicable blocklist for something like this of any size, since by definition, you have to try to work with them manually before adding anyone to the list. I certainly don't blame you for keeping and sharing such a list, though.
Right, I don't run large exits currently, only a few 10s of Mbps, so I can tolerate a few minutes of work responding each time and adding to the blocklist after a few failed responses :).
- snip -
I hear personal frustration rather than pointing out any problem. Keeping an email server clear of RBLs is real work, but also not that hard if you
Ironic that my mail landed in a spam folder given its from a server on a /24 that doesn't host much else and that I personally own, has never sent spam, and is not on any RBLs. EMail is broken, this shouldn't be news.
Matt
tor-relays@lists.torproject.org
-
AMuse -
Matt Corallo -
Mike Perry -
Tortilla