AuthPF/Portknocking

JeGr

Da ich die Diskussion (und das Bounty) nicht stören will und Heiko ohnehin des deutschen mächtiger als des englischen ist ;) wollte ich das Thema aber nicht ganz verschwinden lassen.

Ich verstehe den effektiven Sinn von Portknocking nicht wirklich, deshalb würde mich interessieren, wofür es der ein oder andere einsetzt und ob (sofern bekannt) AuthPF (was zu PF unter OpenBSD "dazugehört") nicht (wenn überhaupt) die sinnigere Methode ist.

Und das ist rein als Diskussion/Frage zu verstehen, denn irgendwo sehe ich den praktischen/sicherheitstechnischen Nutzen nicht wirklich. Aber da ich immer am evaluieren von sinnvollen Möglichkeien bin, bin ich gespannt auf Antworten :)

Grüße
Grey

heiko

Hi, ich antworte natürlich in Deutsch, dann muss ich mich nicht so abmühen ;).

Ich benötige alle Sicherheit die ich bekommen kann für meine russichen Firewalls, dazu gehören halt zeitbasierte Regeln und das Portknocking. Die GUI und SSH sollen per Knock geöffnet werden, so dass ich diese Ports generell zuhabe und nur aus Verwaltungszwecken öffne. Natürlich sagt der eine oder andere, dass sei security by obscurity und 100 % Sicherheit gibt es nicht. Wir hatten in der Vergangenheit in Russland doch schon das eine oder andere Sicherheitsproblem, diverser Art. Das Argument "geht alles mit IPSEC" ist bekannt, hilft aber nicht, wenn aus welchen Gründen auch immer, kein Tunnel zustande kommt oder abbricht, und dann ist das schon ein Problem wenn du auf dem WAN nix an Ports aufhast und du gerade keinen Admin Vor-Ort hast (ab nach Russland…. ;D).

Zu authpf kann ich gar nichts nix sagen.

Ich hoffe aber, dass Du es wenigstens mal ausprobierst, sowohl die zeitbasierten Regeln wie auch das Portknocking. Habe ich auf jeden Fall gerne spendiert und würde mich freuen, wenn der eine o. andere einen Einsatzzweck für sich sieht.

Gruß
heiko

jahonix

Es gab mal einen Thread, der sich mit SSH ausschließlich via Zertifikat und nicht mit User/Password beschäftigte.
Wenn der SSH-Zugang also nur mit einem gültigen Zertifikat auf Deiner Seite zustande kommt, dann würde ich das als sicher betrachten.
Von aussen kann man dann mit jeder brute-force Attacke und unzähligen Kombinationsversuchen nix erreichen. Und Du sitzt drinnen und grinst…

Korrigiert mich bitte wenn ich falsch liege!

hoba

Irgendwo gab es mal einen "hack" für Releng. In HEAD haben wir das mit den Zertifikaten bereits mit drin (wie alles in HEAD aber natürlich noch nicht großartig getestet).

JeGr

Danke auf jedenfall schonmal an Heiko für die Erläuterung, ich dachte mir schon sowas.
Vielleicht bin ich auch der einzige, der von der OpenBSD Seite kommt, daher authPF kennt und dem ganzen Trouble um Portknocking deshalb mit gerunzelter Stirn gegenübersteht ;)

Um das aber noch kurz einzuflechten: Ich würde auch eine SSH Config mit Zugriff nur mit Zertifikat als durchaus sicher ansehen. Der einzige Fall wo das zu wenig wäre, wäre wohl der, dass der SSHD selbst ein Loch hat. Ansonsten würde ich jahonix da zustimmen.

Aber zurück zu PK/AuthPF: AuthPF funktioniert recht simpel. Der ein oder andere hat ja vielleicht mal ein Auge in die rules.debug geworfen und dort die Anchor gesehen? AuthPF arbeitet ebenfalls damit aber mit definierten Ankern, die zB heißen "rules-anchor authpf" u.a.
Der Knackpunkt ist nun der: Es kann pro User eine authpf.rules erstellt werden, in der ein kompletter PF Regelsatz enthalten ist. Zusätzlich zu den üblichen Makros steht bei AuthPF aber noch $user_IP und $user_ID zur Verfügung. Beim User selbst gibt es eine zusätzliche Shell Option namens "authpf". Ist diese bei einem User gesetzt gibt es folgenden Clou:
Kommt von draußen eine Verbindung auf den SSH Port und wird diese für den User sauber authentifiziert, dann wird für diesen User nachgeschlagen, ob eine authpf.rules in seinem Verzeichnis existiert und diese dann in das aktive Regelwerk eingehängt. Darin darf dann das Alias $user_ip bspw. verwendet werden, um - wieder bspw. - eine Regel zu aktivieren, die der ankommenden IP erlaubt, HTTPS auf das externe WAN_IF des Hosts zu unternehmen.
Durch die userspezifischen beiden Aliase ist damit quasi der Einsatz einer PF Regel von Punkt zu Punkt möglich. Die Pseudo-Shell "authpf" wird benötigt, damit der Benutzer keine Login Shell, sondern nur eine Bestätigung erhält, dass er von IP soundso nun aktiv ist und seine Verbindungen freigeschaltet sind. So kann man den HTTP(S) Port schützen und selbst nach dem Einloggen mittels authpf bleibt der Port nur so lange (und nur von der Quell-IP aus erreichbar), wie die SSH Session des Users offen ist. Da man in jener nichts weiter tun kann als sich ausloggen, droht auch hier dem Host keine Gefahr. Beendet man die Session (meist mit STRG+D) wird der Regelsatz ausgehängt und die States gelöscht.

Hat in meinem ehemaligen Unternehmen wunderbar dazu gedient, einen Windows Server im Notfall von außen erreichbar fernwarten zu können (RDP) und da der Port sonst nicht geöffnet ist, reagiert er natürlich auf Portscans nicht.

Vorteil: Einfach, sicher (Ports sind standard closed und Quell-IP kann mit User_IP Alias definiert gesetzt werden, dass selbst nach dem Einloggen für alle anderen der Port geschlossen scheint)
Nachteil: SSH muss erreichbar bleiben (was mit RSA Key only verschmerzbar scheint)

Aber trotzdem nochmal an Heiko ein dickes Lob für das Sponsoring, ich werde auf jeden Fall mehr als einen Blick in die timebased rules werfen und mir auch das Portknocking ansehen. Wer weiß, vielleicht kommt authpf auch irgendwann. :)

Grüße
Grey

jahonix

…ich bin zufällig wieder über den "SSH Zertifikat" Thread gestolpert und schmeisse den Stein nun in die Runde:

http://forum.pfsense.org/index.php/topic,1741.0.html

heiko

Hallo,
cool solution. wäre bestimmt nen bounty wert ;)
gruß
heiko

JeGr

Oha, der SSH Patch ist ja schon in HEAD eingeflossen. Sehr schick. Wäre eine Idee wert, ob man das vielleicht als Package oder Patch zurückportiert ;)

Und AuthPF wäre sicher interessant, allerdings wird es erst dann richtig interessant, wenn man mehrere Benutzer anlegt (mit entsprechender Login-Shell 'authpf'), insofern müsste da Benutzerverwaltung mit rein, und da das ja ggf. in der nächsten großen Version kommen soll (war da nicht was mit mehreren Usern/Rechten in der GUI?) ist es damit vielleicht einfach umzusetzen, als jetzt, wo es eigentlich nur einen "echten" Benutzer gibt :)

stew

Zum Sinn von Portknocking hier mal mein gewünschter Anwendungszweck:

pfSense läuft bei mir auf einem kleinen stromsparenden embedded System. Meinen PC möchte ich nicht die ganze Zeit anhaben, mich aber gelegentlich von außerhalb per SSH einloggen. Mit einfachem Portknocking könnte ich telnet/ssh auf die zu abzuklopfenden Ports machen, was dann das wake-on-lan Script anschmeißt und eine Minute später kann ich mich per SSH einloggen ohne zusätzliche Software installieren zu müssen.

JeGr

OK dann "ketze" ich weiter: Wofür? pfSense kann bereits selbst WOL Pakete erzeugen und abschicken. Muss also nur von extern zugänglich sein und ein nach außen hin offener SSH Port, seit neuestem mit Möglichkeit nur per Schlüssel einzuloggen (funktioniert gut), erachte ich nicht als dramatische Sicherheitslücke.
Ich habe in der Sicherheitsecke eher die Erfahrung gemacht, dass sobald man versucht etwas krampfhaft zu verstecken, es die entsprechende Kundschaft noch mehr anzieht, als das Offensichtliche, das direkt vor ihrer Nase liegt. Zumal SSH keinen "unüblichen" Port hat.
"Schöner" wäre nur noch, wenn nach dem Einloggen per PubKey das passiert, was ich mit AuthPF meinte, nämlich dass auf die IP, von der ich komme, die Freischaltung für die GUI erfolgt. Das wäre extrem schick.

Grüße
Grey