Security für offenen SSH Port

[niemand]

Ja, aber an dem Port muß nur der Pingknockdaemon lauschen, was er auch bei den Pingpaketen machen müßte.

ICMP hat Ports?

Solange der Daemon nicht auf die UDP-Pakete antwortet, sieht das nach aussen nicht wie ein offener Port aus

Ich kenne mich mit UDP nicht aus – ich dachte bislang, dass dort wie bei TCP in Fall eines tatsächlich nicht offenen Ports der letzte Host vor dem Ziel ein „connection refused“ zurückschickt, und anderenfalls nicht. Da werd’ ich nochmal genauer nachlesen müssen, danke für den Hinweis.

[MSfree]

ICMP hat Ports?.

Nein, natürlich nicht.

Aber, der Daemon muß auf Netzwerkpakete im Allgemeinen lauschen. Ob der auf ICMP, UDP oder TCP lauscht, ist da erstmal egal. Der Unterschied zwischen den einzelnen Netzwerkpaketen ist ohnehin gering. Bei einem UDP- oder TCP-Paket steht halt im Datenheader die Portnummer drin, bei einem ICMP-Paket steht der ICMP-Typ da drin. Zwischen UDP und TCP besteht auch nur der Unterschied, daß UDP zustandslos ist, wenn es zu Paketverlusten kommt, muß sich die Anwendung darum kümmern, bei TCP kümmert sich der Kernel darum und entlastet so die Anwendung.

Die Sicherheitslücke bei Netzwerkpaketen besteht hauptsächlich darin, die Daten im Netzwerkpaket falsch zu interpretieren. Wenn z.B. die Portnummer eines TCP-Pakets beim Transport durch das Netz verstümmelt wird, und dort z.B. 22 statt 80 drinsteht, dann wird das Paket an den SSH-Daemon gereicht statt an den HTTP-Daemon, der sich um die mit 80 nummerierten Pakete zu kümmern sollte. Daß dabei völlig unsinnige Daten am SSH-Daemon ankommen, ist wohl logisch. Wenn das einen Pufferüberlauf auslöst, kann man das zum Einschmuggeln von Schadcode nutzen. Wird sowas allgemein bekannt, kann man eine betroffenen Daemon gezielt mit manipulierten, also absiochtlich falschen Daten, angreifen.

Ein Daemon muß also in der Lage sein, die Daten im Datenpaket zu verifizieren und ggfls. einfach zu verwerfen, völlig unabhängig von Tranportprotokoll und Portnummer.

Es macht also keinen Unterschied, ob der Knockdaemon wartet, bis ICMP-Pakete eintrudeln oder ob er wartet, bis UDP-Pakete eintrudeln. In beiden Fällen muß er das gleiche tun, nämlich die Daten lesen, entscheiden, ob es ein korrektes Datenpaket ist, dann entscheiden, ob damit eine Aktion verbunden ist, wie öffnen Port 22 für Quell-IP, und wenn alles erfüllt ist, diese Aktion ausführen.

Ich kenne mich mit UDP nicht aus – ich dachte bislang, dass dort wie bei TCP in Fall eines tatsächlich nicht offenen Ports der letzte Host vor dem Ziel ein „connection refused“ zurückschickt, und anderenfalls nicht.

Der letzte Rechner kann das Paket auch verwerfen (DROP). Dann gtibt es gar keine Antwort, nicht mal "connection refused", egal ob UDP, TCP oder ICMP.

[niemand]

Der letzte Rechner kann das Paket auch verwerfen (DROP). Dann gtibt es gar keine Antwort, nicht mal "connection refused", egal ob UDP, TCP oder ICMP.

Ja – dann weiß der Testende genau, dass der Rechner existiert und der fragliche Port gefiltert ist. Wäre das nicht der Fall, würde der Rechner davor eben den Fehler zurückschicken – zumindest bei TCP ist das so. Bei UDP muss ich, wie gesagt, nochmal nachlesen, wie sich das da so verhält. Ich hätte halt gerne einen Rechner, der von außen aussieht, als wäre gar kein Port offen.

[Livingston]

Schau Dir mal auf Deinem localhost einfache Scans für TCP und für UDP an:

Code: Alles auswählen

$ nc -v 127.0.0.1 12345
nc: connect to 127.0.0.1 port 12345 (tcp) failed: Connection refused
$ nc -u -v 127.0.0.1 12345

In beiden Fällen wartet nix auf Port 12345, und in beiden Fällen erfolgt daher ein DROP.
Bei UDP wird keine Rückmeldung erwartet, folglich gibt's keinen Fehler.

[niemand]

In beiden Fällen wartet nix auf Port 12345, und in beiden Fällen erfolgt daher ein DROP.

Nicht ganz, wenn bei TCP nichts lauscht, gibt’s ein „connection refused“. Bei einem DROP gibt’s irgendwann einen Timeout:

Code: Alles auswählen

root@MIN ~ # nc -v 127.0.0.1 443
localhost [127.0.0.1] 443 (https): Connection refused
1 root@MIN ~ # iptables -A INPUT -p tcp --dport 443 -j DROP
root@MIN ~ # nc -v 127.0.0.1 443
[… irgendwann wird ein Timeout kommen …]                         

Bei UDP verhält’s sich ohne lauschendes Programm erstmal genauso wie mit DROP, aber wenn ich da was lauschen lasse, das das „ping-knock“-Paket entgegennimmt und prüft, mag beispielsweise ein entsprechender nmap-Scan das zutage fördern – wie gesagt, da muss ich mangels Erfahrung mit UDP selbst nochmal schauen.

Ich hätte es halt elegant gefunden, wenn da von außen alle 65535 Ports sowohl für TCP als auch für UDP tatsächlich geschlossen wären, und ein ICMP-Paket mit entsprechender Payload etwa dafür sorgt, dass der sshd gestartet wird.

[MSfree]

Bei UDP verhält’s sich ohne lauschendes Programm erstmal genauso wie mit DROP, aber wenn ich da was lauschen lasse, das das „ping-knock“-Paket entgegennimmt und prüft, mag beispielsweise ein entsprechender nmap-Scan das zutage fördern

nmap kann nichts zutage födern, wenn es keine Antwort bekommt. Daß die Gegenstelle das Paket inspiziert, bekommt nmap über das Netzwerk nicht mit. es kann es gar nicht mitbekommen.

Ein nicht antwortender Rechner sieht für nmap aus, wie ein nicht existierender Rechner.

[Livingston]

Code: Alles auswählen

"server":
# iptables -A INPUT -p udp --dport 12345 -j DROP
"client":
$ nc -u -v 127.0.0.1 12345
Connection to 127.0.0.1 12345 port [udp/*] succeeded!

Hmpf!

[niemand]

nmap kann nichts zutage födern, wenn es keine Antwort bekommt. Daß die Gegenstelle das Paket inspiziert, bekommt nmap über das Netzwerk nicht mit. es kann es gar nicht mitbekommen.

Danke, ich werde damit ein wenig rumspielen.

Bleibt der „Mangel“, dass das UDP-Paket von jedem auf der Route gesehen wird – was zwar bei ’nem ICMP-Paket auch der Fall wäre, dort aber vermutlich als weniger auffällig wahrgenommen würde, als ein einsames UDP-Paket.

Wie gesagt – ich hätte die Idee mit ICMP elegant gefunden und find’s ein wenig schade, dass du’s für dich behalten willst. Warum hattest du eigentlich ICMP genommen, und nicht UDP? Letzteres ist ja einfacher zu implementieren, weil man den Daemon direkt am betreffenden Port lauschen lassen kann, und nicht umständlich über iptables die Pakete rauspopeln und die Payload extrahieren muss.

Ein nicht antwortender Rechner sieht für nmap aus, wie ein nicht existierender Rechner.

… das haben die Hobbyadmins früher auch geglaubt: Pings verwerfen und keiner weiß, dass die IP da ist

[Livingston]

Dann wäre noch die Frage offen, ob ich einen kompletten Rechner verstecken will oder die einige Ports eines als bekannt anzusehenden Rechners verstecken möchte.

[niemand]

„Die“ war schon richtig: das fände ich elegant. Nicht aus Sicherheitsgründen – da bin ich der Meinung, dass der sshd für den Job entwickelt wurde und die Wahrscheinlichkeit gut ist, dass die Kinderkrankheiten raus sind – ich hab den seit 25 Jahren direkt am Netz, und zumindest bislang nicht feststellen können, dass da irgendwann mal irgendwas aufgemacht worden ist.

Einfach nur wegen:

Man könnte also ’ne Kiste völlig ohne offensichtlich offene Ports haben, was ich als ästhetisch empfinden würde …

[Livingston]

Schon richtig, guter Geschmack darf kein Zufall sein.

[MSfree]

Bleibt der „Mangel“, dass das UDP-Paket von jedem auf der Route gesehen wird – was zwar bei ’nem ICMP-Paket auch der Fall wäre, dort aber vermutlich als weniger auffällig wahrgenommen würde, als ein einsames UDP-Paket.

Natürlich kann man das Paket mitlesen, das kann man mit SSH- und VPN-Pakete aber auch. Dank Verschlüsselung sieht man aber nur ein Rauschen. Der von mir verwendete Hash ist ja letztlich auch Rauschen. Ob wirklich ein einzelnes UDP- Paket auffält, ist unwahrscheinlich. Dazu müßte ja jemand alle Paket inspizieren, die durch das Netz rauschen und ausgerechnet über die eine Statistik führen, die besonders selten sind.

Wie gesagt – ich hätte die Idee mit ICMP elegant gefunden und find’s ein wenig schade, dass du’s für dich behalten willst.

Ich habe nicht gesagt, daß ich das für mich behalten will. Das ganze basiert aber noch auf iptables, was eigentlich inzwischen von nftables abgelöst wurde. Ich nutze hier die iptables-Bibliothek, um an einzelne mit -QUEUE aufgestaute Netzwerkpakete ranzukommen. Ich würde auch für UDP-Pakete denselben Mechanismus verwenden. Allerdings sollte man das wirklich mal auf nftables portieren. Das ganze ist halt ein "wenig" veraltet. Ich sage mal, daß es sich in dem Zustand, in dem sich die Software befindet, nicht lohnt, es zu veröffentlichen.

Warum hattest du eigentlich ICMP genommen, und nicht UDP?

Mit Ping kommt man auch durch Firmenfirewalls nach außen, UDP könnte blockiert sein und dann funktioniert das Verfahren nicht. Ping könnte im Prinzip zwar auch blockiert sein, das tut sich aber normalerweise kein Admin an, denn Ping wird halt auch viel genutzt, um die grundsätzliche Netzwerkfunktionalität zu testen.

Dazu kommt, als ich das programmiert habe, hatte ich meinen DSL-Anschluß noch über ein Modem. Als mich mein Provider zwangsweise auf 16MBit/s upgegradet hat und mir dazu einen neuen Router zugeschickt hat, ging das mit dem Pingknocking nicht mehr.

Mittlerweile bin ich von DSL (Telefonleitung) auf Internet via TV-Kabel umgestiegen und konnte dank fester IP die alte Software reaktivieren.

Letzteres ist ja einfacher zu implementieren, weil man den Daemon direkt am betreffenden Port lauschen lassen kann, und nicht umständlich über iptables die Pakete rauspopeln und die Payload extrahieren muss.

Ich brauche die Kernelschnittstelle via iptables sowieso. Der Daemon inspiziert zwar nur die Pingpakete, er urteilt aber aufgrund der Pingpakete darüber, ob SSH-Pakete akzeptiert werden oder nicht, dazu werden auch die SSH-Pakete mit -QUEUE aufgestaut.

… das haben die Hobbyadmins früher auch geglaubt: Pings verwerfen und keiner weiß, dass die IP da ist

[Livingston]

Puh, lang ist's her, dass ich mich mit den Feinheiten rumgeschlagen habe. Die Standardantwort auf einen geschlossenen/nicht vorhandenen UDP-Port ist ein ICMP-Paket vom Typ/Code 3/3 ---> Destination unreachable/Port unreachable
Lässt sich fürs Knocken über eine ip-/nftable rule faken unbenommen der Frage, was wirklich mit dem Paket passiert und ob es ausgewertet wird.