You have a responsibility to protect your peers’ identities. They trusted you enough to give you information that could possibly lead to someone discovering their location, and you need to protect that information.
What follow are various steps to ensure that you are secure.
Secure Communications
First of all, be sure to exchange information over a secure medium. IRC is not secure! If you don’t believe me, download and run Wireshark or tcpdump. This will allow you to spy on all the traffic going through your machine. IRC with SSL is somewhat more secure. the only people that can read your messages if you are talking in a public channel are you, anyone in the channel, and the operators of the IRC servers. If it is a private message then only you, the person you are messaging and the operators of the IRC servers can read your messages. If you use DCC chat (Direct Client to Client) all text is sent un-encrypted from client to client; SSL is no longer in use. As you can see, there is no end to end secure method of communication using IRC.
Jabber with SSL has the same problem that private messages on IRC do. The Jabber server operators could potentially intercept your communications.
As long as there is no certificate authority on anonet, it is possible to use Monkey In The Middle attacks against all SSL connections. In a MITM attack, the attacker just impersonates the target host of a connection using its own SSL certificate and then relays the traffic to the target host.
Using PGP to encrypt the information before sending it is the ideal scenario. Using SILC is another method to communicate securely.
NaCltaia-OTR can be used with IRC and uses NaCl for encryption.
Encrypted Config Files
One can put all configs in an encrypted loopback filesystem. This will work for Linux clients only, but Windows has a way of encrypting directories based on DES which can be enabled in the Properties of that directory.
Before you start, make sure you have cryptoloop support in your kernel. You should know whether or not you do if you built your own, otherwise do a modprobe aes and this should load everything you need. NOTE: cryptoloop exists only on 2.6 unless you patch the kernel, as far as I know.
First, you need somewhere to put the filesystem: dd if=/dev/urandom of=/etc/Vault bs=1M count=3 This will make a 3MB file of random data in /etc called ‘Vault’.
Next, configure this as a device: losetup -e aes-128 /dev/loop7 /etc/Vault On some systems you may have to use ‘aes’ in place of ‘aes-128’. In any case, it should ask you for a password. This should, in reality, be a pass’‘’phrase’’’. A line from your favorite song, a quote from a book, or anything else that’s about 40 characters (a medium-sized sentence). Spaces will work; don’t worry about that. Make sure you type it in correctly ;)
Now you need a filesystem: mkfs.ext2 /dev/loop7 You won’t be writing much here, so you might as well use ext2.
Mount it somewhere: mkdir /mnt/vault chmod 700 /mnt/vault mount /dev/loop7 /mnt/vault
Now you should be able to copy all your old config files here. Do ‘’’NOT’’’ mv or rm them! mkdir /mnt/vault/openvpn mkdir /mnt/vault/quagga cp -R /etc/openvpn/* /mnt/vault/openvpn cp -R /etc/quagga/* /mnt/vault/quagga You need to securely erase the old configs to make sure there is nothing left over in the deep depths of your disk: shred -ufz /etc/quagga/* shred -ufz /etc/openvpn/* rm -rf /etc/openvpn rm -rf /etc/quagga
It’s also a good idea to move any shell scripts that make references to your peers’ IPs in there:
mkdir /mnt/vault/bin
export PATH=$PATH:/mnt/vault/bin
cp /usr/local/bin/whatever /mnt/vault/bin/whatever
shred -ufz /usr/local/bin/whatever
Put these in /usr/local/bin:
#!/bin/bash
echo Opening Vault...
# modprobe aes
losetup -e aes-128 /dev/loop7 /etc/Vault
mount /dev/loop7 /mnt/vault
#!/bin/bash
echo Sealing Vault...
sync
umount /mnt/vault
losetup -d /dev/loop7
Now your config files are secured whenever you turn your machine off.
Firewall
There’s still a risk that your files could be compromised while your machine is on, through random services that you claim you’re not running but for some reason are. You should be able to drop this script in without changing anything.
#!/bin/bash
# By Arctic.
# I'm not an iptables guru (yet) so send any complaints to me on IRC.
echo "Firewalling..."
iptables -F # Clear the tables
iptables -F -t nat # Clear the tables
iptables -X # Clear the tables
iptables -P INPUT DROP # Default policies
iptables -P OUTPUT ACCEPT # Default policies
iptables -P FORWARD DROP # Default policies
iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT # Accept ping replies
iptables -A INPUT -p icmp -i tap+ --icmp-type 8 -j ACCEPT # Accept ping requests on taps
iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT # Accept Dest-Unreachable (Traceroute)
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT # Accept Time-Exceeded (Sometimes traceroute)
iptables -A INPUT -i lo -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # Accept all loopback stuff
iptables -A INPUT -i + -m state --state ESTABLISHED,RELATED -j ACCEPT # Accept reply packets<br>
iptables -A FORWARD -i tap+ -s 1.0.0.0/8 -d 1.0.0.0/8 -j ACCEPT
iptables -A INPUT -i tap+ -d 224.0.0.5 -j ACCEPT # You need this for OSPF to work
iptables -A INPUT -i tap+ -d 224.0.0.6 -j ACCEPT # You need this for OSPF to work
iptables -A INPUT -i + -m state --state NEW -j DROP # Just to make sure
iptables -A INPUT -i + -m state --state INVALID -j DROP # Just to make sure<br>
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all # Ignore Pings
echo "1" > /proc/sys/net/ipv4/ip_forward # Forward Traffic
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Ignore broadcast pings (good)
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route # You may want to turn this on if you're a router
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/secure_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter # if you are a router; not to be used
# in general (has security implications).
# See rfc1812, 5.3.8
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
echo "1" > /proc/sys/net/ipv4/tcp_syncookies # Nice new anti-DoS feature<br>
echo "Firewalled"
Logs
You need to deal with your logs. There can be some really sensitive info in there. In your openvpn configs, make sure verb 0 is set. OSPFd and zebra use a command-line parameter to determine how they log, though you shouldn’t really have to worry about these as they only know internal IPs.
Tunnels
With recent developments in the world it should be no surprise to expect that pretty much every country’s intelligence agencies or even ISPs are recording and/or sniffing the traffic that passes by their routers. It should be also expected that different governments and/or companies cooperate in sharing the data that they can get their hands on. It is thus most important to choose the method of securing the tunnels that in any event is least likely to reveal the data which has been passing them. The most important step in doing so is understanding the advantages and disadvantages of different keying mechanisms available for OpenVPN.
OpenVPN allows to use Static Keys or X509 PKI (public key infrastructure). Most notable advantage of Static Keys is the simplicity of the set up. However, the disadvantage is the lack of perfect forward secrecy which in case of compromise of a Static Key can lead to ‘’revealing all the data which has been passing the tunnel up to that point’’ (as long as the compromised key has been or will be used). This HowTo lists all the pros and cons of Static Keys from where much of this information is derived from.
It is then advisable for the long term tunnel arrangements to use TLS where the session is re-keyed every once in a while (by default every 3600 seconds, adjustable with reneg-* configuration options)
Equally important is to use strong ciphers for encrypting the tunnels. Two of the strongest ciphers available for OpenVPN are AES and BF (Blowfish, default).
AES is a fixed key size cipher and can be specified in configuration like this:
cipher AES-256-CBC
BF is a variable key size cipher and is configured like this:
cipher BF-CBC
keysize 448
For BF key size can go from 32 bits to 448, but by default 128 bits is used. For listing of all the cipher options:
openvpn --show-ciphers
Final point: Don’t let TLS give you a false sense of security about the communications inside the tunnels. While TLS protects you from real time and historical analysis of the traffic inside the tunnels by third parties, it does nothing to protect you from people running the routers. There is no excuse for insecure protocols even if you use TLS for tunnels!
