Outline for a Simple Darkserver and/or Darknet

by p4nt05

0.1 - Prologue

With state programs monitoring everything we say, employers logging everywhere we go, and governments not trusting anyone, some of us have been forced to take measures to make sure that no one can easily listen in to us, even to our online conversations.

It hasn't been easy, and it has not always been fun (there is nothing quite like getting a trouble call for your home systems while you are at work), but in the end it has been worth it; and I have no intention of stopping.

1.0 - Introduction

The term darknet can mean many things; within the context of this article we discuss it as "A set of softwares and systems that are private but Internet accessible, usually used by a group of friends or associates for privacy."

I happen to participate and host one such darknet for myself and a handful of friends.

Ironically, the reason we started our darknet in the first place had nothing to do with privacy concerns as much as ease of use; the side effect became our own little darknet.  Note that it does have one weakness; I use dyndns for the domain name.  I should probably take another reader's suggestion and host my own Dynamic DNS by sending the IP address to participants via some secure method (like a htpasswd SSL page).

Also note that this article covers just a few methods for setting up a darknet; there are many more out there, including full-blown hidden file sharing networks.

Last but not least, this article does not cover the technical details of the steps involved, but outlines them; there are far too many details to document in one article.  Perhaps someday I will outline how to do this in a "how to" online somewhere.

1.1 - Requirements

One can create a darknet on almost any platform, although using a UNIX-like platform is probably easiest.

In my case, the central node is a FreeBSD server; client systems are usually a Linux kernel based system, NetBSD or FreeBSD, or some other UNIX variant (such as Mac OS X).  Windows can be used, but requires tools and utilities such as the former Cygnus suite.¹

1.2 - Recommendations

One recommendation I make is to use a virtual guest on a computer for your central node, if possible.

Any method is acceptable, such as the free VMware Server², FreeBSD jails³, or the Bochs emulator⁴.

The reason for this is two-fold:

1. You can move the Virtual Machine (VM) system.
2. It hides the hardware.

Even doing a 1:1 (one guest on one host) is a good idea as it abstracts the system from the hardware.

If possible, try setting up the host on an internal network that is not accessible by the other nodes on your internal network.  This is not always practical (it isn't for me), but it's definitely a good idea if you can pull it off.

1.2 - Prerequisite: Quiet Router

The router on a node needs to be quiet, meaning the only thing the router does is allow the inbound connection to the particular node that you want; no other services such as remote administration, ICMP, etc. should be allowed on the external (that is the side connected to the Internet) interface.

Eventually, we will want to enable some ports but we don't know exactly which ones yet.

2.0 - Easy Steps: SSH, SCP, Local Services and Distributed

Setting up a central system to run local services is a very cheap and easy method to allow friends to congregate without being watched by the wired world at large.

The catch to setting up a central location is, of course, to make sure all inbound connections are secure.

2.1 - Using SSH and SCP

Setting up a secure shell server and creating local accounts for friends is a very fast and simple way to immediately create a darknet.

The great thing is that, once SSH is running, you can also share files using secure copy.

Granted, secure copy is slower than most file sharing programs, but since the traffic should be relatively light (since it is just your friends), it is probably tolerable.

Also note that the rsync utility supports client-side throttling so as to mitigate possible side effects to the server.⁵

Two other steps are necessary for the SSH server:

1. Use a privileged port (less than 1024), but do not use the default; this may deter some attackers.
2. Enable inbound access through your router to the host.

2.2 - Local Services

Now that connectivity has been established, the door is open to do all sorts of cool stuff.

Here is a quick list of suggestions, some of which I do and others I don't... yet:

• A local IRC server.  Let it run on the default port or lock it down to only run on the localhost internally.  There are alternatives, of course, like ICB.
• Use a local mailer, as will be discussed a little later.  You might want to think about a more advanced remote setup, but a very cheap, fast mail service would be for you and your cohorts to use local mail.
• A group accessible file area is a great one.  Put all of the users in the same group, then set up an area on disk that the group can access to share files.
• Version systems are great, regardless of the type you like; set up a local repo for you and your friends to keep your hacking source code in.

Remember that since all of the connections are using secure shell over some random port, they are encrypted.

2.3 - Distributed Servers

One weakness of the model so far is that we are talking about a single system; this of course presents a weakness.  If that system were to go offline, then the entire darknet (which in our current scenario should probably be called a darkserver) is offline.

There is, however, a cure.

One or more of the other participants, if they have a similar OS, can simply set up a mirror by rsync'ing the needed files and data over to their system.

Using Dynamic DNS, or your own method, you can also keep a list of live addresses online somewhere for all your participants.

This isn't as hard as one might think.  There are some tricks you can use, such as keeping everything under one location on the disk like /usr/local/darknet.

Most systems offer the capability to change the base install location (such as relocatable RPMs or simply using configure scripts to change the default), and user data can reside "wherever."  With one united tree, redundancy can quickly be built into your darknet services.

2.4 - Using IPv6

Many routers these days come IPv6 capable.

It is well worth your while to try to get secure shell up and running using IPv6, if your provider supports it.  Alternatively, you can set up an IPv4 SSH "hop host" where your users then jump to another host running IPv6 (which is sure to confound even the best).

3.0 - Advanced Darknet Topics

So far we have discussed logging directly into systems using local services, file sharing using secure copy or secure shell enabled rsync, and creating redundancy by simply making the same or similar services available on other hosts and sharing the data between them.

Now it is time to look at some advanced topics, such as truly distributed systems that use some form of encrypted communication.

3.1 - GPG Keys

The most obvious method of encrypting emails is using a privacy program like GNU Privacy Guard.

However, while it is not hard to use, it can be hard to convince participants to use it.

Also, is it really worth it?

For trivial emails that do not need to be secured, such as, "Dude check out this Pink Floyd video on YouTube," you probably don't need GPG.  Something like, "Guess what, you have an error in your code" would likely be a great candidate for GPG.

Note that using the local mailer might be easier for your situation.

3.2 - X11 Over SSH

One thing you might want to do is enable your brothers in arms to access X11-enabled graphical stuff.

You can ride this right over SSH and "blow back" the interface right to someone's desktop.  Alternatively, you can go the whole hog and use tools like Xvnc over SSL to enable entire desktops remotely.

Beware: bandwidth can quickly evaporate when doing things like this and it exposes one to the possible insecurities of the graphic tools themselves.

Of course, if you just want to see it, enable X11 forwarding in SSH and pop open an Xterm remotely.

3.3 - Distributed Services

Many services that do not require file synchronization, such as chat and some file sharing, can ride over the top of a Secure Sockets Layer (SSL).

Not unlike GPG, this requires a lot of agreement and some way to keep the IP addresses up to date as close to real time as possible.

For most services, the fail-over method is easiest.  In one neat, distributed service, you can set up the distributed compiler to work over SSH; yes, you can build large programs leveraging an entire network of computers.

3.4 - Distributing Services and Swap Spit Rsyncs

One way of distributing the load can be to designate certain servers in the darknet for certain jobs and setting up backup systems per function instead of all services from a central server; this is essentially spreading out the service load.

3.5 - Mixing it Up with Virtual Private Networks

I saved the most radical method for last, because there is a lot of cool stuff that can be done by creating a Virtual Private Network (VPN) between nodes.

Essentially, the darknet users can log in and have access to all resources immediately, as you have a VPN with its own internal names.

Using a VPN is also great since it is well supported by IPv6, and using IPv6 is yet another way to hide traffic (since most watch programs key on IPv4 only, as mentioned earlier).

4.0 - Summary

Creating a single, simple darkserver is easy enough.

Moving onto an entire darknet or distributed darknet takes a lot of work.

In the end, though, all of these measures mean one simple thing: no one will know.

Footnotes

1. Cygwin can be found at: www.cygwin.com
2. The free VMware Server can be found at: vmware.com/products/server
3. More information about FreeBSD jails: en.wikipedia.org/wiki/FreeBSD_jail
4. Bochs emulator project: bochs.sourceforge.net
5. This can be achieved using the --bwlimit parameter.