Every SPA packet is constructed according to a well-defined set of rules. These rules allow the fwknop server to be confident about the type of access that is being requested through the iptables firewall and who is requesting it. After accepting user input from the fwknop client command line (see "SPA via Symmetric Encryption" on page 244 and "SPA via Asymmetric Encryption" on page 246), each SPA packet contains the following:
Random data (16 bytes) This provides enough random information to ensure that every SPA packet fwknop generates is unique—at least, the packets are unique to the degree of randomness that the Perl function rand() is able to conjure with each invocation. (For Perl versions 5.004 and later, the srand() function is called implicitly at the first utilization of the rand() function.)
Username This is the name of the user that is executing the fwknop command, as returned by getlogin()—or getpwuid() if getlogin() fails. The fwknop server uses this username to determine whether the remote user is authorized to gain access to a service or run a command. (Note that by the time the fwknop server sees the username, the SPA packet has been successfully decrypted, which implies that the SPA packet has been authenticated and the process of verifying authorization can begin.)
Timestamp This is the timestamp on the local system. The fwknop server uses this value to determine whether the SPA packet falls within the timed access window defined by the MAX_SPA_PACKET_AGE variable.
Software version This is the version of the fwknop client:
[[email protected] ~]$ fwknop --Version [+] fwknop v1.8.1 (file revision: 694)
by Michael Rash <[email protected]>
For example, the software version field in this case would contain the value 1.0. The fwknop server uses this information to maintain backward compatibility with older clients if the SPA packet format changes.
Mode This tells the fwknop server whether or not the SPA client wishes to run a command. The default value is 1 for access mode; command mode is denoted by 0.
Access directive This string tells the fwknop server which type of traffic the client wishes to have accepted by the iptables firewall when the policy is modified. The fwknop server parses this string for ports and protocols to instruct iptables to accept, and the policy is reconfigured accordingly. For example, if the client wishes to access both TCP port 22 and UDP port 1194 (which is used by OpenVPN), the string would be client IP,tcp/22,udp/1194. The fwknop server controls whether or not users can request to open specific ports. If only certain ports are allowed to be opened, they must be defined within the access.conf file. (For more information, see "OPEN_PORTS" and "PERMIT_CLIENT_PORTS" on page 238.)
Command string This string is a full command that the fwknop client would like to execute on the server; for example, /etc/init.d/apache2 restart or w |mail -s "w output" [email protected]. This feature can open the fwknop server to a security risk if it is not used wisely, and it is disabled by default. (For more information, see "ENABLE_CMD_EXEC" and "CMD_REGEX" on page 238.)
Packet MD5 sum This MD5 sum is calculated by the fwknop client and is included within the SPA packet for an added degree of confidence that the packet has not been altered while en route over the network. Normally, the encryption algorithm itself provides adequate security, because decrypting altered ciphertext does not normally result in valid plaintext; however, including the MD5 sum allows the fwknop server to independently agree that the data the client received is what the server actually receives.
Server authentication method The fwknop 0.9.6 release added this field to the packet format to allow the fwknop server to require an additional authentication parameter in the SPA packet. For example, the server may require the remote fwknop client to enter the local user's crypt() password. In this case, the authentication method string would be something like crypt, password.
Before SPA packets are encrypted and sent, by default, over UDP port 62201, the fields discussed above are Base64-encoded and then concatenated with colons. This encoding ensures that the colon delimiters remain unique, even across fields that may have contained colons before the encoding. When you combine all these fields without Base64 encoding, you get something like this:
Once you Base64-encode the individual fields, you get this:
Finally, the packet data is encrypted either with the Rijndael symmetric cipher or an asymmetric cipher supported by GnuPG (the Elgamal asymmetric cipher is used by GnuPG by default). If you encrypt with Rijndael, this is the result:
Every SPA packet is encrypted and decrypted with either a symmetric-key cipher or an asymmetric-key cipher. A symmetric-key cipher is an algorithm that encrypts and decrypts data using the same key (hence the symmetric designation). The Rijndael cipher, which has been selected as the Advanced Encryption Standard (AES), is an important example of a symmetric-key cipher. An asymmetric-key cipher, on the other hand, is an algorithm that encrypts and decrypts data with a pair of keys: the public key, which is published publicly, and the private key, which is kept secret. The two keys are related via a mathematical conundrum, but they are not identical (hence the asymmetric designation).
Was this article helpful?