fwknopd - Portknocking der nächsten Generation

Konfiguration Client

Installieren Sie zuerst fwknop-client. Sie können ihn auf diese Art starten:

fwknop -A 'tcp/22' -a 192.168.1.10 -D 192.168.1.20

Starting fwknop client (SPA mode)...
        Enter an encryption key. This key must match a key in the file
        /etc/fwknop/access.conf on the remote system.

Encryption Key:

Building encrypted Single Packet Authorization (SPA) message...
        Packet fields:

Random data:    6576449485301062
                Username:       home
                Timestamp:      1263418373
                Version:        1.9.11
                Type:           1 (access mode)
                Access:         192.168.1.10,tcp/22
                SHA256 digest:  aw7c9mCDIq3DK+4Uy3Fn+SYU4g4S0ckK2E1dqvsGTN0

Sending 182 byte message to 192.168.1.20 over udp/62201...

Erklärung der Parameter:

-A: Hier geben Sie an, welcher Port geöffnet werden soll. Dies muss natürlich einer oder alle der OPEN_PORTS aus /etc/fwknop/access.conf sein.
-a: Dies ist Ihre lokale öffentliche IP-Adresse, von der Sie später auf den Dienst zugreifen.
-D: Server, auf dem fwknop-server läuft.

Sie werden hier auch nach dem Schlüssel gefragt, den wir in /etc/fwknop/access.conf angegeben hatten.

Die Standardkonfiguration ist, dass fwknopd den Netzwerkverkehr auf UDP-Port 62201 überwacht. Dies bedeutet nicht, dass dieser Port auch offen ist. Man kann alternativ auch den Port zufällig wahlen lassen, dazu mehr in /etc/fwknop/fwknop.conf.

Als Alternative zu -a kann man auch -R verwenden. Dies ermittelt Ihre lokale öffentliche IP-Adresse mittels whatismyip.com und packt diese in das SPA-Paket. Ich habe die Erfahrung gemacht, dass dies oft nicht funktioniert. Da ich auch DynDNS verwende, habe ich mir so beholfen, meine öffentliche IP-Adresse stattdessen mittels -a anzugeben.

Hat man alles korrekt gemacht, passiert erst einmal nichts. Schaut man allerdings auf dem Server nach, findet man:

Jan 13 21:48:25 hostname fwknopd: received valid Rijndael encrypted packet from: 192.168.1.10, remote user: home, client version: 1.9.11 (SOURCE line num: 26)
        Jan 13 21:48:25 hostname fwknopd: add FWKNOP_INPUT 192.168.1.10 -> 0.0.0.0/0(tcp/22) ACCEPT rule 30 sec

Und das iptables-Regelwerk sieht wie folgt aus:

Chain INPUT (policy ACCEPT 7807 packets, 8614K bytes)
         pkts bytes target     prot opt in     out     source               destination
          624  214K FWKNOP_INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
         1011  336K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain FWKNOP_INPUT (1 references)
         pkts bytes target     prot opt in     out     source               destination
            0     0 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:22

Das sieht gut aus. Wenn man die 30 Sekunden wartet und sich das iptables-Regelwerk nochmals anschaut, ist die Regel fuer den SSH-Zugriff verschwunden. Prima. Was will man mehr?

Man kann sich nun entweder mittels einem Shell-Alias behelfen, um den obigen fwknop-client-Befehl zu vereinfachen, man kann aber auch einfach fwknop --last-cmd eingeben, denn fwknop speichert das letzte Kommando in ~/.fwknop.run.

Verwenden von GPG-Keys - oder auch: Portknocking der Edelklasse

Als ich mir dies eingerichtet hatte, war ich erst einmal rundum glücklich. Ich brauchte mir keine Sorgen zu machen, dass SSH offen ist. Es hat einfach tadellos funktioniert, wann immer ich es brauchte. Was mich nervte, war, jedesmal diesen Schlüssel einzugeben. Ich hatte keine (sichere) Möglichkeit gefunden, dies irgendwie zu umgehen. Beim Herumstöbern bin ich dann uber das GPG-Howto gestolpert. Portknocking der Edelklasse! Hier eine freie Übersetzung dieser Seite.

Wir installieren gpg auf dem Server und erzeugen als Benutzer root einen neuen Schlüssel mit gpg --gen-key. Aus Sicherheitsgründen sollte dieser Schlüssel nur für fwknopd verwendet werden. Auf keinen Fall sollte man einen bestehenden Schlüssel verwenden, denn fwknopd benötigt das Passwort! Wählen Sie als Schlüsselgröße nur 2048 Bit oder kleiner. Dies ist nötig, weil ein SPA-Paket in einem einzigen IP-Paket Platz finden muss.

gpg --list-keys
        pub   1024D/ABCD1234 2006-05-01
        uid                  fwknop server key <fwknopd@localhost>
        sub   2048g/EFGH1234 2006-05-01
gpg -a --export ABCD1234 > server.asc

Auf dem Client kann man das gleiche machen. Falls man schon z.B. einen Schlüssel für E-Mail verwenden sollte, kann dieser auch verwendet werden. Die Schlüsselgröße ist hier beliebig.

gpg --gen-key
gpg --list-keys
        pub   1024D/1234ABCD 2006-05-01
        uid                  fwknop client key <fwknopd@localhost>
        sub   2048g/1234EFGH 2006-05-01
gpg -a --export 1234ABCD > client.asc

Nun kopiert man den öffentlichen Schlüssel vom Server zum Client (server.asc) und den öffentlichen Schlüssel vom Client zum Server (client.asc). Dann importiert und signiert man den Client-Schlüssel mit dem Serverschlüssel auf dem Server:

gpg --import client.asc
gpg --edit-key 1234ABCD
        Command> sign

Dasselbe machen wir auf dem Client, nur umgekehrt:

gpg --import server.asc
gpg --edit-key ABCD1234
        Command> sign

Nun müssen wir auf dem Server /etc/fwknop/access.conf modifizieren:

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;

Der Server-Schlüssel ist ABCD1234 und der Client-Schlüssel ist 1234ABCD. fwknopd muss auf den privaten Schlüssel zugreifen, daher muss man hier das Passwort angeben. Ich erspare mir das, denn ich bin der Meinung, es bringt keinen Sicherheitsvorteil.

Wenn man nun vom Client mittels

fwknop -A tcp/22 --gpg-recip ABCD1234 --gpg-sign 1234ABCD -a 192.168.1.10 -D 192.168.1.20

das mit GPG verschlüsselte und signierte SPA-Paket sendet, wird man mit

Jan 13 20:12:37 hostname fwknopd: adding FWKNOP_INPUT ACCEPT rule for 192.168.1.10 -> tcp/22 (10 seconds)
        Jan 13 10:13:09 hostname fwknopd: received valid GnuPG encrypted packet (signed with required key ID: 1234ABCD) from: 192.168.1.10, remote user: home

begrüßt.

Mehrere GPG-Clients

Wenn man von mehreren Rechnern zum gleichen Server SPA verwenden möchte, verfährt man für jeden Client wie oben beschrieben. Die Datei /etc/fwknop/access.conf sieht dann ein bisschen anders aus:

GPG_REMOTE_ID: 1234ABCD,4321ABCD;

Windows als fwknop-Client

Es gibt auch einen einfachen Windows-Client für fwknop.

Wenn man das obige verstanden hat, dürfte dieser Client kein Problem darstellen. Als Anmerkung möchte ich erwähnen, dass mit »PGP Private Key« der private Schlüssel des Clients gemeint ist, »PGP Public Key« dagegen den öffentlichen Schlüssel des Servers bezeichnet. Man kann auf der GPG-Webseite auch einen Kommandozeilen-Client für GPG herunterladen, der seinen Zweck erfüllt.

Debugging

Sollte es »einfach nicht funktionieren« wollen, kann es helfen, fwknopd im Debugging-Modus auszuführen.

/etc/init.d/fwknop-server stop
/usr/sbin/fwknopd -d

Schlusswort

Nun kann ich wieder ruhig schlafen. Ich brauche mir keine Sorgen um SSH-Brute-Force-Attacken mehr zu machen, denn die Firewall erlaubt einfach keinen Zugriff. So kann ich einfach jeden Dienst abschotten, der nicht für die Allgemeinheit bestimmt ist.

Und Portknocking mit GPG-verschlüsselten und signierten Paketen hat nicht jeder - allerdings hoffe ich, es werden jetzt einige mehr.