Hacksenkessel's Blog

Hacking, Pentesting, Algorithms, Computer Science

Anonymity on the Internet —

A hacker’s first and most important rule is Don’t get caught.

This is a very difficult task, as hackers’ nature is being eager to work, not giving up on anything and always striving to go forward. This ambition is what can get you caught if you’re not careful. But to be honest you shouldn’t depend on being careful at all, because it’s only a matter of time until you’re not. Sometimes you’re overworked, sometimes you’re tired, sometimes you can’t focus on too many things simultaneously, sometimes you get sloppy.

Humans make mistakes, hackers make mistakes. This is why the only secure way is to set up and use an environment and configuration which protects you even in situations when you make a mistake like accidentally accessing a target’s server without using a proxy which reveals your IP address.

 

VPN vs. TOR:

Commercial VPN providers are not trustworthy these days and we do not know if government agencies like the NSA have access to VPN providers and their servers, so don’t rely on them. You’re better off using the tor-technology for anonymous browsing. The tor-technology does not allow to be easily compromised by agencies, because your tor-traffic is always routed among three different nodes, an entry-node a middle-node/bridge and an exit-node. The chosen nodes are random and might be set up on different continents. There is no way to predict your random traffic-routes and even if there was a way to do so, an agency would have to compromise at least two out of three servers to identify you. Compromising two servers seems like an easy task, but your tor traffic-route changes every ten minutes to different servers/countries/continents and there are tens of thousands tor-servers out there, servers from private people, severs from companies, servers that are not controlled by any government agency. Anyone can set up a tor-server, especially when you already have a web-server with a static IP address. Even this server hacksenkessel is a tor-server. Maybe I’ll blog about setting up a tor-node someday.

If you’re interested to know how tor works: Tor-Project Overview

You can find an overview of some tor-servers here.

 

For this article I’ll use Kali Linux, which is designed for pentesting purposes. I’ll assume you use a debian-based operating system as well.
Now, let’s get started.

 

1.) Downloading the TOR Browser Bundle

At the time of this article, there is a complete, integrated and pre-installed tor browser bundle available, which can be downloaded from the official Tor-Project site.

 

2.) Using TOR

Decompress the downloaded tor browser bundle to your linux home directory and execute the script start-tor-browser:

tar xf tor-browser-linux64-3.5.2.1_en-US.tar.xz
./tor-browser_en-US/start-tor-browser

 
After clicking on connect you should see this:

Tor Initscreen

Tor Initscreen

 

3.) Changing bad habits
The tor-technology and its tor browser bundle can only protect your privacy if you’re willing to change some of your bad habits:

  • Don’t access anything that identifies you via tor. Don’t login to Facebook, Twitter, email accounts, forums or anything else. Don’t login at all.
  • Don’t open documents that you downloaded via tor while still using open tor-connections.
  • Use the tor browser bundle’s NoScript plugin and disable javascript, java, flash and all browser plugins.
  • Stick to these rules.

 

4.) Setting up TOR- and privoxy daemons

Hackers are interested in rerouting not only the www-browser’s traffic through tor, they are interested in rerouting ssh, wget, nmap scans and all kinds of console applications’ traffic through tor as well. We need to install and configure a tor daemon and privoxy for that. Even though the tor browser bundle already has an integrated proxy, which could be used as a local proxy for rerouting console applications’ traffic mentioned above as well, starting the tor browser bundle each time a console application needs access to a tor tunnel is too much overhead.
A tor daemon and privoxy daemon solve this issue by permanently providing a local proxy that allows console applications to communicate via tor-tunnel with the WWW. Best practice is to have them automatically started on bootup. To install tor and privoxy daemons on a debian-linux based operating system, simply install it from the repository:

apt-get install tor privoxy

After the installation you can setup the tor- and privoxy daemon according to this manual.

Finally you should see local ports for privoxy and tor-socks as open:

nmap -p 8118,9050 localhost
(...)
PORT STATE SERVICE
8118/tcp open privoxy
9050/tcp open tor-socks

To let console applications know that there is a local proxy listening, you have to set the proxy environment variables permanently in your .bashrc:

export http_proxy=localhost:8118
export https_proxy=localhost:8118
export ftp_proxy=localhost:8118

From now on, console applications try to communicate through privoxy and tor to the outside world, but there is one important step to guarantee that nothing else on your machine communicates with the outside world without tor:

 

5.) Using local firewall rules to protect your anonymity

As already mentioned above you need to protect your privacy from your own mistakes. As the tor browser bundle has been downloaded and can be used now, it’s time to set up some firewall rules to make sure that no application on your PC or notebook can directly communicate with the WWW without using the tor-network.

  • Your email client pops up when you log in? – It gets blocked.
  • You accidentally clicked on the operating system browser instead on the tor browser bundle? – Guess what – it gets blocked.
  • No accidents, maximum privacy

 

The iptables rules below make sure that nothing on your system communicates without tor. Please make sure that these rules are are automatically loaded after each boot up and do not rely on activating them manually. I put them in a shellscript that is executed via etc/rc.local on each bootup. The following iptables rules assume a debian-linux based operating system (like kali, ubuntu or mint). The below users debian-tor and privoxy might have different names on other linux distributions.
Here are the firewall rules:

# Drop exisiting OUTPUT rules
iptables -F OUTPUT

# Accept tor-user output connections
iptables -A OUTPUT -j ACCEPT -m owner --uid-owner debian-tor

# Accept local connections via loopback device
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A INPUT -j ACCEPT -i lo

# Allow NTP - this is needed for tor-accuracy
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -j ACCEPT

# Accept already established connections
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Redirect http traffic to local proxy
iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --uid-owner privoxy -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 8118

# reject outgoing connections
iptables -P OUTPUT DROP

 

6.) Verify that your machine does not directly communicate with the target

It’s important that every communication line uses tor and that nothing on your machine communicates directly with the WWW, or worse, with the target. The easiest way to evaluate this is to have a (web-)server somewhere, login via ssh through the tor-tunnel from your machine to the web-server and use tcpdump on the web-server to check if there are any incoming datapackets originating from your machine.

Assuming your machine’s IP address is 111.111.111.111 and your web-server’s IP address is 222.222.222.222, logging into your web-server via ssh using the previously configured tor-tunnel, your web-server should not see any datapackets from 111.111.111.111.

  • Bad: Your machine <---> Web-Server
  • Good: Your machine <---> Tor-Network <---> Web-Server

 

Verify this on your web-server via tcpdump:

tcpdump src <your machine's IP-address>
tcpdump src 111.111.111.111

If you do see any datapackets originating from your machine on your web-server, you did something wrong and your original IP address has been revealed. This is the moment you get caught. Your ssh-connection as well as every single tool you use for penetration testing should be tested via tcpdump. The above rules make sure that even pings (ICMP packets) cannot be sent to the target machine. Allowing ICMP packets would be a very bad idea revealing your IP address.

 

7.) Encrypt your entire harddisk

There must not be any proof that your machine is used for hacking and/or pentesting. This is why it’s inevitable that your entire harddisk is encrypted, including the root-device. There are several ways to encrypt a partition, i.e. Truecrypt, which can be used for MS-Windows and MAC OS X as well, LUKS/dm-crypt and geli for FreeBSD and a lot more. For the sake of this article I’ll stick with LUKS/dm-crypt, because it’s a linux standard.

Please note that existing data on <your partition> in the example below gets deleted, so back it up first or use an empty partition. Setup your Luks/dm-crypt partition:

# set up a luks/dm-crypt partition
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/<your device>

# open the encrypted partition for the first time
cryptsetup luksOpen /dev/<your device> crypt
Enter passphrase for /dev/<your device>: ***************

# format the encrypted partition
mkfs.ext4 /dev/mapper/crypt

That’s it. You can from now on open the encrypted partition via option luksOpen and then mount it as usual:

# open encrypted partition using your password
cryptsetup luksOpen /dev/<your device> crypt
Enter passphrase for /dev/<your device>: ***************

# mount it
mkdir -p /media/crypt
mount /dev/mapper/crypt /media/crypt

# There it is
mount | grep crypt
/dev/mapper/crypt on /media/crypt type ext4 (rw,relatime,data=ordered)

You can use the encrypted partition from now on via /media/crypt. Please note that the device name crypt such as ext4 as filesystem format is optional. If you need a swap partition, you have to encrypt it as well.

 

Closing your Luks/dm-crypt partition:

umount /media/crypt
cryptsetup luksClose /dev/mapper/crypt

 

8.) Separate hacking / pentesting from your usual work

It’s easier and a lot more secure to setup a separated hacking/pentesting environment, which does not contain any personal information about you like documents, images, browser cookies and browser history from your daily work. You can use kali linux in a virtual environment like VMware or Virtual Box, or even better and more secure, setup a separate machine with kali linux that is only used for hacking and does not contain any personal information about you at all.
 
Don’t forget to install your operating system’s security patches and make sure that incoming TCP/UDP requests are blocked.
 
Your setup is now secure.
 
DARK HACKSE


Categorised as: Hacking

Comments are disabled on this post