cipherdyne.org

Michael Rash, Security Researcher



Single Packet Authorization with GnuPG Keys

If you want to use GnuPG to encrypt communications from the fwknop client to the fwknopd server, you will need to first create the necessary GnuPG keys on both the client and server. If you already have a GnuPG key that you use for email (or other) encryption, you can safely use this key on the client side since it will only be used for message signing by fwknop. On the fwknopd server you will need to create a special GnuPG key that is exclusively used for fwknop communications. The reason stems from the fact that the password used to unlock this key must be stored within the /etc/fwknop/access.conf file; fwknopd must be able to decrypt messages that have been encrypted by an fwknop client with the server's public key. Hence, it is not a good idea to use a highly valuable personal GnuPG key on the server. Once you have created the requisite keys, you will need to import and sign each key into its "opposite" system; e.g. import and sign the server key into the client's GnuPG key ring, and vice-versa.

Note

Because SPA messages must fit within a single IP packet, it is recommended to choose a key size of 2048 bits or less for the fwknopd server GnuPG key.

The process of generating the necessary GnuPG keys from the perspectives of both the client and server is outlined below. First we generate GnuPG keys and then export them to ascii files: 
[spaserver]# gpg --gen-key
[spaserver]# gpg --list-keys
pub   1024D/ABCD1234 2006-05-01
uid                  fwknop server key <fwknopd@localhost>
sub   2048g/EFGH1234 2006-05-01
[spaserver]#  gpg -a --export ABCD1234 > server.asc

[spaclient]$ gpg --gen-key
[spaclient]$ gpg --list-keys
pub   1024D/1234ABCD 2006-05-01
uid                  fwknop client key <fwknopd@localhost>
sub   2048g/1234EFGH 2006-05-01
[spaclient]$ gpg -a --export 1234ABCD > client.asc
Next, we transfer the ascii files between the two systems. In this example we use scp (which will presumably be firewalled off after fwknop is deployed!), but any other transfer mechanism (ftp, http, etc.) will work: 
[spaclient]$ scp client.asc root@serverhost:

[spaserver]# scp server.asc user@clienthost:
Now we import and sign each key: 
[spaserver]# gpg --import client.asc
[spaserver]# gpg --edit-key 1234ABCD
Command> sign

[spaclient]$ gpg --import server.asc
[spaclient]$ gpg --edit-key ABCD1234
Command> sign
On the server side, we need to add several configuration directives to the /etc/fwknop/access.conf file so that fwknopd uses GnuPG to verify and decrypt SPA packets and are signed and encrypted with GnuPG. Note that the server key ID is ABCD1234 and the client key ID is 1234ABCD: 
SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_REMOTE_ID: 1234ABCD;
GPG_DECRYPT_ID: ABCD1234;
GPG_DECRYPT_PW: <your decryption password>;
GPG_HOME_DIR: /root/.gnupg;
FW_ACCESS_TIMEOUT: 60;
More information on the access.conf directives above can be found in the fwknop man pages. See fwknop(8) and fwknopd(8).

Finally, to see fwknop in action in GnuPG mode, on the client side we execute the following fwknop command to gain access to sshd after fwknopd reconfigures the local Netfilter policy. First we show that nmap is unable to tell that sshd is even listening: 
[scanner]$ nmap -p 22 -n <host>

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2007-01-06 10:21 EST
Interesting ports on 71.127.x.x
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap finished: 1 IP address (1 host up) scanned in 10.316 seconds
Now, to gain access to sshd, we execute fwknop: 
[spaclient]$ fwknop -A tcp/22 --gpg-recip ABCD1234 --gpg-sign 1234ABCD \
-R -D <host>
[spaclient]$ ssh -l mbr <host>
mbr@host's password:
On the server side, fwknopd messages such as the following will be written to syslog: 
Jan 14 20:12:37 host fwknopd: adding FWKNOP_INPUT ACCEPT rule for
72.x.x.x -> tcp/22 (10 seconds)
Jan 15 10:13:09 host fwknopd: received valid GnuPG encrypted packet
(signed with required key ID: 1234ABCD) from: 72.x.x.x, remote user: mbr