SSH absichern durch Portknocking (knockd)

  • Thread starter Thread starter derOli
  • Start date Start date
D

derOli

Guest
Hallo zusammen.

Am Wochenende habe ich versucht die Sicherheit meines Servers durch die Installation eines Portknockers zu erhöhen. Die Installation an sich war nicht schwierig. Allerdings habe ich einige Zeit damit verbracht einen brauchbaren und einfach zu verwendenen Client für Windows zu finden.
Damit der nächste nicht ähnlich lange suchen muss, möchte die kurz auf die notwendigen Schritte eingehen. Die folgenden Schritte beziehen sich auf die Installation unter Debian Wheezy.

Grund der Absicherung per knockd

Aktuell wird mein Server durch fail2ban geschützt. Die Anmeldung per SSH als Root ist deaktiviert. Ebenso ist eine Anmeldung nur per private-key möglich. Dennoch laufen zahlreiche "Attacken" auf Port 22. Ein Verlegen des Ports würde hier sicherlich Abhilfe schaffen. Allerdings gibt es persönliche Gründe die dagegen sprechen. Daher habe ich mich für die Installation des knockd entschieden.

Vorteile von knockd

Der entsprechende SSH-Port kann durchgehend geschlossen bleiben. Nur dann, wenn eine Verbindung erforderlich ist, wird eine Ausnahme-Regel für den entsprechenden Client auf der Firewall generiert. Der entsprechende SSH-Port ist also nur temporär, für eine bestimmte IP zugänglich.


1. Installieren des knockd
Code:
aptitude update
aptitude upgrade
aptitude install knockd

2. Konfiguration von knockd

Das Config-File enthält nach der Installation eine Beispiel-Konfiguration für den SSH-Server. Sequence definiert die Ports und deren Reihenfolge, an die "angeklopft" werden muss, damit die damit verbundene Aktion (command) ausgeführt wird.

[openSSH] erstellt eine Regel per iptables, welche es dem "klopfenden" Client erlaubt, eine Verbindung zum SSH-Server auf Port 22 herzustellen.

"Klopft" der Client entsprechend der in [closeSSH] definierten Sequence, so wird die zuvor erstellte Regel wieder gelöscht, sodass der entsprechende Port wieder komplett geschlossen ist.

Wichtig: Ports, welche in der Sequence zum öffnen genannt werden, sollten nicht in der Sequence genannt werden, welche den Port wieder schließt und umgekehrt. Wird z.B. in der Sequence von [closeSSH] ebenfalls der Port 5000 angesprochen führt dies dazu, dass das "Klopfen" auf Port 5000 als Anfang der Sequence für [openSSH] interpretiert wird. [closeSSH] wird somit nicht ausgelöst.

Code:
root@wheezy:~# nano /etc/knockd.conf

[options]
        logfile = /var/log/knockd.log

[openSSH]
        sequence    = 5000, 6000, 7000, 8000
        seq_timeout = 5
        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000, 10000, 11000, 12000
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

3. Neustart des knockd

Nachdem die Konfigurations-Datei entsprechend angepasst wurde muss der Dienst neugestartet werden.

Code:
service knockd restart

4. Portknocking-Client für Windows

Bemüth man Google auf der Suche nach einem Portknocking-Client für Windows, so finden sich einige mehr oder weniger brauchbare Varianten.
Ich selbst finde den Client von http://www.zeroflux.org/projects/knock sehr gelungen und einfach zu handhaben. Die Windows-Variante kann unter http://www.zeroflux.org/proj/knock/files/knock-win32.zip heruntergeladen werden.

Nach dem entpacken befindet sich im Ordner "Release" eine Datei namens "knock.exe". Diese kann wie folgt verwendet werden.

Code:
knock.exe [options] <host> <port[:protocol]> <port[:protocol]>

Damit die einzelnen Ports nicht jedesmal neu eingegeben werden müssen, habe ich mir zwei batch-files erstellt, welche die entsprechenden Informationen beinhalten.

Code:
[B]openSSH.bat[/B]
knock.exe deine-server-ip 5000:tcp 6000:tcp 7000:tcp 8000:tcp

[B]closeSSH.bat[/B]
knock.exe deine-server-ip 9000:tcp 10000:tcp 11000:tcp 12000:tcp

Alternativ zu zwei einzelnen batch-files kan auch ein batch-file erstellt werden, welches sowohl die Sequenze zum Öffnen und Schließen beinhaltet. Zwischen beiden Sequenzen wird Putty gestartet.

Code:
knock.exe deine-server-ip 5000:tcp 6000:tcp 7000:tcp 8000:tcp
start /w putty
knock.exe deine-server-ip 9000:tcp 10000:tcp 11000:tcp 12000:tcp

5. Konfiguration der Firewall

Abschließend sollte erwähnt werden dass die ganze Maßnahme nur Sinn ergibt, wenn Anfragen auf dem SSH-Port per Default-Policy oder Regel verworfen werden. Ist dies nicht der Fall bringt auch der knockd nicht den gewünschten Effekt, da der Port ohnehin offen steht.
In meinem Beispiel sieht die Konfiguration der IP-Tables wie folgt aus:

Code:
hain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Konstruktive Kritik und Verbesserungsvorschläge sind gerne gesehen. :)

Es grüßt
derOli
 
Last edited by a moderator:
Vielleicht kannst Du das Howto ja noch in das Wiki vom Forum packen, dann passiert dort auch mal wieder was :)
 
Ich würde die zwei Batchdateien komibineren, und nachdem Putty geschlossen wurde den Port schließen.
Code:
knock.exe deine-server-ip 5000:tcp 6000:tcp 7000:tcp 8000:tcp
putty.exe
knock.exe deine-server-ip 9000:tcp 10000:tcp 11000:tcp 12000:tcp
 
Arbeitet windows das nicht parallel ab? Ich meinte, der letzte command wird ausgeführt, auch wenn PuTTY noch offen ist.
 
Arbeitet windows das nicht parallel ab? Ich meinte, der letzte command wird ausgeführt, auch wenn PuTTY noch offen ist.

Ja, die Abarbeitung erfolgt hier im direkten Ablauf. Der Port ist also wieder zu bevor man sich verbinden konnte.

Code:
knock.exe deine-server-ip 5000:tcp 6000:tcp 7000:tcp 8000:tcp
start /w putty.exe
knock.exe deine-server-ip 9000:tcp 10000:tcp 11000:tcp 12000:tcp

So würde es klappen.
 
verbesserungsvorschlag

Hey zusammen,

ich habe auch einen knockd, der mir die SSH-Tür öffnet.

Ich habe das allerdings so gemacht, das alle SYN Packete standardmäßig gedropped werden. Also ein Verbindungsaufbau nicht erfolgen kann.
Code:
iptables -A ssh -p tcp --dport 22 --syn -j DROP -d 123.456.789.123 -m comment --comment "SSH: DROP syn for knockd"

ipables -nL ssh
[...]
DROP       tcp  --  0.0.0.0/0            123.456.789.123       tcp dpt:22 flags:0x17/0x02 /* SSH: DROP syn for knockd */

Dieser wird dann für eine gewisse zeit (bei mir 30 Sekunden) offen geschaltet, so dass ich mich mit MEINER IP verbinden kann.


knockd.conf:
Code:
[opencloseSSH]
        sequence    = 3,1,33,73
        seq_timeout = 10
        start_command     = /sbin/iptables -I INPUT -s %IP% -d 123.456.789.123 -p tcp --dport 22 --syn -j ACCEPT -m comment --comment "Knockd: 30 sec SSH for %IP%"
        cmd_timeout = 30
        stop_command     = /sbin/iptables -D INPUT -s %IP% -d 123.456.789.123 -p tcp --dport 22 --syn -j ACCEPT -m comment --comment "Knockd: 30 sec SSH for %IP%"
        tcpflags    = syn

Also 30 Sekunden zum einloggen, reichen mir dicke (mit SSH-Key und One-Time-Password :) )
Danach ist ein Verbindungsaufbau nicht mehr möglich. Bestehende Verbindungen werden aber erhalten.
So ist nicht während meiner gesamten PuTTY-Session ein Verbindungsaufbau von der IP möglich.

Ich weiß diese Lösung ist noch ein bissel Paranoider als deine, aber hey :)

MfG

Relynapmoc,

immer wieder gerne für Paranoide Absicherungen zu haben :-)
 
Last edited by a moderator:
Das mit dem Einmalkennwort finde ich gut. Hast du hierfür ein paar Informationen womit man das umsetzen kann?

Gruss
Sven
 
Portknocking halte ich für übertrieben. Authentifizierung per Passwort abschalten und Keys benutzen reicht vollkommen aus.
 
Portknocking halte ich für übertrieben. Authentifizierung per Passwort abschalten und Keys benutzen reicht vollkommen aus.
Geht mir generell ähnlich, aber ich denke schon, dass das Sicherheitsvorteile bringen kann. Muss aber halt auch nicht. Mir persönlich wäre (ist) der Aufwand zu groß für sowas.
 
Portknocking halte ich für übertrieben. Authentifizierung per Passwort abschalten und Keys benutzen reicht vollkommen aus.

Ich würde sagen, Portknocking bringt in erster Linie Vorteile, wenn der ssh-daemon durch einen Exploit angreifbar wird. Dann ist er bei Portknocking gar nicht erst zu erreichen.

Ich setze es allerdings auch nicht ein. Habe SSH auf nem anderen Port, was einen ähnlichen Effekt hat, wenn man Portscans auf die Kiste verhindert.
 
Portknocking verhindert zum einen, dass man gar nicht erst an den SSH Deamon ran kommt somit ggf. denken könnte, das gar kein SSH läuft, bzw. nur für bestimmte IPs zugänglich ist, weitere Angriffsversuche werden dann schnell wirkungslos.
Zum Anderen müllt es die Logs nicht so zu wie als wenn der port komplett offen wäre (selbst wenn der SSH-Port umgelegt wurde).
Somit ist eine schnellere Erkennung von ungebetenen besuchern bzw. Loginversuchen schneller und genauer zu erkennen...
 
Knockd ist aber auch ein zusätzlicher Dienst, der somit auch ein neues, potentielles Sicherheitsrisiko darstellt. Dazu besteht das Risiko, dass man sich damit selbst aussperrt.

SSH ist wohl der mit Abstand sicherste Dienst. Key-Access-only mit 4096bit-Schlüsseln und zusätzlicher Passphrase gilt nach aktuellem Stand der Technik und menschlichem Ermessen als sicher.

Auch Knockd fällt für mich in die Kategorie Snake Oil. Wenn ich SSH zusätzlich schützen möchte, dann doch lieber via VPN.
 
Wie schützt du denn dein SSH vor Bots, die 100 Logins in der Sekunde versuchen? Fällt dann fail2ban auch in die Kategorie snake oil?
 
ssh Port verlegen. Seit Jahren habe ich keine zugemüllte Logs mehr.

Das Verlegen des SSH-Ports schafft ohne Zweifel schon eine gewisse Abhilfe. Ausgehend vom Eröffnungspost und anhand meines Beispiels ist/war das verlegen des SSH-Ports aber nicht möglich. Anosten stimme ich dir voll und ganz zu.
 
Vielleicht kannst Du das Howto ja noch in das Wiki vom Forum packen, dann passiert dort auch mal wieder was :)

Habe ich dann nach einigen Wochen auch endlich mal gemacht. Post steht somit auch im Wiki und beinhaltet auch die eine oder andere Anregung aus der hier geführten Diskussion. :)
 
Wie schützt du denn dein SSH vor Bots, die 100 Logins in der Sekunde versuchen?
Die versuchen ausschliesslich Logins per user/pass, also muss man sich darüber bei public-key-auth keinerlei Gedanken machen.

Fällt dann fail2ban auch in die Kategorie snake oil?
Ganz klares ja!
Ich lege so gar Einen drauf und stufe f2b und Co als nahezu perfekte Lösung für einen Self-DoS ein.
 
Back
Top