Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

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!

Topic Author
killswitch
Posts: 9
Joined: Mon Jan 21, 2013 2:11 pm

Creating Adversary Resistant Networking Configurations

Postby 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 127.0.0.1:9050 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 10.0.2.0/24 network is the default for VirtualBox network type NAT, the 0.0.0.0/0 entry is the default route.

netstat -rn

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 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 0.0.0.0/1 and 128.0.0.0/1 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
0.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.55.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
128.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
212.129.10.40 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0


The 212.129.10.40/32 route is the VPN concentrator in use, in this case the Cryptofree service. The 10.0.2.0/24 route is the default NAT network for VirtualBox, the 10.55.0.0/16 network is the link from this machine to Cryptostorm, then the 0.0.0.0/1 & 128.0.0.0/1 routes via 10.55.0.1 ensure nothing uses the default route via 10.0.2.2 – 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
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
212.129.10.40 10.0.2.2 255.255.255.255 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
0.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.55.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
128.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
212.129.10.40 10.0.2.2 255.255.255.255 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 212.129.10.40 is great, but the Cryptostorm config files use the symbolic name linux-cryptofree.cryptostorm.net. 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

212.129.10.40 linux-cryptofree.cryptostorm.net
212.129.10.40 linux-cryptofree.cryptostorm.org
212.129.10.40 linux-cryptofree.cryptokens.ca
212.129.10.40 linux-cryptofree.cstorm.pw
212.129.10.40 linux-cryptofree.cryptostorm.nu


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

parityboy
Site Admin
Posts: 1013
Joined: Wed Feb 05, 2014 3:47 am

Re: Creating Adversary Resistant Networking Configurations

Postby parityboy » Sat Jul 25, 2015 2:58 am

@killswitch

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.


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: Google [Bot] and 5 guests

Login