Home page logo

basics logo Security Basics mailing list archives

Re: Port-Knocking vulnerabilities?
From: Michael Rash <mbr () cipherdyne org>
Date: Mon, 21 Jan 2008 19:26:29 -0500

On Jan 21, 2008, whip () netspace net au wrote:

A server that is behind a default-drop packet filter is not
_practically_ detectable (say, with an nmap scan).  Can you point to a
piece of software that can reliably perform the timing differences you
are referring to in order to infer that a server is really listening
behind such a packet filter?  Do you have to invoke an additional server
(say, a webserver in addition to an SSH server) that is on the same
system that is accessible and then making a statistical argument around
latencies caused by such a server or something like that?

I believe Craig is referring to a Timing Attack.

Not really something that you can script for all purposes, but I'm sure
someone with a decent maths grounding could do so for individual attacks,
like this one.

Timing attacks can come up with some really interesting information, I
agree.  However, I'm not aware of an application of timing attacks
against default drop packet filters to answer the question "is service
XYZ really running behind the filter".  Sure, as an attacker, you can
collect timing differences between round trip times to all sorts of
devices that the target system may be communicating with, but I doubt if
there is a reliable way to infer that a _particular_ service is listening
as result.  After all, the steady state of such as service may be that
there are no sessions at all; only the occasional administrative session
to run a couple of commands and then it exits.  Note that I'm not
questioning whether it is possible to determine if a _system_ exists;
I'm questioning whether it is possible to determine if a particular
service running on a system exists.  To do so, such a timing attack
would have to differentiate between "tcp port 22" communicating vs. "tcp
port 23", etc.  I'm skeptical, and if people think it is possible, I
would like to see relevant papers that make this clear.

I find it interesting that people concentrate on whether a service
protected by a default-drop packet filter and a port knocking or SPA
system is detectable.  Let's assume for a moment that such a timing attack
is able to give an attacker a high probability that SSH is really running
behind a port knocking or SPA system.  Now, what would the attacker be
able to do to exploit a vulnerability (zero day or otherwise) in the SSH
daemon?  It is easier to subvert the port knocking protocol (I wrote a
paper on this here if anyone is interested:
http://www.cipherdyne.org/fwknop/docs/SPA.html), but how about SPA?



Michael Rash
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

I will get back when I have had a chance to trial it fully.

Dr Craig Wright (GSE-Compliance)

From: Michael Rash [mbr () cipherdyne org]
Sent: Sunday, 6 January 2008 3:12 PM
To: Craig Wright
Cc: Goldstein101; Robert Inder; Ansgar -59cobalt- Wiechers;
security-basics () securityfocus com; dave () davekleiman com
Subject: Re: Port-Knocking vulnerabilities?

On Jan 01, 2008, Craig Wright wrote:

First, you have mentioned SPA, and true this offers more then port
knocking, you have also mixed port knocking and SPA up in a couple of your

Now you make the comment that SPA can "encrypt" and store in the IP ID.
IP ID is a 16 bit flag. That is there are a max of 65535 values. Even with 4
IP packets it is functionally equivilant to a 3 character password. Given a
standard ADSL line and 68 byte packets I can send all combinations in just
under 7.5 seconds (and this is not doing any analysis on the IPID).

That is SPA and not port knocking. That is the MORE secure of the two


Yes this way will make a log entry, but are you sitting at the server
24x7 and monitoring ALL scans. Will you stop me in less then 8 seconds?

When did people consider a 3 character password safe?

That is why any implementation of SPA that just uses network or
transport layer headers to communicate information instead of
application layer data is inherently deficient and not worthy of the
SPA designation IMHO (even though technically, yes, it is just a single

In addition to the small key space that just using the 16 bit IP ID field
limits any such implementation to, there are additional limitations

- Such "SPA" packets are replayable against the target (unless some horrid
  S/KEY style iteration of a hash function is used or someone manually
  changes around the key for each SPA packet).  If the application layer
  were used (such as in fwknop: http://www.cipherdyne.org/fwknop) the
  replay problem is trivially solved by prepending every SPA packet with
  16 bytes of random data before it is encrypted.  This is possible
  because of the relatively large amount of data that can be transfered
  within the application layer payload of a single UDP packet.

- It is difficult to protect against MITM attacks because the source IP
  itself in the actual network layer header is allowed through the
  firewall policy on the server side.  Fwknop allows the source IP to be
  placed within the encrypted SPA payload, and is therefore not subject to
  alteration by an attacker that possesses an inline device that can stop
  an SPA packet and retransmit it with a different source IP.

- It is impossible to communicate client-side information that the
  server might find useful because the usage of packet headers is too
  restrictive.  A true SPA implementation can use 2048-bit GnuPG keys
  and do things like communicate crypt() passwords so the server can
  interface with additional authentication mechanisms.  Fwknop supports
  both Rijndael and GnuPG keys, crypt() passwords, and even the
  transmission of full shell commands.

Here is a list of features supported by fwknop - all of these are
possible because of the usage of payload data instead of just packet
headers for SPA communications:


*Disclaimer: I developed fwknop so obviously I'm biased.  However, I
welcome any critique that can point out a non-obvious limitation in the
fwknop architecture or implementation.

Michael Rash
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Dr Craig Wright (GSE-Compliance)

Craig Wright
Manager of Information Systems

Direct : +61 2 9286 5497
Craig.Wright () bdo com au
+61 417 683 914

BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497

Liability limited by a scheme approved under Professional Standards
Legislation in respect of matters arising within those States and
Territories of Australia where such legislation exists.

The information in this email and any attachments is confidential.  If
you are not the named addressee you must not read, print, copy, distribute,
or use in any way this transmission or any information it contains.  If you
have received this message in error, please notify the sender by return
email, destroy all copies and delete it from your system.

Any views expressed in this message are those of the individual sender
and not necessarily endorsed by BDO Kendalls.  You may not rely on this
message as advice unless subsequently confirmed by fax or letter signed by a
Partner or Director of BDO Kendalls.  It is your responsibility to scan this
communication and any files attached for computer viruses and other defects.
BDO Kendalls does not accept liability for any loss or damage however caused
which may result from this communication or any files attached.  A full
version of the BDO Kendalls disclaimer, and our Privacy statement, can be
found on the BDO Kendalls website at http://www.bdo.com.au or by emailing
administrator () bdo com au 

BDO Kendalls is a national association of separate partnerships and


From: listbounce () securityfocus com [listbounce () securityfocus com] On
Behalf Of Goldstein101 [goldstein101 () gmail com]
Sent: Tuesday, 1 January 2008 6:40 AM
To: Robert Inder
Cc: Ansgar -59cobalt- Wiechers; security-basics () securityfocus com
Subject: Re: Port-Knocking vulnerabilities?

I guess most of you haven't bothered to check what port knocking
really is capable of 'cause I'm reading a lot of things that are not

First of all, Port Knocking is just another layer of security. Think
of it as the door of a room that contains a safe. You first have to
break the port knocking daemon and then the safe. Not that easy,
believe me.

Second, Who said port knocking is like transmitting a password in
cleartext? Most modern PK systems are encryption based. An attacker
can sniff port numbers but packets usually contain other information
that is used for authentication.

For example I use Aldaba Knocking Suite (aldabaknocking.com) which
provides Port Knocking and Single Packet Authorization.

In Port knocking mode, basically the client sends this: [IP
Address][Port Number][Open/Close Flag][Checksum].

That information is encrypted and sent encoded in the IP-Id field of 4
TCP-SYN packets. This way you have 2 forms of authentication: The
first is simple: you need to know the exact port numbers to use when
sending those TCP-Syn Packets. Second: you need to know a secret (the
encryption key) used to encrypt the information. If you don't have it,
you can send random data but when decrypted, it won't verify the

However, Port Knocking has some disadvantages and vulnerabilities. A
better and more elegant approach is SPA. Check it out. There are some
papers out there.


On Dec 31, 2007 7:27 PM, Robert Inder <robertinder () googlemail com>
On 29/12/2007, Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
On 2007-12-28 Jay wrote:
Portknocking is a security mechanism as it is a type of
authentication. "Something you know" in this case the sequence of
ports to knock before a unstarted service or daemon begins
for connections.

Since everything is transmitted in the clear port-knocking is as
much of
a security mechanism as cleartext passwords. Technically: maybe
(depending on your definition). Realistically: no.

I think your dismissal of port knocking (and, indeed, plain text
passwords) is unrealistic.

If you can intercept my interaction with some remote server, you can
steal the relevant secrets (the password or the sequence of ports).

But isn't that quite a substantial "if"?

How are you going to do it?  Aren't you going to have to compromise
some other machine, either where I am, or where the server is (or, I
guess, where the relevant DNS records are), and then plant software to
deliberately wait and watch until a relevant interaction takes place?

I'm not saying that's impossible.  But it would take considerable
knowledge, planning and effort.

Why doesn't that make it a substantial defence against most kinds of
casual attack?


Robert Inder        Interactive Information Ltd,            Registered
in Scotland
07808 492 213     3, Lauriston Gardens,                  Company no.
SC 150689
0131 229 1052     Edinburgh EH3 9HH
                          SCOTLAND UK             Interactions speak
louder than words

Room 101, Ministry of Truth.
W2, London. Oceania.

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.17.13/1212 - Release Date: 6/01/2008
10:55 PM

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.7/1234 - Release Date: 20/01/2008
2:15 PM

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]