The Tor Project (The onion routing) is an open source implementation of onion routing that provides free access to an anonymous proxy network. Its primary goal is to enable online anonymity by protecting against traffic analysis attacks.
Users of the Tor network run an onion proxy software on their machines, which presents a SOCKS interface to its clients. This software connects out to Tor, periodically negotiating a virtual circuit through the Tor network. Tor employs cryptography in a layered manner (hence the ‘onion’ analogy), ensuring forward secrecy between routers.
Through this process the onion proxy manages networking traffic for end-user anonymity. It keeps a user anonymous by encrypting traffic, sending it through other nodes of the Tor network, and decrypting it at the last node to receive your traffic before forwarding it to the server you specified. One trade off is that using Tor can be considerably slower than a regular direct connection, due to the large amount of traffic re-routing. Additionally, although Tor provides protection against traffic analysis it cannot prevent traffic confirmation at the boundaries of the Tor network (i.e. the traffic entering and exiting the network). See Wikipedia:Tor (anonymity network) for more information.
Nyx is a command line monitor for Tor, it provides bandwidth usage, connection details and on-the-fly configuration editing. To use it, install the nyx package.
The allows other programs to monitor and modify your Tor node’s configuration while it is running, or get details about the status of the Tor network and its circuits.
You can use this command to check the permissions:
Tor offers a built-in tunneled HTTP proxy and can also be used with an HTTP proxy like Privoxy; however, using the SOCKS5 library is generally recommended.
You can also use this setup in other applications like messaging (e.g. Jabber, IRC clients). Applications that support HTTP proxies you can connect to Privoxy (i.e. ). To use SOCKS proxy directly, you can point your application at Tor (i.e. ). A problem with this method though is that applications doing DNS resolves by themselves may leak information. Consider using Socks4A (e.g. with Privoxy) instead.
In order to use an instant messaging client with tor, we do not need an HTTP proxy like privoxy. We will be using tor’s daemon directly which listens to port 9050 by default.
You can set up Pidgin to use Tor globally, or per account. To use Tor globally, go to Tools -> Preferences -> Proxy. To use Tor for specific accounts, go to Accounts > Manage Accounts, select the desired account, click Modify, then go to the Proxy tab. The proxy settings are as follows:
Libera Chat recommends connecting to directly. It also requires SASL to identify to NickServ during connection; see Irssi#Authenticating with SASL. Start irssi:
Set your identification to nickserv, which will be read when connecting. Supported mechanisms are ECDSA-NIST256P-CHALLENGE (see ecdsatool) and PLAIN. DH-BLOWFISH is not supported.
Disable CTCP and DCC and set a different hostname to prevent information disclosure: [3]
Pacman download operations (repository databases, packages, and public keys) can be done using the Tor network.
Note on GPG: On stock Arch, pacman only trust keys which are either signed by you (that can be done with ) or signed by 3 of 5 Arch master keys. If a malicious exit node replaces packages with ones signed by its key, pacman will not let the user install the package.
The Tor network is reliant on people contributing bandwidth and setting up services. There are several ways to contribute to the network.
Also known as non-exit relays: A guard relay is the first hop in a Tor circuit, while a middle relay acts as the second hop.
This means that your machine will act as an entry node or forwarding relay and, unlike a bridge, it will be listed in the public Tor directory. Your IP address will be publicly visible in the Tor directory but the relay will only forward to other relays or Tor exit nodes, not directly to the internet.
To setup a non-exit relay, see [4] and [5].
A Tor bridge is a Tor relay that is not listed in the public Tor directory, thus making it possible for people to connect to the Tor network when governments or ISPs block all public Tor relays. Visit https://bridges.torproject.org/ for more information and instructions on how to get bridge addresses.
To setup a Tor bridge, see [6] and [7].
Any requests from a Tor user to the regular internet must exit the Tor network at some point, and exit relays provide this essential service. To the destination host, these requests will appear to originate from your machine. This means that running an exit relay is typically viewed as more legally burdensome than running other types of Tor relays.
Tor opens a socks proxy on port 9050 by default — even if you do not configure one. Set if you plan to run Tor only as a relay, and not make any local application connections yourself.
changes logging to stdout, which is also the Tor default.
should reflect your public IP and netmask, which can be obtained with the command , so exit connections cannot connect to the host or neighboring machines public IP and circumvent firewalls.
reduces disk writes and wear on SSD.
“will attempt to lock all current and future memory pages, so that memory cannot be paged out”.
If returns that your CPU supports AES instructions and returns that the module is loaded, you can specify which tries “to use built-in (static) crypto hardware acceleration when available”, see https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration.
Setup and learn to use iptables. Instead of being a Simple stateful firewall where connection tracking would have to track thousands of connections on a tor exit relay this firewall configuration is stateless.
allow already established incoming TCP connections per the rules below and TCP connections established from the exit node.
allow all incoming UDP connections because we do not use connection tracking.
You can use pdnsd to cache DNS queries locally, so the exit relay can resolve DNS faster and the exit relay does not forward all DNS queries to an external DNS recursor.
This configuration stub shows how to cache queries to your normal DNS recursor locally and increase pdnsd cache size to 100MB.
The tor 0.2.x series also provides a built-in DNS forwarder. To enable it, add the following lines to the Tor configuration file and restart the daemon:
This will allow tor to accept DNS requests (listening on port ) like a regular DNS server, and resolve the domain via the Tor network.
A downside of both methods is that they are only able to resolve DNS queries for A, AAAA and PTR records; MX and NS queries are never answered. For more information see this Debian-based introduction.
It is possible to configure your system to use Tor DNS for any A, AAAA, and PTR queries your system makes, regardless of whether you eventually use Tor to connect to your final destination. To do this, configure your system to use as its DNS server and edit the line in to show:
Alternatively, you can use a local caching DNS server, such as dnsmasq or pdnsd, which will also compensate for Tor DNS being a little slower than traditional DNS servers. The following instructions will show how to set up dnsmasq for this purpose. Note, if you are using NetworkManager you will need to add your configuration file to the location outlined in NetworkManager#dnsmasq.
Change the tor setting to listen for the DNS request in port and install dnsmasq.
Modify its configuration file so that it contains:
These configurations set dnsmasq to listen only for requests from the local computer, and to use Tor DNS at its sole upstream provider. It is now necessary to edit so that your system will query only the dnsmasq server:
torsocks allows you to use an application through the Tor network without requiring any configuration changes to the application itself. From torsocks(1):
In some cases it is more secure and often easier to transparently torify an entire system instead of configuring individual applications to use Tor’s socks port, not to mention preventing DNS leaks. Transparent torification can be done with iptables in such a way that all outbound packets are redirected through Tor’s TransPort, except the Tor traffic itself. Once in place, applications do not need to be configured to use Tor, though Tor’s SOCKSPort will still work. This also works for DNS via Tor’s DNSPort, but realize that Tor only supports TCP, thus UDP packets other than DNS cannot be sent through Tor and therefore must be blocked entirely to prevent leaks.
Using iptables to transparently torify a system affords comparatively strong leak protection, but it is not a substitute for virtualized torification applications such as Whonix, or TorVM [16]. Transparent torification also will not protect against fingerprinting attacks on its own, so it is recommended to use an amnesic solution like Tails instead. Applications can still learn your computer’s hostname, MAC address, serial number, timezone, etc. and those with root privileges can disable the firewall entirely. In other words, transparent torification with iptables protects against accidental connections and DNS leaks by misconfigured software, it is not sufficient to protect against malware or software with serious security vulnerabilities.
When a transparent proxy is used, it is possible to start a Tor session from the client as well as from the transparent proxy, creating a “Tor over Tor” scenario. Doing so produces undefined and potentially unsafe behavior. In theory, the user could get six hops instead of three in the Tor network. However, it is not guaranteed that the three additional hops received are different; the user could end up with the same hops, possibly in reverse or mixed order. The Tor Project opinion is that this is unsafe [17] [18].
To run tor as a non-root user and use a port lower than , you can use kernel capabilities to allow it to bind to privileged ports:
If you use , it is also possible to use systemd to grant tor the appropriate permissions. This has the benefit that permissions do not need to be reapplied after every tor upgrade:
Refer to superuser.com for further explanations.
When using the Tor Browser, it is possible to use the running instead of establishing a second connection to the Tor network. Instructions are provided in the starter file for the browser, which by default is located at .
Symlink to register the container on the host, as per systemd-nspawn#Management:
Create a drop-in configuration file for the container:
creates a “macvlan” interface named and assigns it to the container, see systemd-nspawn#Use a “macvlan” or “ipvlan” interface for details. This is advisable for security as it will allow you to give a private IP to the container, and it will not know what your machine’s IP is. This can help obscure DNS requests.
Tor Browser typically works without significant customization. If the bundled proxy fails with for any website, consider reinstallation by removing the directory (make sure to back up important files).
