Ja, aber der "Vorteil" liegt doch eher nur darin, dass dieser Serverdienst nicht so verbreitet ist wie SSH. Wenn er so häufig wie SSH verwendet wird, dann versuchen die Leute halt dort einzubrechen? Logs lesen muss man auch dann. Und da stellt sich mir irgendwie die Frage, ob denn der Code dieses Portknockigservers so robust und getestet ist, wie der SSH-Servercode im allgemeinen.
Hab mir gerade die Sourcen von http://cipherdyne.org/fwknop/download/ runtergeladen und das Changelog angeschaut. Die letzte Vulnerability war 2006 - und das in Crypt::CBC.
Ich denke, man kann von _keinem_ Code sagen, dass er hundertprozentig und in _allen_ Konstellationen getestet wurde.
Meine Absicht ist es, dass der SSH Port nicht offen ist, d.h. eine Firewall diesen Port gaenzlich blockt. Zugriff wird nur ganz bestimmten IPs gegeben, die sich staendig aendern, alles andere wird ausgesperrt.
Mit Sicherheit kann man auch auf andere Art und Weise aehnliches erreichen. Ob man die Logs liest bleibt sowieso jedem selbst ueberlassen - wie das der einzelne macht ist Geschmackssache.
PS: Ich bin uebrigens kein Freund von "Security by Obscurity", denn damit ist nicht wirklich geholfen. Ich sehe es ausserdem auch nicht als "Vorteil", dass diese Software kaum eingesetzt wird. Letztenendes laeuft es immer darauf raus, wenn man eine einzige klitzekleine Luecke/Konfigurationsfehler hat, und die jemand findet, haste Pech gehabt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Jan 2010 um 21:27.
Fwknop scheint vor allem die gefühlte Sicherheit zu erhöhen, nur leider können uns unsere Gefühle oft täuschen. Rational betrachtet machst du einen Port zu und dafür einen anderen auf. Einen Sicherheitsgewinn der mich besser schlafen lassen könnte, kann ich darin nicht erkennen.
Da fwknop weniger eingesetzt wird als SSH, kann man davon ausgehen, dass es weniger getestet und auf Schwachstellen untersucht ist. Die Frage ist dabei nicht, wie viele Sicherheitsprobleme von den Entwicklern im Changelog dokumentiert wurden, sondern wie viele sich tendenziell noch in der Applikation befinden und wie durchdacht das Sicherheitskonzept ist.
Bei SSH geht es in der Hauptsache nicht um Sicherheitslücken, sondern um Brute-Force-Angriffe vor welchen die Anwender Angst haben und sich schützen möchten. Was sich auch sehr einfach durch die Verwendung von SSH-Keys bewerkstelligen lässt. Nur sind diese unbequem, da man sie immer griffbereit haben muss. Wäre es bei der fwknop-Lösung anders, könnte ich darin zumindest einen Vorteil erkennen. Ob ich aber nun einen SSH-Key oder einen GPG-Key griffbereit haben muss, vereinfacht an der Sache nichts.
Nur um nicht missverstanden zu werden: Ich meinte mit "Vorteil" einfach nur, dass die Leute halt vielleicht keinen Portknockingservice vermuten und es deshalb näherungsweise gleich sein lassen.
Das ist aber kein wirklicher Vorteil, wenn man eine weitere Schicht einzieht, die potentiell Konfigurationsfehler und/oder Codeprobleme aufweisen kann.
Ja, aber der "Vorteil" liegt doch eher nur darin, dass dieser Serverdienst nicht so verbreitet ist wie SSH. Wenn er so häufig wie SSH verwendet wird, dann versuchen die Leute halt dort einzubrechen? Logs lesen muss man auch dann. Und da stellt sich mir irgendwie die Frage, ob denn der Code dieses Portknockigservers so robust und getestet ist, wie der SSH-Servercode im allgemeinen.
Hab mir gerade die Sourcen von http://cipherdyne.org/fwknop/download/ runtergeladen und das Changelog angeschaut. Die letzte Vulnerability war 2006 - und das in Crypt::CBC.
Ich denke, man kann von _keinem_ Code sagen, dass er hundertprozentig und in _allen_ Konstellationen getestet wurde.
Meine Absicht ist es, dass der SSH Port nicht offen ist, d.h. eine Firewall diesen Port gaenzlich blockt. Zugriff wird nur ganz bestimmten IPs gegeben, die sich staendig aendern, alles andere wird ausgesperrt.
Mit Sicherheit kann man auch auf andere Art und Weise aehnliches erreichen. Ob man die Logs liest bleibt sowieso jedem selbst ueberlassen - wie das der einzelne macht ist Geschmackssache.
PS: Ich bin uebrigens kein Freund von "Security by Obscurity", denn damit ist nicht wirklich geholfen. Ich sehe es ausserdem auch nicht als "Vorteil", dass diese Software kaum eingesetzt wird. Letztenendes laeuft es immer darauf raus, wenn man eine einzige klitzekleine Luecke/Konfigurationsfehler hat, und die jemand findet, haste Pech gehabt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Jan 2010 um 21:27.Fwknop scheint vor allem die gefühlte Sicherheit zu erhöhen, nur leider können uns unsere Gefühle oft täuschen. Rational betrachtet machst du einen Port zu und dafür einen anderen auf. Einen Sicherheitsgewinn der mich besser schlafen lassen könnte, kann ich darin nicht erkennen.
Da fwknop weniger eingesetzt wird als SSH, kann man davon ausgehen, dass es weniger getestet und auf Schwachstellen untersucht ist. Die Frage ist dabei nicht, wie viele Sicherheitsprobleme von den Entwicklern im Changelog dokumentiert wurden, sondern wie viele sich tendenziell noch in der Applikation befinden und wie durchdacht das Sicherheitskonzept ist.
Bei SSH geht es in der Hauptsache nicht um Sicherheitslücken, sondern um Brute-Force-Angriffe vor welchen die Anwender Angst haben und sich schützen möchten. Was sich auch sehr einfach durch die Verwendung von SSH-Keys bewerkstelligen lässt. Nur sind diese unbequem, da man sie immer griffbereit haben muss. Wäre es bei der fwknop-Lösung anders, könnte ich darin zumindest einen Vorteil erkennen. Ob ich aber nun einen SSH-Key oder einen GPG-Key griffbereit haben muss, vereinfacht an der Sache nichts.
Nur um nicht missverstanden zu werden: Ich meinte mit "Vorteil" einfach nur, dass die Leute halt vielleicht keinen Portknockingservice vermuten und es deshalb näherungsweise gleich sein lassen.
Das ist aber kein wirklicher Vorteil, wenn man eine weitere Schicht einzieht, die potentiell Konfigurationsfehler und/oder Codeprobleme aufweisen kann.