Piyush Shukla(neoned71)
By Piyush Shukla in Computers —

Anonymity Online...Proxies, VPN and TOR...

An overview of the high level activities of online protocols which claim to be safe for you.

Anonymity Online...Proxies, VPN and TOR...
Image Source: https://wallpapersden.com/vendetta-mask-wallpaper/

Your privacy is not safe, ever, at least online. Always trust the software that you can read the source code of, like open source packages. In my opinion one should not use Microsoft and Apple's closed source technologies for critical work. There are plenty of open source projects that can get you covered at the cost of a little convenience.

One of the major reasons for that is that any closed source software can just spy at you and your family and there would not be anything a user would be able to do to detect it or be safe once you have given them permission to be run in your system.

Someone who has gained access to your wireless router

  1. is able to sniff packets for usename and password,
  2. is able to bypass to your router's poor security settings and change the DNS setting or the routing table and
  3. can even break some weak encrpytion schemes to read data being sent.

Well, strong encryption is good, it saves your data from ever being understood by the malicious party, but that is not foolproof. Someone actively fishing will eventually dupe you into thinking that you are logging in the correct website only that you are not. You lose your credentials.

There are a few ways to mitigate some of these issues using a proxy server, a VPN, or going completely dark with the TOR dark web services. Nothing is perfectly safe online, but you can improve your chances by implementing one or more of these techniques.

Note: I am going to be using a Linux(Ubuntu 20.04) environment to showcase all of the concepts inside this article, I recommend you do the same.

How does the common internet work??!!

Internet is a collection of routers that know, in some sense, location of every other router in the world! There are routing protocols which help router figure out where next to send a packet. RIP, EIGRP and BGP are some of the common routing protocols, RIP & EIGRP are used as internal routing protocols for a local area network inside an organization, whereas BGP connects two or more of these local area networks together to form a world wide network. Once all the routers know all that they can know, using the routing protocol of their choice, every single one of them is then able to ship any data to another one.

All that is left is how we mark the routers, we need a way to name at least some of them uniquely in the world, for example, if you want to send a packet to google's server, then you would need its unique name to make other routers transport it for you to your desired destination.

IP addresses are one of many ways to name them all. Where do you get an ip address from??? For the people sitting inside their homes, the router gives it to you from a pool of allowed ip addresses, the protocol is called DHCP, as soon as you are connected. It also gives you an IP address for a DNS server, to query domain names in return for an IP address.

A typical web page loads in the following steps after the device is connected with the router,

  1. You enter a domain name as a URL in the search field in the browser.
  2. Your machine sends a request to the DNS server to query the IP address of the domain name you enetered.
  3. A new GET http request is generated and sent to the gateway (router you are connected to) for further propagation into the internet.
  4. The router replaces your IP address from the source section of the IP header and puts its own, this is called Network address Translation NAT.
  5. Now, your packet is hopping on through the router network. To see this list of routers in the way to, say Google, you can use the command: traceroute google.com to get a result something like that.
traceroute to google.com (142.250.194.110), 30 hops max, 60 byte packets
 1  _gateway (192.168.115.39)  6.378 ms  3.742 ms  6.372 ms
 2  * * *
 3  56.8.137.221 (56.8.137.221)  45.957 ms 56.8.137.233 (56.8.137.233)  45.770 ms 56.8.137.229 (56.8.137.229)  39.344 ms
 4  192.168.44.81 (192.168.44.81)  39.358 ms 192.168.44.79 (192.168.44.79)  45.739 ms 192.168.44.83 (192.168.44.83)  39.266 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  142.250.168.56 (142.250.168.56)  43.628 ms * *
12  72.14.195.22 (72.14.195.22)  33.928 ms 142.250.47.144 (142.250.47.144)  40.539 ms *
13  142.251.52.200 (142.251.52.200)  45.223 ms * *
14  142.251.52.225 (142.251.52.225)  40.494 ms 142.251.52.198 (142.251.52.198)  40.402 ms 172.253.67.94 (172.253.67.94)  51.051 ms
15  142.251.52.225 (142.251.52.225)  51.102 ms 74.125.244.195 (74.125.244.195)  40.494 ms 108.170.251.97 (108.170.251.97)  51.552 ms
16  108.170.251.97 (108.170.251.97)  25.922 ms del12s04-in-f14.1e100.net (142.250.194.110)  39.629 ms 108.170.251.97 (108.170.251.97)  38.972 ms

6. Google, upon receiving your request, sees that the packet has been marked with your router's IP address and sends a reply which reaches your router.

7. Routers remember(by keeping a table to port mapped IP adddressed) whom to send this reply as it did the address translation when the packet is leaving the system. Then the packet is received by the particular device.

Ways to block a web site access

In order to block access to some specific IP address you can,

  1. configure your DNS server to not to answer queries for the IP addresses to the domains you specify. This can be worked around by manually changing the DNS settings in the client.
  2. blocklist an IP address by keeping a list with the gateway router of the restricted IP addresses. This router then checks in this list before doing the network address translation(NAT). This can be evaded by using Proxy servers, a Virtual Private Network(VPN) or The Onion Routing(TOR).
  3. The gateway router can also spy inside the packet to figure out if the content should be blocked or not, simply use encryption(SSL/TLS) to evade that.

Proxies

A proxy server takes a request and passes it to a real server, acting like a middle-man, acting server to the actual client and client to the actual web server. This solves problems with the gateway that has a list of blocklisted sites because you are no longer making a request to any of restricted IPs but to someone that seems like a completely random node in the internet. The response from the real server reaches the proxy server first and then is redirected towards your gateway.

The proxy servers can set the ip address of the real client in the header X-Forwarded-For of the request from proxy to web server, otherwise the web server can only see the proxy server not the actual client, giving you anonymity.

Proxy server performs DNS resolution, not the client because client only does need the IP address of the proxy server not the actual web server. Proxy also encrypts your traffic with a SSL/TLS key handshake with the web server. So, beware, it can see the content of your packet. Do not trust just about any free proxy service out there, they can be spying on you.

This is a typical example of a forwarding proxy. There are reverse proxies as well, nginx is one. A reverse proxy works at the server side, doing load balancing, redirecting to microservices, etc.

HTTP Proxy

A HTTP proxy works by sending HOST + PATH in the request itself, to the proxy server, for example, take a look at a normal HTTP packet sent from the client,

GET /somepage HTTP/1.1
Host: www.somesite.com

Now, compare it with a proxy packet to the proxy server,

GET http://somesite.com/somepage HTTP/1.1
Host: www.somesite.com

For HTTPS, that is HTTP+SSL/TLS, we have the CONNECT method to make the proxy server perform a SSL/TSL handshake, for example,

CONNECT somesite.com:443 HTTP/1.1

Socks is a general proxy protocol, working on layer-5 of the OSI model. Unlike HTTP/HTTPS protocols, it can work with any underlying protocol of your choice, FTP, HTTP or SMTP or a custom made. Socks5 is the more advanced version of this proxy server which included UDP traffic and authentication over Socks4.

Setup your own Socks5 proxy server

Having your own proxy server gives you great security and anonymity. You can spin up an EC2 instance free tier from AWS to setup an actual proxy server with a static IP address that can be accessed from everwhere.

I am using Ubuntu 22.04 while writing these instructions, best if you use the same. The requirements for this process are,

  1. Installing an open source proxy, Dante: sudo apt install danted-server
  2. Configure the server by editing file: sudo nano /etc/danted.conf
logoutput: syslog stdout /var/log/sockd.log

internal: 0.0.0.0 port = 1080

#enter your interface name here!
external: [your_interface_name]

#only allow system users to access the proxy
socksmethod: username

clientmethod: none

client pass {
	#allow all clients to all clients
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

socks pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

3. Check if dante is running, and make sure that the firewall is configured to allow port 1080 by: sudo ufw allow 1080

$ systemctl start danted
$ systemctl status danted

Now this machine will work as a Socks5 proxy server, make a request from another machine to test it out,

curl -x socks5://<your_username>:<your_password>@<dante_server_ip>:<your_danted_port> ifconfig.co

After the initial handshake, the packets look just like HTTP/HTTPS packets.

Even if you encrypt the data contained inside of each request, it is quite clear where the packet is heading, as in the destination IP is known and visible on the packet.

ProxyChains

ProxyChains is an extremely simple tool to make your request pass through a series of HTTP, SOCKS4/SOCKS5 and TOR proxy servers. All you do is install proxychains and configure it by editing file, /etc/proxychains[4].conf,

##content of the /etc/proxychains.conf file
socks5 [dante_server_ip_address] 1080 [username] [password]
#socks5 [another socks5 proxy ip] [port] [username] [password]

Now, to proxy a request through all these proxy server just open a terminal and run,

$ proxychains curl google.com

This curl request is being proxied through all the servers mentioned above in the configuration.

Virtual Private Network (VPN)

A VPN is very similar to a proxy server, in which the traffic is routed through a server but it is much secure than just a proxy server. All the information in the VPN is encrypted, if anyone intercepts the traffic, all they can see is that the client is talking to the VPN server, but does not know anything from there.

All the routing information moves encrypted and once it reaches the VPN edge server, it is decrypted and again encrypted to be released into the world. The way the routing information is encapsulated inside each packet is called Tunneling.

For illustration purposes, let me show you one type of tunneling protocol, IP-IP tunneling with IPsec encryption over the tunnel. It is like having a IP layer packet inside the payload of an IP layer packet.

IPsec is a layer-2 protocol and is different from openVPN which uses SSL at the application layer to provide encryption. This is so because kernel handles the networking stack, so if IPsec is to be used it has to be injected into the kernel using modules.

How to setup an OpenVPN server for yourself?

The easiest way is to spin up a free tier AWS EC2 with OpenVPN-Access Server. It gives you a web interface to manager your VPN, There you can specify new users, up-to 2 for free, for more you pay for the service. After creating a user and credentials, login as that user and download the configuration file *.ovpn.

On the client, install openVPN3 package, then run command as sudo,

sudo openvpn3 session-start --config ${MY_CONFIGURATION_FILE.ovpn}

Once connected through the VPN, you can use ip a command to see all the interfaces,

neoned71@ubuntu:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    .
    .
    .
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    .
    .
    .
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 172.27.250.3/24 brd 172.27.250.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::122b:50e1:899c:b203/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

You get a new virtual interface(tun0), and with it you get a local IP address(172.27.250.3) for that interface. This IP address is what is used to route requests inside the VPN.

Possibly the biggest security Hole in VPNs...

When using a VPN, your packet and data stays encrypted along the hole route except for when it is at the VPN gateway. The flow of the packet is as follows,

  1. Client creates a tunned to the VPN server and uses IP-IP tunneling along with IPsec encryption.
  2. The packet reaches the VPN server and it decrypts the packet to read the actual destination IP address. - HERE it is!
  3. It then initiates a HTTP/HTTPS connection with the Web server.

So, your VPN server can spy on your packet, even when you are using encryption to connect to the VPN because it initiates a new HTTPS request with the web server!

Maybe The Onion Routing is a complete solution...

Dark Web - The Onion Routing(TOR) protocol

The Onion Routing protocol works like a VPN but it solves the problem with the security issue in the VPN. Let us see how the protocol works, let us say, we want to connect to a server with a domain name neoned71.com by the following steps,

  1. You contact a TOR directory, this machine has a public IP address and it contains the list of TOR nodes.
  2. It selects and gives you at least 2 intermediate node IPs and one exit node, entry node T1, T2 and one exit node, T3. So three IP addresses to keep with us for now

3. You, the client, perform a symmetric key exchange( can be Deffie-Hellman key exchange protocol ) and get keys k1,k2 (for T1 entry-node and T2 relay-node) and k3 (for T3 exit-node) respectively for the three TOR nodes.

4. Now, the protocol packs the final data packet as shown in the image,

The packet is encrypted with k3 key first, then k2 and with k1, then sent to T1, T2 and T3 in reverse order.

T1 knows that the packet goes to T2, but it does not know any more because T1 does not have the key for encryption with T2. Similar is the case with T2 and T3. T3, being an exit node knows where the request has gone to finally, but knows nothing of the client address.

5. Replies from the web server routes the same way back. The T3 router encrypts the response with the key K3 and sends it to T2, which encrypts the packet with the key k2 and sends it to T1 which encrypts it with the key k1 and sends it back to the client.

6. The client decrypts the packet in this order of corresponding keys: K1, K2 and then K3 and gets the data.

Possible Packet Sniffing in TOR

  1. TOR packets have a specific digital signature, so, the web server can chose to not to server such a packet, effectively banning TOR and the dark web.
  2. Exit nodes can be monitored for the TOR traffic, although one cannot know who is the client.

To know more about the TOR visit the official web page!

How do you setup and use TOR as a proxy

On a Ubuntu Machine, you would use apt to install,

sudo apt install tor

Now, we can add the TOR port and the ip address in the ProxyChains configuration file as,

socks4 127.0.0.1 9050 
socks5 127.0.0.1 9050

Now ProxyChains will use the TOR network as the proxy server.

$ proxychains curl google.com
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  google.com:80  ...  OK
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

To setup a browser to browse the fancy Dark Web, just go to the proxy settings and add a socks5 proxy with the port 9050 at localhost(127.0.0.1).

Conclusion

No protocol can gaurantee absolute anonymity over the internet. We should know the drawbacks and loopholes of various safe claimed protocols. That we saw with using Proxies, VPN and TOR! Any extra layer of security  helps to protects you, use all that is available and thankyou for reading...

Sign up for the blog-newsletter! I promise that we do not spam...