Running OnionCat Services in a Highly Secure Environment

Running services within dark nets requires a lot of caution and carefulness. If the services are not configured correctly they might leak information and reveal their real location or operator. This of course is also applicable to a service based on OnionCat.

This article explains how to run an OnionCat-based service in a highly secure environment encapsulated within a virtual machine. I assume that the reader is familiar with basic network concepts, such as IP addressing, switching, and routing.

Modes of Operation

Basically there are two modes that OC may be operated in. The “regular” mode in which it runs in parallel to all other services on a server like for example an OpenVPN client. This is recommended for OC network clients and users because it is more or less plug-n-play and doesn’t require any expert knowledge. The second mode is running OC as a network gateway for a system which exists solely within the OC network.

Configuring OC as a network gateway is an extremely secure solution for running services but it is rather complex to configure it. But don’t be afraid! Once you understood it you’ll see that there’s a simple concept behind. I will now explain how this works. The picture on the right shows the basic idea. In the middle you see a system within the OC network. It is completely separated from all other networks (such as the Internet). Below there is the network gateway. It runs Tor (and/or I2P) and OnionCat. On the left hand there is a “regular” OC client which accesses a service on the isolated system through the Tor and OC network.

Configuration

Now let’s explain how to configure this. We need any virtualization technology. In this example I use XEN for explanation but it works with other technologies as well, such as KVM, VMware, VirtualBox, or similar ones.

To configure this scenario we need two guest systems. Install any Linux or whatever Un*x on them. One acts as the network gateway. Let’s call it Charlie. The other one is the isolated system. I call it Isola. The essential part of this setup is the network configuration. The picture on the left shows the network configuration diagram. The gray boxes are standalone systems. On the left Dom0 of XEN, on the upper right Charlie and below Isola. The green boxes are network adapters and the red bars show network bridges. XEN networking is running in bridging mode. Thus, the physical network card is renamed to peth0 (which usually is eth0 on Linux) and the logical interface for Dom0 is called eth0. This type of configuration is activated by the network-bridge script within /etc/xen/xend-config.sxp. All XEN bridges are configured using the bridge-utils.

Charlie gets two network cards which are named eth0 and eth1 from its point of view. The first one is the uplink to the Internet, the second one is the interface to Isola and acts as the network gateway. XEN realizes those virtual adapters within the “real” world in Dom0 by the interfaces vif1.0 and vif1.1. The first one is bridged to peth0 for a real world connection. Vif1.1 will just end up at Isola. We need another virtual bridge to do so, hence, we create it as root using the bridge-utils.

Dom-0# brctl addbr br0

The name br0 is just a random name. The connection of the virtual XEN interfaces to this bridge is done by XEN automatically during the startup of the guest systems if configured in their configuration files. Edit Charlie’s config file /etc/xen/Charlie.cfg

vif = [ 'bridge=eth0', 'bridge=br0' ]

and Isola’s:

vif = [ 'bridge=br0' ]

Now boot Charlie and Isola.

Dom-0# xm create Charlie.cfg
dom-0# xm create Isola.cfg

Within Charlie now install Tor, OnionCat, and the bridge-utils. Configure Tor and OC appropriately. Let’s assume the Onion-URL aerukz4jvpg66ajd.onion. This corresponds to the IPv6 address fd87:d87e:eb43:0123:4567:89ab:cdef:0123. It is important to run OC in TAP-mode. TAP-mode is activated by the option -p. Start OC with the following command:

Charlie# ocat -p aerukz4jvpg66ajd.onion

OC will create a TAP device named tap0. As show in the picture above this adapter must be bridged to eth1. We use a new bridge for that.

Charlie# brctl addbr br0
Charlie# brctl addif br0 eth1
Charlie# brctl addif br0 tap0
Charlie# ifconfig br0 up
Charlie# ifconfig eth1 up
Charlie# ifconfig tap0 up

Charlie is now ready. Now let’s finalize it. All you have to do is to setup the IPv6 address on Isola. To do so bring up eth0 in Isola and then configure the IPv6 address. In theory this may be done with a single command but I sometimes I had troubles doing it at once on some Kernels.

Isola# ifconfig eth0 up
Isola# ifconfig eth0 add fd87:d87e:eb43:0123:4567:89ab:cdef:0123/48

With this setup Isola is exclusively within the OC network. There is no interface to any other network. It might be useful to add a second interface to Isola to do software updates but it should strictly be down during regular operation and should just be used during the time of updating the system.

 

Comments are closed.