This post inaugurates a series about a collection of system-administration tools and good practices that will make your life as a Tor operator better and easier. This series actually started as a single post, but it grew so large that I finally decided to restructure it completely and present it in 3 separate posts, with the following plan:
- in the first post (this one), I will follow the basic steps that you need to cover when creating a new Tor node. This is a basic setup that will get you up and running while preventing several problems and giving you basic tools to monitor your node. This post can be applied to the setup of either middle or exit nodes;
- in part 2, I will cover in more detail some software and tools specific for exit nodes;
- in part 3, I will present more advanced tools that you can deploy at a later time;
Finally, while the use case is setting up and running a Tor relay some of these tools and practices are actually applicable to any server you manage – i.e. any server where you have administartive powers – and they can prevent or solve a variety of problems.
Before installing Tor
The typical scenario I will refer to is the one of Virtual Private Servers that you can buy through many services. If you want to run an exit node, this is the recommended choice, even the Tor Legal FAQs advice not to run an exit relay from home [1]Relevant quote: — Should I run an exit relay from my home? No. If law enforcement becomes interested in traffic from your exit relay, it’s possible that officers will seize your computer. … Continue reading, instead you can consult the Good/Bad ISPs page on the Tor wiki. There you can find several services in several countries and some opinions from other Tor operators.
I will also suppose that you are running a Linux-based system. I would recommend to use Debian where you can install the latest version of Tor very easily.
So, let’s suppose that you have just created your VPS through your favorite service and it is running Debian. Let’s start with taking care of some system configuration.
1. Secure your SSH configuration
You should always use SSH keys to log in you remote servers. There are documented cases of botnets that can be active for years, with thousands of machines and different IPs that will tray to break in your server just by brute-force randomly trying many combinations of users and passwords.
See the instruction in the post about port-knocking for a detailed how-to on how to change the SSH configuration to disable password authentication and change the port on which SSH listens for connections.
For creating your own keypair and copying it on you server you can reference this guide on Digital Ocean.
2. Enable automatic security updates
You should really enable automatic updates now on all the servers you have root on.
You can install and enable the unattended-upgrades
package to automatically download and install security updates.
1 2 3 |
$ apt-get install unattended-upgrades $ wget -p -O /etc/apt/apt.conf.d/50unattended-upgrades https://raw.githubusercontent.com/torservers/server-config-templates/master/50unattended-upgrades $ cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades # enable |
(source: Torservers.net)
3. Add swap
On some of the services that I have tried, when you launch a new server there is no swap partition preset. Swap space is “a preconfigured space on the hard disk used to free up (swapping) a page of memory”, that is a chunk of data used by an application. The combined sizes of the physical memory and the swap space is the amount of virtual memory available (source). If your system runs out of memory some application will crash and, in the case of system applications, this can have many unintended consequences and give rise to weird bugs.
Even the smallest virtual servers come with hard disks of several GBs (10-20 GB at least) and your Tor relay will not need them for storage, so it is wise to create a swapfile that will be used effectively as swap space by your system. You can follow this guide on Digital Ocean, it is applicable both to Ubuntu and Debian-based system and I suppose will work on other distributions too.
On one of my relays, with 512MB of RAM and 20GB of hard disk I have created a 4GB swapfile and I have still plenty of free space left on disk.
1 2 3 4 5 |
$ free -mh total used free shared buffers cached Mem: 497M 472M 24M 0B 476K 9,7M -/+ buffers/cache: 462M 34M Swap: 4,0G 596M 3,4G |
4. Raise apt-cache limit
One bug that I have experienced while running a Tor relay was a weird apt bug that cause my system to crash completely, putting the node offline for a while. This problem basically stems from the fact that the Debian package manager apt
was not able to allocate enough memory for its cache.
You can create a configuration file named 99cache-start
for apt
in the directory /etc/apt/apt.conf.d/
:
1 2 |
~root> cd /etc/apt/apt.conf.d/ /etc/apt/apt.conf.d# vim 99cache-start |
and add the following two lines:
1 2 |
APT::Cache-Start "201326592"; APT::Cache-Limit "0"; |
Then you can clean the apt cache:
1 |
~root> apt-get clean && apt-get update --fix-missing && apt-get upgrade |
This configuration increases the memory available to apt
for its cache[2]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
man apt.conf | grep Cache-Start -B1 -A5 Cache-Start, Cache-Grow, Cache-Limit APT uses since version 0.7.26 a resizable memory mapped cache file to store the available information. Cache-Start acts as a hint of the size the cache will grow to, and is therefore the amount of memory APT will request at startup. The default value is 20971520 bytes (~20 MB). Note that this amount of space needs to be available for APT; otherwise it will likely fail ungracefully, so for memory restricted devices this value should be lowered while on systems with a lot of configured sources it should be increased. Cache-Grow defines in bytes with the default of 1048576 (~1 MB) how much the cache size will be increased in the event the space defined by Cache-Start is not enough. This value will be applied again and again until either the cache is big enough to store all information or the size of the cache reaches the Cache-Limit. The default of Cache-Limit is 0 which stands for no limit. If Cache-Grow is set to 0 the automatic growth of the cache is disabled. |
(source: debian.net Forum).
.
5. Install ntp
NTP stands for Network Time Protocol, installing the ntp
package will keep you system date with exact match to actual date (source):
1 |
$ sudo apt-get install ntp |
6. Install some system-monitoring tools: vnstat, sysstat, nmon and arm
There are several tools that are useful for monitoring the general status of your server. Please note that this monitoring tools allow the collection of general statistic to check the health status of the server, these tool do not log or monitor individual connections.
You can install all these tools with the following command:
1 |
$ sudo apt-get install vnstat tor-arm sysstat nmon |
- vnStat
Quoting from the official site of the project: «vnStat is a console-based network traffic monitor for Linux and BSD that keeps a log of network traffic for the selected interface(s). It uses the network interface statistics provided by the kernel as information source. This means that vnStat won’t actually be sniffing any traffic and also ensures light use of system resources.»
You can edit the vnStat configuration file /etc/vnstat.conf
to specify the network interface and disable the badwith limits on that interface:
1 2 3 4 5 6 7 8 9 10 11 |
# vnStat 1.11 config file ## # default interface Interface "eth0" # ... other configuration options ... # maximum bandwidth (Mbit) for all interfaces, 0 = disable feature # (unless interface specific limit is given) MaxBandwidth 0 |
After installing vnStat you can use the command vnstat
to read traffic statistics of
your network interface, as in the example below:
1 2 3 4 5 6 7 8 |
$ vnstat rx / tx / total / estimated eth0: Jul '16 30.21 TiB / 30.48 TiB / 60.69 TiB Aug '16 7.58 TiB / 7.68 TiB / 15.26 TiB / 59.78 TiB yesterday 0.99 TiB / 1.00 TiB / 1.99 TiB today 975.58 GiB / 988.33 GiB / 1.92 TiB / 2.10 TiB |
- arm
arm stands for “the Anonymizing Relay Monitor” and it is a CLI status monitor for Tor. It shows a real-time monitor of dowload/upload bandwith used by Tor, and other useful info.
It is advised to run arm
with the same user as Tor (and not as root
), on Debian systems the user is debian-tor
, so I have create the following alias (it is also helpful because if I look for a command about “stats” it shows up):
1 |
alias stats-arm='sudo -u debian-tor arm' |
- Sysstat (sar)
Sysstat is a package of performance monitoring tools for Linux, in particular it containssar
, a tool to collect and reports system activity information (sources: 1, 2).
After you install sysstat, you have to change its configuation in /etc/default/sysstat
to enable data collection and then restart the systat
service.
1 2 3 |
$ sudo apt-get install sysstat $ sudo vi /etc/default/sysstat #change ENABLED=”false” to ENABLED=”true” $ sudo service sysstat restart |
You can obtain the system statistics using, the sar
command.
1 2 3 4 5 6 7 8 9 10 11 |
$ sar -A Linux 3.2.0-4-amd64 ([hostanme]) 13/08/2016 _x86_64_ (1 CPU) 00:00:01 CPU %usr %nice %sys %iowait %steal %irq %soft %guest %idle 00:05:01 all 43,26 0,00 17,82 0,02 0,30 0,00 17,14 0,00 21,47 00:05:01 0 43,26 0,00 17,82 0,02 0,30 0,00 17,14 0,00 21,47 00:15:01 all 40,18 0,00 17,07 0,01 0,30 0,00 17,29 0,00 25,15 00:15:01 0 40,18 0,00 17,07 0,01 0,30 0,00 17,29 0,00 25,15 00:25:01 all 40,53 0,00 17,21 0,20 0,30 0,00 17,01 0,00 24,75 00:25:01 0 40,53 0,00 17,21 0,20 0,30 0,00 17,01 0,00 24,75 00:35:01 all 39,11 0,00 18,00 0,21 0,30 0,00 17,04 0,00 25,34 |
- nmon
nmon
stands for “Nigel’s performance Monitor”, with respect to systat it provides nice graphs in the console. You can also use it in capture mode.
After installing, you can start it simply by typing nmon
:
1 2 |
$ sudo apt-get install nmon $ nmon |
You are now ready for installing Tor
Now you have a basic set of tools in your tools box and you can proceed to install Tor, rad carefully the torrc
configuration file – which on Debian system is under /etc/tor/torrc
– and modify it following the guide provided by the extensive comments. You can choose at this moment if you want to set up an exit or a middle node, even if I would advice to wait for the tools in part 2 if you are intrested in setting up and exit node.
Pay attention to the bandwith limits, because providers sell with each “VPS package” only limited bandwith with total data transfer caps over a period of time (typically monthly), and if you go over the cap usually you pay for each additional MB of data consumed (i.e. transfered) an extra amount, so fees can ramp up very steeply.
Finally, do not forget to subscribe to the tor-announce mailing list, I recommend also that you subscribe to the tor-relays list which has much ore traffic, but it has also more information about good setups and god practices for running Tor nodes.
References
↑1 | Relevant quote: — Should I run an exit relay from my home? No. If law enforcement becomes interested in traffic from your exit relay, it’s possible that officers will seize your computer. For that reason, it’s best not to run your exit relay in your home or using your home Internet connection. Instead, consider running your exit relay in a commercial facility that is supportive of Tor. Have a separate IP address for your exit relay, and don’t route your own traffic through it. |
---|---|
↑2 | [crayon-6480d4ac334c5509478405/] (source: debian.net Forum). |