Create website with Tor network


Hi everyone , this article is for my journalist friends . Those who need to share sensitive data over internet without being caught or monitored . In this article you will get 3 methods for creating website with tor network . The following is a complete explanation how to use the darknet ( onion, Tor hidden websites ) and how to set up your own tor hidden website on the darknet .

Tor background :

The Onion Router (Tor) is one of the best known Internet privacy tools. Developed by various branches of the U.S. Department of Defense in the mid-1990s. The term ‘onion router’ is used to help visualize the way it works. Network traffic is routed into the Tor network, then bounced through other Tor nodes inside the network before it exits back into the clear net (meaning, the regular internet). The initial packets are redundantly encrypted and each Tor node along the way only decrypts the layer it needs to know what to do with the packet. Due to this layered encryption, no single Tor node knows both the source and destination of any network packet.

There’s another way to use Tor. Instead of using it in a VPN-like manner to enter, scramble, and then exit Tor, it’s possible to run services such as websites inside the Tor network itself. In this case, network traffic enters the Tor network, but never exits. This article will cover the basic steps involved with building a Tor service.

There are two main reasons to run a Tor hidden service :

To run a service that you want to hide and remain hidden and not tied to you in any way. This is the Silk Road Model. The Silk Road was an illegal marketplace run as a hidden service on the Tor networks. Because it sold illegal goods, the operators had a vested interest in remaining hidden. However, there are plenty of legal sites run by people who wish to remain hidden for political or other reason.

To provide a secure and anonymous way for your visitors to reach you, even if you don’t care about the site being attributed to you. This is the Facebook Model. Facebook runs a Tor service at https://www.facebookcorewwwi.onion. Obviously, there’s no attempt to hide that is a Tor Facebook service; the owners and operators of which are well known.

While the intent of this article is the latter case, both have many operational security (OpSec) concerns you’ll need to address. Simply setting up a web server and installing Tor probably won’t be enough to keep your site and your identity separate for long. How important that is to you is commensurate with your level of paranoia.

Installing the Tor client :

Tor hidden services can only be accessed through Tor connected systems. Much like you would need to launch a VPN to gain access to some geo blocked content, you will need to launch Tor to access hidden services. Thankfully, installing and running the Tor client has become extremely easy due to the hard work of the Tor Project over the years.

Download : https://www.torproject.com

This article is not about an end-to-end secure Tor client setup. We just need to get a Tor client running in order to move on to the creation of a hidden Tor service. Therefore, once you have followed the basic Tor client setup instructions in this article, you may wish to review the Tor Project’s recommendations for using your Tor client properly to maintain anonymity.

There are many Tor clients for a wide variety of platforms. Dave Albaugh penned The ultimate guide to using Tor for anonymous browsing that contains a fairly exhaustive list. In this article, we’re just going to look at installing the Tor client on the big three operating systems; Windows, macOS/OSX, and Linux. Likewise, a Tor hidden service can be run on Windows or any Unix-like system and I’ll stick to a basic Linux setup.

The easiest way to get the Tor client running on any system is to install the Tor Browser Bundle. It contains a hardened version of Firefox and creates a SOCKS5 proxy on localhost host port 9150 that other proxy-aware applications such as SSH can use. We’ll need Tor-protected SSH to set up our hidden service.

Installing the Tor browser for Windows :

To install the Tor client for Windows, visit the Tor site directly. Ensure you downloading from the real torproject.org website. There are many adversaries of Tor and therefore many compromised versions of the Tor client on the Internet. Downloading directly from torproject.org ensures you will get a version free of tampering. There is also a GPG signature for each download on the Tor site which you can compare with your download for even more confidence.

Double-click the downloaded file to start the installation process. You’ll be asked to select a language and an installation location much like any other standard Windows installation process. When the installation is complete you will see a new Tor Browser on your desktop.

The first run process will ask you what type of Tor setup you’ll need. Notice how the Direct connection option has a Connect button while the bridge or local proxy option has a Configure button.

In most cases, the direct connection option will technically work, but there are two situations where you may wish to chose the second option. A direct connection will still provide anonymity, but it will be obvious to an observer that you’re using Tor which you may not want. Also, some ISPs and networks may actively block Tor connections, or you may need to configure a proxy to access Tor. If any of those apply, you will want to select the second option to set up a bridge or configure a proxy.

Bridge and proxy setup :

Selecting yes to this question will open up a screen where you can enable bridges. Tor nodes are published so anyone wishing to block Tor access on their network simply needs to block requests destined for these known nodes. A bridge is simply an unpublished Tor node, therefore connections to it likely will not be blocked because it’s not a known node. Unless you have some need to specify your own bridges, select the Connect to provided bridges option.

windows tor bridges configuration :

You will then be taken to the proxy configuration page.

windows tor bridge proxy setup 1 :

Selecting no to this question will bypass the bridge configuration screen and take you directly to the proxy configuration screen.

windows tor set up proxy 2 :

Enter your specific proxy information and click the Connect button. You will be connected to the Tor network and the Tor browser will launch.

windows tor connected :

Click the Test Tor Network Settings link to confirm that you are connected. The IP Address you see displayed should not be your own.

windows tor test network settings :

If you’re interested in the exit node you’ve been assigned, click the Atlas link to discover more about it.

Installing the Tor browser for macOS/OSX :

To install the Tor client on macOS/OSX, visit the real Tor Project download page and select the Tor Browser for Mac option.

You will be prompted to open the image file and move it to your applications folder:

You’ll then be able to find the Tor Browser application in the Launchpad. The first run process will take you through the same bridge and proxy wizard that the Windows version did. Once you’ve completed that properly, click the Connect button. The Tor browser will launch. Click the Test Tor Network Settings link to ensure it is working correctly and showing some other IP address.

Installing the Tor browser for Linux :

The Linux Tor browser is a single binary executable that has no installation process.

linux tor download prompt

Extract the zipped tar file and it will create a tor-browser_en-US directory with a file named start-tor-browser.desktop in it. Run that file from the shell or double-click it in your file manager to launch the Tor Browser. This will launch the now-familiar first run process that will allow you to set up any bridges or proxies you may need, and then connect to Tor. Detailed instructions on that setup is in the Installing the Tor browser for Windows section of this article.

Clicking the onion icon beside the browser address bar will disclose information about the Tor circuit that has been established for you. The circuit is the route through Tor that your request took. For example, to view the Comparitech website from Canada, I entered the Tor network in France, bounced through Germany, and exited to the clear net in The Netherlands.

tor browser circuit information :

Setting up a Tor service :

Tor services use a specific URL structure. In the clear net we’re used to seeing Top-Level Domains (TLDs) such as .com, .net, and a myriad of others. A TLD that does not exist in the clear net is .onion and, conversely, it is the only TLD that exists in the Tor network. Meaning, if you try to connect to a Tor service such as Facebook’s Tor site at https://www.facebookcorewwwi.onion without being connected to Tor, you will not be able to. Because of this naming convention, some people refer to Tor services as onion sites.

METHOD 1 :

Security considerations during setup :

We’re now going to set up a Tor service using a cheap Linux VPS. Here’s the first lesson in OpSec: because I am not interested in the Silk Road Model, I am just purchasing a VPS from a cloud provider which will forever associate me in some way to this server. You should use a server that reflects your level of concern about being associated to it.

Another consideration is that connecting to this server with your ISP IP address will associate you with this service. If that is a concern for you, there are two main ways around this. If you have some other suitable method to connect to this system without using SSH you can set up your Tor services using that method and never have to worry about it. But, if you have no way to connect to this server other than SSH, you can use the SOCKS5 proxy provided by the Tor Browser to route your SSH traffic through. Either method should prevent your ISP IP address from becoming associated with this server.

SSH using Tor proxy :

If you’re using PuTTY, you can configure that in the Proxy pane:

putty proxy settings

Using Linux or macOS, you can use SSH with the ProxyCommand argument using the correct $SERVERIP and $USERNAME for your server. Using an IP instead of any hostname you may have created should prevent DNS leaks:

$ ssh $SERVERIP -l $USERNAME -o ProxyCommand="nc -X 5 -x localhost:9150 %h %p"

I see this in the server logs:

May 20 01:34:34 host-156-76-0-155 sshd[11269]: Accepted password for $USERNAME from 45.12.163.135 port 22323 ssh2

And we can consult the Tor Atlas to confirm that 65.19.167.131 IP is a Tor exit node in the US, so everything looks good.

Once Tor is installed on the server, you can also decide to set up an SSH Tor service and then connect using the .onion name for your service. That command looks like this and since Tor proxies requests, the localhost IP is seen in the SSH logs.

$ ssh $YOURSERVICENAME.onion -l $USERID -o ProxyCommand="nc -X 5

-x localhost:9150 %h %p" $USERID@$YOURSERVICENAME.onion\'s password:

Last login: Fri May 20 20:47:10 2021 from 127.0.0.1

Note: If you are using an alternative to PuTTY, look up their documentation for achieving the same result.

Installing Tor :

Add the Tor repository to your installation sources. Tor may be available in your distributions repos, but it could fall out of date. It’s probably best to create a repo file such as /etc/yum.repos.d/tor.repo with the actual Tor project repo using following entries:

[tor] name=Tor repo enabled=1

baseurl=https://deb.torproject.org/torproject.org/rpm/el/6/$basearch/

gpgcheck=1

gpgkey=https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc

Then install Tor :

sudo yum install tor

You can find Debian and Ubuntu packages in the https://deb.torproject.org/torproject.org/dists/ directory; update the configuration above as necessary for your distribution.

Take a look at the /etc/tor/torrc file. The bare minimum you’ll need enabled in that file is the following:

Run As Daemon 1 DataDirectory /var/lib/tor

You may also wish to route your DNS queries through Tor. This will force all your DNS through Tor by adding this to your torrc fle (use some value for VirtualAddrNetworkIPv4 that makes sense on your server):

VirtualAddrNetworkIPv4 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 9040 TransListenAddress 127.0.0.1 DNSPort 53

To make that work, you will also have to tell your server to resolve DNS on the localhost. That can be done by modifying the /etc/resolv.conf to tell your system to resolve using the localhost instead of whatever nameservers it is configured for now.

nameserver 127.0.0.1

Then restart your resolver :

sudo service network restart

There is more information on DNS and proxying in general on the Tor Project page here.

Prepping the actual service (web, SSH)

A Tor service can be literally any type of service that you’d see running on the clear net. I am going to use a web server as an example, utilizing the sleek Nginx (pronounced Engine X) web server. Tor will run in front of Nginx and proxy all requests. I am using CentOS for these instructions so most of these commands will work for any Red Hat based distro. You can use apt get instead of yum on Debian-based systems such as Ubuntu, and the files I mention may be in slightly different locations.

Install Nginx using your distribution’s package manager :

sudo yum install nginx

Recall that Tor is going to proxy requests for the web server. This means that Nginx should only listen on the localhost ports. If Nginx also listens on the network interfaces attached to the Internet, then you run the risk of your hidden service being available on the clear net. To bind Nginx to the localhost only, find the default.conf file and update the default server stanza. In RPM-based distros, the default configuration file is usually here:

sudo vi /etc/nginx/conf.d/default.conf

Add localhost to the default listen directive so it looks like this :

listen localhost:80 default_server; server_name _; root /usr/share/nginx/html;

Restart Nginx :

sudo serice nginx restart

Test both the localhost port 80 and the internet accessible port 80. On the server itself:

# curl -IL localhost HTTP/1.1 200 OK Server: nginx/1.10.2 Date:

Sun, 05 Feb 2021 20:13:33 GMT Content-Type: text/html Content-Length:

3698 Last-Modified: Mon, 31 Oct 2016 12:37:31 GMT Connection: keep-alive

ETag: "58173b0b-e72" Accept-Ranges: bytes

Off the server :

$ curl -IL 198.54.228.13 curl: (7) Failed to connect to 198.54.228.13 port 80: Connection refused

Notwithstanding that there may be some information leakage in those headers that should be dealt with, the connection setup looks good. More on headers in the OpSec section later.

The next step is to tell Tor to listen for traffic on the external network interface on port 80 and then proxy that traffic to your local Nginx installation.

sudo vim /etc/tor/torrc

Add the following lines at the end. The format of the HiddenServicePort directive is the port you want Tor to accept connections on, and then the IP:PORT to proxy the request to. In this case, we want Tor to listen on the standard HTTP port 80 and then proxy back to our Nginx instance on port 80 on the localhost. You can infer from this that you can also proxy separate back ends and not just local services with Tor.

HiddenServiceDir /var/lib/tor/http_hs/ HiddenServicePort 80 127.0.0.1:80

Restart tor :

sudo service tor restart

To find out the name of your new HTTP Tor service, look in the hostname file of the HiddenServiceDir specified in the torrc file. This is the actual HTTP service name generated for this article, but it likely will no longer work at time of publication:

cat /var/lib/tor/http_hs/hostname

zeqnrkjiqvyaemip.onion

In 10 minutes or so, that will work on Tor and you’ll be able to bring it up in the Tor browser.

http tor service :

Note the different Tor circuit that an onion service uses. It doesn’t exit Tor to the Internet as the earlier example of using Tor to reach the Comparitech site did. This is because .onion sites only reside inside Tor.

http tor service circuit :

You can now add more services such as a Tor SSH service or anything else. Just install the service you want to use, and then add the two HiddenService directive to your torrc and restart Tor.

sudo vim /etc/tor/torrc

HiddenServiceDir /var/lib/tor/ssh_hs/ HiddenServicePort 22 127.0.0.1:22

Restart Tor to generate the service keys and name:

sudo service tor restart sudo cat /var/lib/tor/ssh_hs/hostname zeqnrkjiqvyaemip.onion

SSH in from some other machine using your onion name:

ssh zeqnrkjiqvyaemip.onion -l $USERID -o ProxyCommand="nc -X 5 -x localhost:9150 %h %p"

$USERID@zeqnrkjiqvyaemip.onion\'s password: Last login: Fri May 20 20:53:20 2021 from 127.0.0.1

Once you have confirmed you can SSH using the onion name, it’s a good time to shut SSH off from the clear net. Uncomment this line in your /etc/ssh/sshd_config file:

#ListenAddress 0.0.0.0

And change it to read :

ListenAddress 127.0.0.1

And restart SSH :

sudo service ssh restart

Keep your hidden service hidden (OpSec) :

Operational Security (OpSec) is the concept that collecting easily available, and seemingly unrelated, information can generate some very specific information. Tor itself is extremely good at anonymizing traffic, but humans are terrible at OpSec. Because of that, many people who have used Tor for evil have been successfully identified.

The highest profile Tor case is likely the Silk Road black market Tor site. The administrators of both generations of that site were arrested as well as some vendors. While the fine details will probably never be fully known, in most cases anonymity is being broken by sloppy OpSec rather than a weakness in Tor itself. However, there are cases where the Tor network itself may have been compromised.

There are reports that adversaries of Tor are operating Tor nodes. The idea being that if an adversary operated enough relay and exit nodes then large-scale traffic analysis could be performed to identify individual users. The FBI Operation Onymous that took down Silk Road 2.0 as well as 400 other sites was likely running Tor nodes as part of its investigative data collection. A number of Tor relays that were modified to change headers to reveal traffic flow information appeared in the Tor network leading up to the arrests. It’s also been noted that 129 of the 400 sites were hosted by a single web hosting provider. This may mean that hosting provider has poor OpSec, or it may mean it cooperated with law enforcement by providing internal server information not available to normal Tor users.

Whatever the case, if you want to remain disassociated from your Tor hidden service, you have a very large task ahead of you. The budget and determination of your adversary will quite likely be the determining factor of success rather than any steps you personally take. But, that’s no reason to be sloppy. Ben Tasker has written a thoughtful piece on Tor OpSec which bears reading. Here are some of the things that you should review to ensure you’re not leaking information that can be used to identify you.

Technical OpSec :

Security is best performed in layers; there is no silver bullet one size fits all security model. We see this in the Tor architecture in that no single node has enough information to compromise a user. Likewise, when setting up your Tor server and services, you should not trust them to be configured with your particular use case in mind.

Firewall :

We configured our two sample Tor services to listen only on the localhost interface. This should be enough to prevent them from being available in the clear net. But, things can happen that are out of your control so it makes sense to add a layer of security and firewall off the entire server on all ports. This will prevent your services from suddenly becoming available on the clear net due to a errant upgrade or human error.

Application headers :

There are two reasons to eliminate as many headers as possible in all your services. First, they may actually divulge information about your system that can help identify where it is. Second, even if they don’t divulge specific information like that, all data can be used in an attempt to fingerprint a server and later correlate it to some other, known, server to identify it.

You can remove the Nginx version string by using the server_tokens directive in server, location, or http section of your Nginx configuration file.

nginx headers tokens on

sudo vim /etc/nginx/conf.d/default/com

I put it in the server section:

server { server_tokens off; listen localhost:80 default_server; server_name _; ...

Now the version is gone:

nginx headers tokens off

You can go farther with Nginx by using the Headers More module. With it, you can set or remove a wider variety of headers.

SSH :

A special consideration with SSH is the server identification fingerprint. When you first connect to an SSH server, you are notified that your system can’t confirm the identity of the remote system, presented with the key fingerprint of the server, and asked what you want to do. Most of us accept it and then the public key of the server is stored in our known_hosts file. Subsequent attempts to connect to that service do not prompt us any more:

$ ssh zeqnrkjiqvyaemip.onion -l $USERID -o ProxyCommand="nc -X 5

-x localhost:9150 %h %p" The authenticity of host

\'zeqnrkjiqvyaemip.onion ()\' can\'t be

established. RSA key fingerprint is

SHA256:FroAZ5QibIdWgYyCajY3BxMQjR5XGQFwS1alTOarmQc. Are you sure you

want to continue connecting (yes/no)? yes Warning: Permanently added

\'zeqnrkjiqvyaemip.onion\' (RSA) to the list of known hosts.

$USERID@zeqnrkjiqvyaemip.onion\'s password:

This line is added to my know_hosts file:

zeqnrkjiqvyaemip.onion ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAQEArIR0Jn5fhY7kQxb37jBC1 hRFZlxjrs4YsWf4DVJjjY7dlVzhN5mEnmBZMsNSLbr9B3Fzk

8ukJp9BysAp0GbPDYT2egCggHfX79806KSMBIuUiU g6AsxsyZPjv8t2xRc7KBfqaDL2BVqOy1bnxUva1AsPHeRG/symeTA3

Zo Qz0YVNMN fPCS3YA7Bc7u1YbP6KLpwyFs CEcJdH1mHiGTx2Z0l9q7atj8tAheO7livBpLacP0SPseQqkEfJ/GWVUB7cW

KB7S2N1dy1M9im883Lpgp9Xe2doy2vScNwb70tES4zZg08AjSsybLXzSdYTEUqSP6IS0YWBE1dqdlfw==

So, the next time I log in that step is not performed :

$ ssh zeqnrkjiqvyaemip.onion -l $USERID -o ProxyCommand="nc -X 5

-x localhost:9150 %h %p" $USERID@zeqnrkjiqvyaemip.onion\'s password:

Last login: Fri May 20 01:10:30 2021 from 127.0.0.1

The problem with this lies in my known_hosts file. Since I connected to my server earlier using the public IP and my Tor proxy, I already have an entry for that onion fingerprint under a different IP address:

198.54.228.13 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArIR0Jn5fhY7kQxb37jBC1 hRFZlxjrs4YsWf4DVJjjY7dlVzhN5mEnmBZMsNSLbr9B3Fzk

8ukJp9BysAp0GbPDYT2egCggHfX79806KSMBIuUiU g6AsxsyZPjv8t2xRc7KBfqaDL2BVqOy1bnxUva1AsPHeRG/symeTA3

Zo Qz0YVNMN fPCS3YA7Bc7u1YbP6KLpwyFs CEcJdH1mHiGTx2Z0l9q7atj8tAheO7livBpLacP0SPseQqkEfJ/GWVUB7cWK

B7S2N1dy1M9im883Lpgp9Xe2doy2vScNwb70tES4zZg08AjSsybLXzSdYTEUqSP6IS0YWBE1dqdlfw==

This is a pretty powerful correlator. It’s almost certain that the IP address 198.54.228.13 is hosting my Tor service at zeqnrkjiqvyaemip.onion based on this information.

These are just two examples of ways in which your service can be fingerprinted for later identification. There’s probably no way to enumerate every possible way your service can be identified but application headers and behaviour are good umbrella topics to review.

Behavioural OpSec :

There are non-technical ways that your service may be tied to you as well.

Uptime :

Your service can be monitored for uptime. Many Tor services are not hosted in traditional data centers and my only be available sporadically. Correlating uptime cycles may give clues to the operator’s time zone or work schedule.

Account data :

There’s little sense in using Tor for anonymity if you access a site and then log in with identifiable information. Ross Ulbricht, convicted as the Dread Pirate Roberts of Silk Road (v 1.0), was momentarily distracted by FBI agents in a library and another FBI agent grabbed his laptop and ran. Ulbricht was logged in to his Silk Road DRP account. Obviously, Ulbricht had already been identified and was set up, but that tiny bit of social engineering allowed the FBI to catch him logged in to the account of the person they were looking for.

Username correlation :

Many people use handles or pseudonyms on the internet to hide their real identities. In some cases, they select a handle early on and just tend to stick with it, or at least re-use it from time to time. This is bad OpSec.

While this has nothing to do with Tor specifically, it serves as a good example of how historical account data can be used to identify people. Hillary Clinton’s email administrator Paul Combetta was targeted by Reddit users as the user ‘stonetear’ who was soliciting information about how to modify email recipients around the time the news of Clinton’s private email server surfaced. There is a long and easily traced history of Combetta using that handle so it provided almost no anonymity at all.

As with the technology OpSec concerns, there is probably no limit to the type of behaviour that can be collected and correlated to identify the operator of a Tor service. Your adversary will simply have to run out of ideas and money before you do.

METHOD 2 :

Common Deployments 

It's obviously very difficult to say what configurations/systems are preferred by Hidden Service operators, but anecdotal evidence would suggest that OpenVZ slices are incredibly popular.

It's not entirely clear why, as using an OpenVZ slice (on someone else's hardware) brings it's own set of risks, but the monthly cost is generally lower, and there are at least some OpenVZ hosts who are willing to accept payment in anonymous forms (such as BTC).

Because OpenVZ is effectively containerisation, the overhead of running a 'VM' is lower, so you can squeeze more slices onto a single server than you could traditional VMs.

For the HS operator though, it carries some additional risks :

Your root filesystem is a directory structure on the host system. The host can easily use tools such as grep and find to explore your filesystem. You don't have the option of HD encryption to protect against this

You have little to no control over what kernel modules are loaded

Escaping from containerisation is, generally, easier than escaping full virtualisation, so there's a (small) risk that another user on that system may also gain access to your VM

HTTP or HTTPS :

Connecting via Tor gives you encryption 'for free', but some thought should still be given to whether HTTPS is a better option. There are some definite drawbacks, but also some benefits to using HTTPS.

Consider the following (simplified) deployment

  Client -> Tor HS (ServerA) -> HTTP(S) Server (ServerB)

The Client's connection is encrypted until it reaches the hidden service on ServerA, however the connection is then proxied, in the clear to ServerB. There may be a number of reasons why you'd want to configure a hidden service in this way, the most obvious being the following

  Client -> Tor HS (ServerA) -> Load Balancer

  -> HTTP(S) Server (ServerB)

  -> HTTP(S) Server (ServerC)

In this deployment, there has to be some trust of the network between ServerA, the load balancer and Servers B&C. The client isn't even aware of the transmission in cleartext, so some would argue that you're unfairly putting their data at risk.

The Snowden leaks showed that the NSA had noted the point at which Google terminated SSL connections (and transmitted in the clear within their network) so it is worth considering if Tor is running on a different server to the services host. For more info regarding the Snowden leak, search for the phrase "SSL added and removed here"

Downsides :

If you use a self-signed certificate, users will see a certificate warning before they can access the site

If you want a CA signed certificate (once you find a willing CA) you as the service provider will likely need to sacrifice some anonymity in order to be issued the certificate

When generating a self-signed certificate, there are also a couple of risks associated - so we'll cover doing that as a precaution

Practice vs Live :

When working on a live server, you want to minimise the amount of information available for an attacker to use if they manage to compromise a server. The difficulty is, that whilst you want to practice that level of OpSec, it's also largely incompatible with looking back to understand where and why you made a mistake. To work around that, on a *practice server* it's wise to ensure you always to the following as soon as you've logged in

  screen -L

This will write a log of your activities (and program output) to ~/screenlog.0 Don't use screen sessions on a live server!

Getting Set UP

Before Tor is even installed, there are a few things which need to be considered

Initial access to the server :

SSH must be via Tor - a single direct connection could be logged and would forever associate your originating IP with that server.

Locking down SSH

Options :

Key based auth only

SSH access limited to a 'trusted' source IP

If key based auth is used, the public key needs to be inspected to make sure it doesn't tie back to you ( 2021 : for someone with resources/time, this can be done without compromising your box ). A new key should be generated and then specified in your client's SSH config file (using IdentityFile).

However, ideally SSH needs to be firewalled off to prevent against Server key comparison based attacks (See Firewall config basics below for an example).

This is less of an issue, however, if you are configuring a system which isn't directly reachable from the internet (such as a VM on a class C network)

If firewall rules are used, the 'trusted' server needs to be one that isn't directly associated with you. It could be an anonymous VPN endpoint, another virtual machine, or potentially a specific Tor exit node.

Each carries it's own risks, using a source only accessible to you reduces the likelihood of key comparison attacks, but may make it easier to identify the server administrator (you).

Permitting publicly accessible sources makes it harder to identify you, but may make it easier to identify your server as the host of a given hidden service.

One other option, once you've achieved the initial access to the server is to configure a VPN (e.g. OpenVPN) on the server and then limit non-tor SSH access to addresses within the VPN address range. You can then connect to the VPN via Tor (hiding your true source IP) without exposing SSH to other users. Although this is a valid option longer-term, you still need to be able to limit SSH access in the meantime.

Routine access will be via a hidden service dedicated for SSH use, but you need some sort of fallback access (for example, if you need to restart Tor). If a serial console is available, that's also a viable option instead of SSH.

If SSH is enabled on the server, you should also consider disabling root logins via SSH - though the various SSH hardening methods fall outside the scope of this document.

Firewall Config Basics :

In principle, no service that's made available via a Tor hidden service should be available to the Surface web. If a service is available on both, an attacker could compare information gleaned from both to prove that a given server hosts a given hidden service.

For example, if a hidden service providing SSH returns a server RSA fingerprint of A1234B, an NMap of the entire IPv4 address space could be used to identify whether any 'real' servers also return that fingerprint.

Traffic hitting a Hidden Service will always have an origination IP of 127.0.0.1 so adding an ALLOW rule for the loopback device should be sufficient to ensure connectivity.

Unless there's a specific case for doing otherwise (e.g. SSH), daemon's should be configured to bind to the loopback device only. This is done to mitigate any mistakes which may be made within the firewall configuration - external connections will fail

As a minimum, you'll want to do the following

    # Create a new chain for SSH

    iptables -N SSH

Replace the following source IP with your trusted host/source range.

    iptables -I SSH -s 192.168.1.3 -j ACCEPT

    iptables -A SSH -j DROP

These rules ensure that existing connections are given a pass, and allow all loopback connections

    iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -I INPUT -i lo -j ACCEPT

We then need to make the SSH rules apply - your connection will remain intact if the IP you authorised in the SSH chain was incorrect, just don't disconnect it

    iptables -A INPUT -p tcp --dport 22 -j SSH

Try and SSH to the server from an authorised IP. If you cannot connect you need to remove the rule (if your current connection drops for some reason you won't be able to reconnect without restarting the server) Once happy that the rules are appropriate, save them

    service iptables save

Protecting your History :

By default, most shells will log your command history (for example BASH logs to ~/.bash_history). To help minimise the information available to an adversary who has compromised your server, you should do the following Ensure the file will never contain content

  rm ~/.bash_history

  ln -s /dev/null ~/.bash_history

Effectively disable any other history logging:

  echo "alias exit='kill -9 \$\$'" >> /etc/profile

The second change ensures that running 'exit' will send a SIGKILL to the parent process rather than running a true exit. Any commands set to run on logout (such as writing a history file) will not execute.

Hidden Service Layout Design :

Some thought needs to go into how many Hidden Service descriptors you want to publish. Services that are not related to each other should always use different .onion addresses.

For example, assuming you wanted to make the following available via Tor Hidden services

HTTP

HTTPS

SSH

FTP (for users of the HTTP/HTTPS site)

Where the SSH access is only provided for your administration purposes, you'd want 2 hidden services, one containing SSH and the other the 'advertised' services, e.g.

HTTP, HTTPS, FTP - 123.onion

SSH - 456.onion

This helps to defend against two different threats

Tor based adversaries trying to compromise your hidden service

Adversaries trying to identify the Surface web address of the hosting for that hidden service

In the SSH section above, an example of correlating HS and Surface web Server fingerprint's was given. Using a different .onion means that should such an attack occur, without further compromise of your systems, that adversary would only be able to show that the physical server is hosting 456.onion.

If the HTTP(S) descriptor also provided the SSH service, that adversary would now have identified you as the hosting platform for 123.onion

Preparation Specifics :

So far, we've simply designed or made minor changes. Before we can install and configure Tor we need to make some specific changes to invalidate any information that an adversary might already have captured about our server (such as SSH RSA fingerprint)

To begin with, we need to ensure that the SSH restrictions are in place, so ensure you've got a firewall rule restricting access to port 22 to a trusted source IP (or have serial console access etc).

Our next step is to make sure that any keys already collected by our unnamed adversary won't match those of the hidden service when published

    ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

    ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa

    ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

    ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa -b 521

The next time you SSH to the server from the client you are currently using, you will see a warning that the server key has changed.

This provides a good means to ensure that the changes were successful, so without disconnecting your current session, try to start a new SSH session (from the same client) with the server.

We also want to ensure that SSH won't leak information whenever we try to connect. The first thing we need to address is SSH's tendency to perform a reverse DNS (PTR) lookup whenever a client attempts to connect

    echo "UseDNS no" >> /etc/ssh/sshd_config

Now we need to make our changes take effect

    service sshd restart

Installing Tor :

Always use the Tor provided repos - where distros provide their own Tor builds, they tend to fall out of date which may expose you to known weaknesses. Assuming a CentOS 6 server, do the following Create /etc/yum.repos.d/tor.repo and enter the following content into it

[tor]

name=Tor repo

enabled=1

baseurl=https://deb.torproject.org/torproject.org/rpm/el/6/$basearch/

gpgcheck=1

gpgkey=https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc

[tor-source]

name=Tor source repo

enabled=1

autorefresh=0

baseurl=https://deb.torproject.org/torproject.org/rpm/el/6/SRPMS

gpgcheck=1

gpgkey=https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc

Then run

    yum install tor -y

    service tor stop

    chkconfig tor off

The installer, by default, will start the Tor service (which is, a little irritating). We don't want Tor running until we've configured it, so we've stopped the service and removed Tor from init (just in case the system reboots whilst we're working).

Configuring Tor :

Don't do this until you have restricted SSH access using iptables!

By default, the Tor configuration file contains a lot of entries, some we need, some we don't. You should never run a system as both a relay and a hidden service host as an adversary will easily be able to correlate any HS downtime with the relay information published in the Tor atlas (and onionoo etc).

The deployment that you'll most likely want, is to have Tor configured both as a client and publishing Hidden Services (we'll look at why you need the former shortly).

So to begin with, enter the following into /etc/tor/torrc (I usually blank the file before beginning)

    # Run in the background

    RunAsDaemon 1

    # Use the default DataDirectory

    DataDirectory /var/lib/tor

    # Client Config

    TransPort 9040

    TransListenAddress 127.0.0.1

    DNSPort 127.0.0.1:54

    # Configure the Socks proxy (useful for troubleshooting)

    SocksPort 127.0.0.1:8080

    SocksPolicy accept 127.0.0.1

    SocksPolicy accept 192.168.1.1 # Replace this with the server's IPv4 address

    SocksPolicy reject *

At this point, we've effectively configured Tor to act as a client and enabled the Socks proxy (allowing us to use a tool like tsocks or torify to force wget requests and the like over Tor)

The next thing to do, is to add some Hidden services - each needs to have it's own directory within the data directory (Tor will create the dir if it doesn't exist).

So in /etc/tor/torrc we might do the following

    HiddenServiceDir /var/lib/tor/ssh_hs/

    HiddenServicePort 22 127.0.0.1:22

Where the syntax of HiddenServicePort is

    HiddenServicePort [Listen to Port] [IP/Port to proxy connections to]

If we start Tor now, it'll generate a private key for each, a hash of which will give us the hostname

    service tor start

    cat /var/lib/tor/ssh_hs/hostname

Note: If at this point you receive 'Permission Denied', you may want to look at reconfiguring SELinux to work with Tor

If you want to back up the private key (if so, do it securely, that key is all that's required for someone to publish to the same address) it can be found in /var/lib/tor/ssh_hs/private_key

There are additional options that you might consider setting in torrc, see 'Other Considerations' below.

Within a few minutes, from a Tor connected client, you should be able to SSH to that hostname. Our next step is to configure our SSH client to make connecting a little easier

We can also now allow Tor to start at boot

  chkconfig tor on

Client SSH Config :

This section assumes you'll be initiating SSH connections from a Linux based system - and it'll obviously need to have Tor installed and running. This section assumes Tor is configured (as by default) to expose a SOCKS proxy on port 9050

You'll also want Netcat (nc) to be installed

First, we generate a new keypair to use when authenticating with the server (you want to make sure you use a different key for every SSH hidden service - if one or more gets compromised, you don't want a comparison of authorized_keys to be able to show there's a common administrator)

    ssh-keygen -b 4096 -t rsa -C "myKey" -f ~/.ssh/sshhs1.rsa

You should set a password for the key, but it is technically optional A breakdown of the arguments used is

    -b 4096 - Keylength should be 4096 bits (4K)

    -t rsa  - Generate a RSA keypair (Assuming your server supports Eliptic

      Curve, you could use ecdsa but there's no current security 

      benefit)

    -C "myKey" - Set the comment to be 'myKey'. Normally this would be

$USER@$HOSTNAME which we want to avoid

    -f - Output file

Next you want to authorise that key, so (we'll look at what the arguments mean shortly)

    ssh-copy-id -o VerifyHostKeyDNS=no -o User=user -o CheckHostIP=no\

    -o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" \

    -i ~/.ssh/sshhs1.rsa domain

Where user is the username you're using to SSH onto the server, and domain is your .onion

Once your key is copied across, you should be able to connect with the following

    ssh -o VerifyHostKeyDNS=no -o User=user -o CheckHostIP=no\

    -o IdentitiesOnly=yes \

    -o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" \

    -i ~/.ssh/sshhs1.rsa domain

Whilst functional, this is obviously a nightmare to type and introduces a huge scope for mistakes. So the next thing to do is to populate your SSH configuration file with these settings Open ~/.ssh/config for editing and insert the following

    Host onionwebsite

      Hostname domain # This should be your .onion

      User user # Whatever username you connect with

      IdentityFile ~/.ssh/sshhs1.rsa

      ProxyCommand nc -X 5 -x localhost:9050 %h %p

      VerifyHostKeyDNS no

      CheckHostIP no

      IdentitiesOnly yes

The name specified for 'Host' is nothing more than a nickname to pass to SSH (so can be the full .onion if desired). Once you've saved the conf file, running

    ssh onionwebsite

will be the equivalent of the commands given above.

The arguments we're passing to SSH are

IdentityFile - Specifies the key to use when authenticating

ProxyCommand - Establish a connection to a proxy (using the specified command)

in order to then try and establish the SSH session. In this

case that means route over Tor

VerifyHostKeyDNS - By setting this to No, we're ensuring our SSH client will

   _NOT_ make a DNS request to try and verify the received

   host key. 

   Failing to set this potentially gives you a major source 

   of information leakage whenever you attempt to connect to

   the server.

CheckHostIP - Don't perform a DNS lookup of the hostname (the Tor proxy will

do that for us and we don't want an observable DNS request 

going over the Surface web)

IdentitiesOnly - By default, SSH will offer up any keys it knows about to try

and authenticate. This is inefficient and introduces a (small)

risk that a compromise of the server could lead to you being 

identified. 

Setting IdentitiesOnly to yes tells SSH to only ever use the 

keys listed in IdentityFile.

Things to Remember :

You should now be set to SSH via your hidden service address, and having copied a key to the server can safely disable Password authentication with SSH if you wish.

As was noted at the beginning, you need to ensure that any changes you make do not prevent you from gaining access to the server via alternative means. At times, you may need to restart the Tor client, which will cause your SSH session to drop, if for any reason Tor does not come back up, you need to have the means to connect and correct that.

Routine connections to the server should be made via the Hidden Service address to minimise the potential for an adversary to identify you as the administrator of the system. Using a hidden service (rather than transitting via a Tor exit node) also reduces an adversary's ability to identify the times at which an administrator connects via SSH (reducing the likelihood of Timezone identification etc).

Tor - Other Considerations :

The configuration used for Tor above is fairly basic, and there may be other options that you want to consider introducing. For example, in the configuration above, the tor daemon will be permitted to use all CPU cores if needed. If for some reason, you wish to limit usage to a specific number of cores, you can add the following to torrc

    NumCPUs 2

On CentOS, Tor will automatically drop root privileges and run as user _tor. This is not always the case on other distributions, so you may need to create a user (say _tor) and include

    User _tor

If you have multiple NICs and want to ensure that Tor only uses one, you can tell Tor which IP to bind to, so in the following example

eth0 192.168.1.2

eth1 192.168.1.3

To ensure Tor only ever uses eth0 you'd enter the following in torrc

    OutboundBindAddress 192.168.1.2

If you're particularly concerned about Tor writing connection information to disk, you can set the following to reduce the likelihood of this occurring

    AvoidDiskWrites 1

    DisableAllSwap 1

This will minimise writes where possible and attempt to prevent memory from being paged to disk.

You can view the options you tor client supports by running

    tor --list-torrc-options

The Tor Project publish a manual on what each of these mean at https://www.torproject.org/docs/tor-manual.html.en

Basic Setup :

NGinx Installation & Configuration :

On CentOS, getting a basic install of NGinx is as simple as as adding the EPEL repository and then running an install.

  U='http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm'

  rpm -Uvh $U

  yum install nginx

  service nginx stop

  chkconfig nginx on

The default configuration contains some small HTTP leaks, however, so changes need to be made to ensure that the server's true identity is not leaked.

To begin, we want to ensure that NGinx will never be accessible via Tor and the Surface web at the same time.

In part 1, we added some basic firewall rules, so we'll start by explicitly blocking external access to the relevant ports

  iptables -A INPUT -p tcp --dport 80 -j DROP

  iptables -A INPUT -p tcp --dport 443 -j DROP

  service iptables save

Next, we want to ensure that if the firewall rules are ever accidentally flushed, we won't automatically be exposed to detection.

To achieve this, we need to edit the default server block and explicitly bind it to the loopback adapter.

  nano /etc/nginx/conf.d/default.conf

Note: On Debian based systems, this will be /etc/nginx/sites-available/default

Within that file, you will see an NGinx Server block, the section we're interested in is the listen directive:

  server {

      listen       80 default_server;

      server_name  _;

Change this so that we explicitly bind to localhost

  server {

      listen       localhost:80 default_server;

      server_name  _;

Were we to start NGinx now, only connections made via the loopback adapter would establish.

NGinx also includes some basic information about itself in headers though, to reduce the amount of information available to an adversary, we want to ensure that that information isn't disclosed.

  nano /etc/nginx/nginx.conf

Within the http section, we want to set the following

  server_name_in_redirect off;

  server_tokens   off;

  port_in_redirect off;

The first of which specifies that the configured server name won't be used in any redirects which may be generated by NGinx.

The second removes version information from both the Server header and error pages.

The third will have no obvious effect if you've configured NGinx to listen on port 80. However, if you have configured it to listen on a different port to that which the client will connect via (i.e. Nginx on port 8080, Tor configured to listen for connections on 80), then this option ensures that NGinx will never include it's configured port number when generating a redirect.

Sanity Checking Our Changes :

In theory, we should now be ready to configure Tor to expose a hidden service and then look at setting up our site. However, we first need to check what data NGinx might expose about itself

We need to run a number of tests, which are most easily achieved with the GET command

  yum install perl-libwww-perl

To begin with, we need to start Nginx

  service nginx start

Our first check is designed to check normal behaviour

  GET -Ssid http://127.0.0.1

Which should give something similar to the following

  GET http://127.0.0.1 --> 200 OK

  Connection: close

  Date: Fri, 20 May 2021 01:20:56 GMT

  Accept-Ranges: bytes

  Server: nginx

  Content-Length: 3698

  Content-Type: text/html

  Last-Modified: Fri, 20 May 2021 01:20:56 GMT

  Client-Date: Fri, 20 May 2021 01:20:56 GMT

  Client-Peer: 127.0.0.1:80

  Client-Response-Num: 1

  Title: Test Page for the Nginx HTTP Server on EPEL

The main thing we're looking for is any header which could potentially be used to fingerprint the server (even if non-uniquely).

Due to the way Tor Hidden services work, you can safely ignore the Client-Peer header.

In the example above, there's nothing which may identify us, NGinx isn't even using the server's configured timezone in it's responses.

The Next thing to do, is to perform the same check for 404's

  GET -Sse http://127.0.0.1/onionwebsite

Check the content for signs of specific version strings, or anything else you feel could be used to fingerprint the server.

Although it's tempting to override the default error pages, doing so (at the default level) could potentially be used to help fingerprint the server if NGinx were ever accidentally exposed to the Surface web.

Building a Static Site :

Unless you've used Shallot to generate a custom .onion you'll need to configure Tor to serve the new hidden service before you can start setting it up.

Open /etc/tor/torrc and add the following to the bottom of the file

  HiddenServiceDir /var/lib/tor/onionwebsite/

  HiddenServicePort 80 127.0.0.1:80

Save and exit, stop Nginx, and then reload tor

  service nginx stop

  service tor reload

(Use reload and not restart, the latter will break your SSH session if you've connected via your .onion).

We stopped Nginx because we don't want any accesses to the new Hidden Service descriptor to result in NGinx's default page being served.

Grab the hostname we've generated (and make a note of it)

  cat /var/lib/tor/onionwebsite/hostname

Next, we need to create a docroot and tell NGinx where to serve from

  mkdir -p /usr/share/nginx/onions/onionwebsite

  echo "Hello World" > /usr/share/nginx/onions/onionwebsite/index.html

We'll create a new file to hold the configuration for our onion site

  cd /etc/nginx/conf.d

  cp default.conf onions.conf

If we now open onions.conf for editing, we want to change the server block to reflect the following

  listen localhost:80; 

  server_name foo.onion; # Use whatever tor gave you

  root /usr/share/nginx/onions/onionwebsite;

  location / {

        root   /usr/share/nginx/onions/onionwebsite;

        index  index.html index.htm;

  }

You can define an onion specific access log if you'd like, though the only interesting information it's likely to contain is what was requested and when. All readers will have a source IP of 127.0.0.1 and all Tor Browser Bundle users will have the same User-Agents.

If we start NGinx now, our (extremely basic) static HTML site should be accessible over Tor.

CGI Scripts :

When using any kind of server side scripting, the risks on information leakage increase greatly.

Whatever solution is being deployed (whether it's a CMS, a bug tracker or something else) the solution itself needs to be carefully checked for anything which may lead to leakage. These may include

Server Information pages :

Experience 'improvement' functionality (essentially, call-home scripts)

Certain CAPTCHA implementations :

The potential risks will vary with each application you deploy, so looking at the specific risks falls outside the scope of this training.

One thing that all have in common, though, is that some sort of application handler will need to be installed and configured in order to run the scripts. The potential risks will vary both with the languages (e.g. Perl, Python) and the handlers themselves.

PHP-FPM :

To provide an example of the kind of thing you need to be checking your CGI handler for, we'll be installing and configuring PHP-FPM.

PHP is known to have a number of leaks, and there are a wide number of PHP applications which can be used, so it's probably a good place to start learning.

  yum install php-fpm

PHP by default will leak it's major version number, and will attempt to 'correct' incorrect URLs by using a 'closest match' mentality. The former can be used for fingerprinting, whilst the latter is incredibly useful if trying to exploit directory traversal vulnerabilities, amongst other things

We disable them both by changing their value in php.ini

  sed -i 's/expose_php = On/expose_php = Off/' /etc/php.ini

  echo "cgi.fix_pathinfo=0" >> /etc/php.ini

Disabling expose_php also brings another (undocumented) benefit. Certain PHP versions contain a number of 'easter eggs' which can also be used to identify the version of PHP being run on the server.

We also want to be sure that error messages will not be displayed to visitors (this should be the default, but again, it's best to be sure).

  sed -i 's/display_errors = On/display_errors = Off/' /etc/php.ini

Failing to prevent the display of errors could lead to serious leakage - most errors will contain filepaths, however the exact information contained in an error/notice will depend on exactly what caused the issue.

In PHP > 7.4 Server timezone information is regularly included in PHP Notice errors

Our next task is to tell NGinx to pass requests for PHP scripts through to PHP-FPM, so open /etc/nginx/conf.d/onions.conf for editing, and add the following to your server block

  location ~ \.php$ {

      root           /usr/share/nginx/onions/onionwebsite;

      fastcgi_pass   127.0.0.1:9000;

      fastcgi_index  index.php;

      fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

      include        fastcgi_params;

  }

Save and exit.

For the changes to take effect we need to reload NGinx (or start if you haven't already)

  service nginx reload

We can create a simple PHP file to test against

  echo '<?php echo "hello world";?>' > /usr/share/nginx/onions/onionwebsite/test.php

<?pre>

And then use GET to see whether the request is correctly passed through (set the

Host header to be the .onion you're setting up)

  GET -H "Host: foo.onion" -Sse http://127.0.0.1/test.php

You should see the headers (with a HTTP 200) followed by a blank line and the string "hello world".

HTTPS :

Configuring a Tor Hidden service to use HTTPS is fairly straight forward, although there are some pitfalls to be avoided - especially if you're intending on running multiple hidden services.

In this section we'll be looking at generating a HTTPS certificate and then configuring NGinx to use it.

Safely Generating an SSL Certificate :

There is a wealth of documentation available online on how to generate a self-signed (snakeoil) certificate, however most of this documentation includes a step which may lead to identification if certificates are generated for multiple hidden services.

Many of the tutorials involve creating your own Certificate Authority and using that to sign your new certificate. As details of the signing CA are embedded within the certificate, and adversary will be able to see that there is a common CA for all certificates that you generate.

This simple information leak allows an Adversary to identify that there is likely a common administrator for each of the affected Hidden Services.

In order to avoid this, we want to generate a certificate without creating a CA. Assuming you do not want to encrypt your private key, run the following

  openssl genrsa -out server.key 2048

If you do want to password protect the key (you'll need to enter the password whenever restarting NGinx)

  openssl genrsa -des3 -out server.key 2048

Next, we need to create a Certificate signing request

  openssl req -new -key server.key -out server.csr

Try to leave the questions at their defaults (for example, country code of XX), but for the common name you'll need to enter your .onion address.

Finally, we create the certificate

  openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

We now want to sanity check the generated certificate to ensure it doesn't contain any un-necessary information.

  openssl x509 -in server.crt -text

Details for both the Issuer and the Subject should be non-descript.

Configuring NGinx to use HTTPS :

Now that we've created a certificate, we need to tell NGinx to actually use it.

First we need to move our Certificate and private key into sane locations

  mv server.key /etc/pki/tls/private/onionwebsite.key

  mv server.crt /etc/pki/tls/private/onionwebsite.crt

Next, we need to create an NGinx server block, configured to use HTTPS

The configuration will be more or less the same as for our HTTP onion - except that we need to enable SSL and set a few options related to that.

  nano /etc/nginx/conf.d/onions.conf

  server {

      listen       localhost:443; # We want to listen on port 443

      server_name  onionwebsite.onion;

      root /usr/share/nginx/onions/onionwebsite;

  # Enable SSL and identify the certificate/key

      ssl                  on;

      ssl_certificate      /etc/pki/tls/certs/onionwebsite.crt;

      ssl_certificate_key  /etc/pki/tls/private/onionwebsite.key;

      ssl_session_timeout  5m;

      # Limit the types of encryption that can be used 

      # (to reduce the  possibility of downgrade attacks)

      ssl_prefer_server_ciphers On;

      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

      # You may also wish to disable specific ciphers here

      # The rest of the config is identical to our HTTP config

      location ~ \.php$ {

    root           /usr/share/nginx/onions/onionwebsite;

    fastcgi_pass   127.0.0.1:9000;

    fastcgi_index  index.php;

    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;

    include        fastcgi_params;

      }

      location / {

  index  index.html index.htm;

      }

      # Here, we've left the error pages as the default, though it's

      # relatively safe to tweak them on a per-hidden-service basis

      # if you wish

      error_page  404              /404.html;

      location = /404.html {

  root   /usr/share/nginx/html;

      }

      # redirect server error pages to the static page /50x.html

      #

      error_page   500 502 503 504  /50x.html;

      location = /50x.html {

  root   /usr/share/nginx/html;

      }

  }

If you save the configuration and restart NGinx, it should now be available on port 443

  service nginx reload

Lets test our connection

  echo | openssl s_client -connect 127.0.0.1:443

We should see our certificate details. This, however, is an issue in itself - we only want an onion's certificate to be supplied if the request uses that onion's hostname within the SNI request. Currently, any attempt to connect via SSL will return this certificate, regardless of hostname:

  echo | openssl s_client -servername in.correct -connect 127.0.0.1:443

To prevent this, we need to generate a generic certificate and configure NGinx to use that

  openssl genrsa -out server.key 2048

  openssl req -new -key server.key -out server.csr

Answer the questions, again using the defaults. When asked for a Common Name enter 'Default.Site'

Sign the CSR to generate a certificate

  openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

  mv server.key /etc/pki/tls/private/default.key

  mv server.crt /etc/pki/tls/certs/default.crt

We simply need to configure the default server block so that it also supports SSL.

Add the following lines to the server block in /etc/nginx/conf.d/default.conf

  listen localhost:443 default_server ssl;

  ssl_certificate /etc/pki/tls/certs/default.crt;

  ssl_certificate_key /etc/pki/tls/private/default.key;

Reload NGinx's configuration and then try connecting with openssl again

  service nginx reload

  echo | openssl s_client -connect 127.0.0.1:443

You should now see the new certificate in use. Using SNI though, you should get the certificate for your onion

  echo | openssl s_client -servername foo.onion -connect 127.0.0.1

Now, should anyone ever manage to establish a HTTPS session to your server, it won't automatically disclose the fact that you're hosting at least one .onion site.

One thing that may still happen, though, depending on the browser in use, is that the default.site certificate may be used for connections to your .onion address.

It essentially boils down to whether or not the browser supports SNI. It's easy to replicate the behaviour with wget:

  wget --header="Host: onionwebsite.onion" https://127.0.0.1

Because wget doesn't automatically parse the host header (when passed in that manner) it won't use SNI and so the server uses the default.site certificate to serve foo.onion.

It's therefore very important to ensure that HTTPS, in particular, is never available on both the Surface web and a Tor Hidden Service at the same time (and the certificate should be regenerated with a new private key if changing between the two) as the certificate can be used as definitive proof that the server is the same as the one hosting the Hidden Service.

For the same reason, you should never have two HTTPS hidden services on the same system - sending a non-SNI request to each is more than sufficient to prove that both hidden services have the same admin (and are likely on the same physical server).

If there is a need to have multiple HTTPS hidden services on the same physical machine, the safest means is to use containerisaion (such as OpenVZ), allowing you to run completely distinct NGinx processes with different keys.

Configuring Tor to serve the HTTPS version :

Configuring Tor is as simple as adding an additional port directive in /etc/tor/torrc. Open that file for editing, and find the relevant hidden service definition.

Just after the declaration for Port 80, add

HiddenServicePort 443 127.0.0.1:443

And then reload Tor

service tor reload

Depending on your needs, you can then optionally configure the port 80 version of the .onion to automatically redirect users to the https version - just as you might on the Surface web.

Hidden Service Design Safety :

As we've seen, setting up a hidden service is straightforward, but avoiding a number of potential pitfalls requires a bit of forethought and planning.

It's important to adopt the mindset that both mistakes and compromises do happen from time to time, so that you automatically put failsafes in place as you go.

For example, you may have noted that the firewall rules we added at the beginning of this module have very little effect - the Nginx server blocks are bound to the loopback interface, so even without those rules, NGinx shouldn't respond to connections from the Surface web.

The risk, of course, is that it's very easy to forget to include 'localhost' when writing a listen directive. The firewall rules are there to ensure that if that mistake is ever made, some protection remains in place.

Conversely, binding to the loopback interface ensures that if the firewall rules are ever accidentally flushed, NGinx still shouldn't be exposed to the wider world.

Particular care needs to be taken when using any kind of server side scripting.

If an adversary finds a way to execute arbitrary code on your system, they can very quickly identify the physical server that you're located on. Just as on the Surface web, there are mitigations you can put in place to reduce the attack surface, but the best defence is to ensure that server side scripting is used only where absolutely necessary.

As discussed in the previous module, in certain deployments, using HTTPS may provide your users with some additional security. However, it needs to be very carefully implemented to minimise the risk of information leakage.

When generating a default certificate, the values given need to be as generic as possible, to help ensure that a correlation cannot be found between multiple servers (as you may, one day, be running multiple services).

This section will cover how to implement various mechanisms which may be of use in protecting from Spam/bots and user account compromise.

Many of the approaches used on the Surface web are effective, but may lead to a small loss of privacy. Most Hidden Service users use Tor precisely because they care about privacy and will expect that design decisions that you make will take that into consideration

In the previous module, it was stated that using server-side scripting should be avoided where possible. For some sites, though, it simply isn't possible - forums for example simply don't work without some form of scripting.

Credential phising is particularly prevalent on the darknet, so you may wish to implement 2 Factor Authentication so that your users can choose to use an additional level of protection. Mechanisms such as Google Authenticator and the Yubikey obviously aren't going to be particularly welcome, as they require information to be disclosed to a third party.

Similarly, you may wish to send emails to users, but care needs to be taken in order to do so without revealing the identity of your server.

In this short module, we'll be looking at :

Bot/Compromise Protection

    CAPTCHA's

    2 Factor Authentication (2FA)

Email

    MTA : Tor

    HS : Public Mailserver

Handling User Data in General

    Opsec is essential

Backups

    Push

    Pull

    Encryption

Bot/Compromise Protection :

CAPTCHA's :

Traditional CAPTCHA services (such as ReCaptcha) require a request to go to a third party (such as Google) to generate (and often to verify) a Captcha. On Tor, this is generally considered to be unacceptable.

You may also, as seems to have been true in Ross Ulbricht's case, be risking your own anonymity by using such a service. It's alleged that Ulbricht misconfigured his Captcha in such a way that it was leaking his server's Surface web address, ultimately leading to identification of the server.

Whether or not this is true, it highlights two major lessons which can be learned

Never use the Surface web IP/hostname in testing, use 127.0.0.1

Minimise use of third party services as far as possible

Although traditional CAPTCHA's are not a good fit for Tor hidden services, it is true that you may still have a need for the protection that they provide.

Essentially, there are two options

Roll your own (basic) CAPTCHA generator

Use a CAPTCHA generator designed for hidden services

The former is generally preferred - although it may be via a hidden service, the latter still requires that trust be placed in an unknown third party. Your captcha needn't be too complex to keep the most common bots out of a Tor Hidden Service.

2 Factor Authentication :

On the Surface web, there are a number of mechanisms commonly used to implement Two Factor Authentication:

User receives a text containing a one-time passphrase/string

User runs an app to generate a one-time passphrase/string

User has a hardware token that generates a one-time passphrase/string

Each of these has it's own strengths and weaknesses, but none of the above are really suitable for a Tor environment as they either require the user to surrender identifying information (e.g. their mobile number), require a request to be made to an external service (e.g. such as Google Authenticator).

At a technical level, you could, theoretically, implement a Tor friendly 2FA solution using a Yubikey. The default configuration would require an API request to go to Yubico's servers, but it is possible to run your own. Most users, however, wouldn't be happy with having a yubikey configured to use a server specific to your site (or Tor in general) as it could consitute physical evidence in some states.

There is, however, a Tor friendly 2FA solution which can be implemented - PGP.

Some sites, after (or during) registration will allow users to upload their PGP public key. Once the 2FA functionality is enabled for a user account, their login flow becomes something similar to the following

Enter username/password and submit

Server encrypts a random string using their public key

User is presented with the ASCII armoured output

User uses their public key to decrypt the string

User enters string into the field supplied and submits

Server checks the string matches and grants access if so

There are a number of common traps to avoid though.

Firstly, you must warn users to use common sense regarding the key they upload. There's very little point in taking steps to keep users anonymous if they then upload a public key with their (publicly known) email address as the recipient. Users should always generate a new keypair using bogus data.

If an invalid password is entered for a user with 2FA enabled, a 2FA page should still be displayed. If an attacker is attempting to access an account, you don't want to admit that they've at least got the password correct (as it may be in use somewhere else). Internally, you can log whether it was 2FA or the password that failed if you wish, but never tell the user trying to log in.

The string you generate doesn't need to be long, but it must be impossible to predict, otherwise the protection that 2FA is supposed to offer is completely negated.

You also need to ensure that uploading a public key and actually enabling the 2FA are two distinct steps. Ideally, you should include a 'test' run within the enabling process so that the user can verify that they've uploaded the public key that they think they have - it's all too easy for a user to lock themselves out of their own account if 2FA is automatically enabled as soon as they've submitted their public key.

Email :

Having a Hidden Service send emails to users requires far more planning than on an equivalent Surface web service.

On the Surface web, you would simply install a Mail Transport Agent (MTA) such as Postfix or Exim and then configure your back-end to send mails via that.

However, a quick glance at the headers of any mail sent through this MTA will reveal your server's IP address - something which is obviously undesirable.

There are a number of options available, each with their own benefits and drawbacks, and it's important to assess which best fits your needs.

MTA : Tor

The simplest way to add email support to your hidden service is to install and configure an MTA, and then add a firewall rule to ensure any traffic your MTA generates is routed over Tor.

Depending on the MTA, you may also need to adjust configuration to ensure that the server doesn't reveal anything about itself.

The major drawback with this approach, however, is that the receiving MTA may reject your mail (or mark it as spam) as the connection source (as it sees it) will be a Tor exit node and may well be included in DNSRBL's.

As your mailserver isn't on the Surface web, you'll also be unable to receive mails sent in response - which may or may not be an issue for you.

You will also need to give careful thought to which MTA you use, and how your hidden service will access it. For example, in some circumstances, Exim may leak BCC addresses . On a Surface web service this may just be embarassing, but on a Hidden Service it constitutes a huge breach in user trust and depending on the content of your hidden service may put users in certain jurisdictions in danger.

Benefits:

Quick and relatively easy to implement

Downsides:

Mail may not actually be received by the users

You'll need to properly configure your MTA

Hidden Service : Public Mailserver

To reduce the likelihood of your mail being filed in the user's spam folder, you'll probably want to use a publicly accessible mailserver. Running your own is an option, but will associate you with the hidden service.

An alternative option is to create an account with an anonymous friendly mail provider such as cock.li or riseup.net. You can then configure your hidden service to connect (via Tor) to this mailserver in order to send mail.

As the mailserver is routable on the Surface web, you'll also be able to receive any responses which may be sent (whether via manually logging in, or having your hidden service retrieve mails using IMAP).

Mailproviders such as Google Mail or Outlook.com should be avoided as they have a tendency to require a mobile number for 'verification' when access is made from a known anonymous proxy (such as a Tor exit node).

You will need to be careful about how you access/set up the account however. No matter how anonymous friendly the mail provider may be, you should always assume that everyone has a price at which they'll sacrifice their principles. Never make a direct connection to their services, as it could potentially later be used to identify you.

Benefits:

Relatively quick and easy to set up

Replies can be sent/received

Likelihood of the mail being rejected is reduced

Downsides:

Service Reliance on an unknown third party

Care needs to be taken when accessing/setting up account

Handling User Data in General :

When considering what user data you need to collect in order to run your service, it's incredibly important to ensure that things are kept minimal.

The only acceptable way to run a service (whether on the Surface web or Tor) is to assume that at some point you will be compromised, and in fact already may have been.

If an adversary manages to identify you as the administrator, you never want to be in a position of being coerced into releasing data on your users. The only way to ensure that, is to never collect identifying data in the first place. For many services, a username and password is all that you will need to collect.

Any data that is collected, for whatever reason, should be encrypted to ensure that simple vulnerabilities (such as SQL Injection) do not lead to the full-scale release of user data. The decryption keys will need to be available to the service somewhere, so encryption doesn't give much protection against a full server compromise, but you should attempt to mitigate the effects of a compromise at any level.

When deciding whether information is 'identifying', consider the various ways in which an adversary might use the data. Certain data points may not be identifying on their own, but can be correlated against data found elsewhere in order to build a profile of the user involved. Take the following as a simplistic example

Data recovered from you :

Username

Zip Code

Data recovered from another service

Username

House number ( without street or Zip )

On their own, neither data set is much use for establishing more than a general vicinity for the user, when combined, however it becomes easy to reduce the number of potential candidates.

You have very little control over what data other services collect, but you can ensure that your systems do not require the user to part with more data than is absolutely necessary. Depending on how serious the consequences might be if an individual was identified as a user of your service, you may wish to encourage users to use a unique username (i.e. not one they've used elsewhere).

Opsec is Essential :

Although this module is aimed at protecting user privacy, many of the techniques we've looked at are nominally concerned with protecting the identity of our server.

The reality is, that however innocent (or otherwise) your services may be, as a Hidden Service operator you hold the keys to user data. As we've already discussed, seemingly meaningless data can be correlated against other data in order to establish a profile.

Your users fortunes are therefore, to some small extent, tied to your own. Quite aside from wanting to protect your own anonymity, a failure in Operational Security (OpSec) could allow an adversary to coerce you into revealing data, or making changes in order to collect additional data.

For example, the (now defunct) secure email service - Lavabit - was famously targetted with a National Security Letter. Although the service could not view user emails, the US Government attempted to force the service to make changes and reveal data that would allow interception of these mails to occur. So whilst you can take steps to ensure you collect minimal data, be aware that a failure to protect your own identity could lead you to being coerced to make similar changes.

Backups :

There's obviously very little point in securing your server if you then push backups, in the clear, across the Surface web.

Having off-server backups is obviously desirable, but careful thought needs to be given to exactly how these are implemented.

Push Backups :

Backups using a 'push' method are fairly common and popular on the Surface web. Whether pushing up to Amazon's S3, or rsyncing to another server, there are a wide range of solutions available.

However, careful thought needs to be given to where you are pushing to. Should the server be compromised, you need to be able to ensure that examination of the backup method in use won't lead to your identification (as it might if pushing to an S3 account).

You'll also probably want to ensure that your backups are pushed out via Tor to ensure that the backup service cannot identify the server hosting your hidden services (in case unencrypted files are ever accidentally pushed).

Pull Backups :

A simple pull mechanism works around a number of the risks involved in using push backups, but does also introduce some new risks.

A basic set up would be

Create a new HTTP(S) hidden service, protected by HTTP Basic or Digest authentication.

The document root for that service would be configured to be the directory that your backup archives are written into.

A script on a system with a Tor client downloads your backup archive at pre-configured intervals.

The advantages of running backups in this way is that neither the backup server, nor the hidden service server need to know the Surface web identity of each other. Your backup 'server' could be something as simple as a Raspberry Pi running on your Home Network, it doesn't need to be directly accessible from the Surface web at all.

However, push backups have one clear advantage over Pull backups - timing. With a push backup, a backup will never be pushed to the backup server until it's complete. Without careful design, this may not be true for Pull backups - if your backup takes longer to run than expected, the pull may result in only part of the backup being pulled off-server.

You need to either design a mechanism to prevent this (such as a simple lock file that the client can check for) or ensure that the scheduled run times are staggered sufficiently. Whatever the mechanism, be sure that it works, otherwise you may find that the first time you know you've been capturing useless backups is when you need them.

Encrypting your Backups :

Whatever solution you opt to use, one constant exists - backups should be heavily encrypted as soon as they've been created. A keypair should be generated on another system, and only the public key should be available on the server hosting your Hidden Service. The private key should be stored somewhere very secure. Should you ever need to put the private key onto the server (for example to recover a backup) you should generate a new keypair and cease use of the old pair immediately after.

The type of encryption you use will generally depend on personal preference, but if using a pre-rolled backup script, be sure to carefully examine how it implements encryption.

For example, the 's3cmd' script can be used to push files to Amazon S3, and includes the ability to PGP encrypt files prior to uploading. When configuring s3cmd, the user is asked to enter a passphrase, and it's easily assumed that this is being used to protect the private key. In reality, however, the passphrase is used to generate a symmetric key which is then used for every single file you upload. When compared to how PGP behaves when using a keypair, this behavior is undesirable.

You may not be finished :

Although we've examined designing and implementing Tor Hidden Service in quite some depth, some users will likely find that there are still additional considerations that they need to make.

For example, whilst we discussed the risks of traffic leakage, we did very little to avoid it - one solution, assuming you have out-of-band access to the host system, is to add iptables rules to ensure that all TCP and DNS traffic is redirected to the ports operated by the Tor Daemon.

You'd still then need to look at filtering out other protocols (including UDP on all other ports) in case someone discovers a means to have your host system send arbitrary traffic.

Similarly, we haven't discussed the impact of your Guard being compromised, those with serious concerns may need to look at running their own guards to help reduce the effectiveness of common Hidden Service de-anonymization attacks

It's also important to remember that this documentation may not cover threats which have not been discovered yet, security is a continuous exercise.

Measure Twice, Cut Once :

Some of the changes we made in Part One may have seemed redundant - why rebind Nginx to the loopback interface if we're firewalling the port? We're all human and make mistakes, if there's a change that can be made to mitigate a potential future mistake, it's well worth considering.

Protect Your Users :

We live in a fairly unstable world, and you can be reasonably sure that however harmless your hidden service (or Surface web website is) there will be someone who will take issue with it. Taking pro-active measures to keep the identity of your server hidden helps to limit your attack surface to only the elements that you're willing exposing to the public.

The threat will not always be against you directly, but against your users. For example, Christians do not fare well in certain countries, a fact which may be important if you're providing a faith based hidden service. Failing to properly secure your server and protect it's identity could mean that you become the conduit via which aggressors identify your users.

Tor Hidden Services have the potential to allow your userbase a level of privacy that they cannot otherwise obtain on the Surface web, but the anonymous nature of Tor doesn't make you, as the site operator, any less responsible for taking measures to protect the data that your users entrust you with.

METHOD 3 :

This is the easiest way to create a website using tor . May be you will love this method .

Follow the path where you installed the tor browser . In my case i just installed it here -

D:\Tor Folder\Tor Browser\Browser\TorBrowser\Data\Tor 

Edit the file : torrc

Paste :

HiddenServiceDir D:\Tor Folder\Tor Browser\Tor website Name

HiddenServicePort 80 127.0.0.1:80

Save and Restart tor browser .

Now you can see a folder named "Tor website Name" on the directory where you typed .

Also there will be a hostname file which include your tor url . now your computer is your website host .

Now make your computer as a web server with XAMPP . Its not a big deal at all . Simply download xampp from https://www.apachefriends.org and start the server .

For sharing basic contents using tor website , this is the perfect and easiest method .

Thats it .

So , I have explained all 3 methods , how to create a website using tor network .

Now its time to give some security tips :

Beware of big names :

Presume that large companies’ encryption systems and possibly even big name operating systems (proprietary software) have back doors that secret services in their country of origin (at least in the US and the UK) can access.

Always encrypt everything :

Security experts use simple math to make their point: as you raise the cost of decrypting your files (say, for intelligence agencies like the NSA), you automatically increase the degree of effort expended on following you. If you’re not Chelsea Manning, Julian Assange, or Edward Snowden and if you weren’t involved in active surveillance around Trump Tower apartments, They may give up the effort even if your encrypted communications were stored. And should anyone decide to track you despite your efforts, it will be more of a headache if you use strong encryption like AES (Advanced Encryption Standard) and tools like PGP or openVPN, which are the strongest widely available encryption methods (VPN’s are used by the US government itself).

Perform full disk encryption :

This is done just in case someone gets their hands on your computer or phone. Full disk encryption can be done using FileVault, VeraCrypt or BitLocker. Putting a computer to “Sleep” (instead of Shutdown or Hibernate) may allow an attacker to bypass this defense. Here, Mika Lee gives a complete guide for encrypting your laptop.

Avoid chatting with sources on the phone :

All phone companies store data related to the caller and the receiver’s numbers, as well as the location of the devices at the time calls were made.  In the US and several other countries, they’re required by law to disclose information on registered calls in their possession.What can be done? You should use a secure call service, such as the one the Signal app – which was tested repeatedly for security – possesses. Although this may mean that both the source and the editor need to download the app as well, the process takes just a few minutes. Here is a guide on how to use it. Just for the hang of it, check out how many of your non-journalist friends are hanging out there.However you choose to communicate with your source, do not bring your mobile phone to sensitive meetings. Buy a disposable device and find a way to convey its number to the source in advance. The source needs to have a disposable safe device too. Authorities can track your movement through cellular network signals and it’s advised to make it harder on them to locate you retroactively in the exact same cafe where the source was sitting. If you fail to follow this rule, all local authorities will be required to do is ask (politely and legally) for the video filmed by the cafĂ©’s security camera at the time of your meeting.

Choose secure messengers :

your calls (cellular ones and via landlines) can be monitored by law enforcement agencies and each SMS is like a postcard – all text is fully visible to those who may intercept it. Therefore, use Messengers that allow for secure end to end call: signal, which was already mentioned above, and Telegram are considered to be the safest (although Telegram as well as WhatsApp’s web apps were compromised once and then fixed). According to some experts, you can  also consider using SMSSecure, Threema and even Whatsapp.The Signal Protocol has been actually implemented into WhatsApp, Facebook Messenger, and Google Allo, making conversations using them encrypted. However, unlike Signal and WhatsApp, Google Allo and Facebook Messenger do not encrypt by default, nor notify users that conversations are unencrypted – but offer end-to-end encryption in an optional mode. You should also keep in mind that Facebook messenger and WhatsApp are both owned by Facebook.Adium and Pidgin are the most popular Mac and Windows instant messaging clients that support the OTR (Off the Record) encryption protocol and Tor – the web’s best encrypted browser, which we will get to in detail later (See how to enable Tor in Adium here and in Pidgin here). Naturally, you could also use the Tor Messenger itself, which is probably the safest of them all.Two final notes on texting: A cyber security expert I’ve discussed this with, says you should also have a working hypothesis that text is encrypted but the fact that these specific two individuals are talking, at this present time, might not go unnoticed.The second note is you should also remember to delete the messages in your phone (although this may not be enough to withstand a forensic check), just in case your device falls in the wrong hands, to avoid exposing them.

Do not use organizational chats :

Slack, Campfire, Skype and Google Hangouts should not be used for private conversations. They are easy to break in, and are exposed to disclosure requests for courts use, to resolve legal issues at the workplace. Therefore, it’s best to avoid them, not only when it comes to conversations with sources, but also conversations between colleagues, editors, etc., when you need to pass information received from your source, whose identity must be kept under cover. Many popular VoIP services like Jitsi have built-in chat features, and several of them are designed to offer most of Skype’s features, which make them a great replacement.

In extreme cases, consider using a Blackphone :

This phone, which strives to provide perfect protection for web surfing, calls, text messages and emails, is probably the best substitute for a regular phone if you are about to topple your government or getting ready to publish secret military files. An anti-bullet vest may also come in handy. Alternatively, try to do without a cell phone, Or opt for a cellular phone RFID signal-blocking bag. There’s always an option that even the Blackphone can be tracked using its IMEI (the mobile phone’s ID).

Avoid these mistakes :

Don’t access any site that requires a login but does not use encryption, especially if the user account on that site contains any personally identifiable information. An encrypted site will use “https:\\” at the beginning of the URL. Most browsers today will display a small padlock icon to the left of the address bar when the site is secure. There may also be a blue or green URL bar button in the Tor Browser.

Don’t log into Google, YouTube, Gmail, Hotmail, Yahoo! or any other secure site that has your personal information while using an anonymizer. All of those sites maintain logs of IP addresses that their users log in from. While this can’t be used to find you, it can be used after you’ve been found to further damage your, and everyone else’s, anonymity. The providers of all of these types of services keep their own logs relating to any user’s access. No matter what anonymous tool is used, after the user has been caught, these logs demonstrate what anonymous tool they used, how that tool works on both ends, as they will invariably be in possession of the user’s computer. Also, those sites use auto-refresh to repopulate your browser with new content. Unfortunately, this also sends your information back to the webhost with every refresh, adding to the information kept in the logs.

Stay away from forums, blogs and microblogs that you normally visit as yourself when online. Don’t even quote any of them. Even creating an anonymous user account at those places can end up working against you. It’s far safer to just stay away from them until you are finished with your anonymous internet session.

Turn off or shut down any applications or programs that automatically sync with a server, or configure them to send all of their traffic through your anonymizer of choice. Things like email clients, Facebook, Twitter, instant messenger programs, streaming media, etc. Anything that cannot be configured to communicate anonymously should not be running while you are trying to be unrecognized. Ideally, the best option is to use a liveOS like Tails or any of the live linux distributions that can be kept on a CD, DVD or even a thumb drive. When a computer is booted into one of these operating systems, especially one that is designed for anonymity, like Tails.

Develop a checklist of anonymous practices before you do anything online. Only you know what sorts of things you do online and it should stay that way. A checklist will help ensure that you don’t get careless.

If you must download something while using an anonymizer, don’t open it while your computer is still connected to the internet. Many innocuous seeming documents can contain links or even live streams of data that can and will give away your IP address when they connect to their remote data source. This is especially true of files ending in .doc and .pdf. Instead, either disconnect from the internet completely or open them in a virtual machine that does not have a network connection.

Do not torrent over Tor or any anonymous access tool that is not specifically designed to be used for torrenting. This is one of the most often ignored pieces of advice. All of the standard torrent clients use the IP address of the host computer to receive the torrent streams from other clients, or seeders, and to source streams to others that are downloading that data, known as leeches. These programs embed the client computer’s actual IP address into the header of each packet of data transmitted. That way both the computer requesting the data and the computer sourcing the data can send and receive data without having to rely on any servers or “middle men.” This is how the vast majority of torrent clients work. Using a standard torrent client is in no way anonymous. However, there are torrent clients that are designed to be anonymous. Look into GNUnet and Aqua for sharing large files anonymously over an anonymous file sharing network.

Do not modify the security settings or install any plugins in your browser or the browser provided as the anonymizer, unless specifically told to do so by the anonymous service provider of your choice. If you are not using the Tor Browser specifically, make sure you do not install any plugins in your web browser. This includes things like Adobe Flash Player, Apple QuickTime, Java and others. Preferably, you will be using the Tor Browser, possibly even the hardened version, or one of its alternatives. That way, you will get the latest updates as soon as they are released.

If you don’t want your ISP to know that you are connecting to an anonymous network, like Tor, use a bridge instead of a regular entry node.

If you are engaged in any activity that is illegal in your home country, know that you will be actively hunted by your local law enforcement at the very least. In the United States, illegal activity is investigated by the FBI for any crimes that cross state lines, the DEA for any crimes involving narcotics, Homeland Security for anything they feel like investigating, the ATF when firearms are involved and the IRS when significant amounts of money is changing hands, regardless of what currency is used. These entities will all work together using a lot of different tools to find you. Any mistakes, no matter how small, will lead them right to you.

Ultimately, you will want to become familiar with and use several different anonymity tools. If you use a VPN, change servers often. Also, never use your anonymous access program without using a VPN, even if the VPN server you are connecting to is in your home city. You already should know that any logs kept by the VPN provider can point right to you, so make sure you choose a provider that does not keep any logs relating to you and your connection.

On the subject of VPNs specifically, not all are created equal. When shopping for one, you want to look for a provider that has, and keeps to, a strict “no logs” policy. You also want to make sure they use shared IP addresses. Just like with some websites, several VPN servers can exist on the same physical server as virtual machines. The physical server has only one IP address, so all of the virtual servers that it hosts all have to share that address. There can also be other servers being hosted like websites, email servers, databases and file sharers. The main benefit is that your VPN server can show up in the destination server logs as any of these, not necessarily a VPN.


Thanks & Regards .