für diesen Vorschlag wurde im Artikel gar nicht genannt: Die gängigen Portforward-Mechanismen besitzen ein Zeitfenster, in dem der TCP-Port allgemein offen ist. Ein Angreifer kann darauf warten und die Verbindung übernehmen, sobald sie von einem validen Client geöffnet wird.
Der Vorschlag zielt darauf ab, diese Lücke zu schließen. Er beruht darauf, dass das SYN-Paket bereits Daten enthalten darf. Wenn man dort einen beliebigen Public Key sendet (den der Server verifizieren kann), kann man die gesamte restliche Payload aller folgenden Pakete digital damit signieren. Damit kann ein Angreifer die Verbindung zu keinem Zeitpunkt mehr übernehmen.
Von Nutzergegend am Mi, 11. Dezember 2013 um 20:01 #
Aber kann man das nicht auch ins Userland verlegen? Warum muss alles im Kernel sein? Ich erinnere mich an den HTTP server im kernel, ka wieso Linus sowas zugelassen hatte.
Du kannst die Behandlung von SYN-Paketen nur sehr schwierig ins Userland verlegen, weil zu diesem Zeitpunkt die Verbindung ja nicht existiert. Der Listen-Socket des Serverprozesses hat noch gar nicht mitbekommen, dass es eine Verbindung gibt. Man könnte sicher mit einem Netlink-Socket irgendwas bauen, aber der dafür nötige Kernelpatch wäre größer und fehleranfälliger als die vorgeschlagene Implementierung.
Im übrigen findet die eigentliche Authentifizierung des Clients ja tatsächlich nur im Userspace statt. Der Kernelpatch stellt durch verwendung der Options des SYN-Paketes als Token nur sicher, dass die Verbindung nicht zwischen Portknocking und Tokenübermittlung gehijackt wurde.
Von kamome umidori am Do, 12. Dezember 2013 um 19:18 #
Allerdings kann man die von Dir angesprochende Gefahr doch auch stark einschränken, indem man den Port beim bisherigen Port-Knocking nur für die anklopfende IP öffnet, oder? So mache ich es mit knockd.
Nein, die Absender-Ip wird bei diesen Angriffen mitgefälscht. Sonst würde es ja auch nicht funktionieren, eine Verbindung mittendrin zu übernehmen - was ganz leicht ist, wenn der Angreifer im selben physikalischen Netz sitzt, also z.B der Server nebenan.
..um die Zeit.
Gibt es doch SPA seit laengerem in diversen Linux Distributionen.
Wozu auf ein deutlich schlechteres, veraltetes System setzen?
Verstehe ich nicht...
Bitte den Artikel noch mal lesen. SPA und kernelseitiges portknock-listening ist nicht miteinander vergleichbar.
... das lässt sich doch bestimmt in systemd einbauen oder ? Der kann das besser und ausserdem und so ist das eh ein NIH Syndrom.
für diesen Vorschlag wurde im Artikel gar nicht genannt: Die gängigen Portforward-Mechanismen besitzen ein Zeitfenster, in dem der TCP-Port allgemein offen ist. Ein Angreifer kann darauf warten und die Verbindung übernehmen, sobald sie von einem validen Client geöffnet wird.
Der Vorschlag zielt darauf ab, diese Lücke zu schließen. Er beruht darauf, dass das SYN-Paket bereits Daten enthalten darf. Wenn man dort einen beliebigen Public Key sendet (den der Server verifizieren kann), kann man die gesamte restliche Payload aller folgenden Pakete digital damit signieren. Damit kann ein Angreifer die Verbindung zu keinem Zeitpunkt mehr übernehmen.
Aber kann man das nicht auch ins Userland verlegen? Warum muss alles im Kernel sein? Ich erinnere mich an den HTTP server im kernel, ka wieso Linus sowas zugelassen hatte.
Du kannst die Behandlung von SYN-Paketen nur sehr schwierig ins Userland verlegen, weil zu diesem Zeitpunkt die Verbindung ja nicht existiert. Der Listen-Socket des Serverprozesses hat noch gar nicht mitbekommen, dass es eine Verbindung gibt. Man könnte sicher mit einem Netlink-Socket irgendwas bauen, aber der dafür nötige Kernelpatch wäre größer und fehleranfälliger als die vorgeschlagene Implementierung.
Im übrigen findet die eigentliche Authentifizierung des Clients ja tatsächlich nur im Userspace statt. Der Kernelpatch stellt durch verwendung der Options des SYN-Paketes als Token nur sicher, dass die Verbindung nicht zwischen Portknocking und Tokenübermittlung gehijackt wurde.
Allerdings kann man die von Dir angesprochende Gefahr doch auch stark einschränken, indem man den Port beim bisherigen Port-Knocking nur für die anklopfende IP öffnet, oder? So mache ich es mit knockd.
Nein, die Absender-Ip wird bei diesen Angriffen mitgefälscht. Sonst würde es ja auch nicht funktionieren, eine Verbindung mittendrin zu übernehmen - was ganz leicht ist, wenn der Angreifer im selben physikalischen Netz sitzt, also z.B der Server nebenan.