Re: [tor-relays] DoS attacks on multiple relays

[null]

> connlimit per /24. it does more good than evil.

Any guidance on the specifics? Like how many concurrent connections to
allow per /24? Not sure what's expected from legitimate user traffic
through the relay... don't want to make things worse.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

> Hi null
>
> Am 04-Dec-17 um 20:40 schrieb null:

...

> Heavy action can be you purge them or tcpdrop(8) before they hurt. Or
> connection limit by ip per firewall.
>

connlimit per /24. it does more good than evil.

cheers

x9p

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[teor]

>> On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter  
>> wrote:
>>> On 04.12.17 11:59, James wrote:
>>> 
>>> As a private individual, after just receiving my 4th abuse complaint
>>> in as many days it's time to stop running my exit node.
>> 
>> I've had an ongoing debate with a hosting service over a fresh exit node
>> being abused for network scans (ports 80 and 443) almost hourly for the
>> last few days. I can understand that they are pissed off, and the whole
>> thing resulted in this particular exit being shut down by the hoster. If
>> I could detect and prevent these scans, it would go a long way to avoid
>> having my exit nodes shut down by hosting services.
> 
> With my exit node operator hat on, I too would like to see some sort
> of port-scanning prevention built into the network.  In my case, I had
> to turn off exiting to the SSH port because we were getting daily
> complaints about abusive scanning for devices with weak admin
> passwords.  Which is a shame, since there are plenty of legitimate
> uses for SSH-over-Tor.
> 
> The tricky part is designing some sort of exit-node-controlled
> new-connection rate limiting that's content-blind and won't interfere
> with legitimate uses.  And "legitimate uses" include things like a web
> browser generating a burst of TCP connections to the same HTTP/1.1
> server cluster, exitmap connecting to the same test server repeatedly
> via every exit node in the network, and so on.  I would want to see
> any proposal document include a long list of known non-abusive traffic
> scenarios and an argument that the mechanism would not interfere with
> each.

Previous proposals have become bogged down in the process of trying
to define "abuse".

Let's limit excessive use of scarce resources instead. It should have a
similar effect, is easily made content-neutral, and doesn't require any
agreed definition of legitimate and illegitimate uses.

Here's a quick sketch of a proposal - I would be happy to work with
others to turn it into a Tor proposal and post it to tor-dev@. Here's
what Tor proposals look like:
https://gitweb.torproject.org/torspec.git/tree/proposals

Background:

Relays currently have token buckets that limit the number of bytes
that can be sent per second. This limits relay bandwidth, but does
not limit the use of other scarce resources, like file descriptors,
TCP ports, and CPU time. (There is an existing file descriptor limit,
but it is an absolute maximum, not a rate limit.)

Proposal:

We define relay-wide token buckets for circuit and stream creation.
These token buckets are refilled on a regular basis. Every time a circuit
or stream is created, a token is removed from the bucket. When the
bucket is empty, the relay takes some action that slows down circuit or
stream creation. (This could be a delay until the next refill, a randomised
delay, or some more sophisticated exponential backoff system.)

We set these limits at default values that are unlikely to be exceeded
during normal exit usage. (This needs measurement on live exits.)

This provides operators with tools to limit excessive usage, while we work
on more fine-grained solutions.

Alternatives:

We could also define a stream limit per circuit, destination IP address, or
destination port. However, this may be a level of complexity which we
don't need. It also significantly increases the number of buckets
required to implement the scheme. And it moves away from the original
goal of limiting resource usage towards a scheme that allocates these
resources more fairly between competing circuits or destinations.
Designing a fairness scheme like this requires more research, including
more sophisticated data collection on live exits.

There are also privacy concerns inherent in storing destination IP
addresses and ports which would have to be addressed.

On 5 Dec 2017, at 06:00, Iain Learmonth  wrote:
>> On 04/12/17 18:19, Ralph Seichter wrote:
>> This is not about third party X complaining to the hoster about their
>> network being scanned. The hoster itself is automatically monitoring all
>> their machines for outgoing network scans, as these scans are prohibited
>> by their terms of use.
> 
> I do wonder how much of this is related to the scarcity of IPv4 address
> space, prevalence of reputation systems and fear of ending up being
> labeled as "bad". When we move to IPv6, perhaps hosting providers would
> be more relaxed knowing that it doesn't matter so much if a /64 or even
> a /56 ends up bad in a reputation system, because for other customers
> you have other address space.

Tor already supports exiting over IPv6, and Tor Browser prefers IPv6 by
default. Now we need Exit operators and major websites to enable IPv6.

I suspect the IP reputation space may take a few years to catch up with
IPv6 - we should take advantage of that as much as we can.

T
___
tor-relays mailing list

Re: [tor-relays] DoS attacks on multiple relays

[Felix]

Hi null

Am 04-Dec-17 um 20:40 schrieb null:
> $ ss -s
> Total: 15855 (kernel 0)
> TCP:   24520 (estab 23969, closed 305, orphaned 31, synrecv 0, timewait
> 261/0), ports 0

imho the attempts have tcp state. I experienced similar from a minor
number of non relays. It seems like you gather too many statefull connects.
The ips might not be evil.
Heavy action can be you purge them or tcpdrop(8) before they hurt. Or
connection limit by ip per firewall.

-- 
Good luck and cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Jonathan Proulx]

On Mon, Dec 04, 2017 at 02:57:25PM -0500, Jonathan Proulx wrote:

:The only reply ever required is a form letter stating this is a Tor
:exit, here's a link to how to block tor exits if that's what you want.

I recognize this doesn't help with "meta-complaints" from hosting
providers, but has worked very well with direct complaints.

-Jon
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Jonathan Proulx]

On Mon, Dec 04, 2017 at 01:55:56PM -0500, Zack Weinberg wrote:

:For the record, those daily complaints about abusive SSH scanning were
:serious reports requiring a reply.  And they were not all from the
:same source.

The only reply ever required is a form letter stating this is a Tor
exit, here's a link to how to block tor exits if that's what you want.

Our standard response is:

---

Hello,

The source address 128.31.0.13 is a Tor exit node, and is not the origin point 
for the traffic in question. See http://tor-exit.csail.mit.edu (which is the 
host in your logs) for details. Any action taken on this node would simply 
result in the problem traffic using a different exit.

For further information please read http://tor-exit.csail.mit.edu/ the bottom 
of this page includes information on how to block all Tor exits should you wish 
to do so (including links to get a list of all current Tor exits).

Sincerely,
The Infrastructure Group
MIT Computer Science and Artificial Intelligence Laboratory

---

Very few people enguage in further discussion (like <1 per year).

-Jon
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] DoS attacks on multiple relays

[null]

Hi,

We're experiencing what looks like a DoS attack on multiple relays in our
family:

https://atlas.torproject.org/#search/family:CBEAE10CBBB86C51059246B2EF92EB2CB4E111BC

The relays are currently running Tor 0.3.1.9 on Linux kernel 4.4.0
(although when the problem started the relays were running Tor 0.3.1.8).

The attack knocked 3 of 6 relays offline overnight. By the time we looked
at logs, the Tor service had stopped and this was the last line in the log:

"Tor[xyz]: Failing because we have 16351 connections already. Please read
doc/TUNING for guidance."

The attack is still ongoing. When it's happening, the number of connections
rises very rapidly, until the attack succeeds in stopping the service.

$ ss -s
Total: 15855 (kernel 0)
TCP:   24520 (estab 23969, closed 305, orphaned 31, synrecv 0, timewait
261/0), ports 0

Transport Total IPIPv6
*   0 - -
RAW   0 0 0
UDP   8 4 4
TCP   24215 24213 2
INET   24223 24217 6
FRAG   0 0 0

... and only a few seconds later:

$ ss -s
Total: 12120 (kernel 0)
TCP:   27389 (estab 20026, closed 1906, orphaned 45, synrecv 0, timewait
1587/0), ports 0

Transport Total IPIPv6
*   0 - -
RAW   0 0 0
UDP   8 4 4
TCP   25483 25481 2
INET   25491 25485 6
FRAG   0 0 0

That's obviously much larger than the normal number of connections, more
than we've ever seen, and seems like more connections than would be needed
for a relay.

We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks
like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:

  elif [ "$system_max" -gt "4" ] ; then
MAX_FILEDESCRIPTORS=16384

Surely that is high enough for normal service?

We haven't started looking into where the traffic is coming from or other
characteristics. We are wondering if: 1) this is a known attack, 2) if
other operators are experiencing it, 3) if there are any ideas for
mitigating it, and 4) if any additional information would be helpful.

Thanks.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Ralph Seichter]

On 04.12.17 20:00, Iain Learmonth wrote:

> I do wonder how much of this is related to the scarcity of IPv4
> address space, prevalence of reputation systems and fear of ending
> up being labeled as "bad".

I remember that last year I was notified by said hoster that the IP
address of one of my exit nodes had ended up on a blacklist and that I
was expected to get the address off that list. Turns out the exit had
made connections to a sinkhole address not yet listed with tornull.org.

This hoster obviously keeps track of the reputations of the IP addresses
assigned to customers' servers. I imagine you are correct to assume that
prohibiting outbound network scans has a similar motivation. Also, scans
consume resources and hence cost money.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[George]

Zack Weinberg:
> On Mon, Dec 4, 2017 at 1:00 PM, s7r  wrote:
>> Zack Weinberg wrote:
>>> With my exit node operator hat on, I too would like to see some sort
>>> of port-scanning prevention built into the network.  In my case, I had
>>> to turn off exiting to the SSH port because we were getting daily
>>> complaints about abusive scanning for devices with weak admin
>>> passwords.  Which is a shame, since there are plenty of legitimate
>>> uses for SSH-over-Tor.
> ...
>> I don't think this is the way to go, under any circumstances. Better to
>> learn to make difference between junk notification and serious reports
>> that require action or reply.
> 
> For the record, those daily complaints about abusive SSH scanning were
> serious reports requiring a reply.  And they were not all from the
> same source.
> 

I realize this issue of SSH brute forcing via exit nodes is old news,
but what is remarkable to me is that:

1. anyone cares about SSH brute force attacks if they are using keys and
passwords for SSH authentication

2. who in the world has the time to investigate SSH brute force attacks,
and if they do, maybe they had enough time to notice that it was from a
Tor exit IP?

/rant

g


-- 


34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Iain Learmonth]

Hi,

On 04/12/17 18:19, Ralph Seichter wrote:
> This is not about third party X complaining to the hoster about their
> network being scanned. The hoster itself is automatically monitoring all
> their machines for outgoing network scans, as these scans are prohibited
> by their terms of use.

I do wonder how much of this is related to the scarcity of IPv4 address
space, prevalence of reputation systems and fear of ending up being
labeled as "bad". When we move to IPv6, perhaps hosting providers would
be more relaxed knowing that it doesn't matter so much if a /64 or even
a /56 ends up bad in a reputation system, because for other customers
you have other address space.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Zack Weinberg]

On Mon, Dec 4, 2017 at 1:00 PM, s7r  wrote:
> Zack Weinberg wrote:
>> With my exit node operator hat on, I too would like to see some sort
>> of port-scanning prevention built into the network.  In my case, I had
>> to turn off exiting to the SSH port because we were getting daily
>> complaints about abusive scanning for devices with weak admin
>> passwords.  Which is a shame, since there are plenty of legitimate
>> uses for SSH-over-Tor.
...
> I don't think this is the way to go, under any circumstances. Better to
> learn to make difference between junk notification and serious reports
> that require action or reply.

For the record, those daily complaints about abusive SSH scanning were
serious reports requiring a reply.  And they were not all from the
same source.

zw
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Tom van der Woerdt]

Op 04/12/2017 om 13:39 schreef teor:
> 
> On 4 Dec 2017, at 22:18, Tom van der Woerdt  > wrote:
> 
>> Hi James,
>>
>> Have you considered running a super restrictive exit policy? I had the
>> same trouble you have, with EFF's restrictive exit policy. So I wrote my
>> own, which also blocks port 80:
>>
>> ExitPolicy accept *:443
>> ExitPolicy accept *:6667
> 
> A restricted exit policy is a good idea, but Exits must include port 80.
> (If they don't, they will mainly be used as guard and middle relays.)
> 
> Blocking port 80 isn't safe for users: it doubles the number of exits that
> they must use, which doubles their risk of a malicious exit.
> 
> So, when directory authorities update to 0.3.2, they will only vote Exit for
> relays that allow both port 80 and 443.
> 
> Background:
> https://trac.torproject.org/projects/tor/ticket/23637
> 
> T

Sorry to hear that :-( Guess I'll also have to stop running my exit, then.

Tom
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[s7r]

Zack Weinberg wrote:
> On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter  
> wrote:
>> On 04.12.17 11:59, James wrote:
>>
>>> As a private individual, after just receiving my 4th abuse complaint
>>> in as many days it's time to stop running my exit node.
>>

Thanks for running the exit and I am sorry you took the decision to shut
it down. However, 4th abuse complaint in few days is really not a big
deal, I could say I swim in such reports, but then again it's up to each
and every one when to stop.

What I want to point out is a HUGE difference between:

1. *Abuse Reports* aka *Serious complaints*, those that are addressed
directly and formally, sent by a human, and explicitly require action or
at least reply with explanation. These are very rare.

2. *Junk NOTIFICATIONS* aka *WARNINGS* aka *Simple Notifications to
safely ignore*, those that are not addressed formally ("to whomever it
may concern..."), are sent by bots or automated scripts (firewalls,
intrusion systems, fail2ban, etc) which simply run a whois on an IP
address and bomb the abuse mailbox with spam, most sent from addresses
that even if a reply is sent the message is discarded - these DO NOT
require action nor reply. These are the 99% ones.

>> I've had an ongoing debate with a hosting service over a fresh exit node
>> being abused for network scans (ports 80 and 443) almost hourly for the
>> last few days. I can understand that they are pissed off, and the whole
>> thing resulted in this particular exit being shut down by the hoster. If
>> I could detect and prevent these scans, it would go a long way to avoid
>> having my exit nodes shut down by hosting services.
> 

This is just a defective policy of that hoster. If a hoster goes mad
because it receives some useless junk notifications, that is not much of
a hoster. The first problem is that one who feels port-scanned or probed
needs to implement defenses at their end, not bomb with automated spam
messages everyone that is connecting to them. You cannot rely on
everyone else doing something in order to ensure your security when you
can implement protections for yourself.

A large exit node (big consensus weight) is almost guaranteed a false
positive to trigger such a dumb warning system, even in legitimate cases
where simply more users pick it as Exit and the service (end point) is
popular.

> With my exit node operator hat on, I too would like to see some sort
> of port-scanning prevention built into the network.  In my case, I had
> to turn off exiting to the SSH port because we were getting daily
> complaints about abusive scanning for devices with weak admin
> passwords.  Which is a shame, since there are plenty of legitimate
> uses for SSH-over-Tor.
> 

I agree it's annoying but it is very hard to implement port-scanning
prevention directly in Tor especially because new connections should not
be distinguishable if they come from the same user or multiple users.
The exit relay should have no definition about this, otherwise you have
to go deeper into streams attached to each circuit which is totally
different. This will be over-engineering with absolutely no gains
because someone that wants to abuse simply does not care about the
network and will just keep port-scanning with isolated requests /
different circuits (might be slower, but still work) and will consume
even more resources in the network.

I don't think this is the way to go, under any circumstances. Better to
learn to make difference between junk notification and serious reports
that require action or reply.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Zack Weinberg]

On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter  wrote:
> On 04.12.17 11:59, James wrote:
>
>> As a private individual, after just receiving my 4th abuse complaint
>> in as many days it's time to stop running my exit node.
>
> I've had an ongoing debate with a hosting service over a fresh exit node
> being abused for network scans (ports 80 and 443) almost hourly for the
> last few days. I can understand that they are pissed off, and the whole
> thing resulted in this particular exit being shut down by the hoster. If
> I could detect and prevent these scans, it would go a long way to avoid
> having my exit nodes shut down by hosting services.

With my exit node operator hat on, I too would like to see some sort
of port-scanning prevention built into the network.  In my case, I had
to turn off exiting to the SSH port because we were getting daily
complaints about abusive scanning for devices with weak admin
passwords.  Which is a shame, since there are plenty of legitimate
uses for SSH-over-Tor.

The tricky part is designing some sort of exit-node-controlled
new-connection rate limiting that's content-blind and won't interfere
with legitimate uses.  And "legitimate uses" include things like a web
browser generating a burst of TCP connections to the same HTTP/1.1
server cluster, exitmap connecting to the same test server repeatedly
via every exit node in the network, and so on.  I would want to see
any proposal document include a long list of known non-abusive traffic
scenarios and an argument that the mechanism would not interfere with
each.

zw
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Ralph Seichter]

On 04.12.17 11:59, James wrote:

> As a private individual, after just receiving my 4th abuse complaint
> in as many days it's time to stop running my exit node.

I've had an ongoing debate with a hosting service over a fresh exit node
being abused for network scans (ports 80 and 443) almost hourly for the
last few days. I can understand that they are pissed off, and the whole
thing resulted in this particular exit being shut down by the hoster. If
I could detect and prevent these scans, it would go a long way to avoid
having my exit nodes shut down by hosting services.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Dr Gerard Bulger]

I so far have got away with no abuse with quite a wide range of ports open, 
avoiding obvious abuse ports and only allowing port 80 to a single Class A, 
chosen belonging to a benign country/service:   x.x.x.x/8:80Gets the server 
listed as an exit.  I have not seen, via arm, anyone use port 80 as an exit, 
but exit on 443 and the other open ports are used a lot.

Perhaps my ISP is eating the abuse.  I doubt it

Gerry



-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Nagaev Boris
Sent: 04 December 2017 12:58
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] So long and thanks for all the abuse complaints

On Mon, Dec 4, 2017 at 12:39 PM, teor  wrote:
> Blocking port 80 isn't safe for users: it doubles the number of exits 
> that they must use, which doubles their risk of a malicious exit.

The risk of using port 443 is much lower than the risk of using port 80, 
because information passed through 443 port is normally encrypted and 
authenticated.

How does the number of exits being affect the risk for users (given only 443 
port is used)? IIUC the more servers the better, because harder to spy on a 
significant part of them.

--
Best regards,
Boris Nagaev
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[James]

I was only allowing 80 and 443 anyway.

https://atlas.torproject.org/#details/7723B1B4B2B4D9D161209F770079A6F0A5A929BC

J
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Save the date! Thursday, Dec 07 - Tor Meetup in NYC

[isabela]

On 12/1/17 18:11, Eran Sandler wrote:
> Any meetups in the bay area happening any time soon?
> 
> Eran
> 

Not that I know of.
isabela
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Nagaev Boris]

On Mon, Dec 4, 2017 at 12:39 PM, teor  wrote:
> Blocking port 80 isn't safe for users: it doubles the number of exits that
> they must use, which doubles their risk of a malicious exit.

The risk of using port 443 is much lower than the risk of using port
80, because information passed through 443 port is normally encrypted
and authenticated.

How does the number of exits being affect the risk for users (given
only 443 port is used)? IIUC the more servers the better, because
harder to spy on a significant part of them.

-- 
Best regards,
Boris Nagaev
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[teor]

> On 4 Dec 2017, at 22:18, Tom van der Woerdt  wrote:
> 
> Hi James,
> 
> Have you considered running a super restrictive exit policy? I had the
> same trouble you have, with EFF's restrictive exit policy. So I wrote my
> own, which also blocks port 80:
> 
> ExitPolicy accept *:443
> ExitPolicy accept *:6667

A restricted exit policy is a good idea, but Exits must include port 80.
(If they don't, they will mainly be used as guard and middle relays.)

Blocking port 80 isn't safe for users: it doubles the number of exits that
they must use, which doubles their risk of a malicious exit.

So, when directory authorities update to 0.3.2, they will only vote Exit for
relays that allow both port 80 and 443.

Background:
https://trac.torproject.org/projects/tor/ticket/23637

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Tom van der Woerdt]

Hi James,

Have you considered running a super restrictive exit policy? I had the
same trouble you have, with EFF's restrictive exit policy. So I wrote my
own, which also blocks port 80:

ExitPolicy accept *:443
ExitPolicy accept *:6667
ExitPolicy accept *:7000
ExitPolicy accept *:5222
ExitPolicy accept *:5223
ExitPolicy accept *:110
ExitPolicy accept *:143
ExitPolicy accept *:220
ExitPolicy accept *:993
ExitPolicy accept *:995
ExitPolicy accept *:9418
ExitPolicy accept *:53
ExitPolicy reject *:*

Now I deal with maybe 1 complaint per quarter. And since 443 is still in
there, it's still contributing substantially to the network (maybe more
so than with port 80 enabled).

Consider giving it a try ;-)

Tom


Op 04/12/2017 om 11:59 schreef James:
> As a private individual, after just receiving my 4th abuse complaint in
> as many days it's time to stop running my exit node. Prior to today I'd
> receive on average 1-2 complaints a month (I had a fairly strict exit
> policy). It saddens me that I have to shut it down, especially as it's
> one of very few running on BSD, but I just don't have the time to
> constantly respond to abuse complaints to ensure I don't get shut down
> by the upstream provider. If there are any devs on this list, some kind
> of mechanism to detect and block abuse traffic on exit would go a long
> way to ensuring legitimate use of the network, that is after all why
> people run exit nodes. It's at least why I did.
> 
> Thank you to everyone else running an exit node. I hope you're able to
> keep yours going for a lot longer than I.
> 
> James
> 
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays