Skip to content

Port Knocking für ssh

ixs berichtet über eine neue mögliche aus der Ferne ausnutzbare Schwachstelle in OpenSSH, und ich nutze die Gelegenheit, für etwas Forschung im Bereich Port Knocking.

Port Knocking ist eine Technik, bei der ein auf einem System im Internet laufender Dienst erst dann für die IP-Adresse eines Clients sichtbar wird, wenn dieser Client vorher eine Folge von vorab festgelegten Paketen an den Host geschickt hat. Das ganze ist natürlich eine Art Security by Obscurity, und ähnelt den Mechanismen von Geheimdiensten, bei denen man erst vom Agenten angesprochen wird, wenn man sich zuerst in der Nase gebohrt, dann die Brille zurechtgerückt und schließlich etwas vom Boden aufgehoben hat.

Eine kurze Suche im Debian-Archiv fördert die Package knockd zu Tage, die einen Daemon und einen Client enthält, mit dem man Port Knocking umsetzen kann. Mit einer schön einfachen konfiguration kann man den knockd dazu veranlassen, nach Empfang gewisser Pakete bestimmte Kommandos auszuführen. Hier ein Beispiel:

[opencloseSSH]
        sequence         = 1234:udp,8765:tcp,54321:tcp
        seq_timeout      = 5
        start_command    = /sbin/iptables --append dynamic -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags         = syn
        cmd_timeout      = 60
        stop_command     = /sbin/iptables --delete dynamic -s %IP% -p tcp --dport 22 -j ACCEPT

In diesem Beispiel legt der knockd eine iptables-Regel an, die den Zugriff auf TCP-Port 22 von einer IP genau dann erlaubt, wenn innerhalb von fünf Sekunden von dieser IP-Adresse ein Paket an UDP-Port 1234, dann ein Paket an TCP-Port 8765 und schließlich ein Paket an TCP-port 54321 empfangen wurde. Diese Regel bleibt 60 Sekunden bestehen und wird danach wieder entfernt.

Sprich: Wenn man knockd verwenden will, braucht's mindestens ein minimales Paketfiltermanagement auf dem System, denn sonst fehlt das Drumrum. Ich habe zwar mit meinem netfilter-init eine eigene Dauerbaustelle von einem sehr leistungsfähigen (aber auch langsamen) Paketfiltermanager, wollte hier aber auf eine Standardlösung zurückgreifen. Die Auswahl hierfür fiel schnell auf shorewall, weil ich mir das schon lange mal angucken wollte.

Die Shorewall-Package in Debian haut mich nicht wirklich vom Stuhl: Entgegen dem, was ich eigentlich erwarte, kommt sie in keinster Weise vorkonfiguriert, der Paketfilter ist disabled und das Regelwerk leer. Man muss sich also aus den nach /usr/share/doc/shorewall installierten Beispielen aus der Original-Doku sein eigenes Regelwerk zusammenzimmern und bekommt auf diese Weise keine automatischen Updates.

Nun, eine "allow all" Policy ist schnell zusammengezimmert. Das Regelwerk, das im Default gebaut wird, kümmert sich schön um Grenzfälle und ist in diesem Punkt besser als das, was mein netfilter-init bastelt.

Allerdings ist shorewall nicht so "high-level" wie es sich in den Markeingtexten gibt. Auch hier schreibt man Regeln, welches Protokoll und welche Quell-/Zielports von welcher IP auf welche IP erlaubt und verboten sein sollen, wobei es schöne Symboliken für Netze und Interfacegruppen (so genannte Zonen) gibt. Hübsch. Auch gibt es Mechanismen, die nach einer bestimmten Zeit wieder auf den alten Zustand (bzw. "komplett offen") zurückrollen, wenn die erfolgreiche Aktivierung des Paketfilters nicht vom Bediener bestätigt wird.

Etwas unterentwickelt sind die Blacklistfähigkeiten. Man kann mit einem Shellkommando einzelne IP-Adressen komplett blocken, und diese Blockierung wieder aufheben. Einem Angreifer nur einen Port sperren, oder eine weiter hinten im Regelwerk stehende Reject-Regel für einzelne IP-Adressen aufheben (wie es für das Port-Knocking-Projekt notwendig ist), geht mit Bordmitteln nicht. Leider sind meine Bugs, die ich heute mittag gegen Shorewall geschrieben habe, irgendwo versackt und nichtmal im Exim-Log des Hosts angekommen.

Mit der Kombination aus dem wie oben gezeigten knockd und shorewall funktioniert Port Knocking auf nechayev.zugschlus.de inzwischen ziemlich gut, ich bin zufrieden. Ich werd mir das mal ein paar Tage angucken und dann überlegen, ob ich es auf die anderen Hosts ausdehne.

knockd enthält auch einen Client, mit dem man die notwendigen Pakete verschicken kann. Das einzige, was noch fehlt, ist eine Hook-Option im Openssh-Client, um den knock-Aufruf automatisch in das ssh-Kommando einzuklinken. Bugreport ist eingereicht.

Trackbacks

Roland's Weblog on : Angriffe gegen SSH und Gegenmaßnahmen

Show preview
Wer einen Server mit Linux betreibt, der aus dem Internet erreichbar ist, kennt sicherlich die Problematik, dass andere versuchen, sich Zugang zu verschaffen, indem sie den SSH-Daemon mit einer Dictionary-Attacke angreifen. Dabei wird versucht, das Pas...

Comments

Display comments as Linear | Threaded

Felix Groebert on :

wenn du nur eine sequence nutzten willst kannst du server seitig den knockd sparen und http://www.soloport.com/iptables.html nutzen. client seitig reicht dann ein nmap -r -p123,124,125

just fyi

cheers, felix

Marc 'Zugschlus' Haber on :

Das ist ein wirklich hübsches Setup. Wär ich selbst nie drauf gekommen.

Ich glaub, ich muss mich mal näher mit den neuen iptables-Features beschäftigen, obwohl ich selbst immer weiter weg von Linux-basierenden Paketfiltern rutsche.

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options