Filtering TOR Non-exit Relay - Just Curious
Tor Exit Relay have the ability to filter traffic by allowing the operator make choices based on personal preferences for personal, legal (ex: country of origin) and for other reasons. Non-exit Relays do not have the ability to set "Relay Policies" (torcc??), and why would they, considering that all this traffic is encrypted anyway, as I understand it, and one would not ever know what type of traffic it is, or its origin, based on the bandwidth graph. I checked my smoothwall firewall logs it does not seem to show the traffic flowing on my relay, I guess this would be obvious because it's Tor traffic; unless I'm not filtering the logs correctly. Running a Tor relay seems straightforward and one could just fire-it-up and easily contribute to the network. But my curiosity gets the best of me. I was looking to add additional URL Filter rules for my smoothwall as a more centralized way of controlling what gets to the LAN for my users. While checking for additional blocklists I came upon P2P rules and I started to compare the new blocklists with my old ones and then I stumbled upon PeerBlock which has been around for a while. On Windows 7, PeerBlock seemed to provide two things I was looking to test on a TOR Relay: 1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic. Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools. In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created. 1. What problems, if any, arise from using peerblock and Tor together? 2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?
Middle nodes don't know the type of traffic. If they have any way to find out, that is a bug that needs to be fixed. End-of. 2013/10/27 Nelson <nelson@net2wireless.net>:
Tor Exit Relay have the ability to filter traffic by allowing the operator make choices based on personal preferences for personal, legal (ex: country of origin) and for other reasons.
Non-exit Relays do not have the ability to set "Relay Policies" (torcc??), and why would they, considering that all this traffic is encrypted anyway, as I understand it, and one would not ever know what type of traffic it is, or its origin, based on the bandwidth graph. I checked my smoothwall firewall logs it does not seem to show the traffic flowing on my relay, I guess this would be obvious because it's Tor traffic; unless I'm not filtering the logs correctly.
Running a Tor relay seems straightforward and one could just fire-it-up and easily contribute to the network. But my curiosity gets the best of me.
I was looking to add additional URL Filter rules for my smoothwall as a more centralized way of controlling what gets to the LAN for my users. While checking for additional blocklists I came upon P2P rules and I started to compare the new blocklists with my old ones and then I stumbled upon PeerBlock which has been around for a while.
On Windows 7, PeerBlock seemed to provide two things I was looking to test on a TOR Relay:
1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic.
Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools.
In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created.
1. What problems, if any, arise from using peerblock and Tor together? 2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I didn't say I knew the type of traffic on my relay, that would be an entirely new set of problems; I said I can see the IP addresses coming in and going out, and the ports used. I would venture to ask this is not how Tor is intended to work? If this is a possible bug in Tor, i dunno, then one could perhaps surmise that an organization with enough capital can build a network flow chart of the majority of the traffic with middle and exit nodes at their disposal? I was curious why my firewall isn't capable of detecting ip's to and from my relay, unless I am looking at the wrong traffic logs, but yet I can see the ip's in peerblock, and this is not what i expected when reading about Tor. If Tor middle nodes are exposing ip addresses that are coming in and out of a relay, and this is not supposed to work like this by design, then oops. On Oct 27, 2013, at 14:23, Lukas Erlacher <l.erlacher@gmail.com> wrote:
Middle nodes don't know the type of traffic. If they have any way to find out, that is a bug that needs to be fixed. End-of.
2013/10/27 Nelson <nelson@net2wireless.net>:
Tor Exit Relay have the ability to filter traffic by allowing the operator make choices based on personal preferences for personal, legal (ex: country of origin) and for other reasons.
Non-exit Relays do not have the ability to set "Relay Policies" (torcc??), and why would they, considering that all this traffic is encrypted anyway, as I understand it, and one would not ever know what type of traffic it is, or its origin, based on the bandwidth graph. I checked my smoothwall firewall logs it does not seem to show the traffic flowing on my relay, I guess this would be obvious because it's Tor traffic; unless I'm not filtering the logs correctly.
Running a Tor relay seems straightforward and one could just fire-it-up and easily contribute to the network. But my curiosity gets the best of me.
I was looking to add additional URL Filter rules for my smoothwall as a more centralized way of controlling what gets to the LAN for my users. While checking for additional blocklists I came upon P2P rules and I started to compare the new blocklists with my old ones and then I stumbled upon PeerBlock which has been around for a while.
On Windows 7, PeerBlock seemed to provide two things I was looking to test on a TOR Relay:
1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic.
Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools.
In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created.
1. What problems, if any, arise from using peerblock and Tor together? 2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?
_______________________________________________ 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
Lukas Erlacher <l.erlacher@gmail.com> wrote:
Middle nodes don't know the type of traffic. If they have any way to find out, that is a bug that needs to be fixed. End-of.
Packet timing analysis may be able to tell you *something* -- this is part of my current research project, ask again in six months :-) Mr. Nelson Laurenti wrote:
I didn't say I knew the type of traffic on my relay, that would be an entirely new set of problems; I said I can see the IP addresses coming in and going out, and the ports used.
That's to be expected. Tor is still using IP, so there is no way around the fact that a relay operator can observe the IP addresses of hosts in direct communication with their relay(s). If your relay is acting strictly as a middle hop, however, the IP addresses you observe should all be the addresses of other Tor relays, and none of the traffic you observe should *originate* from the IP addresses you observe. If you are an entry hop, some of the traffic you observe will be traffic coming directly from clients, and you can learn their IP addresses and probably quite a bit about them. This is part of why we have guards. (I am skeptical about guards actually being a good idea, but that's *also* part of my group's research, so, again, ask again in six months.) Only if you are an exit node should you be able to observe any traffic that is in cleartext and/or coming directly from server hosts. It is possible for one Tor process to serve all three roles simultaneously, but never (by design) for a single circuit. The design intent is that it will be prohibitively difficult for any single operator to control more than one node in a circuit more than some tiny fraction of the time; how feasible this actually is in real life has been the subject of quite a bit of research already (and, yep, my group is looking at that as well, albeit not as centrally). zw
On 10/27/2013 4:49 PM, Zack Weinberg wrote:
Lukas Erlacher <l.erlacher@gmail.com> wrote:
Middle nodes don't know the type of traffic. If they have any way to find out, that is a bug that needs to be fixed. End-of.
Packet timing analysis may be able to tell you *something* -- this is part of my current research project, ask again in six months :-)
Mr. Nelson Laurenti wrote:
I didn't say I knew the type of traffic on my relay, that would be an entirely new set of problems; I said I can see the IP addresses coming in and going out, and the ports used.
That's to be expected. Tor is still using IP, so there is no way around the fact that a relay operator can observe the IP addresses of hosts in direct communication with their relay(s).
If your relay is acting strictly as a middle hop, however, the IP addresses you observe should all be the addresses of other Tor relays, and none of the traffic you observe should *originate* from the IP addresses you observe.
If you are an entry hop, some of the traffic you observe will be traffic coming directly from clients, and you can learn their IP addresses and probably quite a bit about them. This is part of why we have guards. (I am skeptical about guards actually being a good idea, but that's *also* part of my group's research, so, again, ask again in six months.)
Only if you are an exit node should you be able to observe any traffic that is in cleartext and/or coming directly from server hosts.
It is possible for one Tor process to serve all three roles simultaneously, but never (by design) for a single circuit. The design intent is that it will be prohibitively difficult for any single operator to control more than one node in a circuit more than some tiny fraction of the time; how feasible this actually is in real life has been the subject of quite a bit of research already (and, yep, my group is looking at that as well, albeit not as centrally).
zw
ZW, thanks. I will definitely check back in six month and see what kind of progress has been made. Again, I tested this and with PeerBlock I can actually block known ip's of the nodes you mention (not something TOR is intended for, or I want to do or need to do), and for all intents and purposes if "my organization" had sufficient resources, knowing that we could actually create blocklists to prevent traffic coming to and from unwanted middle and exit nodes, then will be in effect "shaping traffic flow"? Considering of course "we" had "several" relays ourselves?
Hi! Maybe I am not such a big expert but this is a good chance for me to expose my understanding so others could correct me if I am wrong. On Sun, 2013-10-27 at 17:27 -0700, Nelson wrote:
Again, I tested this and with PeerBlock I can actually block known ip's of the nodes you mention (not something TOR is intended for, or I want to do or need to do), and for all intents and purposes if "my organization" had sufficient resources, knowing that we could actually create blocklists to prevent traffic coming to and from unwanted middle and exit nodes, then will be in effect "shaping traffic flow"? Considering of course "we" had "several" relays ourselves?
I understood that you want to simply block other tor servers so only (or mostly) your tor servers will be allowed. From my understanding you cannot attack tor that way: a) You need to get client connections. But with such a configuration other tor servers cannot connect to you. and one part of the process is, that other servers connect to your server to measure the speed. b) A client tries to build a circuit. from my understanding, the client is choosing the servers to use. So even if a client connects to your server then the creation of the circuit will fail and the client will build up some other circuit instead. But as a I tried to said before: I am not an expert so far. It is just my understanding which could be completly wrong. With kind regards, Konrad -- Konrad Neitzel <konrad@neitzel.de>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Konrad, initially and completely unrelated to Tor, I was working on adding some blocklists to my firewall when I came upon and old program, Peerblock. Peerblock from what I remember can log all allowed and blocked traffic, and gives one the ability to use already made blocklists or create new ones. Peerblock has some interesting blocklists and I thought maybe I could use some of those blocklists or some of the listed IP's to filter warez, P2P and other undesirable sites. Tor (middle) Relays don't have the filtering options like Exit Relays. With Exit Relays one can choose the type of traffic based on personal and legal reasons, then I thought why don't middle relays at least have some mechanism to block undesirable traffic? So I installed Peerblock on one of my Windows PC's that has a Tor Relay (HelloChilli). Initially Peerblock was set to allow all traffic and to my surprise I could see what seemed to be Tor traffic being logged. Then I activated some blocklists and sure enough I was apparently able to block traffic from undesirable sources. Further, I can right click, copy to clipboard the ip addresses of the blocked ip's, do an NSLOOKUP and generally discern whether the ip address is from a listed Tor relay, a VPN service, from Anti-P2P, Gov or other sources. My initial curiosity about viewing real-time Tor traffic and the ability to block specific traffic on my middle-node seemed to be achieved. - --Nelson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSbn4vAAoJEFlSVOvcX0rHwqkP/jLDwV31FUP/UYZ81l5CONzE s8F1ZSstgwbz4rQtwMuEtc0FogmGE5MOqgUL/10nB1kFtZp7GUd8NQJKyqs0ivKN 5h4irMT+U3PBi2hV+OXlQWmp8CQpc6z1kIgroEoxtxOZC/2q1x+xrIHALsGp8Mov +XpYxXvF+OFX3OwbSnb68wrIHBg74vYRqEHR5gVSvR6IvQk9OcPN1onZ+6PH8rWk x0Wj9Q+JxLLl/wC36j739bFIV8GnU16ZaAG6GqPEnL56ZBXZBGFaHVZS6/DIDOCU TLy3yl/BZvHIZ4wbz5MysCf58N6Vy/e+UgeLHI4Giv42I9g+/o0FsdqQK0FlFBnt scMQWx7ls5t69qu6Z9wHC6ObJA5vcgIcBCgsAh61Y9tqIRI5B0PKNBcVAtH3/Z3i gPIcEe+UN1bGdeB3KmbTQjBcLmz/ZFWWMgmKIO6pfWgICfvehJs5G7e9/un7Zg02 PhQeDPaHIdDSdOZ/sg4bPBrixssw1WvpTzJf23g3qtFT2xdRT+MG8QQfsHB44Cxj ty8jwZNSscJYm1daum/KSnCYnRdA4xyJyQacqPi5an2u8kgTZcDrX+fcd43cxBOy 1LmIMcbEBBAcbM3HMHYQ+jnPE3D3Lcf9JD1MALYQ/GaSvxuZ2lx8ZhUksImkl7Ka B7zrhIcwUjoc6r3YWC29 =9Wbi -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition, there's a host of possibilities (both good and bad) by being able to control a Tor relays traffic. I could be wrong, my previous findings may seem to indicate that anyone with the ability to strategically place a good number of middle and exits nodes can shape or at least control some of the Tor traffic. ZW mentioned previously: "Tor is still using IP, so there is no way around the fact that a relay operator can observe the IP addresses of hosts in direct communication with their relay(s).", and this to me presents a problem in maintaining complete anonymity. On 10/28/2013 8:09 AM, Nelson wrote:
Hello!
Konrad, initially and completely unrelated to Tor, I was working on adding some blocklists to my firewall when I came upon and old program, Peerblock. Peerblock from what I remember can log all allowed and blocked traffic, and gives one the ability to use already made blocklists or create new ones. Peerblock has some interesting blocklists and I thought maybe I could use some of those blocklists or some of the listed IP's to filter warez, P2P and other undesirable sites.
Tor (middle) Relays don't have the filtering options like Exit Relays. With Exit Relays one can choose the type of traffic based on personal and legal reasons, then I thought why don't middle relays at least have some mechanism to block undesirable traffic?
So I installed Peerblock on one of my Windows PC's that has a Tor Relay (HelloChilli). Initially Peerblock was set to allow all traffic and to my surprise I could see what seemed to be Tor traffic being logged. Then I activated some blocklists and sure enough I was apparently able to block traffic from undesirable sources. Further, I can right click, copy to clipboard the ip addresses of the blocked ip's, do an NSLOOKUP and generally discern whether the ip address is from a listed Tor relay, a VPN service, from Anti-P2P, Gov or other sources.
My initial curiosity about viewing real-time Tor traffic and the ability to block specific traffic on my middle-node seemed to be achieved.
--Nelson
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSboGMAAoJEFlSVOvcX0rH7WwP/0/2QNeiBVX16fOPsKDKxHxB cNC4GagCdvlnHAHufkZEGYDTFnDmQou8dvc0ldXYNvTlSEqBfSd1zzMQEW24SAWw /Wlp1hH3tYcEe+AiAvx3jIUR+RdQ7Qp3elfKQmyAVcmNomGPDDB90u+p/Kvp5Lhw dnCj1pA/jV9rJsZRk5SPHuwk2hWZIhmWdcuurkrx/UISAU2QMJzjnkjzlgIMq9od 6gz95IQM6r15sF/ezLP+IwQ8Ltb9AmtrZc7u4MIB8i7Ki5tT5u9A2sIy2z7pJLnG z46JP9LOy5WTlAc1nHxxS2BJqFzQ2IjOQ1zYaJOf9tgfeubY9QJyiKSphUXv/UtF Y7JCdhw9JfpE6+2F9a9bVczymVrvLthb2XK82n+S2SSRVLSD81Tg7WVjo6LvyhBn 72G85kbF4srGnmHSIBtZtAOmG+2E9rBzuDPk/ULwILC8kyv8uxc/zT7OsO0jQ4ZF fmXXbn6wLyhf5nxz7a6XFrcWiGLAJzCL+J8l4/B8EOOfLJAmkqDKrVWTywR+STi3 fiZ04oCkuKi+fQ/lZUYwbI7DPQiN+yZOvBzqevqtP+/nBTTe2wQhWcWx4Wu3tZon ElNkJaWDcpPURO3/y3z/kpwWm7fPHq9A5yrYfpA6rYEWBPETgczYyAx2gSx5Uelg A/Qrq2RPXKyUIDeRPnwg =oR1g -----END PGP SIGNATURE-----
27.10.2013 20:49, Nelson:
1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic.
Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools.
In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created.
1. What problems, if any, arise from using peerblock and Tor together?
Just logging could enable someone to combine your logs with his own or someone's logs trying to 'unmask' user(s). Blocking, depending on the filter lists exits might be blocked or the whole Tor network.
2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?
Tor's design/architecture is based on the assumption that any relay can reach any other relay in the network. There's no classes of traffic for nodes that aren't exits. Exits can guess based on the port what certain traffic is, port 25 for example gets abused by spammers so it is not allowed by default. Exits are able to identify the communication end-point and can exclude those that complain about abuse. Exits are at the worst spot when it comes to complains, they get them, middle-relays don't have that and they can not distinguish traffic anyway, and they shouldn't be able to do so. Regards, Sebastian G.
There's no classes of traffic for nodes that aren't exits. Exits can guess based on the port what certain traffic is, port 25 for example gets abused by spammers so it is not allowed by default. Exits are able to identify the communication end-point and can exclude those that complain about abuse. Exits are at the worst spot when it comes to complains, they get them, middle-relays don't have that and they can not distinguish traffic anyway, and they shouldn't be able to do so.
Regards, Sebastian G.
Thank you. Nelson
participants (6)
-
Konrad Neitzel -
Lukas Erlacher -
Mr. Nelson Laurenti -
Nelson
-
Sebastian G. <bastik.tor> -
Zack Weinberg