Login
Newsletter
Werbung

Thema: fwknopd - Portknocking der nächsten Generation

14 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von free-radical am So, 17. Januar 2010 um 22:30 #

Irgendwie ist euer Link im RSS Feed defekt?! Da bekomme ich

http://www.pro-linux.de/NB3/artikel/1/1177/fwknopd-portknocking-der-naechsten-generation.html

für den Artikel, was dann aber ins Leere führt. Über den Google-Umweg finde ich dann

http://www.pro-linux.de/NB3/artikel/2/1177/fwknopd-portknocking-der-naechsten-generation.html


Grüsse

[
| Versenden | Drucken ]
  • 0
    Von bla am Mo, 18. Januar 2010 um 00:06 #

    es reicht auch die seiteninterne suchfunktion, um den artikel zu finden. den falschen link im feed kann ich bestätigen.

    [
    | Versenden | Drucken ]
    • 0
      Von Demon am Mo, 18. Januar 2010 um 00:23 #

      Das Problem betrifft lediglich die RSS und die "neue Artikel" und wird in dem kommenden Build behoben. Alle anderen Links (Startseite, Magazin, Suche, usw.) sollten stimmen.

      Gruss,
      demon

      [
      | Versenden | Drucken ]
0
Von 1ras am Mo, 18. Januar 2010 um 03:30 #

Mir erschließt sich der Vorteil nicht, nun anstelle eines SSH-Keys einen GPG-Key dabei haben zu müssen.

[
| Versenden | Drucken ]
  • 0
    Von Rantanplan am Mo, 18. Januar 2010 um 08:43 #

    ich find portknocker auch nicht allzu sinnvoll.

    den einizigen vorteil, den ich sehe: wenn man eine reihe von nicht öffentlichen diensten laufen hat (imap, xmpp, ...) kann man sie so bei nicht-benutzung zentral absichern.

    ich persönlich handhabe es so, dass ich - sofern viel "sicherheit" gewünscht ist und der rechner unbedingt am netz hängen muss - alles über ein vpn laufen lassen.

    [
    | Versenden | Drucken ]
    • 0
      Von tpreissler am Di, 19. Januar 2010 um 00:27 #

      Wie ich im anderen Post geschrieben habe, wenn man ALLE Serverlogs liest, ist man froh, auf einige hundert Zeilen verzichten zu koennen.

      Das mit dem VPN ist eine gute Idee.

      Wenn man einen Server betreibt mit mehreren oeffentlichen Webseiten, kann dies ganz sinnvoll sein, aber das steht jedem selbst frei, was er zur Sicherheit macht. Ich will jedenfalls ruhig schlafen und wissen, es sind x Ports offen, da sie offen sein muessen und das wars.

      [
      | Versenden | Drucken ]
    0
    Von tpreissler am Di, 19. Januar 2010 um 00:23 #

    Weil der SSH-Port an Deinem Server offen sein musst. Ich lese taeglich _alle_ Serverlogs auf irgendwelche Probleme und da bin ich froh wenn einige hundert Zeilen SSH Bruteforce einfach nicht gelistet werden, weil es diese einige hundert User auf meinem System einfach nicht gibt. Sicherlich koennte ich die Benachrichtigung so konfigurieren, dass ich diese Emails einfach nicht bekomme, oder generell SSH Publickeys verwende... aber es gibt immer verschiedene Ansaetze.

    Wenn ich weiss, SSH ist dicht, wenn ich nicht eingeloggt bin, KOMPLETT dicht, dann kann ich einfach besser schlafen.

    Dies kann man auf ALLE Ports anwenden, die man nur selber verwendet und nicht offen sein muessen fuer die weite Welt. Je weniger Angriffsflaeche desto besser, sicher nicht uberraschend.


    Zugegebenermassen, ich finde diese Methode einfach cool, mittels GPG Keys Portknocking zu betreiben. Ich verwende GPG sehr viel, daher...

    [
    | Versenden | Drucken ]
    • 0
      Von kanuba am Di, 19. Januar 2010 um 21:00 #

      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.

      [
      | Versenden | Drucken ]
      • 0
        Von tpreissler am Di, 19. Januar 2010 um 21:24 #

        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.
        [
        | Versenden | Drucken ]
        • 0
          Von 1ras am Mi, 20. Januar 2010 um 11:37 #

          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.

          [
          | Versenden | Drucken ]
          • 0
            Von kanuba am Mi, 20. Januar 2010 um 18:56 #

            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.

            [
            | Versenden | Drucken ]
mehr MD5
0
Von MD5 am Mo, 18. Januar 2010 um 17:24 #

MD5 ? Sollte man nicht schön langsam auf die aktuellen SHA Versionen zurückgreifen ?

[
| Versenden | Drucken ]
  • 0
    Von tpreissler am Di, 19. Januar 2010 um 00:16 #

    Das ist m.A. in diesem Fall eigentlich egal, da MD5 hier nur zur Pruefsummenbildung verwendet wird.
    Die Kombination von verschiedenen Verfahren hier (zufaellige Daten, Verschluesselung mit GPG oder Passphrase) gewaehrleistet, dass es nicht anfaellig fuer Replay-Attacken ist. Der Angreifer muesste noch immer entweder die Passphrase haben oder den GPG Key - das ist die beweitem groesste Huerde. Wenn er das schafft, wuerde auch SHA kein Problem darstellen (ich meine, den Aufwand den er betreiben muss, um den GPG Key oder die Passphrase zu knacken ist, ist bedeutend groesser als MD5.)

    [
    | Versenden | Drucken ]
0
Von Hans Olo am Sa, 23. Januar 2010 um 15:19 #

Das Portknocking vor das ssh zu setzen sehe ich ja noch ein, ein funktionierender Sicherheitsmechanismus wird mit einem weiteren, wenn auch von zweifelhafter Sicherheit 'verstärkt' - wer das portknockign überwindet hat immer noch ssh vor sich.
Soweit wäre das ja durchaus ein kleiner Schutz vor dem absoluten Supergau ssh-remmote exploit.
"Single Packet Authorisation" mit der Möglichkeit, befehle auszuführen zerstört diesen kleinen Sicherheitsgewinn hingegen vollends.
Man muss sich verdeutlichen, wass portknocking überhaupt tut: Es wird im Grunde ein ein eigenes In-Band Protokoll innerhalb von TCP gebaut, auf dem dann eine sicherheitstechnische Neuimplementierung des Rades gesprochen wird.
Mit SPA wird nun eine lange erprobte und von Experten erdachte Technologie (ssh) durch die fixe Idee eines Entwicklers ersetzt.
Aufgrund der geringen Verbreitung werden sich sicher auch noch viele Fehler in der Implementierung finden, so dass ein Angreifer vermutlich nicht einmal die Schwächen des Protokolls finden müsste - die es aber mit sehr großer Wahrscheinlichkeit auch gibt.
Zusammengefasst ist das snakeoil security by obscurity, die auch noch ssh umgehen kann - tolle Wurst.

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung