<html><head><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>Port Knocking: A Method for securing a computer by allowing connections
when no ports are open</title><meta name="generator" content="DocBook XSL Stylesheets V1.50.1-EXP2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article"><div class="titlepage"><div><h1 class="title"><a name="id190238"></a>Port Knocking: A Method for securing a computer by allowing connections
when no ports are open</h1></div><div><div class="author"><h3 class="author">Joseph Mack</h3><div class="affiliation"><span class="orgname">mack (dot) joseph (at) epa (dot) gov <br></span><span class="orgdiv">S.A.I.C.<br></span></div></div></div><div><p class="pubdate">Apr 2004</p></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>
Three implementations of port knocking, <tt>knockd</tt>,
<tt>doormand</tt> and <tt>pasmal</tt> are tested.
</p><p>
Port knocking is a new technique
<sup>[<a name="id245647" href="#ftn.id245647">1</a>]</sup>
which holds promise for adding to the armanetarium of security measures.
The current implementations are only just coming out of the
proof-of-principle stage and are not ready for regular use.
Once implemented, these demons will require testing
on sacrificial machines exposed to the internet, to show that they
aren't vunerable to to compromises which are only obvious with hindsight.
Implementations which are good enough to test should be available soon enough,
and the EPA should be ready to use them as soon as they are seen to be useful.
</p></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt>1. <a href="#Introduction">Introduction</a></dt><dt>2. <a href="#implementations">Implementations: knockd, doormand and pasmal</a></dt><dd><dl><dt>2.1. <a href="#knockd">knockd</a></dt><dt>2.2. <a href="#doormand">Doormand</a></dt><dt>2.3. <a href="#id192332">Pasmal</a></dt></dl></dd></dl></div><div class="section"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="Introduction"></a>1. Introduction</h2></div></div><p>
The EPA has been investigating methods of securing an ftp server
and I had considered suggesting port knocking.
Recently (mid Apr 2004), there were a series of security breaches
at Supercomputing Centers across the US (<i>e.g.</i>
<a href="http://securecomputing.stanford.edu/alerts/multiple-unix-6apr2004.html" target="_top">
Stanford University</a>),
I decided to investigate port knocking as a security measure.
</p><p>
For access to computers, ports must be open.
Port scans will reveal the open ports and in many cases will
reveal the OS and OS version on the target computer.
This information allows intruder to run known successful attacks
agains the computers.
There is reasonable evidence that most of the distributed DoS (DDoS) attacks
are by home Windows machines sitting 24hrs/day open on cable modems,
which have been compromised in this way. Thus 1000's of zombie machines
can be coordinated to DDoS a target machine while the owners are sitting
at the keyboard web surfing, oblivious of the mayhem their machine
is helping to produce (or they could be asleep or at work).
</p><p>
A proposal by Martyn Krzywinski, in Linux J.
called
<a href="http://www.linuxjournal.com/article.php?sid=6811" target="_top">port knocking</a>
turns off the open ports (<i>e.g.</i> with <b>iptables</b>)
and listens for a pre-agreed sequence of connect requests to a series of ports
(say port 5000,6000,7000)
within a timeout period (say 15secs) and the
port knocking demon will open the port (say 22 for an ssh connection)
to only the client's IP, allowing the client to login.
The ports chosen for the knocking (here 5000,6000,7000) can be open but are usually closed.
On closing out their session, the client sends a different
sequence of knocks (here called "un-knocking") to close down the port
(this could be the same ports in the reverse order).
</p><p>
Thus a computer with no open ports at all,
and hence undetectable by port scanning,
will still be available for logins.
Even while the user is connected, the open port is open only to the client computer
and will not be detected by port scanning.
Port knocking then appears to be the perfect method for preventing
unauthorised access through port scans.
</p><p>
While not vunerable to port scanning, port knocking is vunerable
to sniffers. A port scan can be done from any remote computer,
but sniffing can only be done on a network segment between the client
and server.
The port knock sequence can in principle be determined,
although possibly with difficulty and hence is insecure.
By itself, it is not a method of securing a machine, but
should be considered as an extra layer to hinder unauthorized attack.
With port-knocking you are ahead of the situation were the ports are open
and detectable by simple port scanning.
The port knock demon is not likely to
be triggered by port scanners. These accesses ports in order or in
some random fashion. By requiring enough steps in the port knocking,
the chances of a random port scan accessing a port knock can be reduced to
an arbitrary level (a factor of 1:65536 for each extra port knocked).
</p></div><div class="section"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="implementations"></a>2. Implementations: knockd, doormand and pasmal</h2></div></div><p>
The original article by Krzywinski used <b>iptables</b>
to log connect requests to the closed port, and a perl
script scanned the logs to open the port for user login (say port 22).
This was a proof of principle implementation and is too slow and clumsy for regular
deployment.
</p><p>
Only <b>knockd</b> will be analysed in detail.
</p><div class="section"><div class="titlepage"><div><h3 class="title"><a name="knockd"></a>2.1. knockd</h3></div></div><p>
<a href="http://www.zeroflux.org/knock/" target="_top">knockd-0.1</a> by Judd Vinet.
This presumably is the first (and preliminary) release of the code.
</p><p>
The server will have sshd running and an <b>iptables</b>
rule like
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">
iptables -p tcp --dport ssh -j REJECT #deny access to port 22
</pre></td></tr></table><p>
preventing access by remote clients to <b>sshd</b>.
</p><p>
On receiving the knock seqence (say connect request to ports 5000,6000,7000
in that order and within 15secs, using the knock client provided), <b>knockd</b> will execute the command.
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">
iptables -I INPUT -s %IP% -p tcp --dport ssh -j ACCEPT #allow access from %IP% to port 22
</pre></td></tr></table><p>
allowing access to sshd from the only the user's IP (here called %IP%).
Multiple accesses by other knockd clients will add similar
rules for each client's IP, allowing connection each new client.
After exiting the session, the user runs the knock client giving the un-knock sequence.
<b>knockd</b> on the server will respond by
closing down access to the client's IP with the command
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">
iptables -D INPUT -s %IP% -p tcp --dport ssh -j ACCEPT #delete the rule which allows access from %IP% to port 22
</pre></td></tr></table><p>
which removes the rule (above) which allowed access from the client's IP.
</p><p>
While <tt>knockd-0.1</tt>
fulfills the requirements above for a minimal port knocking demon,
it has the following problems
</p><div class="itemizedlist"><ul type="disc"><li>
The user has to remember to un-knock after exiting their login session,
to turn off the open port. Few people can be expected to do this.
</li><li>
If the number of knocks and un-knocks is not matched, then multiple identical entries
will appear in the filter rule list, each allowing access by the client. The
user has no way of knowing how many rule entries are in place and
hence does not know the number of un-knocks to run.
</li><li>
If the user is coming in
from a dial-up and the connection drops, the client machine will re-appear on another
IP and will not be able to remove the rule which opened a connection to the
old IP (even if the user wants to remove it).
</li></ul></div><p>
The current implementation is easy to audit for security.
However fixing the problems will require <b>knockd</b> to maintain state
for each user.
Much testing will have to ensure that the security of <b>knockd</b>
has not been compromised by the added code.
</p></div><div class="section"><div class="titlepage"><div><h3 class="title"><a name="doormand"></a>2.2. Doormand</h3></div></div><p>
<a href="http://doorman.sourceforge.net/" target="_top">doormand</a> by J.B. Ward.
</p><p>
This port knocking demon maintains state with BerkeleyDB.
Due to the mutually incompatible APIs of the different version of BerkeleyDB,
I was not able to link <tt>doormand</tt>.
Presumably with enough time I could eventually link it,
but I wasn't prepared to spend the time.
The author needs to recode the section using BerkeleyDB.
</p></div><div class="section"><div class="titlepage"><div><h3 class="title"><a name="id192332"></a>2.3. Pasmal</h3></div></div><p>
<a href="http://pasmal.casino770.com/" target="_top">Pasmal</a> is in between <b>knockd</b>
and <b>doormand</b> in features and complexity.
Unfortunately the documentation is only for d00ds a lot c00l3r than I,
and I didn't persevere.
</p></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">
</pre></td></tr></table><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id245647" href="#id245647">1</a>] </sup>
It's actually been around since the ArpaNet days, but
no-one has implemented it
</p></div></div></div></body></html>