Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful.
Thanks -
gm
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful.
Sounds like you need your config file to read. Try: /etc/tor/torrc
That will likely answer your question (hint, the answer is at least one, inbound and outbound).
Do read the material on torproject.org - there's lots of it, and much of it useful to you if you are running a relay, some of it directly so.
You might also check out whonix.org
Enjoy teh awesome tehclonogy :)
Thanks for the help. I have my ORport and DIRport defined in torrc and forwarded through the firewall up to the Tor Relay. I was just wondering in regards to outbound traffic from the server itself. In the event it gets compromised I really hate to open all ports outbound let alone possible DNS leaks and what not. Appoligize if this doesn't make since I just fired this thing up yesterday and want to make sure it is secure.
gm
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Zenaan Harkness Sent: Thursday, July 10, 2014 6:47 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful.
Sounds like you need your config file to read. Try: /etc/tor/torrc
That will likely answer your question (hint, the answer is at least one, inbound and outbound).
Do read the material on torproject.org - there's lots of it, and much of it useful to you if you are running a relay, some of it directly so.
You might also check out whonix.org
Enjoy teh awesome tehclonogy :) _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Thu, 10 Jul 2014 19:48:06 -0700 "Greg Moss" gmoss82@gmail.com wrote:
Thanks for the help. I have my ORport and DIRport defined in torrc and forwarded through the firewall up to the Tor Relay. I was just wondering in regards to outbound traffic from the server itself. In the event it gets compromised I really hate to open all ports outbound let alone possible DNS leaks and what not. Appoligize if this doesn't make since I just fired this thing up yesterday and want to make sure it is secure.
You do need to have all ports open outbound.
The reason is, your relay needs to be able to connect to all other relays, and people run their relays on all sorts of weird ports.
However one thing to consider would be to restrict outbound port 22 and port 53 outbound to not get into trouble with your provider due to suspicions of SSH bruteforcing / DNS reflection attacks. This will break a very small portion of circuits built via your relay, but hopefully solve more potential problems than this would cause.
Hi Greg,
Thanks for running a relay! You do not need to firewall outbound traffic.
On 07/11/2014 05:30 AM, Roman Mamedov wrote:
You do need to have all ports open outbound. The reason is, your relay needs to be able to connect to all other relays, and people run their relays on all sorts of weird ports.
Correct. Your relay in any case needs to be able to connect to all relays. You could extract the list of IP:Port pairs from your running Tor relay and then update your local firewall accordingly, but I would just allow Tor to connect to all outbound addresses.
In the case of an exit relay, it obviously needs to be able to reach everything out there, on any TCP port.
However one thing to consider would be to restrict outbound port 22 and port 53 outbound to not get into trouble with your provider due to suspicions of SSH bruteforcing / DNS reflection attacks. This will break a very small portion of circuits built via your relay, but hopefully solve more potential problems than this would cause.
No! Tor is not able to detect this case, which will make client connection silently fail, and make the user experience a sad experience.
You can restrict any other traffic leaving your machine, but the Tor process needs to be able to fully mesh with all other relays, and, in the case of exits, be able to reach all the rest of the internet.
On Fri, 11 Jul 2014 11:02:00 +0200 Moritz Bartl moritz@torservers.net wrote:
However one thing to consider would be to restrict outbound port 22 and port 53 outbound to not get into trouble with your provider due to suspicions of SSH bruteforcing / DNS reflection attacks. This will break a very small portion of circuits built via your relay, but hopefully solve more potential problems than this would cause.
No! Tor is not able to detect this case, which will make client connection silently fail, and make the user experience a sad experience.
Agreed, but my point was that only a small minority of relays use port 22 (checked, 27 of them - more than I expected) or port 53 (just three relays), so it may be a sacrifice that's worth making, in order to avoid losing the ability to run Tor altogether due to being kicked out by your ISP.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum. Meanwhile, especially port 53 relays continue causing real problems[2] with ISPs.
Running a relay on ports like 22 and 53 should be considered downright rude to your fellow relay operators.
[1] https://lists.torproject.org/pipermail/tor-talk/2014-June/033173.html
[2] https://lists.torproject.org/pipermail/tor-relays/2014-May/004562.html
On 07/11/2014 11:33 AM, Roman Mamedov wrote:
Agreed, but my point was that only a small minority of relays use port 22 (checked, 27 of them - more than I expected) or port 53 (just three relays), so it may be a sacrifice that's worth making, in order to avoid losing the ability to run Tor altogether due to being kicked out by your ISP.
I don't see the point in blocking arbitrary outgoing ports for an application that is not going to make any connections other than relay connections. The danger of Tor misbehaving on port 22 or port 53 is the same as on any other port.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum.
A port is a number. None of them is special. I really don't see any reason to discriminate any.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum.
A port is a number. None of them is special. I really don't see any reason to discriminate any.
Oh but they are special in a lot of cases: http://www.iana.org/assignments/service-names-port-numbers/service-names-por...
-kali-
-- Moritz Bartl https://www.torservers.net/
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Jul 11, 2014, at 09:41 AM, Moritz Bartl wrote:
On 07/11/2014 11:33 AM, Roman Mamedov wrote:
Agreed, but my point was that only a small minority of relays use port 22 (checked, 27 of them - more than I expected) or port 53 (just three relays), so it may be a sacrifice that's worth making, in order to avoid losing the ability to run Tor altogether due to being kicked out by your ISP.
I don't see the point in blocking arbitrary outgoing ports for an application that is not going to make any connections other than relay connections. The danger of Tor misbehaving on port 22 or port 53 is the same as on any other port.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum.
A port is a number. None of them is special. I really don't see any reason to discriminate any.
-- Moritz Bartl https://www.torservers.net/
I agree but it depends on the service provider. I've just recently begun running some relays and while one provider confirmed I could run a non-exit relay on their network, I was later flagged as abusive for too many outgoing connections on port 22. Their network monitoring software tripped the alert as possible SSH scan / exit relay activity. After a few days of working with them, the issue is finally resolved as they now understand it was not malicious and I am not operating an exit.
While I still don't fully understand why my server connects over port 22 to some servers listed with the OR port of 443, I clearly have more to learn about Tor functionality. Regardless, many providers monitor proactively for malicious traffic patterns. Many outgoing connections on port 22 appear as SSH scans/brute forcing to a provider. 25 often appear as spam and 53 as DNS reflection attacks.
I've worked with many providers that do not provide good support and will instantly suspend/terminate your service when they detect these traffic patterns. Some allow you to resume service after justification and the worst ones never resume your service or allow justification. While these are not providers that I'd recommend using when network diversity is important and more new users attempt to contribute to the network, this does cause additional obstacles when using some providers for hosting a relay. A port is a port but using ports 22, 25 and 53 in particular are definitely going to cause headaches for a subset of contributors.
Regards, Ryan
Ryan Getz schreef op 11/07/14 16:19:
On Fri, Jul 11, 2014, at 09:41 AM, Moritz Bartl wrote:
On 07/11/2014 11:33 AM, Roman Mamedov wrote:
Agreed, but my point was that only a small minority of relays use port 22 (checked, 27 of them - more than I expected) or port 53 (just three relays), so it may be a sacrifice that's worth making, in order to avoid losing the ability to run Tor altogether due to being kicked out by your ISP.
I don't see the point in blocking arbitrary outgoing ports for an application that is not going to make any connections other than relay connections. The danger of Tor misbehaving on port 22 or port 53 is the same as on any other port.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum.
A port is a number. None of them is special. I really don't see any reason to discriminate any.
-- Moritz Bartl https://www.torservers.net/
I agree but it depends on the service provider. I've just recently begun running some relays and while one provider confirmed I could run a non-exit relay on their network, I was later flagged as abusive for too many outgoing connections on port 22. Their network monitoring software tripped the alert as possible SSH scan / exit relay activity. After a few days of working with them, the issue is finally resolved as they now understand it was not malicious and I am not operating an exit.
While I still don't fully understand why my server connects over port 22 to some servers listed with the OR port of 443, I clearly have more to learn about Tor functionality. Regardless, many providers monitor proactively for malicious traffic patterns. Many outgoing connections on port 22 appear as SSH scans/brute forcing to a provider. 25 often appear as spam and 53 as DNS reflection attacks.
I've worked with many providers that do not provide good support and will instantly suspend/terminate your service when they detect these traffic patterns. Some allow you to resume service after justification and the worst ones never resume your service or allow justification. While these are not providers that I'd recommend using when network diversity is important and more new users attempt to contribute to the network, this does cause additional obstacles when using some providers for hosting a relay. A port is a port but using ports 22, 25 and 53 in particular are definitely going to cause headaches for a subset of contributors.
Regards, Ryan
This raises an interesting question: going forward, do we want to keep requiring all relays to be able to reach every other relay?
I run a small relay at home (10mbit-ish) and my ISP blocks all outgoing traffic to port 25 (smtp). The moment someone starts running a relay on this port, my relay will no longer be able to reach all other relays. This would mean I should stop running a relay, which is (imo) worse for the network.
In the near future it seems more likely that networks will get more closed than more open, and more and more relays will face restrictions imposed by governments or ISPs. What about relays in China? Relays there may be able to reach only 50% of the network. With smart algorithms this can be advantageous as these relays have a higher chance of being able to serve people from these countries, while being able to escape the Great Firewall.
I imagine a Chinese user connecting to a Chinese bridge which connects to a relay outside of the country, etc. This bridge may not be able to connect to every other relay, but if it properly advertises what it can reach that's fine. Of course this would allow an attacker to steer traffic, so a client may want to establish a slightly longer circuit and avoid going through more than X of these special hops.
Having relays in places that are hard to reach allows people nearby to connect more easily to the network. Not doing so means we cannot support relays in countries with government-applied internet restrictions.
It would be nice to see some discussion on this topic. Do we really want to stop people from donating bandwidth just because, simply put, they're from China?
Tom
PS: China is obviously just an example here - the same could apply to the USA.
Alright - traffic is picking up a little after 24 hour. Netfow is showing a bunch of outbound SSH connections but for some reason cant see it in the syslog going out. Added ACL for outbound SSH and will watch. Not sure WTF all the SSH traffic is all about.
gm
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Tom van der Woerdt Sent: Friday, July 11, 2014 9:05 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
Ryan Getz schreef op 11/07/14 16:19:
On Fri, Jul 11, 2014, at 09:41 AM, Moritz Bartl wrote:
On 07/11/2014 11:33 AM, Roman Mamedov wrote:
Agreed, but my point was that only a small minority of relays use port 22 (checked, 27 of them - more than I expected) or port 53 (just three relays), so it may be a sacrifice that's worth making, in order to avoid losing the ability to run Tor altogether due to being
kicked out by your ISP.
I don't see the point in blocking arbitrary outgoing ports for an application that is not going to make any connections other than relay connections. The danger of Tor misbehaving on port 22 or port 53 is the same as on any other port.
Some time ago I proposed that Tor flags some ports as being unacceptable as ORPort[1], but this did not gather much of a momentum.
A port is a number. None of them is special. I really don't see any reason to discriminate any.
-- Moritz Bartl https://www.torservers.net/
I agree but it depends on the service provider. I've just recently begun running some relays and while one provider confirmed I could run a non-exit relay on their network, I was later flagged as abusive for too many outgoing connections on port 22. Their network monitoring software tripped the alert as possible SSH scan / exit relay activity. After a few days of working with them, the issue is finally resolved as they now understand it was not malicious and I am not operating an
exit.
While I still don't fully understand why my server connects over port 22 to some servers listed with the OR port of 443, I clearly have more to learn about Tor functionality. Regardless, many providers monitor proactively for malicious traffic patterns. Many outgoing connections on port 22 appear as SSH scans/brute forcing to a provider. 25 often appear as spam and 53 as DNS reflection attacks.
I've worked with many providers that do not provide good support and will instantly suspend/terminate your service when they detect these traffic patterns. Some allow you to resume service after justification and the worst ones never resume your service or allow justification. While these are not providers that I'd recommend using when network diversity is important and more new users attempt to contribute to the network, this does cause additional obstacles when using some providers for hosting a relay. A port is a port but using ports 22, 25 and 53 in particular are definitely going to cause headaches for a subset of contributors.
Regards, Ryan
This raises an interesting question: going forward, do we want to keep requiring all relays to be able to reach every other relay?
I run a small relay at home (10mbit-ish) and my ISP blocks all outgoing traffic to port 25 (smtp). The moment someone starts running a relay on this port, my relay will no longer be able to reach all other relays. This would mean I should stop running a relay, which is (imo) worse for the network.
In the near future it seems more likely that networks will get more closed than more open, and more and more relays will face restrictions imposed by governments or ISPs. What about relays in China? Relays there may be able to reach only 50% of the network. With smart algorithms this can be advantageous as these relays have a higher chance of being able to serve people from these countries, while being able to escape the Great Firewall.
I imagine a Chinese user connecting to a Chinese bridge which connects to a relay outside of the country, etc. This bridge may not be able to connect to every other relay, but if it properly advertises what it can reach that's fine. Of course this would allow an attacker to steer traffic, so a client may want to establish a slightly longer circuit and avoid going through more than X of these special hops.
Having relays in places that are hard to reach allows people nearby to connect more easily to the network. Not doing so means we cannot support relays in countries with government-applied internet restrictions.
It would be nice to see some discussion on this topic. Do we really want to stop people from donating bandwidth just because, simply put, they're from China?
Tom
PS: China is obviously just an example here - the same could apply to the USA.
On 14-07-11 08:59 PM, Greg Moss wrote:
Alright - traffic is picking up a little after 24 hour. Netfow is showing a bunch of outbound SSH connections but for some reason cant see it in the syslog going out. Added ACL for outbound SSH and will watch. Not sure WTF all the SSH traffic is all about.
Some clarification may help regarding what ports are and how they are used. (Corrections welcome.)
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
The local process may or may not be SSH, and the remote process may or may not be SSHD - it is up to each computer's owner how they configure the processes; port 22 is merely a convention for SSH that makes it easy to remember and setup defaults.
(On Linux you can see what process is actually using each active connection with "sudo netstat -p". To see what processes are listening on which ports on your computer, it would be "sudo netstat -lp".)
If you are running a Tor exit node, you specify in the torrc to which destination ports your Tor node will allow Tor users to connect. If your torrc says "ExitPolicy reject *:22" for example, it means your exit node will not allow Tor users to connect to port 22, so don't even try to route circuits through your node. If your torrc doesnt contain that line but your firewall blocks connections to port 22, it means Tor users might try to do their SSH via your exit node and get failed connections (and your node will eventually be labelled a BadExit).
If you are running a non-exit, ie your torrc contains "ExitPolicy reject *:*", then circuits traversing your relay will only connect to other Tor nodes (on their advertised ORports); you cannot control what numbers those ports are nor choose to which relays connections are allowed. In that case you should not see any connections to port 22, except for the Tor process itself connnecting to other Tor relays which happen to use that as their ORport.
On Sat, Jul 12, 2014 at 11:32 AM, krishna e bera keb@cyblings.on.ca wrote:
the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer.
No, it may source from any unused port, assigned hopefully at random, or by successful self selection, hopefully from 49152-65535, and usually not from 0-1023 without priviledge. See ip(4). Your OS may differ.
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
I understand the dynamic port assignment computer initiating the connection to "whatever" port the remote server is listening on . What I am seeing is traffic sourced from port 22 on my relay and wondering what process or program is initiating that connection...... I have outbound port 22 blocked and am seeing a number of hits on the ACL
gm
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of krishna e bera Sent: Saturday, July 12, 2014 8:32 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 14-07-11 08:59 PM, Greg Moss wrote:
Alright - traffic is picking up a little after 24 hour. Netfow is showing a bunch of outbound SSH connections but for some reason cant see it in the syslog going out. Added ACL for outbound SSH and will watch. Not sure WTF all the SSH traffic is all about.
Some clarification may help regarding what ports are and how they are used. (Corrections welcome.)
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
The local process may or may not be SSH, and the remote process may or may not be SSHD - it is up to each computer's owner how they configure the processes; port 22 is merely a convention for SSH that makes it easy to remember and setup defaults.
(On Linux you can see what process is actually using each active connection with "sudo netstat -p". To see what processes are listening on which ports on your computer, it would be "sudo netstat -lp".)
If you are running a Tor exit node, you specify in the torrc to which destination ports your Tor node will allow Tor users to connect. If your torrc says "ExitPolicy reject *:22" for example, it means your exit node will not allow Tor users to connect to port 22, so don't even try to route circuits through your node. If your torrc doesnt contain that line but your firewall blocks connections to port 22, it means Tor users might try to do their SSH via your exit node and get failed connections (and your node will eventually be labelled a BadExit).
If you are running a non-exit, ie your torrc contains "ExitPolicy reject *:*", then circuits traversing your relay will only connect to other Tor nodes (on their advertised ORports); you cannot control what numbers those ports are nor choose to which relays connections are allowed. In that case you should not see any connections to port 22, except for the Tor process itself connnecting to other Tor relays which happen to use that as their ORport.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hmm, I'm getting a bit confused now over the situation and perhaps I was off-topic for this email chain.
I was talking about my server making connections to another server's ports 22 (destination port 22). This is what sets off monitoring at some service providers as they will actively monitor some ports (22, 25, 53 are the three most common as far as I know). This is usually a proactive measure to spot potential abuses before they start receiving a large number of complaints about their customers.
When I run the netstat -p command on my relay that was flagged by my provider, I see something like: # netstat -p | grep :ssh tcp 0 0 localhost:ssh 192.111.148.38:50658 ESTABLISHED tcp 0 0 localhost:38923 42-2-24-248.static.:ssh ESTABLISHED tcp 0 0 localhost:38062 rainbowwarrior.tors:ssh ESTABLISHED tcp 0 0 localhost:43349 hosted-by.snel.com:ssh ESTABLISHED tcp 0 0 localhost:41585 lumumba.torservers.:ssh ESTABLISHED
The first result is incoming to my port 22 - to be expected, this is my own SSH session. The remainder (I'm only including a subset of these connections) are exiting my server on a random source port and connecting to the destination server on it's port 22 (my output says :ssh, rather than :22 - this doesn't mean it's actually SSH traffic).
'lsof | grep :ssh' will also display the same:
~# lsof | grep :ssh sshd 12635 root 3r IPv4 768026447 0t0 TCP localhost:ssh->192.111.148.38:50658 (ESTABLISHED) sshd 24893 root 3u IPv4 158040 0t0 TCP *:ssh (LISTEN) sshd 24893 root 4u IPv6 158041 0t0 TCP *:ssh (LISTEN) tor 28193 debian-tor TCP localhost:38062->rainbowwarrior.torservers.net:ssh (ESTABLISHED) tor 28193 debian-tor TCP localhost:38923->42-2-24-248.static.netvigator.com:ssh (ESTABLISHED) tor 28193 debian-tor TCP localhost:41585->lumumba.torservers.net:ssh (ESTABLISHED)
The part I'm still not fully understanding... just to use the two torservers.net connections as an example, if I look at iptables, netstat or lsof, it shows I connect to rainbowwarrior and Lumumba on those server's port 22 (my source port is random - 22 is the destination port). However, when I look up either server in Atlas or Globe, both appear to be configured with OR port as 443. Therefore, I was expecting to see something more like:
debian-tor TCP localhost:41585->lumumba.torservers.net:https (ESTABLISHED) (for port 443)
As far as the comment on restricting what ports are available to be used for the OR port, I cannot comment on whether ports should be restricted or remain unrestricted. Having worked for a company that provides hosting/dedicated servers, I have seen more and more companies begin to implement proactive monitoring in an attempt to identify malicious traffic being sourced from their network in recent years. While the number of companies doing this remains small, it may be worth a larger discussion on what would be best for Tor. I was able to keep my relay running by proving that all of my outgoing connections to a destination port 22 were all Tor relays and my server was not doing anything malicious. Many other contributors of relays may have faced termination in a similar circumstance.
Greg - my understanding from your last email is that you see traffic exiting *your* server on it's own port 22, to a random destination port. the lsof command above should show what process on your server is responsible for that traffic. However, especially if you have SSH listening on port 22, I really would not expect port 22 to be used as a source port for outgoing traffic on your server. As grarpamp pointed out, the first 1023 ports are usually excluded from being chosen as a source port and this should be especially true if you have a service configured to listen on that port.
Regards, Ryan
On Sat, Jul 12, 2014, at 05:01 PM, Greg Moss wrote:
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
I understand the dynamic port assignment computer initiating the connection to "whatever" port the remote server is listening on . What I am seeing is traffic sourced from port 22 on my relay and wondering what process or program is initiating that connection...... I have outbound port 22 blocked and am seeing a number of hits on the ACL
gm
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of krishna e bera Sent: Saturday, July 12, 2014 8:32 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 14-07-11 08:59 PM, Greg Moss wrote:
Alright - traffic is picking up a little after 24 hour. Netfow is showing a bunch of outbound SSH connections but for some reason cant see it in the syslog going out. Added ACL for outbound SSH and will watch. Not sure WTF all the SSH traffic is all about.
Some clarification may help regarding what ports are and how they are used. (Corrections welcome.)
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
The local process may or may not be SSH, and the remote process may or may not be SSHD - it is up to each computer's owner how they configure the processes; port 22 is merely a convention for SSH that makes it easy to remember and setup defaults.
(On Linux you can see what process is actually using each active connection with "sudo netstat -p". To see what processes are listening on which ports on your computer, it would be "sudo netstat -lp".)
If you are running a Tor exit node, you specify in the torrc to which destination ports your Tor node will allow Tor users to connect. If your torrc says "ExitPolicy reject *:22" for example, it means your exit node will not allow Tor users to connect to port 22, so don't even try to route circuits through your node. If your torrc doesnt contain that line but your firewall blocks connections to port 22, it means Tor users might try to do their SSH via your exit node and get failed connections (and your node will eventually be labelled a BadExit).
If you are running a non-exit, ie your torrc contains "ExitPolicy reject *:*", then circuits traversing your relay will only connect to other Tor nodes (on their advertised ORports); you cannot control what numbers those ports are nor choose to which relays connections are allowed. In that case you should not see any connections to port 22, except for the Tor process itself connnecting to other Tor relays which happen to use that as their ORport.
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
Ryan -
The remainder (I'm only including a subset of these connections) are exiting my server on a random source port and connecting to the destination server on it's port 22.
As long as I don't get flagged by my ISP I am ok with above. As stated below I was seeing traffic originating from source 22 on my relay which got my attention (my relay is not listening on port 22). I have since blocked outbound port 22 and still seeing hits my ACL. My attack service is minimal on the relay is running in a DMZ with ONLY Tor OR port 8080 and DIR port 9030 exposed to the outside. My concern is in the event it was somehow compromised ( Tor exploit or some other type of attack) that I am able to see and identify that "malicious" traffic connection outbound. That goes along with opening up all outbound ports. If a backdoor or Trojan happed to get installed I want to be able to identify that traffic and ports used assuming it doesn't wrap and tunnel it though the Tor service.
Greg
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Ryan Getz Sent: Sunday, July 13, 2014 12:23 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
Hmm, I'm getting a bit confused now over the situation and perhaps I was off-topic for this email chain.
I was talking about my server making connections to another server's ports 22 (destination port 22). This is what sets off monitoring at some service providers as they will actively monitor some ports (22, 25, 53 are the three most common as far as I know). This is usually a proactive measure to spot potential abuses before they start receiving a large number of complaints about their customers.
When I run the netstat -p command on my relay that was flagged by my provider, I see something like: # netstat -p | grep :ssh tcp 0 0 localhost:ssh 192.111.148.38:50658 ESTABLISHED tcp 0 0 localhost:38923 42-2-24-248.static.:ssh ESTABLISHED tcp 0 0 localhost:38062 rainbowwarrior.tors:ssh ESTABLISHED tcp 0 0 localhost:43349 hosted-by.snel.com:ssh ESTABLISHED tcp 0 0 localhost:41585 lumumba.torservers.:ssh ESTABLISHED
The first result is incoming to my port 22 - to be expected, this is my own SSH session. The remainder (I'm only including a subset of these connections) are exiting my server on a random source port and connecting to the destination server on it's port 22 (my output says :ssh, rather than :22 - this doesn't mean it's actually SSH traffic).
'lsof | grep :ssh' will also display the same:
~# lsof | grep :ssh sshd 12635 root 3r IPv4 768026447 0t0 TCP localhost:ssh->192.111.148.38:50658 (ESTABLISHED) sshd 24893 root 3u IPv4 158040 0t0 TCP *:ssh (LISTEN) sshd 24893 root 4u IPv6 158041 0t0 TCP *:ssh (LISTEN) tor 28193 debian-tor TCP localhost:38062->rainbowwarrior.torservers.net:ssh (ESTABLISHED) tor 28193 debian-tor TCP localhost:38923->42-2-24-248.static.netvigator.com:ssh (ESTABLISHED) tor 28193 debian-tor TCP localhost:41585->lumumba.torservers.net:ssh (ESTABLISHED)
The part I'm still not fully understanding... just to use the two torservers.net connections as an example, if I look at iptables, netstat or lsof, it shows I connect to rainbowwarrior and Lumumba on those server's port 22 (my source port is random - 22 is the destination port). However, when I look up either server in Atlas or Globe, both appear to be configured with OR port as 443. Therefore, I was expecting to see something more like:
debian-tor TCP localhost:41585->lumumba.torservers.net:https (ESTABLISHED) (for port 443)
As far as the comment on restricting what ports are available to be used for the OR port, I cannot comment on whether ports should be restricted or remain unrestricted. Having worked for a company that provides hosting/dedicated servers, I have seen more and more companies begin to implement proactive monitoring in an attempt to identify malicious traffic being sourced from their network in recent years. While the number of companies doing this remains small, it may be worth a larger discussion on what would be best for Tor. I was able to keep my relay running by proving that all of my outgoing connections to a destination port 22 were all Tor relays and my server was not doing anything malicious. Many other contributors of relays may have faced termination in a similar circumstance.
Greg - my understanding from your last email is that you see traffic exiting *your* server on it's own port 22, to a random destination port. the lsof command above should show what process on your server is responsible for that traffic. However, especially if you have SSH listening on port 22, I really would not expect port 22 to be used as a source port for outgoing traffic on your server. As grarpamp pointed out, the first 1023 ports are usually excluded from being chosen as a source port and this should be especially true if you have a service configured to listen on that port.
Regards, Ryan
On Sat, Jul 12, 2014, at 05:01 PM, Greg Moss wrote:
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
I understand the dynamic port assignment computer initiating the connection to "whatever" port the remote server is listening on . What I am seeing is traffic sourced from port 22 on my relay and wondering what process or program is initiating that connection...... I have outbound port 22 blocked and am seeing a number of hits on the ACL
gm
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of krishna e bera Sent: Saturday, July 12, 2014 8:32 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 14-07-11 08:59 PM, Greg Moss wrote:
Alright - traffic is picking up a little after 24 hour. Netfow is showing a bunch of outbound SSH connections but for some reason cant see it in the syslog going out. Added ACL for outbound SSH and will watch. Not sure WTF all the SSH traffic is all about.
Some clarification may help regarding what ports are and how they are used. (Corrections welcome.)
When we say a process connects on port 22 we mean a process on the local computer tries to connect to a remote computer on its port 22, ie 22 is the "destination". The process on the local computer will use a random numbered "source" port (from 1 to 65535) on leaving the local computer. On the remote computer, there will be a process listening on its inbound port 22.
The local process may or may not be SSH, and the remote process may or may not be SSHD - it is up to each computer's owner how they configure the processes; port 22 is merely a convention for SSH that makes it easy to remember and setup defaults.
(On Linux you can see what process is actually using each active connection with "sudo netstat -p". To see what processes are listening on which ports on your computer, it would be "sudo netstat -lp".)
If you are running a Tor exit node, you specify in the torrc to which destination ports your Tor node will allow Tor users to connect. If your torrc says "ExitPolicy reject *:22" for example, it means your exit node will not allow Tor users to connect to port 22, so don't even try to route circuits through your node. If your torrc doesnt contain that line but your firewall blocks connections to port 22, it means Tor users might try to do their SSH via your exit node and get failed connections (and your node will eventually be labelled a BadExit).
If you are running a non-exit, ie your torrc contains "ExitPolicy reject *:*", then circuits traversing your relay will only connect to other Tor nodes (on their advertised ORports); you cannot control what numbers those ports are nor choose to which relays connections are allowed. In that case you should not see any connections to port 22, except for the Tor process itself connnecting to other Tor relays which happen to use that as their ORport.
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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Friday 11 July 2014 11:02:00 Moritz Bartl wrote:
Correct. Your relay in any case needs to be able to connect to all relays.
Unfortunately the assumption that every relay is able to connect to any other relay does not hold. See https://trac.torproject.org/projects/tor/ticket/12131 If you find your relay in the top 100 of relays having either inbound or outbound connectivity issues, please fix it!
Best, Robert
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Thanks for the help. I have my ORport and DIRport defined in torrc and forwarded through the firewall up to the Tor Relay. I was just wondering in regards to outbound traffic from the server itself.
What type of tor server did you decide to run (relay, exit, bridge)?
I feel you are rushing things a little.
Do some more reading.
Personally I suggest an exit relay, but without informing yourself first, how can you make an informed choice? An exit may be worse, or better, given your needs/ intentions of what you want to achieve here.
In the event it gets compromised I really hate to open all ports outbound let alone possible DNS leaks and what not. Appoligize if this doesn't make since I just fired this thing up yesterday and want to make sure it is secure.
You want "secure". OK, so does everyone. So what's your threat model?
If you are worried about a compromised tor server, and consequent information leaks, perhaps set up whonix?
If you are just impatient, just run TBB.
If security is genuinely important, and you rush things, you are MUCH more likely to come unstuck.
If you are in a time sensitive situation, and (picking a random offtopic thought here :) wanting to do some leaks, the best thing might be to find someone you trust (who is reasonably technically literate), and pass the material to them, ask them to post it to various drop boxes and provide it (anonymously and/ or without any phone calls etc made) to their own trusted friends etc, to get the info out there.
Do this with a few different people, if you have trustworthy friends/ contacts.
Your situation sounds like you are impatient.
Go do some reading, and good luck, Zenaan
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Zenaan Harkness Sent: Thursday, July 10, 2014 6:47 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful.
Sounds like you need your config file to read. Try: /etc/tor/torrc
That will likely answer your question (hint, the answer is at least one, inbound and outbound).
Do read the material on torproject.org - there's lots of it, and much of it useful to you if you are running a relay, some of it directly so.
You might also check out whonix.org
Enjoy teh awesome tehclonogy :)
OMG dude - take a downer........
If you are in a time sensitive situation, and (picking a random offtopic thought here :) wanting to do some leaks, the best thing might be to find someone you trust (who is reasonably technically literate), and pass the material to them, ask them to post it to various drop boxes and provide it (anonymously and/ or without any phone calls etc made) to their own trusted friends etc, to get the info out there.
Do this with a few different people, if you have trustworthy friends/ contacts
Its shit like that that fucks up the whole program for everybody else. If that's what TOR NETWORK is all about then I think I will just sit back and watch!
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Zenaan Harkness Sent: Thursday, July 10, 2014 8:47 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Thanks for the help. I have my ORport and DIRport defined in torrc and forwarded through the firewall up to the Tor Relay. I was just wondering in regards to outbound traffic from the server itself.
What type of tor server did you decide to run (relay, exit, bridge)?
I feel you are rushing things a little.
Do some more reading.
Personally I suggest an exit relay, but without informing yourself first, how can you make an informed choice? An exit may be worse, or better, given your needs/ intentions of what you want to achieve here.
In the event it gets compromised I really hate to open all ports outbound let alone possible DNS leaks and what not. Appoligize if this doesn't make since I just fired this thing up yesterday and want to make sure it is secure.
You want "secure". OK, so does everyone. So what's your threat model?
If you are worried about a compromised tor server, and consequent information leaks, perhaps set up whonix?
If you are just impatient, just run TBB.
If security is genuinely important, and you rush things, you are MUCH more likely to come unstuck.
If you are in a time sensitive situation, and (picking a random offtopic thought here :) wanting to do some leaks, the best thing might be to find someone you trust (who is reasonably technically literate), and pass the material to them, ask them to post it to various drop boxes and provide it (anonymously and/ or without any phone calls etc made) to their own trusted friends etc, to get the info out there.
Do this with a few different people, if you have trustworthy friends/ contacts.
Your situation sounds like you are impatient.
Go do some reading, and good luck, Zenaan
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Zenaan Harkness Sent: Thursday, July 10, 2014 6:47 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports
On 7/11/14, Greg Moss gmoss82@gmail.com wrote:
Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful.
Sounds like you need your config file to read. Try: /etc/tor/torrc
That will likely answer your question (hint, the answer is at least one, inbound and outbound).
Do read the material on torproject.org - there's lots of it, and much of it useful to you if you are running a relay, some of it directly so.
You might also check out whonix.org
Enjoy teh awesome tehclonogy :)
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
grarpamp -
Greg Moss -
Kali Tor -
krishna e bera -
Moritz Bartl -
ra -
Roman Mamedov -
Ryan Getz -
Tom van der Woerdt -
Zenaan Harkness