update man page in client/server directories to the latest
This commit is contained in:
Michael Rash
parent
b4171fe90c
commit
9cbb80d434
@ -2,12 +2,12 @@
|
||||
.\" Title: fwknop
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.76.1 <http://docbook.sf.net/>
|
||||
.\" Date: 05/20/2013
|
||||
.\" Date: 05/31/2013
|
||||
.\" Manual: Fwknop Client
|
||||
.\" Source: Fwknop Client
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "FWKNOP" "8" "05/20/2013" "Fwknop Client" "Fwknop Client"
|
||||
.TH "FWKNOP" "8" "05/31/2013" "Fwknop Client" "Fwknop Client"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
@ -34,15 +34,15 @@ 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 passive service protection\&. SPA requires only a single non\-replayed encrypted packet together with an HMAC in order to communicate various pieces of information including desired access to a service that is otherwise blocked by a firewall\&. The main application of SPA is to use a firewall in a default\-drop stance to protect services such as \fISSH\fR with an additional layer of security in order to make the exploitation of vulnerabilities (both 0\-day and unpatched code) more difficult\&. In addition, services that are protected in this fashion naturally cannot be scanned for with \fINmap\fR\&.
|
||||
\fBfwknop\fR implements an authorization scheme known as Single Packet Authorization (SPA) for strong service protection\&. 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 protected 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\&.
|
||||
.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 supported, 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 lightweight cryptographic operations for SPA packet authentication and encryption/decryption\&.
|
||||
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 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\&.
|
||||
.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 CBC\-mode padding oracle attacks such as the Vaudenay attack and 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\&. Generating an HMAC for SPA communications requires a dedicated key in addition to the normal encryption key\&.
|
||||
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
|
||||
\fBfwknop\fR encrypts SPA packets either with the \fIRijndael\fR block cipher or via \fIGnuPG\fR and associated asymmetric cipher\&. If the symmetric encryption method is chosen, then as usual the encryption key is shared between the client and server (see the \fBfwknopd\fR \fIaccess\&.conf\fR file for details)\&. The actual encryption key used for Rijndael encryption is generated via the standard PBKDF1 key derivation algorithm, and CBC mode is set\&. If the GnuPG method is chosen, then the encryption keys are derived from GnuPG key rings\&. SPA packets generated by fwknop running as a client adhere to the following format (before encryption and the HMAC is applied):
|
||||
\fBfwknop\fR encrypts SPA packets either with the \fIRijndael\fR block cipher or via \fIGnuPG\fR and associated asymmetric cipher\&. If the symmetric encryption method is chosen, then as usual the encryption key is shared between the client and server (see the \fBfwknopd\fR \fI\*(Aq@sysconfdir@/fwknop/access\&.conf\fR file for details)\&. The actual encryption key used for Rijndael encryption is generated via the standard PBKDF1 key derivation algorithm, and CBC mode is set\&. If the GnuPG method is chosen, then the encryption keys are derived from GnuPG key rings\&. SPA packets generated by fwknop running as a client adhere to the following format (before encryption and the HMAC is applied):
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
@ -65,7 +65,7 @@ Each of the above fields are separated by a ":" character due to the variable le
|
||||
.sp
|
||||
By default, the \fBfwknop\fR client sends authorization packets over UDP port 62201, but this can be altered with the \fB\-\-server\-port\fR argument (this requires \fBfwknopd\fR to be configured to acquire SPA data over the selected port)\&. Also, \fBfwknop\fR can send the SPA packet over a random port via the \fB\-\-rand\-port\fR argument\&. See \fIfwknopd(8)\fR for further details\&. See the \fBEXAMPLES\fR section for example invocations of the \fBfwknop\fR client\&.
|
||||
.sp
|
||||
The \fBfwknop\fR client is quite portable, and is known to run on various Linux distributions (all major distros and embedded ones such as OpenWRT as well), FreeBSD, OpenBSD, and Cygwin on Windows\&. There is also a library \fBlibfko\fR that both \fBfwknop\fR and \fBfwknopd\fR use for SPA packet encryption/decryption and HMAC authentication operations\&. This library can be used to allow third party applications to use SPA\&.
|
||||
The \fBfwknop\fR client is quite portable, and is known to run on various Linux distributions (all major distros and embedded ones such as OpenWRT as well), FreeBSD, OpenBSD, and Cygwin on Windows\&. There is also a library \fBlibfko\fR that both \fBfwknop\fR and \fBfwknopd\fR use for SPA packet encryption/decryption and HMAC authentication operations\&. This library can be used to allow third party applications to use SPA subject to the terms of the GNU Public License (GPL)\&.
|
||||
.SH "REQUIRED ARGUMENTS"
|
||||
.sp
|
||||
These required arguments can be specified via command\-line or from within the \fI\&.fwknoprc\fR file (see \fI\-n, \-\-named\-config\fR option and the FWKNOPRC FILE section below)\&.
|
||||
@ -86,7 +86,7 @@ argument via an SPA packet to be executed by
|
||||
does not require this argument\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB\-D, \-\-destination\fR=\fI<IP\-address>\fR
|
||||
\fB\-D, \-\-destination\fR=\fI<hostname/IP\-address>\fR
|
||||
.RS 4
|
||||
Direct the
|
||||
\fBfwknop\fR
|
||||
@ -431,7 +431,7 @@ client sends SPA packets\&. This requires root on the client side access since a
|
||||
argument can be given in this mode in order to pass any
|
||||
\fBREQUIRE_USERNAME\fR
|
||||
keyword that might be specified in
|
||||
\fI/etc/fwknop/access\&.conf\fR\&.
|
||||
\fI@sysconfdir@/fwknop/access\&.conf\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB\-r, \-\-rand\-port\fR
|
||||
@ -462,7 +462,7 @@ uses the URL:
|
||||
to resolve the caller IP\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB\-\-resolve\-url\fR
|
||||
\fB\-\-resolve\-url\fR \fI<url>\fR
|
||||
.RS 4
|
||||
Override the default URL used for resolving the source IP address\&. For best results, the URL specified here should point to a web service that provides just an IP address in the body of the HTTP response\&.
|
||||
.RE
|
||||
@ -533,8 +533,8 @@ Specify the message digest algorithm to use in the SPA data\&. Choices are:
|
||||
\fB\-M, \-\-encryption\-mode\fR=\fI<mode>\fR
|
||||
.RS 4
|
||||
Specify the encryption mode when AES is used for encrypting SPA packets\&. The default is CBC mode, but others can be chosen such as CFB or OFB as long as this is also specified in the
|
||||
\fIaccess\&.conf\fR
|
||||
file on the server side via the ENCRYPTION_MODE variable\&. In general, it is recommended to not use this argument and just use the default (CBC)\&. Note that the string \(lqlegacy\(rq can be specified in order to generate SPA packets with the old initialization vector strategy used by versions of
|
||||
\fI\*(Aq@sysconfdir@/fwknop/access\&.conf\fR
|
||||
file on the server side via the ENCRYPTION_MODE variable\&. In general, it is recommended to not include this argument and let the default (CBC) apply\&. Note that the string \(lqlegacy\(rq can be specified in order to generate SPA packets with the old initialization vector strategy used by versions of
|
||||
\fBfwknop\fR
|
||||
prior to 2\&.5\&. With the 2\&.5 release,
|
||||
\fBfwknop\fR
|
||||
@ -623,7 +623,8 @@ to acquire GnuPG key password from a running gpg\-agent instance (if available)\
|
||||
.RS 4
|
||||
Specify the path to the GnuPG directory; normally this path is derived from the home directory of the user that is running the
|
||||
\fBfwknop\fR
|
||||
client\&. This is useful when a \(lqroot\(rq user wishes to log into a remote machine whose sshd daemon/service does not permit root login\&.
|
||||
client (so the default is
|
||||
\fI~/\&.gnupg\fR)\&. This is useful when a \(lqroot\(rq user wishes to log into a remote machine whose sshd daemon/service does not permit root login\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB\-\-gpg\-recipient\fR=\fI<key ID or Name>\fR
|
||||
@ -649,12 +650,12 @@ The \fI\&.fwknoprc\fR file contains a default configuration area or stanza which
|
||||
.sp
|
||||
There are directives to match most of the command\-line parameters \fBfwknop\fR supports\&. Here is the current list of each directive along with a brief description and its matching command\-line option(s):
|
||||
.PP
|
||||
\fBSPA_SERVER\fR
|
||||
\fBSPA_SERVER\fR \fI<hostname/IP\-address>\fR
|
||||
.RS 4
|
||||
Specify the IP or hostname of the destination (\fBfwknopd\fR) server (\fI\-D, \-\-destination\fR)\&.
|
||||
Specify the hostname or IP of the destination (\fBfwknopd\fR) server (\fI\-D, \-\-destination\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBALLOW_IP\fR
|
||||
\fBALLOW_IP\fR \fI<IP\-address>\fR
|
||||
.RS 4
|
||||
Specify the address to allow within the SPA data\&. Note: This parameter covers the
|
||||
\fB\-a\fR,
|
||||
@ -673,32 +674,32 @@ resolve the external network IP via HTTP request (the
|
||||
option)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBACCESS\fR
|
||||
\fBACCESS\fR \fI<port list>\fR
|
||||
.RS 4
|
||||
Set the one or more protocol/ports to open on the firewall (\fI\-A, \-\-access\fR)\&.
|
||||
Set the one or more protocol/ports to open on the firewall (\fI\-A, \-\-access\fR)\&. The format of this list is \(lq+<proto>/<port>\&...<proto>/<port>+\(rq, e\&.g\&. \(lqtcp/22,udp/53\(rq\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBSPA_SERVER_PORT\fR
|
||||
\fBSPA_SERVER_PORT\fR \fI<port>\fR
|
||||
.RS 4
|
||||
Set the server port to use for sending the SPA packet (\fI\-p, \-\-server\-port\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBSPA_SERVER_PROTO\fR
|
||||
\fBSPA_SERVER_PROTO\fR \fI<protocol\fR>
|
||||
.RS 4
|
||||
Set the protocol to use for sending the SPA packet (\fI\-P, \-\-server\-proto\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBKEY\fR
|
||||
\fBKEY\fR \fI<passphrase>\fR
|
||||
.RS 4
|
||||
This is the passphrase that is used for SPA packet encryption and applies to both Rijndael or GPG encryption modes\&. The actual encryption key that is used for Rijndael is derived from the PBKDF1 algorithm, and the GPG key is derived from the specified GPG key ring\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBKEY_BASE64\fR
|
||||
\fBKEY_BASE64\fR \fI<base64 encoded passphrase>\fR
|
||||
.RS 4
|
||||
Specify the encryption passphrase as a base64 encoded string\&. This allows non\-ascii characters to be included in the base64\-decoded key\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBUSE_HMAC\fR
|
||||
\fBUSE_HMAC\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Set HMAC mode for authenticated encryption of SPA packets\&. This will have
|
||||
\fBfwknop\fR
|
||||
@ -709,17 +710,17 @@ or
|
||||
directives (see below)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBHMAC_KEY\fR
|
||||
\fBHMAC_KEY\fR \fI<key>\fR
|
||||
.RS 4
|
||||
Specify the HMAC key for authenticated encryption of SPA packets\&. This supports both Rijndael and GPG encryption modes, and is applied according to the encrypt\-then\-authenticate model\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBHMAC_KEY_BASE64\fR
|
||||
\fBHMAC_KEY_BASE64\fR \fI<base64 encoded key>\fR
|
||||
.RS 4
|
||||
Specify the HMAC key as a base64 encoded string\&. This allows non\-ascii characters to be included in the base64\-decoded key\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBHMAC_DIGEST_TYPE\fR
|
||||
\fBHMAC_DIGEST_TYPE\fR \fI<digest algorithm>\fR
|
||||
.RS 4
|
||||
Set the HMAC digest algorithm used for authenticated encryption of SPA packets\&. Choices are:
|
||||
\fBMD5\fR,
|
||||
@ -730,46 +731,54 @@ Set the HMAC digest algorithm used for authenticated encryption of SPA packets\&
|
||||
\fBSHA512\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBSPA_SOURCE_PORT\fR
|
||||
\fBSPA_SOURCE_PORT\fR \fI<port>\fR
|
||||
.RS 4
|
||||
Set the source port to use for sending the SPA packet (\fI\-S, \-\-source\-port\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBFW_TIMEOUT\fR
|
||||
\fBFW_TIMEOUT\fR \fI<seconds>\fR
|
||||
.RS 4
|
||||
Set the firewall rule timeout value (\fI\-f, \-\-fw\-timeout\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBRESOLVE_URL\fR
|
||||
\fBRESOLVE_URL\fR \fI<url>\fR
|
||||
.RS 4
|
||||
Set to a URL that will be used for resolving the source IP address (\-\-resolve\-url)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBTIME_OFFSET\fR
|
||||
\fBTIME_OFFSET\fR \fI<time>\fR
|
||||
.RS 4
|
||||
Set a value to apply to the timestamp in the SPA packet\&. This can be either a positive or negative value (\fI\-\-time\-offset\-plus/minus\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBENCRYPTION_MODE\fR
|
||||
\fBENCRYPTION_MODE\fR \fI<mode>\fR
|
||||
.RS 4
|
||||
Specify the encryption mode when AES is used\&. This variable is a synonym for the
|
||||
\fI\-\-encryption\-mode\fR
|
||||
command line argument\&.
|
||||
\fI\-M, \-\-encryption\-mode\fR
|
||||
command line argument\&. In general, it is recommended to not include this argument and let the default (CBC) apply\&. Note that the string \(lqlegacy\(rq can be specified in order to generate SPA packets with the old initialization vector strategy used by versions of
|
||||
\fBfwknop\fR
|
||||
prior to 2\&.5\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBDIGEST_TYPE\fR
|
||||
\fBDIGEST_TYPE\fR \fI<digest algorithm>\fR
|
||||
.RS 4
|
||||
Set the SPA message digest type (\fI\-m, \-\-digest\-type\fR)\&.
|
||||
Set the SPA message digest type (\fI\-m, \-\-digest\-type\fR)\&. Choices are:
|
||||
\fBMD5\fR,
|
||||
\fBSHA1\fR,
|
||||
\fBSHA256\fR
|
||||
(the default),
|
||||
\fBSHA384\fR, and
|
||||
\fBSHA512\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBUSE_GPG\fR
|
||||
\fBUSE_GPG\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Set to
|
||||
\fIY\fR
|
||||
to specify the use of GPG for encryption (\fI\-\-gpg\-encryption\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBUSE_GPG\fR
|
||||
\fBUSE_GPG_AGENT\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Set to
|
||||
\fIY\fR
|
||||
@ -780,62 +789,63 @@ interface with a GPG agent instance for the GPG key password (\fI\-\-gpg\-agent\
|
||||
environmental variable\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBGPG_SIGNER\fR
|
||||
\fBGPG_SIGNER\fR \fI<key ID or Name>\fR
|
||||
.RS 4
|
||||
Specify the GPG key name or ID for signing the GPG\-encrypted SPA data (\fI\-\-gpg\-signer\-key\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBGPG_RECIPIENT\fR
|
||||
\fBGPG_RECIPIENT\fR \fI<key ID or Name>\fR
|
||||
.RS 4
|
||||
Specify the GPG key name or ID for the recipient of the GPG\-encrypted SPA data (\fI\-\-gpg\-recipient\-key\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBGPG_HOMEDIR\fR
|
||||
\fBGPG_HOMEDIR\fR \fI<dir>\fR
|
||||
.RS 4
|
||||
Specify the GPG home directory (\fI\-\-gpg\-home\-dir\fR)\&.
|
||||
Specify the GPG home directory (\fI\-\-gpg\-home\-dir\fR)\&. Defaults to
|
||||
\fI~/\&.gnupg\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBSPOOF_USER\fR
|
||||
\fBSPOOF_USER\fR \fI<user>\fR
|
||||
.RS 4
|
||||
Set the username in the SPA data to the specified value (\fI\-U, \-\-spoof\-user\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBSPOOF_SOURCE_IP\fR
|
||||
\fBSPOOF_SOURCE_IP\fR \fI<IP>\fR
|
||||
.RS 4
|
||||
Set the source IP of the outgoing SPA packet to the specified value (\fI\-Q, \-\-spoof\-source\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBRAND_PORT\fR
|
||||
\fBRAND_PORT\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Send the SPA packet over a randomly assigned port (\fI\-r, \-\-rand\-port\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBKEY_FILE\fR
|
||||
\fBKEY_FILE\fR \fI<file>\fR
|
||||
.RS 4
|
||||
Load an encryption key/password from a file (\fI\-G, \-\-get\-key\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBHTTP_USER_AGENT\fR
|
||||
\fBHTTP_USER_AGENT\fR \fI<agent string>\fR
|
||||
.RS 4
|
||||
Set the HTTP User\-Agent for resolving the external IP via \-R, or for sending SPA packets over HTTP (\fI\-u, \-\-user\-agent\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBNAT_ACCESS\fR
|
||||
\fBNAT_ACCESS\fR \fI<internalIP:forwardPort>\fR
|
||||
.RS 4
|
||||
Gain NAT access to an internal service protected by the fwknop server (\fI\-N, \-\-nat\-access\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBNAT_LOCAL\fR
|
||||
\fBNAT_LOCAL\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Access a local service via a forwarded port on the fwknopd server system (\fI\-\-nat\-local\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBNAT_PORT\fR
|
||||
\fBNAT_PORT\fR \fI<port>\fR
|
||||
.RS 4
|
||||
Specify the port to forward to access a service via NAT (\fI\-\-nat\-port\fR)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBNAT_RAND_PORT\fR
|
||||
\fBNAT_RAND_PORT\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Have the fwknop client assign a random port for NAT access (\fI\-\-nat\-rand\-port\fR)\&.
|
||||
.RE
|
||||
@ -850,7 +860,7 @@ Because \fBfwknop\fR places the IP to be allowed through the firewall within the
|
||||
The following examples illustrate the command line arguments that could be supplied to the fwknop client in a few situations:
|
||||
.SS "Access mode examples"
|
||||
.sp
|
||||
The most common usage of \fBfwknop\fR is to gain access to \fISSH\fR running on a remote system that has the \fBfwknopd\fR daemon deployed along with a default\-drop firewall policy\&. The following command illustrates this where IP \fI1\&.1\&.1\&.1\fR is the IP to be allowed through the firewall running on \fI2\&.2\&.2\&.2\fR (note that the \fIaccess\&.conf\fR file consumed by \fBfwknopd\fR will need to have matching encryption and HMAC keys, and configuration specifics can be found in the \fIfwknopd(8)\fR manual page):
|
||||
The most common usage of \fBfwknop\fR is to gain access to \fISSH\fR running on a remote system that has the \fBfwknopd\fR daemon deployed along with a default\-drop firewall policy\&. The following command illustrates this where IP \fI1\&.1\&.1\&.1\fR is the IP to be allowed through the firewall running on \fI2\&.2\&.2\&.2\fR (note that the \fI\*(Aq@sysconfdir@/fwknop/access\&.conf\fR file consumed by \fBfwknopd\fR will need to have matching encryption and HMAC keys, and configuration specifics can be found in the \fIfwknopd(8)\fR manual page):
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
|
||||
@ -2,12 +2,12 @@
|
||||
.\" Title: fwknopd
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.76.1 <http://docbook.sf.net/>
|
||||
.\" Date: 05/20/2013
|
||||
.\" Date: 05/31/2013
|
||||
.\" Manual: Fwknop Server
|
||||
.\" Source: Fwknop Server
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "FWKNOPD" "8" "05/20/2013" "Fwknop Server" "Fwknop Server"
|
||||
.TH "FWKNOPD" "8" "05/31/2013" "Fwknop Server" "Fwknop Server"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
@ -297,7 +297,7 @@ will not check incoming SPA packet data against any previously save digests\&. I
|
||||
Allow SPA clients to request access to services through an iptables firewall instead of just to it (i\&.e\&. access through the FWKNOP_FORWARD chain instead of the INPUT chain)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBENABLE_IPT_LOCAL_NAT\fR \fI>Y/N>\fR
|
||||
\fBENABLE_IPT_LOCAL_NAT\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
Allow SPA clients to request access to a local socket via NAT\&. This still puts an ACCEPT rule into the FWKNOP_INPUT chain, but a different port is translated via DNAT rules to the real one\&. So, the user would do \(lqssh \-p <port>\(rq to access the local service (see the
|
||||
\fB\-\-NAT\-local\fR
|
||||
@ -482,6 +482,18 @@ before 2\&.5\&. With the 2\&.5 release,
|
||||
uses PBKDF1 for key derivation\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBHMAC_DIGEST_TYPE\fR \fI<digest algorithm>\fR
|
||||
.RS 4
|
||||
Specify the digest algorithm for incoming SPA packet authentication\&. Must be one of
|
||||
\fBMD5\fR,
|
||||
\fBSHA1\fR,
|
||||
\fBSHA256\fR,
|
||||
\fBSHA384\fR, or
|
||||
\fBSHA512\fR\&. This is an optional field, and if not specified then
|
||||
\fBfwknopd\fR
|
||||
defaults to using SHA256 if the access stanza requires an HMAC\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBENABLE_CMD_EXEC\fR \fI<Y/N>\fR
|
||||
.RS 4
|
||||
This instructs
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user