Protecting the bridge port from active probes
Hello, I run a private obfuscated Tor bridge for myself and some friends. All in all it has worked fine so far but having recently run some security scans on the bridge host, I now wonder how resistant to active probing my bridge is. Apologies if this has already been asked, I have yet to find a searchable archive of this list. Anyway, here is my logic. In order to operate properly, my bridge must have its ORPort reachable from the Internet. I have chosen a port to be used for this purpose at random but these days, scanning all 64k TCP ports on a host takes mere minutes. The X.509 server certificate offered on the ORPort is rather suspicious, if only because of the randomly generated name; I suspect there might be other peculiarities as well. Therefore, I strongly suspect that it wouldn't take more than a few minutes for any attacker employing active probing to detect my bridge and block access to it. Does this make sense? And in any case, is there anything else I could do to protect my bridge against active probing? The best I could come up with is to make the bridge host periodically change the ORPort, I reckon wouldn't really help because if I had to restart tor on the bridge every few minutes the it wouldn't be of much use connectivity-wise. Having the border firewall block or slow down suspected port scans might perhaps make it possible to change the ORPort less frequently but alas, I have no control over the border firewall beyond being able to ask to open or close specific ports on my host. Thank you in advance for your time. -- MS
On Thu, 28 Mar 2019 17:08:38 +0000 Marek Szuba <scriptkiddie@wp.pl> wrote:
Anyway, here is my logic. In order to operate properly, my bridge must have its ORPort reachable from the Internet.
I might be wrong, but I got impression that if bridge is using pluggable transports (obfs3, obfs4, meek, snowflake, etc) then ORPort is only useful for bridge authority and users which want to use the bridge without pluggable transports. Communication between pluggable transport and Tor process is going via ExtORPort which isn't public by default (binds to localhost). Clients connect to pluggable transport port and their traffic is obufscated by the transport. Since your bridge is private then bridge authority is none of your concerns. In that case you need ORPort reachable only if you have bridge clients which use bridge without pluggable transports.
On Thu, Mar 28, 2019 at 08:43:34PM +0300, Dmitrii Tcvetkov wrote:
Since your bridge is private then bridge authority is none of your concerns. In that case you need ORPort reachable only if you have bridge clients which use bridge without pluggable transports.
Yes, this advice is correct. Feel free to firewall off your ORPort from the outside. It will make your bridge complain that it is unreachable, until somebody reaches it via one of the pluggable transports, which will satisfy it and it should stop complaining. You can also simplify that step by setting "AssumeReachable 1" in your torrc file. Longer term, we want to address the design issue in this ticket: https://bugs.torproject.org/7349 and see e.g. https://bugs.torproject.org/7349#comment:22 but so far we keep finding other things to do more urgently. --Roger
On 2019-03-29 07:46, Roger Dingledine wrote:
Yes, this advice is correct. Feel free to firewall off your ORPort from the outside.
It will make your bridge complain that it is unreachable, until somebody reaches it via one of the pluggable transports, which will satisfy it and it should stop complaining.
I see, thanks for clarifying - it's mostly those scary-looking messages in the log that have prompted me to ask this in the first place.
You can also simplify that step by setting "AssumeReachable 1" in your torrc file.
Handy! PS. Thank you very much for an inspiring talk at FOSDEM, Roger. Everything else aside I now always make sure I keep a Snowflake proxy running in my browser whenever I am online, and have even seen it being used (or have seen the logo animate in any case) on a few occasions. Next stop, trying to convince my employer to run a relay - hopefully an exit one! -- MS
Dmitrii Tcvetkov wrote:
On Thu, 28 Mar 2019 17:08:38 +0000 Marek Szuba <scriptkiddie@wp.pl> wrote:
Anyway, here is my logic. In order to operate properly, my bridge must have its ORPort reachable from the Internet.
I might be wrong, but I got impression that if bridge is using pluggable transports (obfs3, obfs4, meek, snowflake, etc) then ORPort is only useful for bridge authority and users which want to use the bridge without pluggable transports. Communication between pluggable transport and Tor process is going via ExtORPort which isn't public by default (binds to localhost). Clients connect to pluggable transport port and their traffic is obufscated by the transport.
Since your bridge is private then bridge authority is none of your concerns. In that case you need ORPort reachable only if you have bridge clients which use bridge without pluggable transports.
This works for me: AssumeReachable 1 PublishServerDescriptor 0 ORPort PUBLIC-IP:2345 NoListen ORPort 127.0.0.1:2345 NoAdvertise ExtORPort 127.0.0.1:3456 # you can try auto ServerTransportListenAddr obfs4 PUBLIC-IP:4567 ServerTransportPlugin obfs4 exec /path/to/obfs4proxy -- Alex
On Sat, Mar 30, 2019 at 08:44:45PM +0000, Alexander Nasonov wrote:
This works for me:
AssumeReachable 1 PublishServerDescriptor 0 ORPort PUBLIC-IP:2345 NoListen ORPort 127.0.0.1:2345 NoAdvertise ExtORPort 127.0.0.1:3456 # you can try auto ServerTransportListenAddr obfs4 PUBLIC-IP:4567 ServerTransportPlugin obfs4 exec /path/to/obfs4proxy
You probably also want a "BridgeRelay 1" in there too. That will help make sure you fetch appropriate directory information in order to have it available for users of your bridge. And depending on your Tor version, it will also make sure that your exit policy is reject *:*. (Not that bridge clients should be trying to exit from you, but you want to make sure that they don't succeed if for some reason they try :) --Roger
participants (4)
-
Alexander Nasonov -
Dmitrii Tcvetkov -
Marek Szuba -
Roger Dingledine