A handy trio of tools for protecting your privacy
Creating a Tor Relay
If you want to get deeper into using Tor, try becoming a relay. If you configure a relay system, you are contributing to the Tor network. Relaying servers communicate with the rest of the Tor network by default on TCP Port 9001.
To configure Tor to relay remote connections, edit the /etc/tor/torrc file
and change the SocksPort
value to read:
SocksPort 0
As a result, this system will not accept local connections. Of course, you can change the standard SocksPort value to anything you wish, but I prefer using the above value. Once you have made the above changes, restart Tor so that they take effect. Now, your system will become part of the Tor network. For more configuration options, see the box titled "Throttling and Listening Addresses."
Throttling and Listening Addresses
Tor turns your system into a sophisticated VPN server. As with any sophisticated system, it is possible to create custom settings. You do this by editing the /etc/tor/torrc
file.
For example, you'll likely become concerned about bandwidth usage if you decide to become a Tor relay. Tor tends to communicate by doing bulk transfers. A large transfer might end up using more bandwidth than you wish to give. Therefore, you can throttle back your settings. For example, if you wish to throttle bandwidth to 50Kbps, you would uncomment the RelayBandwidthRate
setting, then change the value as follows:
RelayBandwidthRate 50 KB # Throttle traffic to 50KB/s (400Kbps)
It is also possible to throttle back specific traffic bursts:
RelayBandwidthBurst 100 KB # But allow bursts up to 100KB/s (800Kbps)
Some of us have ISPs that count each byte so they can charge more each month if we exceed a predefined bandwidth usage. If Tor uses too much total bandwidth, the price can get high. So, you can set a maximum amount of bandwidth for a specific period. To do this, uncomment the AccountingMax
value, then add a number that works for you. For example, if you wish to set a limit of 1GB, your entry would appear as follows:
AccountingMax 1 GB
You will need to set a starting point. In this case, you likely would want to start at a particular day in the month:
## Each period starts daily at midnight (AccountingMax is per day) AccountingStart month 9 11:00
In the preceding entry, Tor restarts its accounting at 11:00am on the ninth of the month.
Your system might have multiple network interfaces. If you wish, you can tell Tor to listen on a specific interface, rather than the loopback address (127.0.0.1). If you specify the loopback address, Tor will listen on all interfaces. To tell Tor to run only one of the network cards, add the following entry:
SocksListenAddress 192.168.15.3:9050
In the preceding entry, Tor will listen on TCP port 9050 on the 192.168.15.3 interface.
Creating a Rendezvous Point
It is possible to mask your instance of your Tor system. A masked server is called a rendezvous point. In this case, Tor no longer listens on default ports. You can specify a port, which helps mask the instance. You can also make your system appear as if it is simply running a web server, when it is actually running Tor.
For example, you can advertise your Tor server as an SSL/TLS-protected web server that listens on the standard TCP port 443. Yet your system is actually simply forwarding connections on port 443 to Tor, which is listening on custom port number 9191:
ORListenAddress 0.0.0.0:9191
The preceding entry tells Tor to listen on the 9191 port. You will, however, need to forward your IP traffic from port 443 to the proper port using iptables:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 443 -j REDIRECT --to-ports 127.0.0.1:9191
The preceding entry tells your system to forward connections going to port 443 to the port you have specified. Remember that each time you edit the /etc/tor/torrc
file, you will need to restart Tor.
Timing is Everything with Tor
As with most network-aware services, it's important to make sure your system has accurate clock settings. Your computer will have to work and play well with other systems, which means you'll need to be sure you have accurate information for the date, time zone, and clock time.
If your system doesn't have coherent time settings, your traffic will get dropped. System time is especially critical when configuring tor as a relay.
So, make sure you install and run a good Network Time Protocol (NTP) client, such as Open NTP (openntpd
). You don't need to become an NTP server. Most Linux distros have these services already installed and running; however, if you don't have them, take the necessary steps. In my Ubuntu Linux system, I would issue the following command to get the client:
$ sudo apt-get install ntpdate
The following command installs the server, in case you should need it:
$ sudo apt-get install openntpd
Your commands will differ if you're using a Red Hat-based system, of course. Once you have installed the relevant NTP element, make sure you have edited the relevant files, which might include /etc/ntp.conf
. Then, add at least two time server entries, such as:
server im.pool.ntp.org, server pool.ntp.org
You might need to edit your network perimeter firewall settings as well. Your network perimeter firewall will be the most likely culprit for blocking NTP-based traffic. However, I've also run into instances where zealous individuals use iptables to manage and block traffic types. So, make sure you have unblocked NTP-based ports on your local system in addition to your perimeter firewall.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.