Chapter 1
Invisibility Cloak

Imagine that you could hide a server from the Internet but still have access to your ISP's superior bandwidth. Without making any changes, you would be able to securely use it as a file repository, among many other things.

You'd also have full access to the command line so that you could start and stop or even install any services that you wanted to use. The choice would be yours, whether you ran those services briefly and then closed them down, or left them running and visible to the outside world for a period of time.

This is possible to achieve using a technique called port knocking. You can disguise your server by closing all network ports to the outside world, genuinely making it invisible. The single port that you might choose to open up at will, by using a prearranged "door-knock," could be for your SSH server or for some other service. In this chapter, you'll see how you can create an invisible server along with some options that you might want to consider.

Background

By disguising the very existence of a server on the Internet, at best you can run a machine in private, and at worst, even if its existence is known, you will reduce the attack surface that an attacker can target by limiting the time ports are open and even partially visible.

Probing Ports

Before beginning, let's take a closer look at network ports on a server, so you'll have a frame of reference. If you've ever used security tools such as Nmap, then you may be familiar with the initially confusing premise that some ports appear to be closed when in fact they are not. Nmap makes the distinction between whether a nonopen port has a service (a daemon) listening behind it or not.

Nmap refers to closed ports as those that don't have a daemon listening behind them but do appear to be open or at least potentially available. If Nmap refers to filtered ports, it means that a firewall of some kind is preventing access to the IP address that is scanning the system in question. This is partly to do with TCP RST packets, and there are also three other states that Nmap reports back on: unfiltered, open|filtered, and closed|filtered. If you want more information on how these states are different, go to https://nmap.org/book/man-port-scanning-basics.html.

Confusing a Port Scanner

Now that you know how ports may present themselves to port scanners, let's look at how to obfuscate the response you give back in order to confuse sophisticated port scanning techniques. The most obvious tool of choice, thanks to its powerful feature set, would be the kernel-based firewall Netfilter, more commonly known as iptables.

Here's how it works. For TCP packets, you want to manipulate how you respond to port probes by using iptables to generate a REJECT request. For other protocols you want to simply DROP the packets. This way, you get closed, not filtered, responses from Nmap. Based on what I've gathered from most online opinions (and it seems that this argument is both contentious and changeable), a closed port is the best response that you can hope for. This is because you're not openly admitting to blocking any ports with a firewall, nor is the port simply open because a daemon is running behind it.

To explain a little further, under normal circumstances, an unreachable port would usually generate an ICMP Port Unreachable response. You don't want these errors to be generated, however, because that would mean a server was listening on that port in the first place and you would give your server's presence away. The tweaked REJECT response that you want to generate instead is applied as follows:-reject-with tcp-reset. This helps you to respond as if the port were unused and closed, and also not filtered.

You simply append this snippet to the end of each of your iptables rules:

By using this technique, you're simply making sure you're not giving away unnecessary information about your system.

Note that in the port knocking example that you're about to look at, you won't be using that iptables option. This is because you won't be running additional services to your SSH server. However, this background information will help you understand how an attacker might approach a machine's ports and how you can apply a-reject-with tcp-reset option to other services.

There is some debate about using iptables DROP versus REJECT responses in your rules. If you're interested, you'll find some insightful information on the subject at

www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject.

Installing knockd

Now that you are armed with some useful background information, I'll walk you through how to install a port knocker on your server. As we continue you might consider which services you may wish to run hidden from the Internet at large. There might be an occasion to run a web server or a mail server on an unusual port for a few hours, for example.

Packages

Let's look at installing the package that will give your system port knocking functionality. Called knockd, this package is installed in different ways depending on your system.

On Debian derivatives you install the package as follows:

On Red Hat derivatives you install it as follows:

A main config file controls most of the config required for knockd. On a Debian Jessie server, this file resides at /etc/knockd.conf. Take a look at Listing 1.1, which shows my main config file, to see how knockd works.

Listing 1.1 The main config file. The port sequences and (importantly) -I INPUT have been altered from the defaults

Changing Default Settings

In Listing 1.1, you can see a section for setting up your options at the top. The other two sections are the actions that you want to perform when knockd opens up SSH access or when you shut down your port access. Both sections also include the default port knocking sequence to trigger those actions under the sequence option. After installing knockd, I immediately changed those ports from the defaults to avoid reducing the effectiveness of my server security. The defaults are ports 7000, 8000, and 9000 to open up SSH access and ports 9000, 8000, 7000 to close access. As you can see, I've added more ports to open up the access so someone will be less likely to stumble across their combination with an arbitrary port scan.

After changing any settings, you can simply restart knockd as follows on systemd-based operating systems:

After installing knockd, if you want more background information on the package, then Debian Jessie has a brief README file that you can find at /usr/share/doc/knockd/README.

This helpful README file discusses how knockd works, among other things. It uses a library called libpcap, which is also used by several other packages such as tcpdump, ngrep, and iftop (which capture packets for inspection). Thanks to its clever design, knockd doesn't even need to bind to the ports, which it's covertly listening on, in order to monitor raw traffic.

Altering Filesystem Locations

Events such as connections, disconnections, or errors are logged directly to your system's syslog, and may be written to the /var/log/messages or /var/log/syslog file. If you don't want this information to be buried among other system log activities, or go to the bother of parsing an unwieldy log file, then you can create your own custom log file. I prefer to do this so that debugging is much clearer, and I might use an automated tool or a custom shell script to e-mail logs to myself daily so that I can monitor suspicious events. Because I'm keeping all knockd logs in one place, the information is easier to parse for scripts and other tools.

Changing the logfile's location is a common solution, but you can also alter where the Process ID file is written when the knockd service is launched. You can change the location under the [options] section of the config file, as follows:

Some Config Options

Now that you've got a better understanding of how the main config file is set up, you can examine how to configure it for your needs. Among a number of other tasks, you will consider how the timeouts of certain options play a part in setting up your server.

Starting the Service

Don't be alarmed if you see an error message saying that knockd is disabled. This is a precaution so that until you have finished setting it up, knockd won't introduce unwelcome changes to iptables.

On Debian Jessie the error message asks you to change the following...