Creating Adversary Resistant Networking Configurations

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
Posts: 8
Joined: Mon Jan 21, 2013 2:11 pm

Creating Adversary Resistant Networking Configurations

Post by killswitch » Fri Jul 24, 2015 10:04 pm

There are two schools of thought regarding Adversary Resistant Networking, one depends on application level proxies, the other on fail closed VPN configurations.

Tor offers a SOCKS5 port, usually if you're running Tor locally, or port 9100 on a nearby machine if you're splitting gateway and workstation duties. I've found SOCKS5 support in Firefox to be sketchy, so I often configure the Polipo HTTP proxy at port 8123, and have it use SOCKS5 as an upstream proxy. Many applications offer the capability to use a proxy in their configuration and command line tools can be wrapped with torsocks to achieve the same goal.

I2P maps individual local ports to services at remote locations, so it is similar in spirit to Tor. Both of these anonymizing networks offer application level proxies, which means that the system providing them is not required to NAT traffic from local subnets. These systems fail closed because they are incapable of forwarding traffic.

Creating a fail closed configuration with a VPN requires mucking around with firewall and/or route table configurations. There are several ways you can create a fail closed VPN solution, but these are the methods I am using for the moment.

When your workstation boots it probably gets it's IP address, DNS servers, and a default route from a local router via DHCP, the dynamic host configuration protocol. This configuration presumes you want to reach the whole world. Here is what this looks like in a VirtualBox VM, preceded by the command used to inspect the routing table. The network is the default for VirtualBox network type NAT, the entry is the default route.
netstat -rn

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface UG 0 0 0 eth0 U 0 0 0 eth0

When you activate an OpenVPN tunnel the system enters a host route to the VPN server you are using, and then adds and to the route table. This divides the 32 bit global Ipv4 address space into two 31 bit blocks, which disables the default route. Ipv4 packets are sent using the most specific route for their destination.
Netstat -rn

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface UG 0 0 0 tun0 UG 0 0 0 eth0 U 0 0 0 eth0 U 0 0 0 tun0 UG 0 0 0 tun0 UGH 0 0 0 eth0
The route is the VPN concentrator in use, in this case the Cryptofree service. The route is the default NAT network for VirtualBox, the network is the link from this machine to Cryptostorm, then the & routes via ensure nothing uses the default route via – easy enough, right?

If you want the system to fail closed you would need to delete the default route and add a static host route to the VPN concentrator. The routing table prior to the VPN launch would look like this:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface U 0 0 0 eth0 UGH 0 0 0 eth0
And once the VPN is started it would look like this
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface UG 0 0 0 tun0 U 0 0 0 eth0 U 0 0 0 tun0 UG 0 0 0 tun0 UGH 0 0 0 eth0
If the VPN connection stumbles the two /1 routes it offers would be withdrawn, and the system would be disconnected. This part is easy enough to understand, but there are two pitfalls you must avoid.

The static route to is great, but the Cryptostorm config files use the symbolic name Your system probably has an /etc/resolv.conf file with the IP addresses of a couple of DNS servers in there. You could add a pair of static host routes to your DNS servers, but since we're in lockdown mode it's probably safer to add this to /etc/hosts
The other issue you have to deal with is DHCP lease renewal. If your system is configured with DHCP, then you add the statements to create your fail closed config to /etc/rc.local, the minute your DHCP lease is up the system will renew, your default route is back, and you are exposed. As above with the DNS versus /etc/hosts config, it is safer to make your IP configuration static.

It has long been said that “Eternal vigilance is the price of liberty”, and this has never been more true than when we face a surveillance dragnet recording our every move.

User avatar
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: Creating Adversary Resistant Networking Configurations

Post by parityboy » Sat Jul 25, 2015 2:58 am


Great write up. :D

Both of these models have their issues in the real world. Firewalls once set will stay set, however it takes a certain level of technical confidence and knowledge to set them up. On the other hand, application level proxies require each application to be set up to use the local proxy (assuming the software in question actually has the proxy features in it - many don't and using something like torsocks isn't always an option), and is dependent upon the software developer to not failover silently if the local proxy connection fails.

Additionally, others in this world have learned the hard way what happens if/when they forget to set their application to use Tor/I2P - with the VPN/firewall combination, this worry is removed.

Ultimately, this is more about people than it is about technology. Not only do more networking applications need to support HTTP and SOCKS proxies, they need to do so reliably, they need to warn the user when the local proxy connection is unavailable and they MUST NOT failover silently to the clear Internet if/when the local proxy connection fails. In addition, they must connect to Tor or I2P simply and if possible automatically.