FWKNOP(8)

📦 version 2.6.11, in alpine 3.24, arch rolling, debian bookworm, debian trixie, epel 10, epel 9, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ NAME ✨

fwknop — the Firewall Knock Operator 💅

(Also: this is FWKNOP(8), the Fwknop Client page, bestie. Part one of a whole saga, so buckle up 🎀)

🌸 SYNOPSIS 🌸

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

🦋 DESCRIPTION 🦋

Okay so picture this: fwknop runs a whole authorization scheme called Single Packet Authorization (SPA) and it exists purely so your services can be strongly concealed. We're talking one (1) single packet. It's encrypted, it's non-replayable, and it's authenticated via an HMAC, and that one lil packet is how you tell a service sitting behind a firewall in a default-drop filtering stance that you'd like in, please 🙏

The main character application of SPA? Using a firewall to drop all attempts to connect to stuff like SSH, which makes exploiting vulnerabilities (both 0-day and unpatched code, yikes 😭) way harder. And here's the slay: any service concealed by SPA naturally cannot be scanned for with Nmap. Periodt. 🛡️

The fwknop project natively supports four different firewalls: iptables, firewalld, PF, and ipfw, across Linux, OpenBSD, FreeBSD, and Mac OS X. There's also support for custom scripts, so you can make fwknop support other infrastructure like ipset or nftables. Versatile icon behavior ✨

SPA is essentially next generation Port Knocking (PK), except it solves sooo many of the limitations PK is out here exhibiting while keeping its core benefits. Like, PK's limitations include:

  • it's generally difficult to protect 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 limitations are solved by SPA. Meanwhile 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. No cap.

This is the manual page for the fwknop client, which is the one 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. Highly recommend you read the fwknopd(8) manual page as well, bestie — it's giving required reading 📚

Further detailed information may be found in the tutorial "Single Packet Authorization: A Comprehensive Guide to Strong Service Concealment with fwknop", available online (see: http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html).

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 — because 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 / SHA3_256 / SHA3_512)

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. Not me catching you trying to replay 👀

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, Mac OS X, 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 v2+).

🎀 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> — Hand over 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 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 the REQUIRE_SOURCE_ADDRESS variable in the /etc/fwknop/access.conf file.

Important: note that the most secure option is -a so that fwknop does not have to issue any HTTPS request to https://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. iykyk 🫶

✨ GENERAL OPTIONS ✨

okay bestie, this is the general-options era, and there are so many little switches. let's get into it. 💅

  • -h, --help — prints a usage summary message and exits. bye bestie, but usefully. 👋
  • -G, --get-key=<file> — loads an encryption key/password from the specified file. the key file has one line for each destination hostname or IP address, then a colon (":"), then optional space, then the password, then a newline. note that the last line has to have a terminating newline character. also note: even though this is convenient, 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. and 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 — reads the encryption key/password from stdin. you can use this to send the data via a pipe, for example. this command is similar to --fd 0.
  • --fd=<number> — specifies 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> — loads 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 and authentication. 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-gen-file=<file> — writes generated keys to the specified file. note that the file is overwritten if it already exists. if this option is not given, then --key-gen writes the keys to stdout.
  • --key-len=<length> — specifies the number of bytes for a generated Rijndael key. the maximum size is currently 128 bytes.
  • --hmac-key-len=<length> — specifies the number of bytes for a generated HMAC key. the maximum size is currently 128 bytes.
  • -l, --last-cmd — executes 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> — specifies 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> — specifies 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> — specifies 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> — specifies 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> — specifies 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> — specifies the path to the fwknop rc file. default is “$HOME/.fwknoprc”.
  • --no-rc-file — performs fwknop client operations without referencing the “$HOME/.fwknoprc” file.
  • --no-home-dir — does not allow the fwknop client to look for the home directory associated with the user.
  • --save-rc-stanza=<stanza name> — saves 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 — dumps a list of the stanzas found in “$HOME/.fwknoprc”. 📋
  • --show-last — displays the last command-line arguments used by fwknop.
  • -E, --save-args-file=<file> — saves 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 — does 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> — instructs 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 — appends the generated packet data to the file specified with the -B option.
  • --fault-injection-tag=<tag> — this option is only used for fault injection testing when fwknop is compiled to support the libfiu library (see: http://blitiri.com.ar/p/libfiu/). under normal circumstances this option is not used, and any packaged version of fwknop will not have code compiled in so this capability is not enabled at run time. it is documented here for completeness.
  • -v, --verbose — runs 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 — displays version information and exits.

🔥 SPA OPTIONS 🔥

these are the options that get real specific about SPA packet behavior. main character energy only. 👑

  • --use-hmac — sets 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> — specifies an 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 https://www.cipherdyne.org/cgi-bin/myip. this returns the actual IP address it sees from the calling system. 🛡️
  • -g, --gpg-encryption — uses 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> — sets the HMAC digest algorithm for authenticated encryption of SPA packets. choices are: MD5, SHA1, SHA256 (the default), SHA384, SHA512, SHA3_256, and SHA3_512.
  • -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 — okay so normally you're out here requesting access to a specific port like tcp/22 on a box running fwknopd. But --nat-port lets you request access to that port (yes, tcp/22 again, keep up bestie) while the access gets granted through a different, specified port — so the -p argument is what you'd then use on your SSH client command line. Want the full lore on reaching services via a NAT operation? Go peep --nat-local and --nat-access. 🦋
  • --nat-rand-port — same energy as above, but make it chaotic: you request access to a particular service (yeah, tcp/22), and the access gets granted through a random translated port. So once you run the fwknop client in this mode and it shows you the random port it picked, you gotta go change the destination port your follow-on client uses to match. For SSH, that's the -p argument doing the work. Again, --nat-local and --nat-access have the extra deets on NAT-based service access. ✨
  • -p, --server-port=<port> — tell it which port fwknopd accepts packets on via libpcap or the ulogd pcap writer. Default vibe: fwknopd looks for authorization packets over UDP port 62201. 👑
  • -P, --server-proto=<protocol> — sets the protocol for the outgoing SPA packet. Your options are udp, tcp, http, udpraw, tcpraw, or icmp. Heads up: the udpraw, tcpraw, and icmp modes use raw sockets, so they require root access to run, no cap. Also: tcp mode expects to establish a TCP connection to the server before sending the SPA packet. That's not normally done, but it's useful for compatibility with Tor for strong anonymity — see http://tor.eff.org/. In that case your fwknopd server needs to be configured to listen on the target TCP port (which is 62201 by default). 🧚
  • -Q, --spoof-src=<IP> — spoof the source address the fwknop client sends SPA packets from. This needs root on the client side since a raw socket is required to pull it off. Ngl, in this mode you can also pass the --spoof-user argument to satisfy any REQUIRE_USERNAME keyword that might be sitting in /etc/fwknop/access.conf. 💅
  • -r, --rand-port — tells the fwknop client to send an SPA packet over a random destination port between 10,000 and 65535. Your fwknopd server must use a PCAP_FILTER variable configured to accept those packets. For example, PCAP_FILTER could be set to udp dst portrange 10000-65535. 🔥
  • -R, --resolve-ip-https — this one's important, bestie. It tells the fwknop client to fire an HTTPS request at a script running on cipherdyne.org that returns the client's IP address (as the web server sees it). Sometimes you need this to figure out which IP address should be allowed through the firewall policy on the remote fwknopd side. It's a lifesaver when your fwknop client is behind some obscure NAT address and the external internet-facing IP is a mystery to the user. The full resolution URL is https://www.cipherdyne.org/cgi-bin/myip, and fwknop hits it via wget in --secure-protocol mode. But ngl, it's generally more secure to use -a if the externally routable IP address for the client is already known to the user, since that skips the whole HTTPS request thing entirely. 🌸
  • --resolve-url <url> — override the default URL used for resolving the source IP address. For best results, point this at a web service that returns just an IP address in the body of the HTTP response. Keep it clean, keep it simple. ✨
  • --resolve-http-only — forces the fwknop client to resolve the external IP via HTTP instead of HTTPS. There are some circumstances where this might be necessary, like when wget isn't available (or wasn't compiled with SSL support), but generally this is not recommended since it opens up the possibility of a MITM attack through manipulation of the IP resolution HTTP response. Either specify the IP manually with -a, or use -R and omit this option. Periodt. 💀
  • -w, --wget-cmd=<wget full path> — manually set the full path to the wget command. Normally the configure script finds wget for you, but this option exists for when it's chilling in a non-standard place. 🎀
  • -s, --source-ip — tells the fwknop client to form an SPA packet containing the special-case IP address 0.0.0.0, which informs the destination fwknopd SPA server to use the source IP address the SPA packet originates from as the IP that gets allowed through once the firewall ruleset is modified. Useful if your fwknop client is deployed on a machine behind a NAT device and the external IP is unknown. However, usage of this option is not recommended — use either -a or -R instead. Also note: the permit-address options -s, -R and -a are mutually exclusive, so pick one and commit. 👑
  • -S, --source-port=<port> — set the source port for the outgoing SPA packet. That's it, that's the vibe. 💖
  • --server-resolve-ipv4 — forces the fwknop client to only accept an IPv4 address from DNS when a hostname is used for the SPA server. Necessary in some cases where DNS is being messy and returning both IPv6 and IPv4 addresses. 🙈
  • -f, --fw-timeout=<seconds> — specifies how long (in seconds) the remote firewall rule granting access to a service stays active. The default maintained by fwknopd is 30 seconds, but any established connection can be kept open after the initial accept rule is deleted, thanks to a connection tracking mechanism that your firewall may offer. 🌈
  • -C, --server-cmd=<command to execute> — instead of requesting access to a service with an SPA packet, this specifies a command that the fwknopd server will execute. The command is encrypted inside the SPA packet and sniffed off the wire (as usual, bestie) by fwknopd. 🔥
  • -H, --http-proxy=<proxy-host>[:port] — specify an HTTP proxy the fwknop client will use to send the SPA packet through. Using this option automatically sets the SPA packet transmission mode (usually set via --server-proto) to http. You can also specify the proxy port by tacking :<port> onto the proxy host name or ip. 🦋
  • -m, --digest-type=<digest> — pick the message digest algorithm used in the SPA data. Choices are: MD5, SHA1, SHA256 (the default), SHA384, and SHA512, SHA3_256, and SHA3_512. 💅
  • -M, --encryption-mode=<mode> — specify the encryption mode when AES is used for encrypting SPA packets. Default is CBC mode, but you can choose others like CFB or OFB — as long as that's also specified in /etc/fwknop/access.conf on the server side via the ENCRYPTION_MODE variable. In general, it's recommended to not include this argument and just let the default (CBC) do its thing. Also: you can pass the string legacy to generate SPA packets with the old initialization vector strategy used by fwknop versions prior to 2.5. With the 2.5 release, fwknop generates initialization vectors in a manner 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 inside each SPA packet as a time stamp, validated by the fwknopd server after decryption. But sometimes the clocks are out of sync and the user on the client system doesn't have the access needed to change the local clock setting, which makes it lowkey hard to construct an SPA packet with a time stamp the server will accept. Enter --time-offset-plus, which lets you specify an offset (like 60sec, 60min, 2days, etc.) that gets added to the local time. ⭐
  • --time-offset-minus=<time> — same as --time-offset-plus above, but it subtracts the specified time offset instead of adding it to the local time stamp. Symmetry, we love her. ✨
  • -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. 🎀
  • --use-wget-user-agent — by default, when the fwknop client resolves the external IP with wget via SSL, it sets the User-Agent to Fwknop/<version> unless it was already manually specified with the --user-agent option mentioned above. However, the --user-wget-user-agent option lets the default wget User-Agent string apply, without any influence from fwknop. 🫶
  • -U, --spoof-user=<user> — specify the username that gets included within the SPA packet. This lets the fwknop client satisfy any non-root REQUIRE_USERNAME keyword on the fwknopd server (and psst: --spoof-src mode requires the fwknop client to be executed as root). 👑
  • --icmp-type=<type> — in -P icmp mode, specify the ICMP type value that gets 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 gets set in the SPA packet ICMP header. The default is zero. 🌸

🔐 GPG OPTIONS 🔐

okay bestie listen up, because this part is important 💖 First things first: using GPG for SPA encryption/decryption can and should involve GPG keys that are signed by each side (client and server, both of them, no skipping 💅). The basic procedure for this, after the client key has been transferred to the server and vice-versa, goes like this:

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

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

If you want the full lore, more comprehensive info lives here: http://www.cipherdyne.org/fwknop/docs/gpghowto.html.

  • --gpg-agent — tells fwknop to go get the GnuPG key password from a running gpg-agent instance (if one is available, that is 🧚).
  • --gpg-home-dir=<dir> — point fwknop at the path to the GnuPG directory. Normally this path gets derived from the home directory of whoever's running the fwknop client (so the default is ~/.gnupg). This is lowkey a lifesaver when a "root" user wants 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 (peep the output of gpg --list-keys), or the key name (the associated email address) of the recipient of the Single Packet Authorization message. The fwknopd server imports this key and the associated private key is what decrypts the SPA packet. Heads up though: the recipient's key has to be imported into the client GnuPG key ring first 👑.
  • --gpg-signer-key=<key ID or Name> — specify the GnuPG key ID, e.g. ABCD1234 (again, see the output of gpg --list-keys), or the key name to use when signing the SPA message. You'll get prompted for the associated GnuPG password so the signature can be created. This is the glow-up that adds a cryptographically strong mechanism letting the fwknopd daemon on the remote server authenticate who created the SPA message 🔥.
  • --gpg-no-signing-pw — tells fwknop to not acquire a passphrase for usage of the GnuPG signing key. This option exists 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. Buuut it is usually better to leverage gpg-agent instead of using this option, fr fr 🙈.

📁 FWKNOPRC FILE 📁

The .fwknoprc file is what you use to set various parameters that override default program parameters at runtime. It also lets you make additional named configuration stanzas for setting program parameters for a particular invocation 🎀.

The fwknop client will create this file if it doesn't already exist in the user's home directory. This initial version has some sample directives that are commented out, and it is up to you, the user, to edit this file to meet your 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 — command line stays undefeated, periodt 💅.

There are directives to match most of the command-line parameters fwknop supports. Here's 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 used for SPA packet encryption, and it applies to both Rijndael or GPG encryption modes. The actual encryption key 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 is how you sneak non-ascii characters into the base64-decoded key ✨.
  • USE_HMAC <Y/N> — set HMAC mode for authenticated encryption of SPA packets. This makes 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. Again: non-ascii characters, base64-decoded key, you know the vibe 💜.
  • 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, SHA512, SHA3_256, and SHA3_512.
  • 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_IP_HTTPS <Y/N> — set to Y to automatically resolve the externally routable IP associated with the fwknop client. This is done over SSL via wget in --secure-protocol mode against the IP resolution service available at https://www.cipherdyne.org/cgi-bin/myip 🦋.
  • RESOLVE_HTTP_ONLY <Y/N> — when the fwknop client is instructed to resolve the external client IP, this option can be used to force an HTTP connection instead of an HTTPS connection when set to Y. Super handy when wget isn't installed on the local OS, or when it isn't compiled against an SSL library.
  • RESOLVE_URL <url> — set to a URL that will be used for resolving the source IP address (--resolve-url).
  • WGET_CMD <wget full path> — set the full path to the wget command (used for client IP resolution).
  • 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's recommended to not include this argument and just 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, SHA512, SHA3_256, and SHA3_512.
  • 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). The agent information itself is specified with the GPG_AGENT_INFO environmental variable.
  • GPG_SIGNING_PW <passphrase> — this is the passphrase used for signing SPA packet data in GPG encryption mode, and it's 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. Yes, non-ascii characters in the base64-decoded key, you already know 🌸.
  • 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.
  • GPG_EXE <path> — specify the path to GPG (--gpg-exe). Defaults to /usr/bin/gpg.
  • 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).
  • USE_WGET_USER_AGENT <Y/N> — allow the default wget User-Agent string to be used when resolving the external IP instead of a User-Agent supplied by the fwknop client.
  • 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)

that's the whole env lineup bestie, short and sweet 🫶

💀 SPA PACKET SPOOFING 💀

okay so here's the tea bestie: fwknop tucks the IP that's supposed to get through the firewall inside the encrypted SPA payload — unless you use -s, which is not recommended and can even be straight-up prohibited in the fwknopd server config. so because of that, SPA packets can be spoofed super easily, and in this context that's actually iconic. 💅

fr fr: the source IP of an SPA packet gets ignored by the fwknopd daemon (when the REQUIRE_SOURCE_ADDRESS variable is set in the /etc/fwknop/access.conf file) and the only IP that gets granted firewall access is the one sitting inside an authenticated and properly decrypted SPA packet. so you can make it look like, say, www.yahoo.com is trying to authenticate to a target system, when actually the real connection is coming from some seemingly unrelated IP. main character energy honestly. 👑

✨ EXAMPLES ✨

here's what the command line args could look like in a few situations, bestie:

🌸 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, then save them to the "$HOME/.fwknoprc" file along with your access request specifics. you'll also need to transfer those keys over to the system where fwknopd is running. and the client supports a separate set of encryption and HMAC keys for each SPA destination if you've got multiple fwknopd servers running on different systems. 🦋

so, assuming 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, do this via some secure means such as SSH before SPA is enabled and SSHD is blocked by the firewall. here's 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_HTTPS            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 that's 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 like in the "$HOME/.fwknoprc" file case above. but you can convert all of the following examples to use 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 gets added to the command line, then some SPA packet specifics get 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 — here's 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 so many cases where an fwknop client is deployed on a network behind a NAT device and the externally routable IP is just... not known to the user. 😭 in that case, use the IP resolution service available at https://www.cipherdyne.org/cgi-bin/myip via the -R command line switch to derive the external client IP address. this is a safer way of acquiring the client IP address than using the -s option mentioned earlier in this manual page, because the source IP gets 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's possible to take advantage of the NAT capabilities offered by iptables in order to transparently reach systems behind the firewall via SPA. 🌈 here's an example where the fwknop client is used to gain access to SSH running on the non-routable IP 192.168.10.23 that's 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 went through significant changes in its usage of cryptography — including adding support for HMAC authenticated encryption for both Rijndael and GnuPG modes, making sure PBKDF1 is used properly for key derivation when SPA packets are encrypted with Rijndael, and fixing several bugs from previous versions of fwknop. ✨

in general, this means 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. but even when 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. that 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).

heads up bestie: HMAC is only supported as of 2.5 and it's 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 exists 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 can't 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 motivation 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 🧩

okay so bestie, here's the tea on what fwknop needs to actually function 💅

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. So like, you don't have to go hunting for it, it usually just shows up with the rest of the package ✨

Whenever the fwknopd server is used, libpcap is a required dependency. required, bestie, not optional 🙈

But!! the upcoming 2.6 release will offer a UDP listener mode along with privilege separation support, and will not require libpcap in this mode. slay.

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. no gpgme, no gpg vibes, that's just how it is 🎀

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. pick your fighter 🔥

🩺 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. She's thorough, okay?

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. and fwknop in version 2.6.4 supports the American Fuzzy Lop (AFL) from Michal Zalewski as well 🌈 (fuzzing? in my SPA implementation? it's more likely than you think)

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. a little round trip just to prove she works 💖

In addition, the --verbose command line switch is useful to see various SPA packet specifics printed to stdout. turn it on, watch the magic, be obsessed ⭐

👀 SEE ALSO 👀

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. (spoiler: she's different because she's her 💅)

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 👑

The primary developers of fwknop are:

  • Michael Rash (project creator) <mbr@cipherdyne.org>
  • Damien Stuart <dstuart@dstuart.org>
  • Jonathan Bennett <jbennett@incomsystems.biz>

legends, honestly 🙌

💜 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 https://github.com/mrash/fwknop/blob/master/CREDITS 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. icons only, no notes 🎀

The phrase "Single Packet Authorization" was coined by MadHat and Simple Nomad at the BlackHat Briefings of 2005. history was made fr fr 💀✨

🐛 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). come say hi, we don't bite 😭

📦 DISTRIBUTION 📦

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

and that's the whole page bestie!! 💖✨🎀 this was the Fwknop Client page, dated 08/06/2018, from the FWKNOP(8) source — go forth and SPA responsibly, you absolute main character 👑🦋🌸

📦 where this page comes from