[docs] man page updates

This commit is contained in:
Michael Rash
2015-12-23 11:47:17 -05:00
parent fcb0102d69
commit 9c54d774f6
4 changed files with 97 additions and 37 deletions
+4 -4
View File
@@ -2,12 +2,12 @@
.\" Title: fwknop
.\" Author: [see the "AUTHORS" section]
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
.\" Date: 11/10/2015
.\" Date: 12/23/2015
.\" Manual: Fwknop Client
.\" Source: Fwknop Client
.\" Language: English
.\"
.TH "FWKNOP" "8" "11/10/2015" "Fwknop Client" "Fwknop Client"
.TH "FWKNOP" "8" "12/23/2015" "Fwknop Client" "Fwknop Client"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
@@ -34,11 +34,11 @@ fwknop \- Firewall Knock Operator
\fBfwknop\fR \fB\-A\fR <\*(Aqproto/ports\*(Aq> \fB\-R\fR|\fB\-a\fR|\fB\-s \-D\fR <\*(Aqhost\*(Aq> [\fIoptions\fR]
.SH "DESCRIPTION"
.sp
\fBfwknop\fR implements an authorization scheme known as Single Packet Authorization (SPA) for strong service concealment\&. SPA requires only a single packet which is encrypted, non\-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default\-drop filtering stance\&. The main application of SPA is to use a firewall to drop all attempts to connect to services such as \fISSH\fR in order to make the exploitation of vulnerabilities (both 0\-day and unpatched code) more difficult\&. Any service that is concealed by SPA naturally cannot be scanned for with \fINmap\fR\&. The fwknop project supports three different firewalls: \fIiptables\fR on Linux systems, \fIpf\fR on OpenBSD, and \fIipfw\fR on FreeBSD and Mac OS X\&.
\fBfwknop\fR implements an authorization scheme known as Single Packet Authorization (SPA) for strong service concealment\&. SPA requires only a single packet which is encrypted, non\-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default\-drop filtering stance\&. The main application of SPA is to use a firewall to drop all attempts to connect to services such as \fISSH\fR in order to make the exploitation of vulnerabilities (both 0\-day and unpatched code) more difficult\&. Any service that is concealed by SPA naturally cannot be scanned for with \fINmap\fR\&. The fwknop project natively supports four different firewalls: \fIiptables\fR and \fIfirewalld\fR on Linux systems, \fIpf\fR on OpenBSD, and \fIipfw\fR on FreeBSD and Mac OS X\&.
.sp
SPA is essentially next generation Port Knocking (PK), but solves many of the limitations exhibited by PK while retaining its core benefits\&. PK limitations include a general difficulty in protecting against replay attacks, asymmetric ciphers and HMAC schemes are not usually possible to reliably support, and it is trivially easy to mount a DoS attack against a PK server just by spoofing an additional packet into a PK sequence as it traverses the network (thereby convincing the PK server that the client doesn\(cqt know the proper sequence)\&. All of these limitation are solved by SPA\&. At the same time, SPA hides services behind a default\-drop firewall policy, acquires SPA data passively (usually via libpcap or other means), and implements standard cryptographic operations for SPA packet authentication and encryption/decryption\&.
.sp
This is the manual page for the \fBfwknop\fR client which is responsible for constructing SPA packets and sending them over the network\&. The server side is implemented by the \fBfwknopd\fR daemon which sniffs the network for SPA packets and interacts with the local firewall to allow SPA authenticated connections\&. It is recommended to read the \fIfwknopd(8)\fR manual page as well\&.
This is the manual page for the \fBfwknop\fR client which is responsible for constructing SPA packets and sending them over the network\&. The server side is implemented by the \fBfwknopd\fR daemon which sniffs the network for SPA packets and interacts with the local firewall to allow SPA authenticated connections\&. It is recommended to read the \fIfwknopd(8)\fR manual page as well\&. Further detailed information may be found in the tutorial \fISingle Packet Authorization: A Comprehensive Guide to Strong Service Concealment with fwknop\fR available online here: \fIhttp://www\&.cipherdyne\&.org/fwknop/docs/fwknop\-tutorial\&.html\fR\&.
.sp
SPA packets generated by \fBfwknop\fR leverage HMAC for authenticated encryption in the encrypt\-then\-authenticate model\&. Although the usage of an HMAC is currently optional (enabled via the \fB\-\-use\-hmac\fR command line switch), it is highly recommended for three reasons: \fI1)\fR without an HMAC, cryptographically strong authentication is not possible with \fBfwknop\fR unless GnuPG is used, but even then an HMAC should still be applied, \fI2)\fR an HMAC applied after encryption protects against cryptanalytic CBC\-mode padding oracle attacks such as the Vaudenay attack and related trickery (like the more recent "Lucky 13" attack against SSL), and \fI3)\fR the code required by the \fBfwknopd\fR daemon to verify an HMAC is much more simplistic than the code required to decrypt an SPA packet, so an SPA packet without a proper HMAC isn\(cqt even sent through the decryption routines\&. Reason \fI3)\fR is why an HMAC should still be used even when SPA packets are encrypted with GnuPG due to the fact that SPA data is not sent through \fBlibgpgme\fR functions unless the HMAC checks out first\&. GnuPG and libgpgme are relatively complex bodies of code, and therefore limiting the ability of a potential attacker to interact with this code through an HMAC operation helps to maintain a stronger security stance\&. Generating an HMAC for SPA communications requires a dedicated key in addition to the normal encryption key, and both can be generated with the \fB\-\-key\-gen\fR option\&.
.sp