Difference between revisions of "31C3/laptop preparation"

Revision as of 16:40, 1 November 2014

Laptop preparation

Goal is easy: prevent unauthorized accesses to your laptop while still being able to access resources. Oh, and, ensure resources aren't faked or messed up by some rogue proxy.

It's mainly based on CCC Survival Guide . It's a (very) good start to follow their advices, especially regarding physical protection ;).

Network

The proposed setup is based on two Onion Routers<ref>Wikipedia: Onion Routing</ref>: i2p<ref>Wikipedia: i2p</ref> and Tor<ref>Wikipedia: Tor</ref>. The first one is optional, but it's always cool having some new stuff in order to try them. Well, new… i2p is 11 years old now ;).

All is based on Debian Sid, but most of the packages are present on Arch, Ubuntu, Gentoo and so on.

Tor

Get package

First, install Tor. On Debian, we can use Torporject sources in order to get the latest official releases:
deb http://deb.torproject.org/torproject.org <DISTRIBUTION> main

You can get the distribution code with this command: lsb_release -c.

You will also need the GPG key in order to be able to validate packages:

gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

Then, sudo apt-get update && sudo apt-get install deb.torproject.org-keyring && sudo apt-get install tor.

Configuration

Now we have the package and related daemon, we have to configure it a bit. As the main aim of this setup is to make all the traffic through Tor, here are the settings you'll need. You may empty the file and copy&paste this:

# Create SOCKS port, and ensure we isolate streams
SocksPort 9050 IsolateDestAddr IsolateDestPort
SafeSocks 0
TestSocks 1
# This port will be used for "non-socks" connection. I.e. for
# stupid apps which just don't know what a SOCKS is
TransPort 9040
TransListenAddress 127.0.0.1
# Create a listener for DNS queries.
DNSPort 5400
DNSListenAddress 127.0.0.1
NumCPUs 1
VirtualAddrNetwork 10.192.0.0/10
AvoidDiskWrites 1
AutomapHostsOnResolve 1

Comments should be enough, but you might want to read some more documentation about the tor configuration file.

Restart Tor with sudo service tor restart, and we're done :).

i2p

As said, this step is optional. But anyway, it's cool. And even easier in fact.

Get package

Add the following source to your Debian system:
deb http://deb.i2p2.no/ unstable main

Import the following key for package signature: wget https://geti2p.net/_static/debian-repo.pub -O - | sudo apt-key add -

Install required packages: sudo apt-get update && sudo apt-get install i2p i2p-keyring

Edit the /etc/default/i2p file in order to enable the daemon. Start it with sudo service i2p start, and… well, that's all ;).

More information available here.

IPTables

Now we hit the game: we might as well kill our connection capabilities, or make some great things. After all, that's IPTables<ref>Wikipedia: iptables</ref> ;)

There are multiple goals with the proposed configuration:

1. lock out the intruders
2. force outgoing traffic through Tor by default
3. allow "smart" application to connect by them-selves to the SOCKS or Transproxy
4. allow i2p to go out freely
5. allow Tor to go out freely

More over, we want this policy to be enforced as soon as we get network. In order to do so, we will need an "iptables-restore" call, and a script/configuration to feed it.

The following content is to be put in /etc/network/iptables file (or something like that, you'll have to create the file anyway). We will explain bellow how it works.

*filter
:INPUT DROP [1:264]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [60:12415]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i vboxnet0 -j ACCEPT
-A INPUT -j LOG --log-prefix "INPUT DROP "

-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m owner --uid-owner debian-tor -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -m owner --uid-owner i2psvc -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p udp -m udp --dport 5400 -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9050 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9040 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -s 127.0.0.1/32 -p tcp -m tcp --dport 631 -j ACCEPT
-A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -j LOG --log-prefix "OUTPUT DROP "
COMMIT

*nat
:INPUT DROP [524:86738]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [637739:421546290]
-A OUTPUT -m owner --uid-owner debian-tor -j RETURN
-A OUTPUT -m owner --uid-owner i2psvc -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 5400
-A OUTPUT  -p udp -m udp --dport 123 -j REDIRECT --to-ports 123
-A OUTPUT ! -o lo -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
-A OUTPUT -j LOG --log-prefix "OUTPUT nat DROP "
-A INPUT -j LOG --log-prefix "INPUT nat DROP "
COMMIT

So. How does it work? Pretty easy in the end: with iptables, we can filter packets by user ID, i.e. iptables knows "who" sends the packet it's filtering. As bot Tor and i2p daemon have dedicated users, we can tell iptables to let those two guys connections, while forcing the others through Tor. Or whatever you want, in fact.

The filter table (block starting with the *filter) will manage the IN and OUT, allowing only i2p and tor traffic out, while allowing related traffic in. It will force non-i2p/tor traffic to go through Tor TransPort we defined earlier, and it will also redirect DNS queries to Tor in order to avoid DNS poisoning.

The nat table (block starting with *nat) will do the redirects.

In order to enforce that, you'll need to edit your /etc/network/interfaces file and add the following line in your eth0/wlan0 definitions: post-up iptables-restore /etc/network/iptables.

Firefox

PAC

Physical

Feel free to add stuff ;).

References

<references />