Talk:Port knocking

Misc

Comment on "a set of prespecified closed ports"
Client can fecth current time and date from any public realtime service, calculate 128 bits hash with this number and secret word known both to the client and the knock server and use the result as a sequence of ports to knock. Knock server checks the received sequence against the same or any other reliable time server. This way the knocking sequence is going to be unique for every session and can not be easily replicated by adversary.
Larytet

Man in the middle attack

still prone to man in the middle attacks y don't use openvpn or ipsec?

What that's got to do with anything? Man in the middle attacks are nothing to do with port knocking. Port knocking is an access control method to individual ports. If those ports are plaintext POP3 or publickey SSH, port knocking doesn't care. Preventing man-in-the-middle attacks is nothing to do with port knocking. If you don't want people sniffing your connection and opening ports, then use an encrypted port knock. Even with a simple port knock, it's only the underlying protocol that needs to be protected against man-in-the-middle attacks. --212.159.12.218 13:25, 12 January 2006 (UTC)

Why don't man-in-the-middle attacks apply to port knocking? Someone in the network between the client and the host can see the sequence of packets going back and forth between them.--216.1.16.126 22:02, 11 April 2007 (UTC)

That's not a man-in-the-middle attack. That's traffic sniffing. Simple, "plain-text" port knocking is vulnerable to traffic sniffing and replay, but more advanced one-time or challenge-response forms, as described in deGraaf's and Jeanquier's theses (listed under "External links") and other sources are not vulnerable to this type of attack.In fact, there's no such thing as a man-in-the-middle attack against a single-message protocol. Man-in-the-middle and related attacks require that messages be exchanged in both directions between two parties.

earlier publication

It should be noted that most likely the first implementation to this was posted Jun 13, 2000 see:

https://packetstormsecurity.com/files/22121/cd00r.c.html — Preceding unsigned comment added by 84.140.150.107 (talk) 10:51, 21 February 2022 (UTC)

It would be nice if you could also cite the announcement and public discussion about this topic on the mailinglist of the "Braunschweiger Linux User Group":

http://www.lk.etc.tu-bs.de/lists/archiv/lug-bs/2001/msg05734.html

I didn't use the term "port knocking", but it's exactly the same method and it was published about a year before the earliest article that is mentioned on portknocking.org.

As this is my own work, I don't want to edit the port knocking article by myself but like to ask you to decide, if it's relevant or not.

Christian Borss

That's not the first time that port knocking appeared. An acquaintance who worked on information security for the Canadian armed forces in the 1990s informed me that he had a port knocking system running in 1998, although he declined to give me any details. Also, an employee of a large US defense contractor informed me that similar systems exist in classified defense networks in the United States; he did not give me any dates, though.

However, your posting is the first public description of port knocking of which I am aware.

Rennie deGraaf

I have been looking for that list message but I haven't been able to find it. Jeanquier's paper references this:

Borss C. (2001) ‘DROP/DENY vs. REJECT’. Listserv post to Braun-schweiger Linux User Group (lug-bs@lk.etc.tu-bs.de).

Available at: http://www.lk.etc.tu-bs.de/lists/archiv/lug-bs/2001/msg05734.html

The site no longer holds list archives. The lug-bs list is now at https://lists.lug-bs.de/listinfo/lug-bs but the archives start from 2005. Does anyone have a copy of the list thread? It would be nice if we could publish it somewhere for future reference. I wouldn't mind storing a copy on my web site. Anyone?

Luis MartinGarcia.

You can find a copy on archive.org or on our publication server:

http://web.archive.org/web/20060618092902/http://www.lk.etc.tu-bs.de/lists/archiv/lug-bs/2001/msg05734.html

http://www2.ika.rub.de/publications/2001/www.lk.etc.tu-bs.de_lists_archiv_lug-bs_2001_msg05734.html

You can cite this posting as follows:

Borß, C. (2001). "DROP/DENY vs. REJECT", The Linux User Group Braunschweig Mailinglist <lug-bs.lk.etc.tu-bs.de>, Oct. 2001, Braunschweig, Germany, URL: http://www2.ika.rub.de/publications/2001/www.lk.etc.tu-bs.de_lists_archiv_lug-bs_2001_msg05734.html

Christian Borss —Preceding unsigned comment added by Christian Borss (talk • contribs) 13:33, 15 September 2008 (UTC)

Deleted text, and the reasons

Port knocking is most often used to determine access to port 22, the Secure Shell (SSH) port.

This maybe true, maybe not, we don't know and there are no references. It's just as well possible that port knocking is mostly used to hide backdoors from server administrators who audit their servers only by doing port scans.

A port knock setup takes next to no resources and very simple software to implement.

A port knock setup needs a firewall that logs every port access, a daemon which has means to change the firewall rules (!), and, depending on how complex the knock sequences should be, cryptographic hash generators, handling of multiple knock attempts coming in at the same time, etc. This is not necessarily simple, nor takes it "near to no resources".

How Port knocking works in theory

Step 1

(A) Client cannot connect to application listening on port n; (B) Client cannot establish connection to any port.

Step 2

(1,2,3,4) Client tries to connect to a well-defined set of ports in sequence by sending certain packets; Client has prior knowledge of the port knocking daemon and its configuration, but receives no acknowledgement during this phase because firewall rules preclude any response.

Step 3

(A) Server process (a port knocking daemon) intercepts connection attempts and interprets (decrypts and decodes) them as comprising an authentic "port knock"; server carries out specific task based on content of port knock, such as opening port n to the client.

Step 4

(A) Client connects to port n and authenticates using application’s regular mechanism.

This has already been described in the text above. No need to write this twice.

The 'benefits' section should also be reworked and shortened, and the article lacks of some criticism, think of the reliability in slow networks with packet loss, or DoS attacks agains knock-protected services (e.g., Debian bug [1]). I will look at it when i have more time. --Dc12 (talk) 22:26, 11 December 2007 (UTC)

Comments on deleted text

Software complexity is very subjective. Port knocking has been implemented as a shell script, which meets most people's requirements for simplicity. Firewalls that log packets are included with the default installations of most operating systems on which people use port knocking, so counting such software in the complexity of port knocking is unfair. A robust, well-featured port knocking implementation requires no more than a couple thousand lines of C -- which is at least an order of magnitude less than an implementation of IPsec or some other standard protocol that can provide similar functionality.

As for resource requirements, well-designed port knocking servers require no more than tens of kilobytes of memory at runtime and use very little CPU time, even under heavy load. See this for more information.

There has been little work done on making port knocking resistant to packet loss. The only decent attempt of which I am aware is this one, which depends on a specific authentication algorithm and has some limitations.

Against some port knocking designs, DoS attacks are a major problem, but against othes, they are impratical or would require massive resources to be effective. Again, see this for descriptions of port knocking designs. DoS attacks are a weakness of certain specific designs, not a systemic flaw in the port knocking concept.

--70.73.65.22 (talk) 07:11, 5 January 2008 (UTC)

Link Section

In my opinion there are too many irrelevant links. ¿Is it that useful to link a 7-line article from slashdot? There are also links to 7 different implementations. It seems that 5 of them are no longer maintained by their authors (Fwknop and the netfilter module are the only active developments).

I suggest removing most of those links. I keep a list of resources about Port Knocking and Single Packet Authorization. That includes references to papers, magazine articles, implementations, presentations, etc. I have no interest on linking my own implementation but I honestly think it would be useful to link that list of references. Check it out at http://www.aldabaknocking.com/?q=portknocking and let me know what you think. If nobody complains I will remove the following links in a couple of days:

• A Linux IP Tables implementation of port knocking.
• Slashdot "Port Knocking" For Added Security
• A Windows implementation of port knocking: KnockKnock
• A simple implementation of port knocking.

and I will add this one:

List of resources about PK and SPA (papers, implementations, presentations...)

Luis Martin.

PS: Please keep in mind that the link I intend to add is from my own website. I want to make it clear so nobody thinks I'm trying to silently introduce spam. —Preceding unsigned comment added by Luismgarcia (talk • contribs) 16:24, 28 February 2008 (UTC)

Incorrent number of packets

If there is a sequence of 3 packets for port knocking, there are 65535³ possibilities. Ie. not 4. --Milan Kerslager (talk) 19:33, 27 May 2008 (UTC)

I think 65535^4 is correct because for every combination, 65335 port probes are sent to determine if a port has been opened on the target system. The article explains that in "would require an attacker without prior knowledge of the sequence to test every combination of four ports in the range 1-65535, and then to scan each port in between to see if anything had opened." Luismgarcia (talk) 08:45, 24 June 2008 (UTC).

rootkits

While this technique for securing access to remote network daemons has not been widely adopted by the security community, it has been integrated in newer rootkits.

There does not seem to be any citation to back this up, does anyone know of any? Hogan (talk) 17:55, 23 December 2010 (UTC)

SM-J700F Zazaviza (talk) 00:48, 7 January 2017 (UTC)

Disadvantages section is overstated to the point of being nonsense

There are numerous components and processes in a system (and external to it, also) which must all work properly in order for that system to stay reachable.

A port knocking deamon is a completely trivial piece of the whole puzzle.

If you can't rely on such a thing to stay up, maybe the system is not very stable as a whole.

And since this Disadvantages section acknowledges in its conclusion that this trivial piece of software can be monitored by a watchdog, it erodes whatever point it tries to make at the outset.

192.139.122.42 (talk) 18:57, 16 April 2012 (UTC)

Brute force inaccuracy

"That equates to a maximum of 65536^3 packets in order to obtain and detect a single successful opening, in the worst case scenario"

This is incorrect, or at least unclear, since attempts can overlap. For example, trying the combinations 1,2,3 and 2,3,1 would require 4 packets (1,2,3,1), not 6 (1,2,3,2,3,1). — Preceding unsigned comment added by Zxenon (talk • contribs) 22:46, 21 July 2012 (UTC)

Single Packet Authorization

Single Packet Authorization currently redirect here. However, I don't think it is port knocking as the packet is actually an encrypted UDP payload that needs to be verified. In addition, the protocol can be used to specify ports and destinations, thus it is closer to UPnP in application. --Voidvector (talk) 03:36, 2 September 2017 (UTC)

Example in benefits section why the example is assuming that the client is Windows ?" "using at the bare minimum a shell script on the server and a Windows batch file or command line utility on the client." — Preceding unsigned comment added by XP 2600 (talk • contribs) 12:01, 6 December 2021 (UTC)