{"id":1068,"date":"2008-10-06T13:06:37","date_gmt":"2008-10-06T13:06:37","guid":{"rendered":"https:\/\/www.darknet.org.uk\/?p=1068"},"modified":"2015-09-09T19:39:15","modified_gmt":"2015-09-09T11:39:15","slug":"fwknop-port-knocking-tool-with-single-packet-authorization","status":"publish","type":"post","link":"https:\/\/www.darknet.org.uk\/2008\/10\/fwknop-port-knocking-tool-with-single-packet-authorization\/","title":{"rendered":"fwknop – Port Knocking Tool with Single Packet Authorization"},"content":{"rendered":"

[ad]<\/p>\n

Port Knocking<\/a> came about in around 2003, but it has various weaknesses. There are plenty of implentations though (some quite advanced). Most of the problems are fixed however by fwknop!<\/p>\n

fwknop stands for the “FireWall KNock OPerator”, and implements an authorization scheme called Single Packet Authorization (SPA)<\/a>. This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap.<\/p>\n

SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through a firewall policy and\/or complete commands to execute on the target system. By using a firewall to maintain a “default drop” stance, the main application of fwknop is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult.<\/p>\n

With fwknop deployed, anyone using nmap to look for sshd can’t even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively monitors authorization packets via libcap and hence there is no “server” to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from a fwknop client.<\/p>\n