Port Knocking

An introduction to how trusted users can manipulate firewall rules to transmit information across closed ports.

Firewall administrators are challenged to
balance flexibility and security when designing a comprehensive
rule set. A firewall should provide protection against malfeasants,
while allowing trusted users to connect. Unfortunately, it is not
always possible to filter out the bad guys, because filtering on
the basis of IP addresses and ports does not distinguish connecting
users. Bad guys can and do come from trusted IP addresses. Open
ports remain a necessary vulnerability: they allow connections to
applications but also may turn into open doors for attack. This
article presents a new security system, termed port
knocking, in which trusted users manipulate firewall
rules by transmitting information across closed ports.

Briefly, users make connection attempts to sequences of
closed ports. The failed connections are logged by the server-side
packet filtering firewall and detected by a dæmon that
monitors the firewall log file. When a properly formatted knock
sequence, playing the role of the secret used in the
authentication, is received, firewall rules are manipulated based
on the information content of the sequence. This user-based
authentication system is both robust, being mediated by the kernel
firewall, and stealthy--it's not possible to detect whether a
networked machine is listening for port knocks. Port knocking does
not require any open ports, and it can be extended to transmit any
type of information encoded in a port sequence.

In commonly deployed firewalls, filtering is done either by
the IP address of the connecting host or by the port to which this
host is connecting. Firewalls examine and interact with packets
before any user authentication takes place; therefore, they do not
discriminate amongst the users making the connection. It is
expected that once the firewall has approved the packet and allowed
it to enter the network, downstream applications will handle user
authentication. Normally, this provides a sufficient balance
between protection and flexibility. Some IP ranges, say
cracker-friendly Internet cafés, may be closed completely to
incoming traffic, while hosts in other IP ranges may be allowed to
connect to ports otherwise unavailable to the general public
(proprietary/sensitive applications). Unfortunately, this type of
IP-based filtering has the potential to lock out trusted users from
your system. Flexibility is limited by the fact that nobody from
the blocked IP ranges can connect, regardless of their trust
statuses. At the same time, protection is undermined by the fact
that anyone from the blocked IP range physically can travel and
connect from an unfiltered host.

In the end, as long as ports remain open, network
applications are susceptible to attack. Using intrusion detection
systems and keeping applications up to date can go a long way
towards providing protection, but they do so against only known,
derivative or anticipated attacks.

To eliminate the risk associated with publically open ports,
port knocking provides an authentication system that works across
closed ports. The use of these ports, however, has to be subverted
because all packets are denied. Fortunately, in most firewalls that
perform even the most rudimentary logging, information already is
flowing across closed ports in the form of entries in a log file
indicating connection attempts.

Consider the following example. A handful of ports (100-109)
are configured to deny all traffic--no ICMP error packets are sent
back to the connecting client--and all attempted connections are
logged. In this example, the firewall IP is IPF and the connecting
client IP is IPC. The appropriate ipchains command to close the
ports and log connections is:

ipchains -A input -p tcp -s 0/0 -d IPF/32 100:109 -j DENY -l

A user attempts to connect from IPC to the following firewall
ports in sequence: 102,100,100,103. From the point of view of the
user, the connections fail silently. On the firewall, though, the
102,100,100,103 number sequence has been recorded.

The knock sequence appears in the firewall log, and the user
has transmitted data across the closed ports.

Any implementation of the port knocking system needs to
provide some basic functionality. First, some way to monitor the
firewall log file needs to be devised. A simple Perl application
that tails the file is presented in Listing 2, discussed more fully
later in the article. Second, a method is required to extract the
sequences of ports from the log file and translate their payload
into usable information. In this step it is important to be able to
(a) detect when a port sequence begins and ends, (b) correctly
detect a port sequence in the presence of spurious connection
attempts that are not part of the sequence and (c) keep track of
multiple port sequences arriving at the same time from different
remote IPs. The encoding used to generate the port sequence can be
designed to minimize the length of the sequence. For example, the
sequence 100,102 could correspond to one or a series of predefined
operations (for example, open port ssh/22 for 15 minutes for a
specific IP and then close the port). Finally, once the information
is derived from the sequence, the implementation must provide some
way to manipulate the firewall rules.

this is something that has been in use and known for quite some time, a simple google search for a program called 'cd00r.c' will reveal a backdoor that was developed years ago that uses a packet sniffer to do this. I have also seen a real implementation of this in a blackhat's backdoor, execpt rather than using something like that, it uses a specific sequence of packet header options and part of an encrypted payload to create a reverse/connect back shell.

as per usual, the whitehats are slow and are stealing the ideas of blackhats everywhere.

Why not use UDP instead of TCP for "Port Knocking"? Using UDP allows you to pass real data without stretching the TCP/IP protocol rules and/or crafting strange IP packets.

To do this, you set up a non-responding UDP listener on one or more UDP ports. If no response is ever given, such ports are indistinguishable from ports filtered by a firewall (e.g. via iptables DROP).

When the UDP listener receives a packet it likes, it instructs the firewall to open up the desired TCP (or UDP) port for the service in question. If you want to be extra fancy, the UDP listener can be a state machine which listens for a sequence of packets on one or more ports, but this may be overkill.

The hidden service can be always "running" -- directly or via xinetd -- listening on the usually filtered port. When the firewall allows traffic on that port, the service can then become active. To be extra safe, a TCP service can immediately instruct the firewall to filter the port it is now using against further SYNs (until another UDP knock).

There are two advantages I see to using UDP. First, the UDP listener can be more easily responsive, since it is a regular network program and doesn't have to dig through firewall log files (which might even be "rotated" during the knock sequence).

Second, the knocks can be much less conspicuous to anyone monitoring traffic. For example, you could use the traditional traceroute ports, or other UDP service ports like DNS or NETBIOS with valid looking requests. If you do this, you might want to use a state machine to require a sequence such as: (1) "Traceroute on port 34567 TTL 3", followed by (2) "DNS lookup of foo.mydomain.com", followed by (3) "NETBIOS something-or-other COLORPRINTER" (my NetBios is sketchy). The point is that these look pretty innocuous to the snooper.

On the other hand, you might want to make things much more straightforward and just have "DNS lookup of pcXYZ.mydomain.com" mean "allow incoming SYNs on port 57XYZ for the next minute" so that you can set up a SSL/SSH/TLS connection to port 57XYZ. Of course, this assumes you aren't running DNS (and hence aren't responding), or you *are* running DNS but have hooked some kind of sniffer on port 53.

Finally, UDP "knock" packets (and even some TCP ones) work just as well with spoofed source addresses. But this should *not* be done without the approval of your network administrator, and is quite inappropriate -- or even illegal -- on the Internet (and may be grounds for your ISP to terminate your account).

There is a simpler way. Make a script on your SSL encrypted server that returns a 404 error unless a correct password is provided in the URL. https://yourserver.com/secretknockscript/SeCrEtPass/
The script then looks up the pass in a config file to know what ports to open and send the command to open that port for 10 seconds.

The request is encrypted so nobody will get your pass by sniffing. It would be in the web server log so perhaps make a local form that POSTs.

I think you mean, port 443 (unless otherwise configured). Also, it is quite often that the machine that you are trying to gain access to is indeed providing some services to the Internet, so the point is a valid one, whether it be an SSL-protected http request or pop3s request or whatever.

Ok, here are some ideas I thought up after reading this initially great idea:

1. Improve it to make the port number sequence tied into something like cryptographic key services like SecurID. This prevents later abuse of the port by anyone who would be sniffing.

2. iptables doesn't need to allow all new connections for the ip after it is first established, since it is statefull, so the first connection attempt could succeed wheras any subsequent attempts would fail before another knock is given.

3. Using other garbage data inside a TCP connection attempt, like TOS, or some such garbage, even varying the TTL of each packet could be used to convey some simple type of number combination.

Internet Cafes, libraries, business partners will all present the potential to not allow outbound traffic to arbritrary ports. Indeed, a good firewall implementation would not allow such traffic. As an example, what business does a client have connecting to ports 822, 915, 341?

And at all it's nothing really new, but just another level of security - like a password, just not on this high (application) level. It's the same: You have some secret which you shouldn't share and which gives you access to some resources you're denied access otherwise.

I.e. might be nice as an additional level, but nothing exceptionally new.

Specifically because a legitimate client has no business connecting to unusual ports like 822, 915, 341, the firewall can be configured to use these ports for user authentication. The method provides a firewall-based method of authentication, as another layer to protect the system.

It is not necessary to allow inbound traffic to arbitrary ports - merely that connection attempts to these ports be logged. In fact, the method relies on these logged ports to be set to deny all connections.

I think the concern that's actually presented here is one of whether it'll be possible to knock at all if your particular set of arbitrary ports (or any subset thereof) is blocked to outbound use. I've worked in call centers and the like that use a default-deny policy on outbound traffic with the exception of a very very few ports (the most draconian allowed only 53, 80 and maybe 443 on tcp, and I think they killed 53 sometime after I left). Of course, in that case the exercise might be moot anyway...

Second, because information is flowing in the form of connection attempts rather than in typical packet data payload, without knowing that this system is in place it would be unlikely that the use of this authentication method would be detected by monitoring traffic. To minimize the risk of a functional sequence being constructed by the intercepting party, the information content containing the remote IP of the sequence can be encrypted.

IMHO, though, it seems very likely - especially given the nature of this article in explaining what to monitor for: a series of seemingly-random port connect attempts followed by a steady stream of accepted packets. The steady stream would have valid IP addresses in them, unlike the possibly encrypted portknock packets. A comparison of groups of such port connect sequences followed by normal traffic reveals the presence of the portknocking. Unless I've misunderstood something, the port numbers have to remain in clear, so they *can* be monitored even if the IPs of the portknocking packets can't be.

I think this is a valid technique, but it's not quite as undetectable as presented.

One can change the port knocking sequence randomly based on a shared key scheme. So it might depend on time and a key and change every second. So listening to ports won't mean anything since the same sequence would not work again. THe randomizer on both the client and the server would take the shared key and based on the key and let say time would create sequence of random ports.

One can change the port knocking sequence randomly based on a shared key scheme. So it might depend on time and a key and change every second. So listening to ports won't mean anything since the same sequence would not work again. THe randomizer on both the client and the server would take the shared key and based on the key and let say time would create sequence of random ports.

Creating a client to go with the knockdeamon that also requires a password as part of the shared key scheme might also work. The ports triggered by the client could cause a client predictable key response, like the opening of a communications port on the server.

Because a hacker would not know which ports might be opened on the server side (it is not in the packet afterall, but part of a shared key and password scheme), it would be difficult for a hacker to guess which ports had been opened, but the client would know because of the shared key.

This newly opened port is random and based on a shared key, and could actually be the service you need open running on an uncommon port (the client would either tunnel the port, or start ssh pointed to the right port, for instance). The other option would be some secured communication on that port that could include further identification, or some sort of handshake to agree on what must be done (opening servers or what have you).

Good point - I agree. If the eavesdropper is sophisticated and is looking for what you describe then the IP address of the connecting client would be detected.

It may be possible to prevent the eavesdropper from spoofing their IP address to match the clients, thereby being allowed to reach the application authentication after a successful connection. The server daemon could be configured to disregard any subsequent connections (even if they come from the same IP address) after the initial legitimate port knock is received and the first connection is made.

The port can always be closed immediately after first connection has been made. Adding a rule for allowing packages related to established connections come through, there is no need for keeping the port open. This works at least with iptables (--state related,established), dunno about ipchains.

and think of this: Because each attempt to knock is logged, whats to prevent an attacker from just filling up your logs? I sit behind a router that logs internally to its memory and the logs are "rolling" ie if the log gets full then the oldest entries are dropped as new ones are added. If i was using a pc to do this and logging to disk it would present a problem. If on the other hand you only log attempts at the port knocking ports then it reduces this problem greatly - I think port knocking is a good idea, but it needs more thought put to it especially by some security guru's, definately a step in the right direction tho.