E
Eric Hansen
Guest
After writing a few articles on Tor and how to operate it I thought I’d dive more into the configuring it to be more secure from an end-user’s standpoint. This won’t cover being an exit node as personally should you enter that aspect of Tor you should already know what you’re doing (otherwise don’t do it).
Instead I’ll be dissecting the torrc file we’ve edited in the past and go into detail about what the features do. The first is SocksPolicy:
Entries here will either be allowed (accept) or denied (reject) via Tor to pass through your Tor instance. I can see this being useful if you’re doing an exit node but its also helpful for regular nodes too (since every Tor node routes traffic through it regardless). If you don’t or can’t allow traffic coming from a specific location you can specify the IP address and/or subnet here of that location to disallow (or allow). Think of it as basically Tor’s personal firewall.
This specifies how much traffic is allowed through Tor on your network before Tor stops relaying traffic for the day, week or month. First you specify “AccountMax” (default is 4 GB) which states what the cap is for upstream and downstream separately (i.e.: 8 GB total [4 GB up / 4 GB down]). Next specify when the bandwidth accountant restarts. The first example is every day at midnight, while the second example is every 3rd of the month at 3 PM (15:00). This lets you make sure your bandwidth isn’t all going towards Tor and also doesn’t bog down your network.
ExitPolicy acts as an aide of sorts (or also on its own) to SocksPolicy. Any traffic that matches what’s shown in the ExitPolicy is handled accordingly. Tor reads it from left to right, but Tor does suggest to not to use the default exit policy. To do this you specify either “reject *:*” or “accept *:*”. The ExitPolicy can match IP, port or both.
Since a lot of ISPs, firewalls, etc… have restrictions on the traffic flow, ports and whatnot this helps to improve the performance of the Tor traffic flowing through your network as well. This way Tor doesn’t have to assume it can fit traffic through a specific, it will just automatically know and act accordingly.
If you have multiple adapters (which would make dealing with Tor and regular traffic) you can tell Tor which adapter to use specifically. This will make it so you can delegate one adapter strictly for normal Internet use while the other handles Tor traffic exclusively. While not greatly a security risk, it does trick packet sniffers that are trying to eavesdrop on Tor traffic without your knowledge.
There really isn't a lot to "securing" Tor as its meant to be anonymous and the best way to do that is to only provide enough customization to make it effective. However, you can still vastly improve the speed of Tor network traffic with some simple changes (i.e.: the ExitPolicy).
Instead I’ll be dissecting the torrc file we’ve edited in the past and go into detail about what the features do. The first is SocksPolicy:
Code:
#SocksPolicy accept 192.168.0.0/16
#SocksPolicy reject *
Code:
#AccountingMax 4 GB
#AccountingStart day 00:00
#AccountingStart month 3 15:00
Code:
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more
#ExitPolicy accept *:119 # accept nntp as well as default exit policy
#ExitPolicy reject *:* # no exits allowedSince a lot of ISPs, firewalls, etc… have restrictions on the traffic flow, ports and whatnot this helps to improve the performance of the Tor traffic flowing through your network as well. This way Tor doesn’t have to assume it can fit traffic through a specific, it will just automatically know and act accordingly.
Code:
# OutboundBindAddress 10.0.0.5There really isn't a lot to "securing" Tor as its meant to be anonymous and the best way to do that is to only provide enough customization to make it effective. However, you can still vastly improve the speed of Tor network traffic with some simple changes (i.e.: the ExitPolicy).
