I should point out that I am not a good person to threaten. The idea of a threat is to subdue or otherwise intimidate another to your will. As somebody acting on their own identity and with the capability to de-anonymise a lot of the sites out there, I am a pretty poor target for such threats.

So here we go. The Russian market/classified area onion address is:
http://map2rampqm6qxbvz.onion/

I feel obliged to point out I have no idea if this was the market making the threat, nor do I care. I hope this serves as a gentle reminder that as somebody doing research and trying to remind people about vulnerabilities in their sites, I am not against the “dark net” sites. I can’t use magic and thus if you have no vulnerabilities, you are safe from me. If I can find your server, so can a capable state agency, and who would you prefer sent you this reminder?

So, here is some of the information on the site:

IP: 188.32.214.154
Document root: /home/map2ramp/www/
Server admin: root@work.local3
Internal IP: 10.0.0.13
OS: Gentoo

Unmasking this server was rather straightforward and again is down to a misconfiguration on their behalf. This time, however, it was a poorly configured PHP module with the web server. Another reason not to use PHP.

[This is the first entry in many to come as I roll up my sleeves and drag up some dirt and gold on the world of hidden services.]

Following Joseph’s article, whom I have talked to on some occasions in recent weeks, I decided to look further into the sites that often meet people entering the “dark web”. There is an impression that the “dark web” is full of a few things; child porn, drug sites, hacking groups, weapon traffickers and more. So I’m going to give some of these sites a quick digging and see what comes up.

Legal Disclosure: On the advice of my solicitor, even for the purposes of this publication, it could be considered a crime in my country to knowingly visit or attempt to visit sites that may contain indecent images of children. Even if my intent is to bring them down or report them. Thus, I shall be excluding child porn sites from those I investigate. Furthermore, I am legally advised to say I do not encourage using these sites and links are included only so that you may do your own further research.

The first stop is the “Hidden Wiki”. There are many clones out there, so I picked a few at random and started on my list. One site that stood out to me, in particular, was amazingitriw6yro.onion, which allegedly belongs to Shiny-Flakes. SF was a dark net market vendor who was busted this year in one of the largest drug seizures in Germany. I have made no attempt to verify if this is a scam site or was genuinely some kind of bazaar. Anyway, it is the technical information that grabbed my interest.

Interestingly (and by that, I mean moronically), the Apache server that operates the site has all the default modules loaded in. This provides the first point of entry into exploring a wider ecosystem of sites. By passing the URI of server-status, Apache serves up a list of statistics and other vhosts on the webserver, which is usually used for the system administrator to monitor the server.

From this – there are 3 obvious possibilities from this. The first is that this “Shiny Flakes” person operates a lot of hidden services – possible if he wasn’t behind bars right now. Since he is and we can see the last server restart was this week, I feel it safe to exclude this possibility. The second possible explanation is that it is a scam site, but having a brief glance over I have no idea.

The third possibility is that there is a shared web hosting service behind the site. This seems plausible as independent sites or operations are likely to be willing to share servers. So from the other vhosts available on the apache server status page, I pulled three other URLs from a list of many:

hacktorbnrmel7rj.onion
A supposed professional hacker group, offering everything from doxxing, to DDOS, to tracking partners and of course fraud of various kinds. In fact, they offer pretty much everything under the sun with huge promises.

killer6qdkbbh66d.onion
The front page prompts me to log in to an “Assassins Community”. Didn’t bother going further in on this one.

armorykr2fqsulxk.onion
Presents itself as the “Deepweb Gun Store”. Again, a login page which I did not proceed any further with at this point.

Without needing to investigate this further, I feel I can draw a few probable truths of what are behind this (admittedly, small) sample of sites.

1. If the sites above are legitimate, they are on a shared hosting service of some description. This means that whoever controls the server will also have full access to the data of the site, and so should one site be compromised – so shall they all.

2. If the sites are scams – which I rank as a reasonable belief, then it certainly shows that most other listings probably are too. They are in constant competition to push themselves to the top of the various wikis, with no clear leader based on reputation or peer review like the dark net markets.

3. The people behind these sites are no techies. They use an Apache web server with the server-status module loaded in, suggesting no thought has been given to the operational security of the web server. This is more common with scam sites since they have lower expenditure to rent a cheap server, with no other expenses that real traders would have in whatever wares they were advertising.

Take note, none of the above outcomes is what are advertised or touted by the mass media about the “dark web”. There are lots of listings for all sorts of services, but many of them are scams. Just as we don’t believe the guy on eBay selling a nuke, we should also take many of these offerings with a pinch of salt. Above all is the integrity of how journalists report these things in perspective with a healthy dose of skepticism.

As a quick overview of them all, I wanted to update those who follow my projects on some of them.

First is the shared hosting project. Most of us remember Freedom Hosting and the stir that caused over a year ago. It was one of the few places in the hidden service ecosystem that people with very little to no technical ability could maintain their site without having any knowledge of command lines, web servers and hardening. With that now gone, it puts the entry barrier to hidden services ever higher. Despite my previous post designed to make is quite painless, the fact of the matter is that using a command line is still intimidating to many people who have never even ventured away from Windows.

Making a shared host is a much harder job than one would imagine, particularly with the prevalence of them on the “clearnet”. Most shared hosts on the DNS system rely on a small set of tools to achieve this, usually cPanel WHM, Plesk and WHMCS. While there is nothing particularly wrong with these tools, they are simply not designed for hidden services and licensing issues could pose a real problem to widespread deployment. This is what made me decide that I need to create a custom solution from scratch.

Scaling on the hidden service is also a very difficult problem, especially with high traffic. In addition, I don’t want to be redesigning this system every few months as it drastically increases workload over time, and so getting this right the first time will make things way easier for me. Here are some of the problems I am thinking about when building this system:

1. Tor can only use one core of a CPU to process traffic and perform crypto operations. That means I must load balance between several tor processes. What are the best means by which to monitor this and automate the process of load balancing hidden service keys across the processes – in particular if the virtual machine isolation is used between them.
Solution: Using a single core virtual machine on another server, and then pointing the HS at another dedicated server means the CPU is dedicated to that process for maximum throughput. Then, using a machine on the control server, it can use SSH keys to distribute the private keys and hostnames based on their load readings and shuffled as required.

 2. If a DDOS is performed, it will likely max out the CPU core before saturating the traffic or guard. How can I mitigate this?
Solution: Creating a separate virtual machine from the rest that has more stringent resources allocated to it. This means the DDOS will only exhaust a small pool of resources and leave the others to perform normally, serving the existing hidden services. This does not prevent or stop a DDOS, but it does limit the damage that is caused by a single client being the target of an attack.

3. How can I prevent the system being overloaded by the tor process, the web server, the database and the file storage all on a single server?
Solution: Split them. One server shall handle the tor processes, split into smaller virtual machines for isolation and pseudo load-balancing. The Tor server will also have an Nginx reverse proxy installed on it locally with a large SSD cache, perhaps 240Gb that will store frequently accessed disk material. This reduces the intra-server network load and reduces requests and connections between the frontend and the web server. Plus using an SSD over a hard drive reduces the latency between the request being made and replied to, so larger files like images or constantly accessed text files are read at lightning speed. Using hardware to their specific tasks is also useful; so for the Tor process machine a high CPU clock rate and small SSD storage is best. For the webserver, multiple cores are better with large storage pools in a RAID array for redundancy. The database server must have a good CPU, but large amounts of RAM and a SSD storage pool, that performs better under a large amount of small read/write requests than disk-based drives, will make increase performance substantially.

4. How can I scale the storage pools? Ideally I would like to point the webserver to a single backend storage mechanism so it can grow seamlessly, but I cannot use a cloud solution due to the inherent privacy risks.
Problem: I haven’t fully thought this part through yet, but redundancy and the ability to scale it to many TB’s is very important. Please feel free to write in if you have any suggestions!

My aim in this project is to bring hidden services to the masses. This is critical to me as with every new revelation from the Snowden leaks; I am losing faith constantly in traditional security models. Tor hidden services provide end to end encryption by default and offer privacy for both the user and host. But to make a technology come to a larger audience, we have to lower the barrier to entry so that anybody can easily throw up their own blog. We can work together to break the dogma that privacy is only for “bad” people.

Another, probably more controversial project, is a file/image hosting service.  Now there is the stereotype that all image hosts are simply for the purpose of child porn on the “dark net”, but I differ. The only reasons tor hidden services have a reputation for child porn is because nobody bothers to challenge the stereotype. We need more challengers, who want to shift the landscape. We can’t wipe out child porn, but what we can do is bring the layman to hidden services and spring up legitimate services to drown out the notion that such technology is only for criminals. We can only change the world when enough good people stand up and challenge whatever negativities or reserves people may have.

An image/file host has many of the same challenges, minus the databases, so that project is somewhat straightforward and shall be a great primer to optimising the full web hosting service.

If you have any thoughts on what sort of hidden services you’d like me to launch, please do let me know! My 2015 goal is getting hidden services to the masses and so I’d always love to hear your suggestions, or perhaps feedback on my plans above.

This guide is in no way meant to be exhaustive here. This is not a hardening guide. This is here to get you started with your first hidden service. You can rent a VPS to do this, or you can even host it on a virtual machine on your computer (it makes no difference – really).

Now I intend for this to be as accessible as possible but there is a very small set of requirements. I don’t believe this will rule out anyone who is intending on setting up a basic hidden service.

Requirements:
– Know how to SSH into a VPS/server
– Running Debian 7 (Wheezy) 64 bit

What I would recommend for your Debian installation is at least 256 MB RAM, 1 core or more and 8Gb or more hard drive space. If you are installing Debian on your local machine, you do not need to install anything but the very base files. Everything you  need in this guide will be installed as we go along. However for the purpose of this guide, I will act like you are using a basic VPS. Commands will be highlighted in purple & configuration entries in blue.

Contents at a glance:

1. Connect to the server
2. Retrieve some packages
3. Setup user
4. Add user to sudoers & basic SSH configuration
5. Download & install Tor
6. torrc file configuration & hidden service key generation
7. Nginx installation & configuration

1. Connect to the server

To SSH into your VPS, it is very simple. If you have a Linux computer, go to the command line and type:

ssh root@<ip-address-here>

This will prompt you to enter the root password and once you have entered it, you should be logged in as root!

2. Retrieve some packages

As root, type the following command:
apt-get update && apt-get upgrade && apt-get install sudo nano
You will then be told how much additional space is required to install the above packages after the package list has been updated, and the updates downloaded. Type “Y” and hit enter to accept and install them.

3. Setup user

It is recommended you never run any software as root when you can avoid it. So as root type:

adduser user

This will add a new user called “user” (feel free to replace this with whatever you want). You may be asked for various other bits of information like full name, office number etc, you can just hit enter to skip them. At the end you will be asked “Is the information correct?”, again type Y and hit enter to confirm.

4. Add user to sudoers & basic SSH configuration

For those not familiar with Linux systems, sudo is the package which enables users to obtain superuser capabilities just like root for certain tasks. This allows a user to login to the system and manage it without needing to switch to root. To add your new user to the sudo list, type the following as root:
sudo adduser user sudo

Now “user” has been added to the sudoers list. Now we should make some very quick and basic changes to your sshd process to block off anyone trying to SSH into your VPS as root and a simple technique to stop brute force SSH attempts.

To open up your sshd configuration, type:
nano /etc/ssh/sshd_config

The first option to find is “Port 22” which should be near the top of the file. Change the port “22” to something non-standard, for example 22555, so the new entry should look like this:
Port 22555

Now you need to disable root SSH login attempts. Find the option “PermitRootLogin yes” and change it to “no” so the new entry is as follows:
PermitRootLogin no

Now as root, reload the SSH service using:
service ssh reload

This reloads sshd, and your changes should now take effect. Note that in future when you SSH into your server, you must remember the new port and login as a user. So for example, if your new user is called “user” and the port you changed the above setting to is 22555, your new ssh command is:

ssh -p 22555 user@<ip-address-here>

5. Download & install Tor

The first and most important thing that must be done is to update the sources list to the official Tor Project repository. To make this easy for you, I have reduced this to a single command:

echo ‘deb http://deb.torproject.org/torproject.org wheezy main’ >> /etc/apt/sources.list && echo ‘deb-src http://deb.torproject.org/torproject.org wheezy main’ >> /etc/apt/sources.list && gpg –keyserver keys.gnupg.net –recv 886DDD89 && gpg –export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add – && apt-get

This means the official Tor repository is now added to your sources list, and you have downloaded the official Tor Project keys to your server to cryptographically ensure the binaries you receive are genuine. Now to install Tor itself, we want to switch to our newly created user which in this instance I have called “user”. This can be done by running the command:

su user

Now to install the Tor binary and the Tor Project keyring, run:

sudo apt-get update && sudo apt-get install tor deb.torproject.org-keyring

Tor is now installed and automatically starts!

6.  torrc file configuration & hidden service key generation

The torrc file is the configuration file Tor reads your options from. The file is full of information that we don’t currently need, and so I recommend deleting the existing torrc file and creating a new one. This can be done using a single quick command:

sudo rm /etc/tor/torrc && sudo nano /etc/tor/torrc

This should now remove the existing torrc and open a new one up in the nano file editor. The minimum you will require for running a hidden service is the following configuration, which can be pasted and saved in the new file:

DataDirectory /var/lib/tor
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

Pressing Ctrl + X will save the file. Now to generate the hidden service key and make the Tor process take note of our changes, we should reload the process:

sudo service tor reload

To find out what your hidden service key is (also known as the hostname), use the cat command. Write this hostname down somewhere or copy it to your clipboard – you will need it in a moment:

sudo cat /var/lib/tor/hidden_service/hostname

The private key can be found at (you don’t need to view this right now, this is for your information only):
/var/lib/tor/hidden_service/private_key

You can share the hostname key with anyone you want to visit your site. It should look something like qhzwfy24i22jchdw.onion (this is the one I generated when testing this tutorial).

7. Nginx installation & configuration

As user, type the following command to install Nginx:

sudo apt-get install nginx

Now we need to make a new directory in /var/www/ for our hidden service site. Use the mkdir command to do this:

sudo mkdir -p /var/www/hidden_service/

Finally, we need to set the permissions for the new folders:

sudo chown -R www-data:www-data /var/www/hidden_service/ && sudo chmod 755 /var/www

So we can test the setup in a moment, let us generate a quick test index page, very similar to how we made the new torrc file earlier:

sudo nano /var/www/hidden_service/index.html

In this file, paste the following snippet of HTML code and save the file:

<html> <head> <title>Hidden Service Success</title> </head> <body> <h1>Success: You Have Set Up Your Hidden Service With NGINX</h1> </body> </html>

Now comes the part where we need to configure Nginx to listen in the correct place. In Apache, this would be called a Virtual Host but on Nginx they are known as Server Blocks. To make the new Server Block, we are going to to use the nano command again:

sudo nano /etc/nginx/sites-available/hidden_service

In this newly created file, paste the following snippet of information. Using the hostname you copied earlier to replace qhzwfy24i22jchdw.onion with your own address:

server {
listen   127.0.0.1:80;

root /var/www/hidden_service/;
index index.html index.htm;
server_name qhzwfy24i22jchdw.onion;
}

Save and exit this new file. The last step now is to create a symbolic link between the sites-available directory and sites-enabled directory. In Apache, we use a2ensite but Nginx does not have such a function, but instead we can use the following command to form one:

sudo ln -s /etc/nginx/sites-available/hidden_service /etc/nginx/sites-enabled/hidden_service

Finally, restart Nginx for all the new configuration options to take effect:

sudo service nginx restart

That’s it! You now have your own hidden service online! Using the Tor Browser, if you visit your hostname (the 16 characters followed by the .onion) you should now see a page reading “Success: You Have Set Up Your Hidden Service With NGINX”. You can now upload your files in the /var/www/hidden_service/ directory or follow other setup guides on the net to install other applications!

I hope this guide has been of some use to you, particularly if you are new to hidden services. For the non-techies out there, it is a considerable stepping stone to understanding how the web works once you have gone through the steps of setting up your own, particularly using a hidden service! If you have any further questions on this, have errors or want me to write further guides on installing specific applications, please do let me know by getting in touch via the Contact page or catch me on Twitter @CthulhuSec!

However, I would first like to draw the attention of everybody to a specific phrase he used when asked to clarify what the legislation would possibly entail. In reply, he expressed the need for “more modern forms of communication” to be allowed in the UK and to be covered by such legislation. This term, I would assume, is concerning smartphone apps (a commonly cited example would be WhatsApp and iMessage) as opposed to traditional messages in SMS form and plain text emails. Speaking as somebody who has been under surveillance (and still is), I know the concern over such “encrypted communications” is certainly not a problem to handle under existing legislation. In successive raids, I have had phones searched, “data storage mediums” seized and been subject to questioning over my activities. The one common factor, they never seem to have a problem with, is searching my phone. As an iPhone user, I expect no privacy on the device and to me it is much more for checking my Twitter account on the move, taking photos, reading the news and so forth. I have no email accounts tied to it and I certainly would never enter any private information into a device I know can be easily compromised either locally or remotely. Therefore, I can only deduce if the Prime Minister was concerned about terrorists using WhatsApp or iMessage, existing legislation (requiring a court signed warrant) would cover the scenario. Resorting to compromising the privacy of everyone using such networks in the name of “security” has nothing to do with combatting terrorism, but enabling mass surveillance.

Then we come to how “banning encryption” would be practical. I run a series of Tor exit relays, for example, but they are based in the Netherlands and Sweden. If I am under any obligation to provide information, that will mean logging the data passing through my exits to the servers/websites being visited. Yet this information alone is not very useful since the majority of traffic will be encrypted using TLS and what plaintext information is recorded, will be that of primarily foreign citizens to the UK. This information would not even be traceable back to the original owner in any case. The design of the Tor network prevents any one group [or individual] being able to correlate the users of the network to a particular packet of traffic leaving the exits. Furthermore, as all of the maintainers of Tor are based outside the UK, UK law would not apply to them or the product, meaning the software could not be forcibly backdoored anyhow.

This leaves the government with a few options; to disregard the legislation and the idea of banning encryption, or to set up the Great Firewall of Airstrip One [2]. Considering the successive assaults on access to the open internet by the UK government, if such power is granted to the security services and police force, I fear for my country. I fear we will raise the next generation with no expectation of privacy and grow up in the knowledge everything done is recorded, reviewed and held on their permanent records. In that knowledge, what are we to teach about risk and exploratory behaviour? Risk is inherent in everything great and when fear holds back those who we shall inherit our world, can we expect them to build upon what we have built?