/c/ – Eine der letzten echten Webseiten

>SPA packets generated by fwknop leverage HMAC for authenticated encryption
>The code required by the fwknopd daemon to verify an HMAC is much more simplistic than the code required to decrypt an SPA packet, so an SPA packet without a proper HMAC isn't even sent through the decryption routines.
Bringt im Vergleich zu "Port verrammeln" die Gefahr einer Work-Amplification-Attacke. HMAC-SHA256 macht 2x SHA-256-Summe, und zwar jeweils mit 64 Runden.
Der Attackeur kann so das Zielsystem dazu bringen, 24/7 nur SHA-256-Berechnungen anzustellen.
Man _muss_ das mit ASN-basierter IP-Bannerei kombinieren. Grüße gehen raus an AWS, Alibaba Cloud, Azure und andere ASNs für Angriffe mit "hoher krimineller Energie".
Ein Heimrouter, auf dem das laufen würde, ist von der Leistung her nicht so weit von einem 1-Kern-Billo-VPS entfernt.

Wenn ein Attackeur das Zielsystem bereits jetzt dazu bringen kann, dass 24/7 nur Private/Public-Keys geprüft werden, ist HMAC natürlich schneller.

t. schrieb vor Monaten an einem nginx-Modul, das Proof-of-Work implementiert, und das auf einem 1-Kern-Billo-VPS gegen tausend AI-Scraper bestand haben soll. Hat sogar AES-NI-Instruktionen für die SHA-256-Summe benutzt. Natürlich eingeschlafen.

>That is, a firewall running on a host has a default-drop policy against all incoming SSH connections so that SSHD cannot be scanned, but a SPA daemon reconfigures the firewall to temporarily grant access to a passively authenticated SPA client
>The SSH daemon along with iptables and fwknopd are deployed on the [server] system, and the SSH and fwknop clients are deployed on the [client] system.
>One of the [...] features offered by the fwknopd daemon is the ability to interact with the NAT facilities offered by the local firewall.
Funktioniert nicht in dem häufigen Anwendungsfall, dass der Rechner, zu den man hinverbinden will, beim Benutzer zu Hause steht, weil der 0815-User da seinen normalen, verdongelten Heimrouter mit NAT dazwischen stehen hat. Hole-Punching ist stattdessen angesagt.

fwknopd setzt außerdem anscheinend iptables voraus, das ist auch aktuell mit eBPF auf dem Weg in die ewige Kotgrube.

t. schreibt vor Monaten an einem SSH-Patch, das Hole-Punching mit benutzerdefinierten TURN/STUN-Servierer implementiert (der SSH-Servierer muss sowieso die ganze Zeit laufen, warum also dann nicht den gleichen Prozess nutzen, um die Verbindung zum TURN-Servierer durch Senden von Paketen alle paar Minuten aufrecht zu erhalten?). Natürlich eingeschlafen.

>>164532
Würde es etwas bringen seine Feuerwand im Tarnkappen-Modus zu betreiben? Geschlossene Häfen und klopfbare Häfen sollten per se bei nkarte-Abtastung ununterscheidbar sein. Dann eine hohe Hafennummer für sichere Hülse und den Klopfer-Hafen ebenso. Das eine Reaktion und Lastabwurf auch Arbeit ist wird ein unlösbares Problem der Technik bleiben, außer du hast eine Schnittertod-Drohne und Höllenfeuer-Raketen um deinen Angreifer vom Zwischennetz zu trennen (siehe staatl. legitimer Häckbäck/Rückmett).

Verstehe immer noch nicht, was Port Knocking bringen soll. Ist das nicht einfach bloß security through obscurity?

>>164536
>Ist das nicht einfach bloß security through obscurity?
Im Endeffekt ja, wenn es keine HMAC nutzt. Ich denke >>164532 hat es gut auf den Punkt gebracht. Weniger CPU-Last und weniger Vergeudung der Entropie durch Handshakes mit Bots. Auch braucht keiner 15 MB logs für Ali-Google-AWS-Azure-Cloud-IPs die rein wollten

>>164536
Oh Felix, es gab schon viele Beispiele für das Anklopfen und dann eine Tür sich geöffnet hat.

Die Frage ist, wozu das gut sein soll. Wenn es darum geht, Glühwürmchen draußen zu halten, ist es zweifelhaft, ob eine neue Kotbasis von irgendeinem Shithub-Account besser ist als der jahrzehntelang gut abgegangene Auth-Code von OpenSSH.

Wenn es darum geht, Angriffe mit hoher krimineller Energie CPU-schonend abzuwehren, kann man Port-Knocking mit einem Klartextpasswort machen, weil der Angreifer nicht auf dem Draht lauscht.

So oder so nicht zielführend.