ExitPolicy should apply to already established outbound connections (with a config option, off by default)

To reduce the impact of tor running out of free TCP source ports (see pending comment in #26646) we added a reject entry for the destination causing most outbound TCP connections to the ExitPolicy and restarted tor.

ExitPolicy reject 1.2.3.4:*  <<<< added to avoid outbound connections to this target
ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

Expected: Tor should not create any connections to 1.2.3.4

Even after changing the torrc and restarting tor we see established TCP connections to 1.2.3.4, this is unexpected.

This wouldn't be unexpected if (for example) 1.2.3.4 was a Tor relay: the connections opened in that case would be OR connections, not exit connections. On the other hand, there should not be a large number of them.

Has anybody else seen something like this?

We can rule out that the destination is a tor relay because the IP address is not in the consensus and the destination is tcp port 443, where a webserver is running using a valid certificate from a public root CA. The source IP for these connections is the one we specified in OutboundBindAddressExit which is not used by any other software on the relay and netstat says the PID is from tor.

changed milestone to %Tor: 0.4.8.x-freeze

This isn't one of those thing where if you move the reject 1.2.3.4 line below the accept 443 it works? :S

@dgoulet: placing the reject 1.2.3.4:* line, bellow the accept lines does not solve the issue.

The issue creator asked me to test this on my relays as well. I can confirm the behavior.

3 annoying DDoS IP's with sometimes over 500k connections. I block these IP's in nft chain ingress and by ExitPolicy:

reject 45.20.67.1:*
reject 185.149.120.37:*
reject 194.26.229.2:*
reject *:22
reject *:25
accept *:*

I set an outbound counter for these 3 IP's for test purposes. Then reloaded tor, but the IP's continue to increase nft output counter.

I had to reboot a few hours ago due to kernel update. Since the reboot I see no connections from or to these IP's. nft list ruleset & reboot

added Icebox label

removed Icebox label

Ok this is very surprising... I'll grab this ticket and try to reproduce and investigate.

assigned to @dgoulet

mentioned in issue #40194 (closed)

A second exit operator confirmed also having the same issue as described here.

We can confirm that restart vs. reload makes a difference.

Can you confirm that tor does not terminate existing connections on reload if they are against the exit policy? In that case: To avoid having to restart tor (killing all connections) on every exitpolicy change, please consider implementing that on reload.

Yes, correct, Tor doesn't retroactively go close already existing exit connections. The goal of the exit policy is to decide which destinations you will allow to exit -- if you have already allowed an exit stream because it complied with your exit policy, then it is established and stays that way. Similarly, SocksPolicy doesn't go through and kill existing socks connections if you change it.

Are all of the people on this ticket who are concerned that ExitPolicy is buggy trying to use it to close existing streams? The title of the ticket is "tor creates outbound connections" which sounds like it means new streams.

The title of the ticket is "tor creates outbound connections" which sounds like it means new streams.

This was my understanding as well, but being able to make tor close "newly illegal" connections would be great for operators suffering from "outbound connection DoS". Right now we have to systemctl restart our exit instances to save our servers from becoming useless, which kicks everyone else off as well. Maybe as an option that's disabled by default (and a separate GitLab issue)?

So I just tested this on an Exit I control.

Basically, this FAILS as in it let the connection to 1.2.3.4:8080 go through:

ExitPolicy accept *:8080
ExitPolicy reject 1.2.3.4:8080

This version, it works as in it rejects the exit connection to 1.2.3.4:8080:

ExitPolicy reject 1.2.3.4:8080
ExitPolicy accept *:8080

It also works if I do as in it rejects:

ExitPolicy reject 1.2.3.4:8080
ExitPolicy accept *:*

So I wonder why I can't reproduce your issue here because the original policy posted in the ticket should do it... hmmmm

added Doing label

dgoulet: I believe tor's exit policy is behaving as intended, i.e. your concern above about the order of exitpolicy lines isn't the issue.

Rather, what these relay operators want is for their Tor to loop through existing already established exit streams when the exit policy changes, and close the streams that would have been refused by the new exit policy.

I think giving them a torrc option to do it, off by default, would make sense.

I note in passing that if the main use case for this behavior is resisting socket DoS, maybe we should consider something like proposal 341 as a higher priority.

Yes! I think from a network health perspective we want to bump up the priority of proposal 341.

The exit stream overload behavior has stopped for the moment, but it could come back anytime. It is a straightforward overload that is easy to perform and that we should have better support for inside the Tor protocol.

Cc'ing @ahf because we had a brief discussion yesterday on whether Tor should solve this "in protocol" or we should leave it to relay operators to solve it externally with iptables or scripts. I think long term we want to do it in-protocol.

changed title from ExitPolicy is ignored: tor creates outbound connections to destinations rejected by ExitPolicy to ExitPolicy does not apply to already estblished outbound connections

This topic came up in the relay operator meetup today, and I changed the title ticket to what everything in the meetup thought this ticket is about.

If you are the original ticket filer, and you meant something different, please jump in.

changed title from ExitPolicy does not apply to already estblished outbound connections to ExitPolicy should apply to already established outbound connections

submitted on Sat 19 Nov 2022 11:57:35 PM UTC:

I'm the original ticket filer and I was at the meeting today.

You can choose between:

• close this ticket with its original title and open a new one for the reload vs. restart topic - that would be the more appropriate step
• or just continue with the new title and meaning, but @dgoulet tagged it as doing under the initial meaning

both is fine with me

Yep! I will let dgoulet clarify if he wants, but my guess is that his 'doing' tag meant only "trying to reproduce the bug, and then eventually closing the ticket as can't-reproduce because the originally reported behavior is not a bug."

So, I will let the ticket proceed with the new title. :)

I think we are making the mistake here with converting a ticket that is very specific into something bigger than what was originally planned. I think the prop 341 suggestions should happen in another ticket than this.

Yes, agreed that any prop 341 work should be a new ticket. Is there one already? I didn't want to jump in and add work to the network team without you being involved in the decision. :)

Makes sense - let's talk about it with David here.