Admins eHow SysAdmin Tips & Tricks

A Transparent SSL Socks proxy can be useful to encrypt and secure all TCP connections and/or infiltrate Internet censorship systems.
In order to make this setup, you need two Linux based boxes, one in your local network and one which will act as server in a remote location.
Theoretically what we are going to achieve is to intercept all TCP connections on our local network transparently, encrypt them and then tunnel them to our remote server.
This can be achieved easily using a powerful Linux application called Stunnel.
In my own setup, I am using a raspberry pi 2 for my local device. it is a cheap device and has a very low power usage and can be running 24/7, so it is very suitable to act as a full featured Linux based router. although you can use a PC or a virtual machine to achieve the same.
Debian is my favorite Linux distro, so my guide will be based on Debian.
Enough introduction, lets get started.

Part I: Setting up SSL Socks Proxy
1.Install stunnel on both local and remote devices:
Download and install the latest version of stunnel from stunnel website: https://www.stunnel.org/downloads.html
You may need to compile it from source.

2.Create stunnel config on local device /etc/stunnel/stunnel.conf:

foreground = no
socket = r:TCP_NODELAY=1
output = /var/log/stunnel.log
#compression = zlib
syslog = no

[SOCKS Client Direct]
client = yes
PSKsecrets = /etc/stunnel/secrets.txt
accept = 0.0.0.0:LOCAL_PORT
connect = REMOTE_SERVER_IP:REMOTE_PORT
protocol = socks

LOCAL_PORT: The local port which stunnel will listen on.
REMOTE_SERVER_IP: The remote server IP.
REMOTE_PORT: The port which remote server will accept connections on.

Note I: I noticed raspbian prebuilt openssl package doesn’t support zlib compression, so in my case I had to recompile openssl with zlib support. If you have an openssl package with zlib support you can uncomment “compression = zlib” line.
Note II: If you need to see the log messages for debug purposes, you can set “foreground = yes” temporarily. “foreground = no” makes stunnel to run in daemon mode.

3.Create local PreShareKey secret file /etc/stunnel/secrets.txt:

USERNAME:PASSWORD_MORE_THAN_20_CHARS

pick your username and password accordingly.

4.Create stunnel config on remote server /etc/stunnel/stunnel.conf:

foreground = no
socket = l:TCP_NODELAY=1
#compression = zlib

[SOCKS Server]
PSKsecrets = /etc/stunnel/secrets.txt
accept = 0.0.0.0:REMOTE_PORT
protocol = socks

REMOTE_PORT: The port which remote server will accept connections on.
The notes which I mentioned in previous section also apply to this section.

5.Create /etc/stunnel/secrets.txt on remote server identical to secrets file on local device.

6.Run both stunnel instances on local device and remote server.

stunnel /etc/stunnel/stunnel.conf

Part II: Making the SSL Socks Proxy Transparent
In order to make the SSL Socks Proxy Transparent, we need to setup our local device as the router and gateway of our local network and intercept all TCP connections.

The following settings should be made on local device.
1.Enable IPv4 forwarding in /etc/sysctl.conf:

net.ipv4.ip_forward=1

and apply the changes:

sysctl -p

2.Redirect all TCP connections to socks proxy:

iptables -t nat -A PREROUTING -p tcp -d LOCAL_IP_ADDRESS_CLASS -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports LOCAL_PORT

iptables -t nat -A OUTPUT -p tcp -d REMOTE_SERVER_IP --dport REMOTE_PORT -j ACCEPT
iptables -t nat -A OUTPUT -o lo -j ACCEPT
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports LOCAL_PORT

LOCAL_IP_ADDRESS_CLASS: It is very important to set this option correctly otherwise you will lose your network access to your local device. it should be the network address of your local network for example : 192.168.0.0/16 or 10.0.0.0/8 or 192.168.1.0/24
LOCAL_PORT: The local port which stunnel is listening on.
REMOTE_SERVER_IP: The remote server IP.
REMOTE_PORT: The port which remote server will accept connections on.

The PREROUTING rules redirects all TCP connections of other clients on the LAN to Socks Proxy and The OUTPUT rules redirects all TCP connections of local device to Socks Proxy.

3.Set the gateway of network devices on local network to local device IP address. you can configure it manually or configure your DHCP server to assign the new gateway to DHCP clients. if you have an advanced router, you can probably set it up in your router configuration, otherwise you may need to disable your router DHCP server and install a full featured DHCP server on your local device.

Part III: Setting up DHCP server (OPTIONAL)
1.Install ISC DHCP server:

apt-get install isc-dhcp-server

2.Create /etc/dhcp/dhcpd.conf:

ddns-update-style none;
option domain-name-servers 192.168.1.2;
authoritative;
log-facility local7;
subnet 192.168.1.0 netmask 255.255.255.0 {
        range 192.168.1.50 192.168.1.100;
        option routers 192.168.1.2;
        option broadcast-address 192.168.1.255;
        default-lease-time 86400;
        max-lease-time 172800;
}

It is the exact configuration of my DHCP server, I think it is self explanatory.
192.168.1.2 is my local device (raspberry pi), you need to change it to your local device IP address and also change ranges and broadcast address accordingly.
If you are wondering why I am using my local device as my DNS server, you need to read the next section. you may want to use google public DNS servers 8.8.8.8 and 8.8.4.4.

Part IV: Forward DNS queries on a different port than 53(OPTIONAL)
One of common DNS attacks is called DNS Hijacking.
It is a very easy attack and is performed by hijacking your DNS requests which are sent on port 53 UDP, then the hijacker can send you any reply that he wants and you can not verify if it is a legitimate response or not. Unfortunately in most operating systems you can not configure DNS client to use a different port which is not hijacked or it is very hard to do.
I have invented a very simple, yet brilliant solution for this problem. it can be performed by doing two DNAT operations on our local device and remote server to reach a safe DNS server.
This solution does not encrypt or secure the request, but it changes the DNS port transparently to a non-hijacked port, which works fine 🙂
Here is how it is done:

1.Run the following commands on your local device:

iptables -t nat -A PREROUTING -p udp --dport 53 -d LOCAL_DEVICE_IP -j DNAT --to REMOTE_SERVER_IP:5353
iptables -t nat -A POSTROUTING -p udp --dport 5353 -d REMOTE_SERVER_IP -j SNAT --to LOCAL_DEVICE_IP

Change LOCAL_DEVICE_IP & REMOTE_SERVER_IP accordingly.

Edit: Although the above solution works, I found out it is better to install a caching DNS server on local device rather than forwarding every DNS queries to remote server.

1.Install pdnsd on local device:

apt-get install pdnsd

2.Make following changes to /etc/pdnsd.conf:
in global section:

server_ip = 0.0.0.0

in server section:

ip = REMOTE_SERVER_IP;
port = 5353;

3.Set “START_DAEMON=yes” in /etc/default/pdnsd

4.Restart pdnsd:

service pdnsd restart

5.Run the following commands on your remote server:

iptables -t nat -A PREROUTING -p udp --dport 5353 -d REMOTE_SERVER_IP -j DNAT --to 209.244.0.3:53
iptables -t nat -A POSTROUTING -p udp --dport 53 -d 209.244.0.3 -j SNAT --to REMOTE_SERVER_IP

Change REMOTE_SERVER_IP accordingly.

209.244.0.3 is the IP address of Level3 public DNS server. I used it because it had a very good ping to my remote server. you can use a different DNS server.
If you do it properly, your local device can be used as a DNS server and in my case it would act as Level3 public DNS server. not susceptible to port 53 DNS hijacking.

Part V: Setting up an encrypted TCP based DNS caching server (Solution II for secure DNS – OPTIONAL)
In my experience I noticed forwarding DNS queries on port 5353 can be unreliable and cause problems for web browsing, although there is no technical reason for this problem and it could be just my ISP dropping such UDP packets. also my previous solution was not encrypted and was just used to bypass DNS hijackers listening for DNS packets on port 53.
I tried a new solution and it works much more reliably. I encrypted local device (raspberry pi) TCP connections using 3 new iptables OUTPUT rules (which is explained above) and then set up my DNS caching server to resolve queries only on TCP. using TCP is several times more slower than UDP but it will be encrypted and reliable.
Here is how it is done:

1.Install pdnsd on local device:

apt-get install pdnsd

2.Make following changes to /etc/pdnsd.conf:
in global section:

server_ip = 0.0.0.0
query_method = tcp_only;
min_ttl = 86400;

in server section:

ip = 209.244.0.3;

Note: The DNS server you choose should support resolving DNS queries on TCP port 53. 209.244.0.3 is Level3 public DNS server and supports TCP DNS queries.
Note: “min_ttl = 86400” overrides the default TTL of DNS queries to 24 hours which is OK for 99.999% of websites. But if a website changes its DNS records meanwhile it is in pdnsd cache, you may need to flush the cache manually or wait up to 24 hours for the record to be updated.

3.Set “START_DAEMON=yes” in /etc/default/pdnsd

4.Restart pdnsd:

service pdnsd restart