Security für offenen SSH Port

[MSfree]

Das Problem, das ich beim Portknocking sehe: es ist aufzeichenbar (es sei denn, knockd erlaubt wechselnde Folgen aufgrund eines gemeinsamen Geheimnisses – was aber beim schnellen Drüberschauen nicht danach aussieht).

Zumindest wird in keiner mir bekannten Beschreibung erwähnt, daß man die Knocksequenz variabel gestalten kann.

Deswegen erschien’s mir recht geschickt, das mit einem ICMP-Paket erledigen zu können und ich hatte gehofft, dass jemand das bereits offen umgesetzt hätte.

Vielleicht sollte ich meinen Code doch mal nach GIT schubsen. Ich scheue mich aber ein wenig vor dem Aufwand, das auch sachgerecht zu dokumentieren, Anleitungen zu schreiben und Beispiele zu erstellen. Der Quellcode ansich ist keine Raketenwissenschaft.

Letztlich handhabt der Kernel die ICMP-Pakete, oder? Lässt sich die Payload dann ohne Modifikationen daran etwa via ip/nftables extrahieren?

Wie gesagt, der Code beruht noch auf iptables. Man kann mit iptabels Netzwerkpakete mit -QUEUE auf eine Warteschlange schicken. Ich schicke hierfür die ICMP-Pakete und auch die SSH-Pakete auf die Queue.

Der Daemon lauert auf der Queue und kann dann das ICMP-Paket in vollem Umfang inklusive Header und Payload auslesen. Es ist dann die Aufgabe des Daemons, die gequeueten Pakete zu beurteilen, dem Kernel also ein Verdict zu schicken. Wenn zuerst ein gültiges ICMP-Paket ankommt und danach eine SSH-Connectrequest mit passendem Quell-IP-Attribut, wird einfach ein positives Verdict an den Kernel geschickt und das Paket wird durchgelassen. Ständige Änderungen an den Filterlisten (wie bei fail2ban) sind hier also nicht nötig.

[cosinus]

Richtig, und so eine Lücke hatte mich vor etwa 20 Jahren selbst erwischt. Ein Angreifer hatte es geschafft, trotz Absicherung via Keyfiles, Schadsoftware auf meiner Kiste zu instalieren

Wie hat der das denn geschafft? Sicherheitslücke/Programmierfehler in sshd?

[MSfree]

Wie hat der das denn geschafft? Sicherheitslücke/Programmierfehler in sshd?

Das Problem war eines von CVE-2002-0083, CVE-2002-0639 und/oder CVE-2002-0640, alle mit 10.0-Rating. Welche Sicherheitslücke es speziell war, weiß ich nicht mehr. Der Angreifer konnte sich jedenfalls eine Shell mit root-Rechten auf der Kiste beschaffen und Schadsoftware in einem Unterverzeichnis einrichten und starten. Das root-Passwort wurde ebenfalls geändert. Die Schadsoftware war eine IRC-Variante, die in einem mit "." beginnenden Verzeichnis "versteckt" wurde.

Das Ding hat die damalige 1.5MBit/s Leitung ziemlich verstopft und ist dadurch praktisch unmittelbar aufgefallen. Mehr als 30 Minuten hat die Software nicht auf dem System gewütet bevor ich den Netzwerkstecker gezogen habe.

Am Ende habe ich eine andere Platte aus meinem Fundus genommen, das OS neu installiert und konfiguriert und den SSH-Zugang nach außen erstmal komplett deaktiviert. Die verseuchte Platte habe ich mir im Nachhinein angeschaut, um zu sehen, was da passiert war.

Daß so ein Erlebnis nachhaltig prägt, kannst du dir ja vorstellen. Ein ungeschützter Zugang von außen kommt mir jedenfalls nicht mehr auf die Kiste. Egal ob SSH oder VPN, das wird bei mir hinter Pingknocking verbarrikadiert.

[uname]

Ich denke die meisten Angriffe passieren eher von innen und dort vor allen mit Malware bei Windows. Da hilft die Absicherung von SSH wenig und dagegen sind die Angriffe über SSH wohl zu vernachlässigen.

Etwas offtopic:
Ich hatte sowas mal. Die Nichtverwendung von Windows war hierbei die beste Sicherheitsfunktion für mich.

Alles begann damit, dass mein damaliger TP-Link-DSL-Router aus mir nicht bekannten Gründen das Webinterface auch nach außen geöffnet hatte. Dann kam hinzu, dass dieses Webinterface eine Sicherheitslücke hatte, die natürlich nicht gepatcht wurde. Am Ende hat der Angreifer nicht viel gemacht. Er konnte ja nicht wirklich weiter. Der Angreifer hat wahrscheinlich auf einer Vielzahl baugleicher Systeme einfach den DNS-Server auf einen DNS-Server umgebogen bzw. so manipuliert, dass nur gewisse Seiten auf Malwareseiten umgeleitet wurden. Man will ja nicht auffallen.

Wie ist es mir aufgefallen:
Unter Debian habe ich beim Aufruf von Wikipedia-Seiten nicht mehr die Wikipedia-Seiten erhalten, sondern einen Link auf eine Windows-Malware. Beim Test unter Android (ich bin ja neugierig und habe Android-Pakete aus fremden Quellen deaktiviert), wurde ich auf einen APK-Download verwiesen. Die Kombination hat mir gezeigt, dass die Ursache im LAN und damit beim TP-Link-DSL-Router liegen musste. Natürlich habe ich seinerzeit keinen neuen Router gekauft. Im Internet habe ich dann eine Lösung gefunden. Da man das Interface und damit die Sicherheitslücke wohl nicht ganz deaktivieren konnte , musste ich den Socket IP:Port oder nur Port irgendwie auf eine nicht existierende Adresse im LAN umleiten wenn ich mich recht erinnere. Neue Hardware habe ich aus Sicherheitsgründen noch nie gekauft. Irgendwann habe ich dann eine FRITZ!Box bekommen. Dort habe ich eine HTTP/HTTPS-Weiterleitung auf meine Nextcloud, die ich aber meistens gar nicht an habe. Ob sonst irgendwelche Ports erreichbar sind, habe ich nie überprüft.

[Livingston]

TP-Link? Spätestens nach dem Unfall hätte ich da ein Debian druffgepackt

[speefak]

Klingt sehr interessant, zumal Fehler im SSH auf diese weise durch ein völlig anderes Programm "kontrolliert" werden

Eine Andere Möglichkeit wäre eine Shell Eingabe direkt nach dem Login und ein serverseitiges Skript was diese Eingabe prüft und entsprechend reagiert ( User disconnect ).

Damit ist der Angreifer zwar kurzzeitig auf dem System, aber dafür funktioniert der Ansatz ohne modifizierte Programme von jeder ssh Shell aus. Man könnte es noch absichern indem der IP gesperrt wird wenn der user 2 mal den Disconect bekommt weil die Shell Eingabe nicht erfolgte.

gallery/image/4844/source

[speefak]

"Ich denke die meisten Angriffe passieren eher von innen und dort vor allen mit Malware bei Windows. Da hilft die Absicherung von SSH wenig und dagegen sind die Angriffe über SSH wohl zu vernachlässigen."

Aus genau dem Grund sollte man JEDEN! Rechner mit SSH/HTTP etc Zugang absichern - auch wenn der Rechner nur übers LAN erreichbar ist.

Vor Jahren hatte ich so etwas auch mal getestet : 4 VMs (3 mal Linux 1 x Windows XP) über ein Virtuelles Netzwerk per DMZ ins INet gehängt. Keine 12 Stunden hat es gedauert, und Fail2Ban schlug auf den anderen Linuxsystemen, die nicht aus dem INet erreichbar waren, für SSH Alarm.

[cosinus]

Vor Jahren hatte ich so etwas auch mal getestet : 4 VMs (3 mal Linux 1 x Windows XP) über ein Virtuelles Netzwerk per DMZ ins INet gehängt.

Du hattest Windows XP direkt im Internet, ohne Firewall? Auch ohne Windows-Firewall?

[speefak]

Aber sicher doch, ohne Köder fängt man selten etwas

Das Netzwerk in dem die Windows VM und die 3 Linux Systeme liefen war aber komplett von meinem LAN getrennt.

[MSfree]

...Damit ist der Angreifer zwar kurzzeitig auf dem System

Und damit ist es dann auch schon zu spät. Wenn ein Fehler im sshd ausgenutzt werden kann, um sich ohne Benutzername, Passwort und/oder Keyfile einen root-Zugang zum System zu verschaffen, wirkt deine nachgeschaltete Zusatzabfrage nicht. Der Angreifer ist schon im System drin, ohne daß deine Abfrage überhaupt erscheinen würde.

aber dafür funktioniert der Ansatz ohne modifizierte Programme von jeder ssh Shell aus.

Mir war es wichtig, etwas vor den SSH-Connect zu schalten. Von außen sieht mein Linuxrouter nämlich dadurch aus, als ob er SSH gar nicht erst anbietet, ein Portscan liefert bei meiner Kiste schlicht gar nichts, nichtmal ein Return auf normale Pings. Nur Pings mit korrekter Payload werden überhaupt beantwortet.

[cosinus]

Aber sicher doch, ohne Köder fängt man selten etwas

Und dann bist du überrascht, sich etwas einzufangen zu haben?

[uname]

Man könnte auch von außen den Anwendungs-Multiplexer sslh z. B. auf Port 443 bereitstellen. Dann kann man TLS/SSL und SSH gemeinsam z. B. auf Port 443 betreiben. Aber die Sicherheit erhöht es nicht wirklich. Es spart aber einen zusätzlichen Port. Vielleicht kann das mal jemand installieren, konfigurieren und schauen wie z.B. der Portscanner nmap darauf reagiert. Würde mich schon interessieren.

[speefak]

Aber sicher doch, ohne Köder fängt man selten etwas

Und dann bist du überrascht, sich etwas einzufangen zu haben?

Nö - darauf wollte ich doch hinaus. Es hätte mich überrascht wenn nichts passiert wäre.

[speefak]

...Damit ist der Angreifer zwar kurzzeitig auf dem System

Und damit ist es dann auch schon zu spät. Wenn ein Fehler im sshd ausgenutzt werden kann, um sich ohne Benutzername, Passwort und/oder Keyfile einen root-Zugang zum System zu verschaffen, wirkt deine nachgeschaltete Zusatzabfrage nicht. Der Angreifer ist schon im System drin, ohne daß deine Abfrage überhaupt erscheinen würde.

aber dafür funktioniert der Ansatz ohne modifizierte Programme von jeder ssh Shell aus.

Mir war es wichtig, etwas vor den SSH-Connect zu schalten. Von außen sieht mein Linuxrouter nämlich dadurch aus, als ob er SSH gar nicht erst anbietet, ein Portscan liefert bei meiner Kiste schlicht gar nichts, nichtmal ein Return auf normale Pings. Nur Pings mit korrekter Payload werden überhaupt beantwortet.

Dein Ansatz ist sicherer, keine Frage - benötigt aber auch einen DDNS Service und modifiziertes ping auf dem client.

Mitbekommen würde ich es ( Mailversandt bei jedem Login ). Der Angreifer müsste allerdings genau wissen was wie nach dem Login auf dem Server passiert und es in wenigen Sekunden herausfinden und unterbinden. In der Zeit ist zumindest die Mail lange versendet worden.

[Livingston]

Man kann Portknocking als eine zusätzliche Passphrase betrachten: Eine Außenstehenden unbekannte Abfolge von Ports (Zahlen von 0 - 65335, also 16 Bit) mit unbekannter Intervalllänge zwischen den Abfragen (Milisekunden , also z.B. kodierbar in 10 Bit).
Bei wie vielen Ports in welchen Abständen kann man denn anklopfen?

[MSfree]

...benötigt aber auch einen DDNS Service

Den brauchst du sowieso, außer du hast einen Internetzugang mit fester IP.

und modifiziertes ping auf dem client.

Richtig. das muß auf der Clientseite vorhanden sein, kann aber bei der Einrichtung des Zugangs auf den Rechner kopiert werden. Die Arbeit, daraus ein .dep zu machen, habe ich mir noch nicht gemacht. Das Pingprogramm kann auch für Windows und MacOS übersetzt werden.

[niemand]

Man kann Portknocking als eine zusätzliche Passphrase betrachten: Eine Außenstehenden unbekannte Abfolge von Ports (Zahlen von 0 - 65335, also 16 Bit) mit unbekannter Intervalllänge zwischen den Abfragen (Milisekunden , also z.B. kodierbar in 10 Bit).

Naja … die ist einem Außenstehenden unter Umständen halt nur beim ersten Mal unbekannt. Ansonsten würde ich das Timing nicht unbedingt mit einbeziehen: die Laufzeiten sind zwar heutzutage insgesamt eher kurz, aber es kann immer Verzögerungen und Jitter geben – technisch gesehen kann sich dabei auch die Reihenfolge der Pakete ändern.

Mich würd’s freuen, wenn MSfree seinen „pingknockd“ zur Verfügung stellen könnte. Im Gegensatz zu knockd würde ich da tatsächlich einen handfesten Mehrwert sehen – weil man’s eben zumindest nicht auf Vorrat mitschneiden kann (gegen „man in teh™ middle“ hilft’s freilich nicht so – da muss man sich dann wieder auf ssh selbst verlassen).

[cosinus]

Nö - darauf wollte ich doch hinaus. Es hätte mich überrascht wenn nichts passiert wäre.

Ab Ende 2003 war das ja schon, ja kamen die ersten Würmer, die die RPC-Lücke ausnutzten. Ich glaube der Blaster-Wurm war das. 2004 kam dann der Sasser. Da wurden reihenweise 2000/XP Kisten befallen und man konnte damit schön sehen wer keinen Router nutzte und gleichzeitig die Windows-Updates ignorierte oder gar bewusst deaktivierte. Da reicht ein kurzer Gang ins Internet ohne Firewall sprich Modem/ISDN und bääm war die Kiste nach wenigen Sekunden voll mit Gewürm

[MSfree]

Mich würd’s freuen, wenn MSfree seinen „pingknockd“ zur Verfügung stellen könnte. Im Gegensatz zu knockd würde ich da tatsächlich einen handfesten Mehrwert sehen

Die Sache hat letztlich trotzdem einen Haken.

Wenn man seinen Internetzugang über ein Modem hat, funktioniert Pinkknocking einwandfrei. Wenn man aber eine der typischen Internetrouter hat, und das dürften inzwischen fast alle Privatanschlüsse zutreffen, dann geht das leider nicht. Man kann zwar hinter so einen Router eine Debiankiste stellen, auf die man den gesamten Netzwerkverkehr umleitet (exposed Host), nur leider werden die Ping-Pakete dabei nicht durchgereicht, die fängt der Router nämlich vorher ab.

Es gibt ein paar, nicht immer funktionierende Umwege:

• man kann den Router für PPP-Passthrough konfigurieren und die Internetverbindung vom Linuxrechner per PPPoE aufbauen lassen. Der Router würde dann aber für die IP-Telefonie auch nochmal eine PPPoE-Verbindung aufbauen, was je nach Anbieter klappen kann oder auch nicht (doppeltes Login erlaubt?). Billige Plastikrouter können oft kein PPP-Passthrough.
• man kann einen Internetvertrag mit fester IP-Adresse buchen, dann klappt es auch wieder mit dem Durchreichen der Ping-Pakete an den exposed Host, der ja eine andere IP-Adresse hat als der Router.
• man kann, sofern man es überhaupt noch käuflich erwerben kann, ein DSL-Modem verwenden, und man müßte sich um die IP-Telefonie selbst kümmern. Gibt es überhaupt Modems für Glasfaser bzw. TV-Kabel?

Um dem ICMP-Problem aus dem Weg zu gehen, könnte man auch andere Pakete mit einer Payload beaufschlagen, die dieselbe Aktion auslösen wie die von mit verwendeten Pingpakete. UDP-Pakete würden sich da anbieten, die kommen aber, wie beim Portknocking auch, eben nicht durch jede Firewall.

[MSfree]

Da wurden reihenweise 2000/XP Kisten befallen und man konnte damit schön sehen wer keinen Router nutzte und gleichzeitig die Windows-Updates ignorierte oder gar bewusst deaktivierte.

Win2000 hatte meiner Erinnerung nach noch keinen Updateautomatismus. Da mußte man sich noch Servicepakcs bei MS runterladen und selbst installieren. Auch XP wurde meines Wissens erst mit SP2 oder so mit einem Updateautomatismus versehen.

Da reicht ein kurzer Gang ins Internet ohne Firewall sprich Modem/ISDN und bääm war die Kiste nach wenigen Sekunden voll mit Gewürm

Bei den ISDN-Datenraten hat es dann doch etwas länger als ein paar Sekunden gedauert.
Ich hatte zwar schon ab Januar 2001 DSL mit 1.5MBit/s, das stand aber damals noch längst nicht jedem zur Verfügung. Die Telekom hat mit von Juni 2000 bis Dezember 2000 vertröstet, daß es dann doch nächste Woche kommt, ganz bestimmt... Im Dezember habe ich dann den Antrag bei der Telekom storniert und bei Arcor nochmal beantragt, da ging es dann komischerweise ganz schnell.

[niemand]

Wenn man aber eine der typischen Internetrouter hat, und das dürften inzwischen fast alle Privatanschlüsse zutreffen, dann geht das leider nicht.

Das mit dem Router hatte ich nun nicht auf dem Schirm. Aber lässt der ICMP nicht generell durch? Ich kann ja auch problemlos über den Router meine Kisten anpingen. Andersrum, wenn ich vom Server aus meine öffentliche IP pinge, handhabt der Router das, aber hier geht’s ja um die andere Richtung?

Um dem ICMP-Problem aus dem Weg zu gehen, könnte man auch andere Pakete mit einer Payload beaufschlagen, die dieselbe Aktion auslösen wie die von mit verwendeten Pingpakete.

Das würde letztlich wieder einen dauerhaft offenen Port bedeuten. Das Elegante an der Lösung via ICMP erschien mir, dass man das eben nicht benötigt – sodass ein Beobachter alleine vom Angucken der Kiste erstmal keinen Anhaltspunkt erhält, wo man da ansetzen könnte. Man könnte also ’ne Kiste völlig ohne offensichtlich offene Ports haben, was ich als ästhetisch empfinden würde …

[cosinus]

Win2000 hatte meiner Erinnerung nach noch keinen Updateautomatismus. Da mußte man sich noch Servicepakcs bei MS runterladen und selbst installieren. Auch XP wurde meines Wissens erst mit SP2 oder so mit einem Updateautomatismus versehen.

Jein. Die Urversion von Windows 2000 hat keinen Dienst "Automatische Updates", das wurde erst mit SP3 oder irgendeinem anderen Update eingeführt, das man manuell installieren musste, aber danach hatte man diesen Service auch unter Windows 2000.
Bei XP war das IIRC von Anfang an drin, aber ich meine das Teil lief recht unzuverlässig, daher hatten wir gerne damals die Kisten mit 2000 und XP noch über die Windows-Update-Seite mit dem Internet Explorer aktualisiert.

Bei den ISDN-Datenraten hat es dann doch etwas länger als ein paar Sekunden gedauert.

Also ich weiß nur, dass es Ruckzuck ging...spätestens nach 5 Minuten nach der ersten Internetverbindung war damals ein ungepatchtes und ungesichertes Windows 2000/XP voll mit Würmern M$ hatte damals nur von 12 bis Mittag gedacht und generell alle möglichen Ports geöffnet. Da war dann sowas wie RPC, NETBIOS und SMB direkt aus dem Internet erreichbar

[MSfree]

Das mit dem Router hatte ich nun nicht auf dem Schirm. Aber lässt der ICMP nicht generell durch?

Der Pingknockdaemon muß auf der Empfängerseite laufen. In meinem Fall ist das eine als Router konfigurierte Linuxkiste, die hinter einer Fritzbox Cable hängt.

Wenn ich von Timbuktu auf mein Heimnetz zugreifen will, muß ich einen Ping an die öffentlich IP meines Linuxrouters schicken. Dumm nur, wenn die Fritzbox Cable das Ping schon abfängt. Geforwarded werden eben nur TCP- und UDB- Pakete. Ich habe mir allerdings den Luxus einer festen IP-Adresse gegönnt, die Fitzbox und der Linuxrouter haben unterschiedliche IPs, so daß die Pings an den Linuxrouter nicht von der Fritzbox abgefangen werden können.

Bei dem Rechner in Timbuktu ist die Sache einfach, da werden die Pingpakete, die ich vom Laptop durch den Hotspot in der Karavanserei abschicke, durch den dort befindelichen Internetrouter bis zu meinem Heimrouter durchgereicht.

Das würde letztlich wieder einen dauerhaft offenen Port bedeuten.

Ja, aber an dem Port muß nur der Pingknockdaemon lauschen, was er auch bei den Pingpaketen machen müßte. Das Risiko von Sicherheitslücken in diesem Daemon ist also nicht größer, wenn man UDP statt ICMP/8 nimmt.

Das Elegante an der Lösung via ICMP erschien mir, dass man das eben nicht benötigt – sodass ein Beobachter alleine vom Angucken der Kiste erstmal keinen Anhaltspunkt erhält, wo man da ansetzen könnte.

Solange der Daemon nicht auf die UDP-Pakete antwortet, sieht das nach aussen nicht wie ein offener Port aus. Der Daemon muß ja nur Pakete entgegen nehmen, ohne Bestätigungsantworten zu schicken. Eine Anwort könnte er aber in dem Fall schicken, wenn die Payload akzeptiert wurde, um dem Rechner in Timbuktu über den Erfolg zu informieren.

[JTH]

und XP noch über die Windows-Update-Seite mit dem Internet Explorer aktualisiert.

Ach ja, das waren noch Zeiten …

[cosinus]

Ach ja, das waren noch Zeiten …

Jo...und Installation erfolgte über CD, nicht wenige mussten sogar per Diskette einen SATA-Treiber im ersten Teil des Setups einbinden, sonst gabs nen Bluescreen im AHCI-Modus