Provided by: fwknop-client_2.6.0-2.2_i386 bug

NAME

       fwknop - Firewall Knock Operator

SYNOPSIS

       fwknop -A <'proto/ports'> -R|-a|-s -D <'host'> [options]

DESCRIPTION

       fwknop 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 SSH 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
       Nmap. The fwknop project supports three different firewalls: iptables
       on Linux systems, pf on OpenBSD, and ipfw on FreeBSD and Mac OS X.

       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’t 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.

       This is the manual page for the fwknop client which is responsible for
       constructing SPA packets and sending them over the network. The server
       side is implemented by the fwknopd 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 fwknopd(8)
       manual page as well.

       SPA packets generated by fwknop leverage HMAC for authenticated
       encryption in the encrypt-then-authenticate model. Although the usage
       of an HMAC is currently optional (enabled via the --use-hmac command
       line switch), it is highly recommended for three reasons: 1) without an
       HMAC, cryptographically strong authentication is not possible with
       fwknop unless GnuPG is used, but even then an HMAC should still be
       applied, 2) 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 3) the code required by the fwknopd 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’t even sent
       through the decryption routines. Reason 3) 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 libgpgme 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 --key-gen option.

       fwknop encrypts SPA packets either with the Rijndael block cipher or
       via GnuPG 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 fwknopd /etc/fwknop/access.conf 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):

               random data (16 digits)
               username
               timestamp
               software version
               mode (command mode (0) or access mode (1))
               if command mode => command to execute
               else access mode  => IP,proto,port
               message digest (SHA512 / SHA384 / SHA256 / SHA1 / MD5)

       Each of the above fields are separated by a ":" character due to the
       variable length of several of the fields, and those that might contain
       ":" characters are base64 encoded. The message digest (SHA256 by
       default) is part of the data to be encrypted and is independent of the
       HMAC which is appended to the SPA packet data after encryption. The 16
       digits of random data (about 53 bits) ensures that no two SPA packets
       are identical, and this is in addition to and independent of using
       PBKDF1 for key derivation for Rijndael in CBC mode (which uses an
       8-byte random "salt" value). Because fwknopd tracks the SHA256 digest
       of all incoming valid SPA packets and throws out duplicates, replay
       attacks are not feasible against fwknop. Syslog alerts are generated if
       a replay is detected.

       By default, the fwknop client sends authorization packets over UDP port
       62201, but this can be altered with the --server-port argument (this
       requires fwknopd to be configured to acquire SPA data over the selected
       port). Also, fwknop can send the SPA packet over a random port via the
       --rand-port argument. See fwknopd(8) for further details. See the
       EXAMPLES section for example invocations of the fwknop client.

       The fwknop 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 libfko that both fwknop and fwknopd 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 General Public License (GPL).

REQUIRED ARGUMENTS

       These required arguments can be specified via command-line or from
       within the ~/.fwknoprc file (see -n, --named-config option and the
       FWKNOPRC FILE section below).

       -A, --access=<port list>
           Provide a list of ports and protocols to access on a remote
           computer running fwknopd. The format of this list is
           “+<proto>/<port>...<proto>/<port>+”, e.g. “tcp/22,udp/53”.  NOTE:
           The vast majority of usages for fwknop require the -A argument, but
           sending full commands with the --server-cmd argument via an SPA
           packet to be executed by fwknopd does not require this argument.

       -D, --destination=<hostname/IP-address>
           Direct the fwknop client to authenticate with the fwknopd
           daemon/service at the specified destination hostname or IP address.
           The connection mode is discovered by the fwknopd daemon/service
           when it decrypts and parses the authentication packet.

       -R|-a|-s
           One of these options (see below) is required to tell the remote
           fwknopd daemon what IP should be allowed through the local
           firewall. It is recommend to use the -R or -a options instead of -s
           in order to harden SPA communications against possible
           Man-In-The-Middle (MITM) attacks, and on the server side set
           REQUIRE_SOURCE_ADDRESS variable in the /etc/fwknop/access.conf
           file. Note that the most secure option is -a so that fwknop does
           not have to issue an HTTP request to
           http://www.cipherdyne.org/cgi-bin/myip in order to resolve the
           externally routable IP address. Using -a requires that the user
           already knows what the external IP is for the network where fwknop
           is running.

GENERAL OPTIONS

       -h, --help
           Print a usage summary message and exit.

       -G, --get-key=<file>
           Load an encryption key/password from the specified file. The key
           file contains a line for each destination hostname or IP address, a
           colon (":"), optional space and the password, followed by a
           newline. Note that the last line has to have a terminating newline
           character. Also note: though this is a convenience, having a file
           on your system with clear text passwords is not a good idea and is
           not recommended. Having the fwknop client prompt you for the key is
           generally more secure. Note also that if a key is stored on disk,
           the fwknop rc file is a more powerful mechanism for specifying not
           only the key but other options as well.

       --stdin
           Read the encryption key/password from stdin. This can be used to
           send the data via a pipe for example. This command is similar to
           --fd 0.

       --fd=<number>
           Specify the file descriptor number to read the key/password from.
           This command avoids the user being prompted for a password if none
           has been found in the user specific stanza, or none has been
           supplied on the command line. A file descriptor set to 0 is similar
           to the stdin command.

       --get-hmac-key=<file>
           Load an HMAC key/password from the specified file. Similarly to the
           format for the --get-key option, the HMAC key file contains a line
           for each destination hostname or IP address, a colon (":"),
           optional space and the password, followed by a newline. Note that
           the last line has to have a terminating newline character. Also
           note: though this is a convenience, having a file on your system
           with clear text passwords is not a good idea and is not
           recommended. Having the fwknop client prompt you for the HMAC key
           is generally more secure. Note also that if a key is stored on
           disk, the fwknop rc file is a more powerful mechanism for
           specifying not only the HMAC key but other options as well.

       --key-gen
           Have fwknop generate both Rijndael and HMAC keys that can be used
           for SPA packet encryption. These keys are derived from /dev/urandom
           and then base64 encoded before being printed to stdout, and are
           meant to be included within the “$HOME/.fwknoprc” file (or the file
           referenced by --get-key). Such keys are generally more secure than
           passphrases that are typed in from the command line.

       --key-len=<length>
           Specify the number of bytes for a generated Rijndael key. The
           maximum size is currently 128 bytes.

       --hmac-key-len=<length>
           Specify the number of bytes for a generated HMAC key. The maximum
           size is currently 128 bytes.

       -l, --last-cmd
           Execute fwknop with the command-line arguments from the previous
           invocation (if any). The previous arguments are parsed out of the
           ~/.fwknop.run file.

       -n, --named-config=<stanza name>
           Specify the name of the configuration stanza in the
           “$HOME/.fwknoprc” file to pull configuration and command
           directives. These named stanzas alleviate the need for remembering
           the various command-line arguments for frequently used invocations
           of fwknop. See the section labeled, FWKNOPRC FILE below for a list
           of the valid configuration directives in the .fwknoprc file.

       --key-rijndael=<key>
           Specify the Rijndael key on the command line. Since the key may be
           visible to utilities such as ps under Unix, this form should only
           be used where security is not critical. Having the fwknop client
           either prompt you for the key or acquire via the “$HOME/.fwknoprc”
           file is generally more secure.

       --key-base64-rijndael=<key>
           Specify the base64 encoded Rijndael key. Since the key may be
           visible to utilities such as ps under Unix, this form should only
           be used where security is not critical. Having the fwknop client
           either prompt you for the key or acquire via the “$HOME/.fwknoprc”
           file is generally more secure.

       --key-base64-hmac=<key>
           Specify the base64 encoded HMAC key. Since the key may be visible
           to utilities such as ps under Unix, this form should only be used
           where security is not critical. Having the fwknop client either
           prompt you for the key or acquire via the “$HOME/.fwknoprc” file is
           generally more secure.

       --key-hmac=<key>
           Specify the raw HMAC key (not base64 encoded). Since the key may be
           visible to utilities such as ps under Unix, this form should only
           be used where security is not critical. Having the fwknop client
           either prompt you for the key or acquire via the “$HOME/.fwknoprc”
           file is generally more secure.

       --rc-file=<file>
           Specify path to the fwknop rc file (default is $HOME/.fwknoprc).

       --save-rc-stanza=<stanza name>
           Save command line arguments to the $HOME/.fwknoprc stanza specified
           with the -n option. If the -n option is omitted, then the stanza
           name will default to the destination server value (hostname or IP)
           given with the -D argument.

       --force-stanza
           Used with --save-rc-stanza to overwrite all of the variables for
           the specified stanza

       --stanza-list
           Dump a list of the stanzas found in “$HOME/.fwknoprc”.

       --show-last
           Display the last command-line arguments used by fwknop.

       -E, --save-args-file=<file>
           Save command line arguments to a specified file path. Without this
           option, and when --no-save-args is not also specified, then the
           default save args path is ~/.fwknop.run.

       --no-save-args
           Do not save the command line arguments given when fwknop is
           executed.

       -T, --test
           Test mode. Generate the SPA packet data, but do not send it.
           Instead, print a break-down of the SPA data fields, then run the
           data through the decryption and decoding process and print the
           break-down again. This is primarily a debugging feature.

       -B, --save-packet=<file>
           Instruct the fwknop client to write a newly created SPA packet out
           to the specified file so that it can be examined off-line.

       -b, --save-packet-append
           Append the generated packet data to the file specified with the -B
           option.

       -v, --verbose
           Run the fwknop client in verbose mode. This causes fwknop to print
           some extra information about the current command and the resulting
           SPA data.

       -V, --version
           Display version information and exit.

SPA OPTIONS

       --use-hmac
           Set HMAC mode for authenticated encryption of SPA communications.
           As of fwknop 2.5, this is an optional feature, but this will become
           the default in a future release.

       -a, --allow-ip=<IP-address>
           Specify IP address that should be permitted through the destination
           fwknopd server firewall (this IP is encrypted within the SPA packet
           itself). This is useful to prevent a MITM attack where a SPA packet
           can be intercepted en-route and sent from a different IP than the
           original. Hence, if the fwknopd server trusts the source address on
           the SPA packet IP header then the attacker gains access. The -a
           option puts the source address within the encrypted SPA packet, and
           so thwarts this attack. The -a option is also useful to specify the
           IP that will be granted access when the SPA packet itself is
           spoofed with the --spoof-src option. Another related option is -R
           (see below) which instructs the fwknop client to automatically
           resolve the externally routable IP address the local system is
           connected to by querying a website that returns the actual IP
           address it sees from the calling system.

       -g, --gpg-encryption
           Use GPG encryption on the SPA packet (default if not specified is
           Rijndael).  Note: Use of this option will also require a GPG
           recipient (see --gpg-recipient along with other GPG-related options
           below).

       --hmac-digest-type=<digest>
           Set the HMAC digest algorithm for authenticated encryption of SPA
           packets. Choices are: MD5, SHA1, SHA256 (the default), SHA384, and
           SHA512.

       -N, --nat-access=<internalIP:forwardPort>
           The fwknopd server offers the ability to provide SPA access through
           an iptables firewall to an internal service by interfacing with the
           iptables NAT capabilities. So, if the fwknopd server is protecting
           an internal network on an RFC-1918 address space, an external
           fwknop client can request that the server port forward an external
           port to an internal IP, i.e. “+--NAT-access 192.168.10.2,55000+”.
           In this case, access will be granted to 192.168.10.2 via port 55000
           to whatever service is requested via the --access argument (usually
           tcp/22). Hence, after sending such an SPA packet, one would then do
           “ssh -p 55000 user@host” and the connection would be forwarded on
           through to the internal 192.168.10.2 system automatically. Note
           that the port “55000” can be randomly generated via the
           --nat-rand-port argument (described later).

       --nat-local
           On the fwknopd server, a NAT operation can apply to the local
           system instead of being forwarded through the system. That is, for
           iptables firewalls, a connection to, say, port 55,000 can be
           translated to port 22 on the local system. By making use of the
           --nat-local argument, the fwknop client can be made to request such
           access. This means that any external attacker would only see a
           connection over port 55,000 instead of the expected port 22 after
           the SPA packet is sent.

       --nat-port
           Usually fwknop is used to request access to a specific port such as
           tcp/22 on a system running fwknopd. However, by using the
           --nat-port argument, it is possible to request access to a (again,
           such as tcp/22), but have this access granted via the specified
           port (so, the -p argument would then be used on the SSH client
           command line). See the --nat-local and --nat-access command line
           arguments to fwknop for additional details on gaining access to
           services via a NAT operation.

       --nat-rand-port
           Usually fwknop is used to request access to a specific port such as
           tcp/22 on a system running fwknopd. However, by using the
           --nat-rand-port argument, it is possible to request access to a
           particular service (again, such as tcp/22), but have this access
           granted via a random translated port. That is, once the fwknop
           client has been executed in this mode and the random port selected
           by fwknop is displayed, the destination port used by the follow-on
           client must be changed to match this random port. For SSH, this is
           accomplished via the -p argument. See the --nat-local and
           --nat-access command line arguments to fwknop for additional
           details on gaining access to services via a NAT operation.

       -p, --server-port=<port>
           Specify the port number where fwknopd accepts packets via libpcap
           or ulogd pcap writer. By default fwknopd looks for authorization
           packets over UDP port 62201.

       -P, --server-proto=<protocol>
           Set the protocol (udp, tcp, http, udpraw, tcpraw, or icmp) for the
           outgoing SPA packet. Note: The udpraw, tcpraw, and icmp modes use
           raw sockets and thus require root access to run. Also note: The tcp
           mode expects to establish a TCP connection to the server before
           sending the SPA packet. This is not normally done, but is useful
           for compatibility with the Tor for strong anonymity; see
           http://tor.eff.org/. In this case, the fwknopd server will need to
           be configured to listen on the target TCP port (which is 62201 by
           default).

       -Q, --spoof-src=<IP>
           Spoof the source address from which the fwknop client sends SPA
           packets. This requires root on the client side access since a raw
           socket is required to accomplish this. Note that the --spoof-user
           argument can be given in this mode in order to pass any
           REQUIRE_USERNAME keyword that might be specified in
           /etc/fwknop/access.conf.

       -r, --rand-port
           Instruct the fwknop client to send an SPA packet over a random
           destination port between 10,000 and 65535. The fwknopd server must
           use a PCAP_FILTER variable that is configured to accept such
           packets. For example, the PCAP_FILTER variable could be set to:
           “+udp dst portrange 10000-65535+”.

       -R, --resolve-ip-http
           This is an important option, and instructs the fwknop client and
           the fwknopd daemon/service to query a web server that returns the
           caller’s IP address (as seen by the web server). In some cases,
           this is needed to determine the IP address that should be allowed
           through the iptables policy at the remote fwknopd server side. This
           is useful if the fwknop client is being used on a system that is
           behind an obscure NAT address. Presently, fwknop uses the URL:
           http://www.cipherdyne.org/cgi-bin/myip to resolve the caller IP.
           Note that it is generally more secure to use the -a option if the
           externally routable IP address for the client is already known to
           the user since this elminates the need for fwknop to issue an HTTP
           request.

       --resolve-url <url>
           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.

       -s, --source-ip
           Instruct the fwknop client to form an SPA packet that contains the
           special-case IP address “+0.0.0.0+” which will inform the
           destination fwknopd SPA server to use the source IP address from
           which the SPA packet originates as the IP that will be allowed
           through upon modification of the firewall ruleset. This option is
           useful if the fwknop client is deployed on a machine that is behind
           a NAT device and the external IP is not known. However, usage of
           this option is not recommended, and either the -a or -R options
           should be used instead. The permit-address options -s, -R and -a
           are mutually exclusive.

       -S, --source-port=<port>
           Set the source port for outgoing SPA packet.

       -f, --fw-timeout=<seconds>
           Specify the length of time (seconds) that the remote firewall rule
           that grants access to a service is to remain active. The default
           maintained by fwknopd is 30 seconds, but any established connection
           can be kept open after the initial accept rule is deleted through
           the use of a connection tracking mechanism that may be offered by
           the firewall.

       -C, --server-cmd=<command to execute>
           Instead of requesting access to a service with an SPA packet, the
           --server-cmd argument specifies a command that will be executed by
           the fwknopd server. The command is encrypted within the SPA packet
           and sniffed off the wire (as usual) by the fwknopd server.

       -H, --http-proxy=<proxy-host>[:port]
           Specify an HTTP proxy that the fwknop client will use to send the
           SPA packet through. Using this option will automatically set the
           SPA packet transmission mode (usually set via the --server-proto
           argument) to "http". You can also specify the proxy port by adding
           ":<port>" to the proxy host name or ip.

       -m, --digest-type=<digest>
           Specify the message digest algorithm to use in the SPA data.
           Choices are: MD5, SHA1, SHA256 (the default), SHA384, and SHA512.

       -M, --encryption-mode=<mode>
           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
           /etc/fwknop/access.conf 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 “legacy” can be specified in order to generate SPA
           packets with the old initialization vector strategy used by
           versions of fwknop prior to 2.5. With the 2.5 release, fwknop
           generates initialization vectors in a manner that is compatible
           with OpenSSL via the PBKDF1 algorithm.

       --time-offset-plus=<time>
           By default, the fwknopd daemon on the server side enforces time
           synchronization between the clocks running on client and server
           systems. The fwknop client places the local time within each SPA
           packet as a time stamp to be validated by the fwknopd server after
           decryption. However, in some circumstances, if the clocks are out
           of sync and the user on the client system does not have the
           required access to change the local clock setting, it can be
           difficult to construct and SPA packet with a time stamp the server
           will accept. In this situation, the --time-offset-plus option can
           allow the user to specify an offset (e.g. “60sec” “60min” “2days”
           etc.) that is added to the local time.

       --time-offset-minus=<time>
           This is similar to the --time-offset-plus option (see above), but
           subtracts the specified time offset instead of adding it to the
           local time stamp.

       -u, --user-agent=<user-agent-string>
           Set the HTTP User-Agent for resolving the external IP via -R, or
           for sending SPA packets over HTTP.

       -U, --spoof-user=<user>
           Specify the username that is included within SPA packet. This
           allows the fwknop client to satisfy any non-root REQUIRE_USERNAME
           keyword on the fwknopd server (--spoof-src mode requires that the
           fwknop client is executed as root).

       --icmp-type=<type>
           In -P icmp mode, specify the ICMP type value that will be set in
           the SPA packet ICMP header. The default is echo reply.

       --icmp-code=<code>
           In -P icmp mode, specify the ICMP code value that will be set in
           the SPA packet ICMP header. The default is zero.

GPG OPTIONS

       Note that the usage of GPG for SPA encryption/decryption can and should
       involve GPG keys that are signed by each side (client and server). The
       basic procedure for this involves the following steps after the client
       key has been transferred to the server and vice-versa:

               [spaserver]# gpg --import client.asc
               [spaserver]# gpg --edit-key 1234ABCD
               Command> sign

               [spaclient]$ gpg --import server.asc
               [spaclient]$ gpg --edit-key ABCD1234
               Command> sign

       More comprehensive information on this can be found here:
       http://www.cipherdyne.org/fwknop/docs/gpghowto.html.

       --gpg-agent
           Instruct fwknop to acquire GnuPG key password from a running
           gpg-agent instance (if available).

       --gpg-home-dir=<dir>
           Specify the path to the GnuPG directory; normally this path is
           derived from the home directory of the user that is running the
           fwknop client (so the default is ~/.gnupg). This is useful when a
           “root” user wishes to log into a remote machine whose sshd
           daemon/service does not permit root login.

       --gpg-recipient=<key ID or Name>
           Specify the GnuPG key ID, e.g. “+1234ABCD+” (see the output of
           "gpg—list-keys") or the key name (associated email address) of the
           recipient of the Single Packet Authorization message. This key is
           imported by the fwknopd server and the associated private key is
           used to decrypt the SPA packet. The recipient’s key must first be
           imported into the client GnuPG key ring.

       --gpg-signer-key=<key ID or Name>
           Specify the GnuPG key ID, e.g. “+ABCD1234+” (see the output of "gpg
           --list-keys") or the key name to use when signing the SPA message.
           The user is prompted for the associated GnuPG password to create
           the signature. This adds a cryptographically strong mechanism to
           allow the fwknopd daemon on the remote server to authenticate who
           created the SPA message.

       --gpg-no-signing-pw
           Instruct fwknop to not acquire a passphrase for usage of GnuPG
           signing key. This option is provided to make SPA packet
           construction easier for client-side operations in automated
           environments where the passphrase for the signing key has been
           removed from the GnuPG key ring. However, it is usually better to
           leverage gpg-agent instead of using this option.

FWKNOPRC FILE

       The .fwknoprc file is used to set various parameters to override
       default program parameters at runtime. It also allows for additional
       named configuration stanzas for setting program parameters for a
       particular invocation.

       The fwknop client will create this file if it does not exist in the
       user’s home directory. This initial version has some sample directives
       that are commented out. It is up to the user to edit this file to meet
       their needs.

       The .fwknoprc file contains a default configuration area or stanza
       which holds global configuration directives that override the program
       defaults. You can edit this file and create additional named stanzas
       that can be specified with the -n or --named-config option. Parameters
       defined in the named stanzas will override any matching default stanza
       directives. Note that command-line options will still override any
       corresponding .fwknoprc directives.

       There are directives to match most of the command-line parameters
       fwknop supports. Here is the current list of each directive along with
       a brief description and its matching command-line option(s):

       SPA_SERVER <hostname/IP-address>
           Specify the hostname or IP of the destination (fwknopd) server (-D,
           --destination).

       ALLOW_IP <IP-address>
           Specify the address to allow within the SPA data. Note: This
           parameter covers the -a, -s, and -R command-line options. You can
           specify a hostname or IP address (the -a option), specify the word
           "source" to tell the fwknopd server to accept the source IP of the
           packet as the IP to allow (the -s option), or use the word
           "resolve" to have fwknop resolve the external network IP via HTTP
           request (the -R option).

       ACCESS <port list>
           Set the one or more protocol/ports to open on the firewall (-A,
           --access). The format of this list is
           “+<proto>/<port>...<proto>/<port>+”, e.g. “tcp/22,udp/53”.

       SPA_SERVER_PORT <port>
           Set the server port to use for sending the SPA packet (-p,
           --server-port).

       SPA_SERVER_PROTO <protocol>
           Set the protocol to use for sending the SPA packet (-P,
           --server-proto).

       KEY <passphrase>
           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.

       KEY_BASE64 <base64 encoded passphrase>
           Specify the encryption passphrase as a base64 encoded string. This
           allows non-ascii characters to be included in the base64-decoded
           key.

       USE_HMAC <Y/N>
           Set HMAC mode for authenticated encryption of SPA packets. This
           will have fwknop prompt the user for a dedicated HMAC key that is
           independent of the encryption key. Alternatively, the HMAC key can
           be specified with the HMAC_KEY or HMAC_KEY_BASE64 directives (see
           below).

       HMAC_KEY <key>
           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.

       HMAC_KEY_BASE64 <base64 encoded key>
           Specify the HMAC key as a base64 encoded string. This allows
           non-ascii characters to be included in the base64-decoded key.

       HMAC_DIGEST_TYPE <digest algorithm>
           Set the HMAC digest algorithm used for authenticated encryption of
           SPA packets. Choices are: MD5, SHA1, SHA256 (the default), SHA384,
           and SHA512.

       SPA_SOURCE_PORT <port>
           Set the source port to use for sending the SPA packet (-S,
           --source-port).

       FW_TIMEOUT <seconds>
           Set the firewall rule timeout value (-f, --fw-timeout).

       RESOLVE_URL <url>
           Set to a URL that will be used for resolving the source IP address
           (--resolve-url).

       TIME_OFFSET <time>
           Set a value to apply to the timestamp in the SPA packet. This can
           be either a positive or negative value (--time-offset-plus/minus).

       ENCRYPTION_MODE <mode>
           Specify the encryption mode when AES is used. This variable is a
           synonym for the -M, --encryption-mode command line argument. In
           general, it is recommended to not include this argument and let the
           default (CBC) apply. Note that the string “legacy” can be specified
           in order to generate SPA packets with the old initialization vector
           strategy used by versions of fwknop prior to 2.5.

       DIGEST_TYPE <digest algorithm>
           Set the SPA message digest type (-m, --digest-type). Choices are:
           MD5, SHA1, SHA256 (the default), SHA384, and SHA512.

       USE_GPG <Y/N>
           Set to Y to specify the use of GPG for encryption
           (--gpg-encryption).

       USE_GPG_AGENT <Y/N>
           Set to Y to have fwknop interface with a GPG agent instance for the
           GPG key password (--gpg-agent). Agent information itself is
           specified with the GPG_AGENT_INFO environmental variable.

       GPG_SIGNING_PW <passphrase>
           This is the passphrase that is used for signing SPA packet data in
           GPG encryption mode, and is a synonym for the KEY variable (i.e.
           the signing passphrase can be specified with the KEY variable
           instead). The SPA packet is encrypted with the remote server key
           and signed with the local client key.

       GPG_SIGNING_PW_BASE64 <base64 encoded passphrase>
           Specify the GPG signing passphrase as a base64 encoded string. This
           allows non-ascii characters to be included in the base64-decoded
           key.

       GPG_SIGNER <key ID or Name>
           Specify the GPG key name or ID for signing the GPG-encrypted SPA
           data (--gpg-signer-key).

       GPG_RECIPIENT <key ID or Name>
           Specify the GPG key name or ID for the recipient of the
           GPG-encrypted SPA data (--gpg-recipient-key).

       GPG_HOMEDIR <dir>
           Specify the GPG home directory (--gpg-home-dir). Defaults to
           ~/.gnupg.

       SPOOF_USER <user>
           Set the username in the SPA data to the specified value (-U,
           --spoof-user).

       SPOOF_SOURCE_IP <IP>
           Set the source IP of the outgoing SPA packet to the specified value
           (-Q, --spoof-source).

       RAND_PORT <Y/N>
           Send the SPA packet over a randomly assigned port (-r,
           --rand-port).

       KEY_FILE <file>
           Load an encryption key/password from a file (-G, --get-key).

       HTTP_USER_AGENT <agent string>
           Set the HTTP User-Agent for resolving the external IP via -R, or
           for sending SPA packets over HTTP (-u, --user-agent).

       NAT_ACCESS <internalIP:forwardPort>
           Gain NAT access to an internal service protected by the fwknop
           server (-N, --nat-access).

       NAT_LOCAL <Y/N>
           Access a local service via a forwarded port on the fwknopd server
           system (--nat-local).

       NAT_PORT <port>
           Specify the port to forward to access a service via NAT
           (--nat-port).

       NAT_RAND_PORT <Y/N>
           Have the fwknop client assign a random port for NAT access
           (--nat-rand-port).

ENVIRONMENT

       SPOOF_USER, GPG_AGENT_INFO (only used in --gpg-agent mode).

SPA PACKET SPOOFING

       Because fwknop places the IP to be allowed through the firewall within
       the encrypted SPA payload (unless -s is used which is not recommended
       and can be prohibited in the fwknopd server configuration), SPA packets
       can easily be spoofed, and this is a good thing in this context. That
       is, the source IP of an SPA packet is ignored by the fwknopd daemon
       (when the REQUIRE_SOURCE_ADDRESS variable is set in the
       /etc/fwknop/access.conf file) and only the IP that is contained within
       an authenticated and properly decrypted SPA packet is granted access
       through the firewall. This makes it possible to make it appear as
       though, say, www.yahoo.com is trying to authenticate to a target system
       but in reality the actual connection will come from a seemingly
       unrelated IP.

EXAMPLES

       The following examples illustrate the command line arguments that could
       be supplied to the fwknop client in a few situations:

   Quick start
       The most effective and easiest way to use fwknop is to have the client
       generate both an encryption key and an HMAC key, and then save them to
       the “$HOME/.fwknoprc” file along with access request specifics. The
       keys will also need to be transferred to the system where fwknopd is
       running. The also client supports a separate set of encryption and HMAC
       keys for each SPA destination if multiple fwknopd servers are running
       on different systems.

       So, assuming that the IP 2.2.2.2 is the system where fwknopd is
       deployed and SSH is protected by the firewall on that system in a
       default-drop stance, run the client like so to generate encryption and
       HMAC keys:

               $ fwknop -A tcp/22 --use-hmac -R -D 2.2.2.2 --key-gen --save-rc-stanza --verbose
               [+] Wrote Rijndael and HMAC keys to rc file: /home/user/.fwknoprc

       With the access request arguments and encryption and HMAC keys
       generated and saved in “$HOME/.fwknoprc”, the keys themselves need to
       be transferred to the 2.2.2.2 system where fwknopd is running. As
       always, this should be done via some secure means such as SSH before
       SPA is enabled and SSHD is blocked by the firewall. Here is what the
       new 2.2.2.2 stanza looks like in the ~/.fwknoprc file:

               $ tail -n 8 /home/user/.fwknoprc
               [2.2.2.2]
               ACCESS                      tcp/22
               SPA_SERVER                  2.2.2.2
               KEY_BASE64                  HvUtIOramehLGKimD4ECXOzinaH4h3U8H1WXum7b54Q=
               HMAC_KEY_BASE64             DLeLf93a3yBT2vhEpM+dWlirGta5GU+jdyG5uXp4461HgOtbqMem4gX0Bp2PJGzYZlbbcavcOM00UPm+0GqkXA==
               USE_HMAC                    Y
               VERBOSE                     Y
               RESOLVE_IP_HTTP             Y

       The keys are base64 encoded blobs of random data, and both the
       KEY_BASE64 and HMAC_KEY_BASE64 lines should be copied verbatim and
       placed within the /etc/fwknop/access.conf file on 2.2.2.2. Once this is
       done, fwknopd can be started on that system, a default-drop policy
       against SSH connections can be put in place, and then access to SSH is
       managed via fwknop. To access SSH, just use the -n argument to
       reference the 2.2.2.2 stanza out of the .fwknoprc file (some --verbose
       output is included for illustration):

               $ fwknop -n 2.2.2.2

               FKO Field Values:
               =================

                  Random Value: 8950423288486978
                      Username: mbr
                     Timestamp: 1370194770
                   FKO Version: 2.5
                  Message Type: 1 (Access msg)
                Message String: 1.1.1.1,tcp/22
                    Nat Access: <NULL>
                   Server Auth: <NULL>
                Client Timeout: 0 (seconds)
                   Digest Type: 3 (SHA256)
                     HMAC Type: 3 (SHA256)
               Encryption Type: 1 (Rijndael)
               Encryption Mode: 2 (CBC)
               ...

               $ ssh -l user 2.2.2.2
               user@2.2.2.2's password:

   Access mode examples
       The most common usage of fwknop is to gain access to SSH running on a
       remote system that has the fwknopd daemon deployed along with a
       default-drop firewall policy. The following command illustrates this
       where IP 1.1.1.1 is the IP to be allowed through the firewall running
       on 3.3.3.3 (note that the /etc/fwknop/access.conf file consumed by
       fwknopd will need to have matching encryption and HMAC keys, and
       configuration specifics can be found in the fwknopd(8) manual page).
       Also, note the examples below prompt the user to supply the encryption
       and HMAC keys via stdin instead of writing them to disk as in the case
       of using the “$HOME/.fwknoprc” file in the example above. However, all
       of the following examples can be converted to using the ~/.fwknoprc
       file just by adding the --save-rc-stanza argument:

               $ fwknop -A tcp/22 --use-hmac -a 1.1.1.1 -D 3.3.3.3
               Enter encryption key:
               Enter HMAC key:
               $ ssh -l user 3.3.3.3
               user@3.3.3.3's password:

       If the --verbose flag is added to the command line, then some SPA
       packet specifics are printed to stdout (not all output is shown for
       brevity):

               $ fwknop -A tcp/22 --use-hmac -a 1.1.1.1 -D 3.3.3.3 --verbose
               Enter encryption key:
               Enter HMAC key:

                  Random Value: 1916307060193417
                      Username: mbr
                     Timestamp: 1368498909
                   FKO Version: 2.5
                  Message Type: 1 (Access msg)
                Message String: 1.1.1.1,tcp/22
                    Nat Access: <NULL>
                   Server Auth: <NULL>
                Client Timeout: 0 (seconds)
                   Digest Type: 3 (SHA256)
                     HMAC Type: 3 (SHA256)
               Encryption Type: 1 (Rijndael)
               Encryption Mode: 2 (CBC)

       Simultaneous access to multiple services is also supported, and here is
       an example of requesting access to both SSH and OpenVPN on 3.3.3.3:

               $ fwknop -A "tcp/22,tcp/1194" --use-hmac -a 1.1.1.1 -D 3.3.3.3

       There are many cases where an fwknop client is deployed on a network
       behind a NAT device and the externally routable IP is not known to the
       user. In this case, use the IP resolution service available at
       http://www.cipherdyne.org/cgi-bin/myip via the -R command line switch
       in order to derive the external client IP address. This is a safer
       method of acquiring the client IP address than using the -s option
       mentioned earlier in this manual page because the source IP is put
       within the encrypted packet instead of having the fwknopd daemon grant
       the requested access from whatever IP address the SPA packet originates
       (i.e. using -s opens the possibility of a MITM attack):

               $ fwknop -A tcp/22 --use-hmac -R -D 3.3.3.3

       Use the Single Packet Authorization mode to gain access to SSH and this
       time use GnuPG keys to encrypt and decrypt:

               $ fwknop -A tcp/22 --use-hmac --gpg-sign ABCD1234 --gpg--recipient 1234ABCD -R -D 3.3.3.3

       Instruct the fwknop server running at 3.3.3.3 to allow 1.1.1.1 to
       connect to SSH, but spoof the authorization packet from an IP
       associated with www.yahoo.com (requires root on the fwknop client OS):

               # fwknop --spoof-src "www.yahoo.com" -A tcp/22 --use-hmac -a 1.1.1.1 -D 3.3.3.3

       When fwknopd is running on an iptables firewall with systems deployed
       behind it, it is possible to take advantage of the NAT capabilities
       offered by iptables in order to transparently reach systems behind the
       firewall via SPA. Here is an example where the fwknop client is used to
       gain access to SSH running on the non-routable IP 192.168.10.23 that is
       deployed on the network behind 3.3.3.3. In this case, the SSH
       connection made to 3.3.3.3 is translated via NAT to the 192.168.10.2
       system automatically:

               $ fwknop -A tcp/22 -N 192.168.10.2:22 -R -D 3.3.3.3

BACKWARDS COMPATIBILITY

       With the 2.5 release, fwknop underwent significant changes in its usage
       of cryptography including the addition of support for HMAC
       authenticated encryption for both Rijndael and GnuPG modes, ensuring
       the proper usage of PBKDF1 for key derivation when SPA packets are
       encrypted with Rijndael, and several bugs were fixed from previous
       versions of fwknop. In general, this implies that when Rijndael is
       used, SPA packets produced by the 2.5 release are incompatible with
       previous versions of fwknop. The GnuPG encryption mode is unaffected by
       these updates. However, even with Rijndael is used, backwards
       compatibility is supported through setting the legacy encryption mode
       with -M on the fwknop client command line and/or the ENCRYPTION_MODE
       variable in the /etc/fwknop/access.conf file. This way, a pre-2.5
       server can decrypt SPA packets produced by a 2.5 and later client (set
       -M legacy), and a 2.5 and later server can decrypt SPA packets produced
       by pre-2.5 clients (set ENCRYPTION_MODE legacy in the access.conf
       file). Note that HMAC is only supported as of 2.5 and is an optional
       feature, so backwards compatibility is only for configurations that
       don’t use an HMAC on either side. It is strongly recommended to upgrade
       all fwknop clients and servers to 2.5 and use the new HMAC mode for
       properly authenticated SPA communications. The backwards compatibility
       support is used to make it easier to upgrade clients and servers with a
       phased approach.

       For emphasis, if the fwknopd server is upgraded to 2.5 (or later), but
       older clients cannot be upgraded at the same time, then for each SOURCE
       stanza in the /etc/fwknop/access.conf file, add the following line:

               ENCRYPTION_MODE         legacy

       In addition, if the KEY variable has an encryption key longer than 16
       bytes, it will need to be truncated to 16 characters in the access.conf
       file in order for pre-2.5 clients to work properly. This limitation is
       fixed in 2.5, and provides additional motiviation for upgrading all
       clients and servers to 2.5 or later.

       Now, flipping the scenario around, if the fwknop clients are upgraded
       but the fwknopd server is still at a pre-2.5 version, then add the -M
       legacy argument to the fwknop command line:

               $ fwknop -A tcp/22 -M legacy -R -D 2.2.2.2

DEPENDENCIES

       The fwknop client requires libfko which is normally included with both
       source and binary distributions, and is a dedicated library developed
       by the fwknop project. Whenever the fwknopd server is used, libpcap is
       a required dependency. However, the upcoming 2.6 release will offer a
       UDP listener mode along with privilege separation support and will not
       require libpcap in this mode. In UDP listener mode, even though fwknopd
       binds to a UDP port, SPA packets are never acknowledged so from an
       attacker’s perspective there is no difference between fwknopd sniffing
       the wire passively vs. listening on a UDP socket in terms of what can
       be scanned for.

       For GPG functionality, GnuPG must also be correctly installed and
       configured along with the libgpgme library.

       To take advantage of all of the authentication and access management
       features of the fwknopd daemon/service a functioning iptables, ipfw, or
       pf firewall is required on the underlying operating system.

DIAGNOSTICS

       The most comprehensive way to gain diagnostic information on fwknop is
       to run the test suite test-fwknop.pl script located in the test/
       directory in the fwknop sources. The test suite sends fwknop through a
       large number of run time tests, has valgrind support, validates both
       SPA encryption and HMAC results against OpenSSL, and even has its own
       built in fuzzer for SPA communications. For more basic diagnostic
       information, fwknop can be executed with the -T (or --test) command
       line option. This will have fwknop simply create and print the SPA
       packet information, then run it through a decrypt/decode cycle and
       print it again. In addition, the --verbose command line switch is
       useful to see various SPA packet specifics printed to stdout.

SEE ALSO

       fwknopd(8), iptables(8), pf(4), pfctl(8), ipfw(8), gpg(1), libfko
       documentation.

       More information on Single Packet Authorization can be found in the
       paper “Single Packet Authorization with fwknop” available at
       http://www.cipherdyne.org/fwknop/docs/SPA.html. A comprehensive
       tutorial on fwknop operations and theory can be found at
       http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html. This
       tutorial also includes information about the design of fwknop that may
       be worth reading for those interested in why fwknop is different from
       other SPA implementations.

       fwknop uses the git versioning system as its source code repository
       along with Github for tracking of issues and milestones:

               $ git clone https://github.com/mrash/fwknop.git fwknop.git

       Additional commentary on Single Packet Authorization can be found via
       Michael Rash’s Twitter feed: http://twitter.com/michaelrash,
       @michaelrash

AUTHORS

       Damien Stuart <dstuart@dstuart.org>, Michael Rash <mbr@cipherdyne.org>

CONTRIBUTORS

       This “C” version of fwknop was derived from the original Perl-based
       version on which many people who are active in the open source
       community have contributed. See the CREDITS file in the fwknop sources,
       or visit http://www.cipherdyne.org/fwknop/docs/contributors.html to
       view the online list of contributors. A few contributors deserve to be
       singled out including: Franck Joncourt, Max Kastanas, Vlad Glagolev,
       Sean Greven, Hank Leininger, Fernando Arnaboldi, and Erik Gomez.

       The phrase “Single Packet Authorization” was coined by MadHat and
       Simple Nomad at the BlackHat Briefings of 2005.

BUGS

       Send bug reports to dstuart@dstuart.org or mbr@cipherdyne.org, or open
       a new issue on Github (see https://github.com/mrash/fwknop.git).
       Suggestions and/or comments are always welcome as well. Additional
       information may be found in the fwknop mailing list archives (see:
       https://lists.sourceforge.net/lists/listinfo/fwknop-discuss).

DISTRIBUTION

       fwknop is distributed under the GNU General Public License (GPL)
       version 2, and the latest version may be downloaded from
       http://www.cipherdyne.org.