OnionCat Security Advisory
This security advisory shall highlight the most important issues regarding computer security when running OnionCat. Note, that this document does not and cannot cover all possible security breaches. The issues discussed here apply also to GarliCat. Specific differences between OnionCat/Tor and GarliCat/I2P will be pointed out.
Running OnionCat basically means connecting your computer to an additional network. Thus, one runs into similar troubles as if connecting the computer to the Internet. Hence, all rules for computer security apply as they do for systems connected to the Internet. At this point, this advisory could end again but nevertheless because of the specific and precarious issues regarding anonymization networks the important topics are discussed below.
OC is a peer-to-peer VPN node. Hence, it is designed to connect to other nodes as well as accept incoming connections from other nodes. Data is read from a local tunnel device and forwarded to the remote peer and vice versa. Upon packet transmission, regardless if incoming or outgoing, OnionCat checks the packet type. All packets that are not of type IPv6 or IPv4 are dropped. IP packets are forwarded to the tunnel devices and are handled by the operating system kernel accordingly.
OnionCat Server/Client Operation
This is the normal mode of operation but it is mandatory if OnionCat is run with the intention to operate services (http, irc, smtp,...). Obviously, the anonymization software has to be configured to allow incoming connections. For Tor (OnionCat) this is done by setting up a hidden service. For I2P (GarliCat) this is done by creating a server tunnel. In this case, every other OnionCat can connect to this one. Once the connection is established the two OnionCat peers can bi-directionally exchange IP packets.
OnionCat Client-only Operation
If you do not intend to run a services you do not have to configure your anonymization client (Tor or I2P) to accept incoming connections, although this is not the recommended way of configuration. It is less flexible. Be aware that once a connection is established to another OnionCat, IP packets can of course be exchanged bi-directional.
If operated in normal mode (server/client), anyone can setup connections to it. In client-only mode incoming connections are not possible but if initiated locally, the remote system can send back IP packets. Thus, in both cases any IP based attacks are possible although the risk is lower in the latter case. This is because the attacker is not able to initiate the connection on his own. Those attacks may be port scanning, OS fingerprinting, exploiting low level vulnerabilities and many other know types of attacks.
OnionCat itself does currently not have any known vulnerability. Furthermore, to improve security, OnionCat runs as unprivileged user (It must be launched by root but it immediately drops privileges after initialization.).
Before running OnionCat, all local services should be bound to specific IP addresses. Usually this is the official IPv4 address, but it is generally a good idea to bind also to the IPv4 localhost address (127.0.0.1) and the IPv6 localhost address (::1). Most services bind to any IP address of a system by default. Following are some popular examples.
- sshd: edit the configuration file (usually /etc/ssh/sshd_config) and set options
- lighttpd: edit the configuration file /etc/lighttpd/lighttpd and set options
- apache2: edit configuration file /etc/apache2/httpd.conf and set the option
- sendmail: edit configuration file /etc/mail/sendmail.mc and add
If possible, packet forwarding should be disabled. On Linux this is done by setting
net.ipv6.conf.all.forwarding to 0 using
sysctl. On OpenBSD this is done by setting the kernel variables
net.inet6.ip6.forwarding to 0.
Use a firewall to block traffic incoming on the tunnel device. You should make sure that the firewall supports also IPv6.