ssh delay gegen unerwunschte logins
Hallo Liste unsere Systeme mit offenem ssh-Port werden laufend mit allen erdenklichen Namen gescannt, bzw. wird versucht ein login zu erreichen. Ich empfinde es als sehr störend und überlege nach Abhilfemassnahmen. Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten. In dieser Zeit würden keine Anfragen mehr beantwortet. Eine solche Einstellmöglichkeit habe ich für Konsole-Logins bei Yast gefunden. Gibt es dies auch für ssh? Wie und wo ist es zu setzen? Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken? Herzlichen Dank für jede Antwort und ein gutes neues Jahr an Alle Bernhard
Bernhard Bühler, Mittwoch, 28. Dezember 2005 10:08:
Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten.
Damit wäre ein DoS leicht, weil Du dann auch selbst nur noch schwer auf Deine Kiste kommst. D.h. Du müßtest es auf die jeweilige IP beschränken.
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
Ich hab den sshd auf einem anderen Port laufen. Das führt zu einer Abnahme der unerwünschten Versuche um mindestens 99%. -- Andre Tann
Hallo Bernhard, Am Mittwoch, 28. Dezember 2005 10:08 schrieb Bernhard Bühler:
unsere Systeme mit offenem ssh-Port werden laufend mit allen erdenklichen Namen gescannt, bzw. wird versucht ein login zu erreichen. Ich empfinde es als sehr störend und überlege nach Abhilfemassnahmen.
Hatte ich auch eine Zeit lang.
Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten. In dieser Zeit würden keine Anfragen mehr beantwortet. Eine solche Einstellmöglichkeit habe ich für Konsole-Logins bei Yast gefunden. Gibt es dies auch für ssh? Wie und wo ist es zu setzen?
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
Ich benutze für dieses Problem fail2ban (http://fail2ban.sourceforge.net/). Dieses beobachtet die logfiles und wenn wer versucht übermässig viel einzuloggen kann man eine Aktion ausführen. Ich benutzt in dem Zusammenhang auch noch TARPIT für iptables (http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT). So werden solche würmer/botnetze schön ausgebremst und ich hab meine Ruhe. Gruß Tim -- http://we-are-teh-b.org/~tim/
Hallo Tim danke für deine Antwort. Ich bin etwas erstaunt, dass meine Anfrage eine kleine Diskussion über für und wieder, usw. ausgelöst hat. Ich werde mir deine Lösung einmal in Betrieb nehmen und sehen wie es sich entwickelt. Ein weiterer guter Lösungsweg wäre noch s. Mail von Thomas Becker. Am Mittwoch, 28. Dezember 2005 10.43 schrieb Tim Daniel Schumacher:
Hallo Bernhard,
Am Mittwoch, 28. Dezember 2005 10:08 schrieb Bernhard Bühler:
unsere Systeme mit offenem ssh-Port werden laufend mit allen erdenklichen Namen gescannt, bzw. wird versucht ein login zu erreichen. Ich empfinde es als sehr störend und überlege nach Abhilfemassnahmen.
Hatte ich auch eine Zeit lang.
Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten. In dieser Zeit würden keine Anfragen mehr beantwortet. Eine solche Einstellmöglichkeit habe ich für Konsole-Logins bei Yast gefunden. Gibt es dies auch für ssh? Wie und wo ist es zu setzen?
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
Ich benutze für dieses Problem fail2ban (http://fail2ban.sourceforge.net/). Dieses beobachtet die logfiles und wenn wer versucht übermässig viel einzuloggen kann man eine Aktion ausführen. Ich benutzt in dem Zusammenhang auch noch TARPIT für iptables (http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT). So werden solche würmer/botnetze schön ausgebremst und ich hab meine Ruhe.
Gruß
Tim
Grüsse und ein gutes neues Jahr Bernhard
Quoting Bernhard Bühler
unsere Systeme mit offenem ssh-Port werden laufend mit allen erdenklichen Namen gescannt, bzw. wird versucht ein login zu erreichen.
Na und?
Ich empfinde es als sehr störend
Warum?
und überlege nach Abhilfemassnahmen.
Public Key Authentifizierung benutzen oder wenigstens auf sichere und ausreichend lange Passwörter achten. Am besten beides. Eventuell kannst Du auch per iptables den Adreßbereich beschränken, von dem aus man an den SSH-Port kommt.
Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten.
Womit man Dich dann wunderbar DoSen kann.
In dieser Zeit würden keine Anfragen mehr beantwortet. Eine solche Einstellmöglichkeit habe ich für Konsole-Logins bei Yast gefunden. Gibt es dies auch für ssh? Wie und wo ist es zu setzen?
Das ist keine gute Idee. Man braucht Dich dann nur noch mit falschen Anmeldedaten zuzumüllen - am besten auch noch von gespooften IPs aus - und schon könntest Du Deinen sshd genausogut gleich komplett abschalten.
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Erhard Schwenk, Mittwoch, 28. Dezember 2005 11:11:
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Was ist daran gefährlich? Wenn der sshd an Port 30000 statt an Port 22 lauscht, dann ergibt sich doch kein Risikounterschied. Worin besteht die Gefahr beim Portknocking? Wohl aber sind die Maßnahmen keineswegs wirkungslos: ich beobachte, daß die Anzahl der Unterhaltungsversuche mit dem sshd gegen Null geht, sobald ich irgend einen hohen Port einstelle. Und das ist doch schon mal was, und wenn es nur die Übersichtlichkeit des Logfiles ist. Davon abgesehen: Die Verwendung eines Paßwortes oder eines Public Keys ist letztlich auch nur Security by Obscurity. -- Andre Tann
* Andre Tann wrote on Wed, Dec 28, 2005 at 11:35 +0100:
Erhard Schwenk, Mittwoch, 28. Dezember 2005 11:11:
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Was ist daran gefährlich? Wenn der sshd an Port 30000 statt an Port 22 lauscht, dann ergibt sich doch kein Risikounterschied.
Gefährlich an "Security by Obscurity" ist, dass es suggeriert, es wäre ein Unterschied - ist's aber nicht. Ein brauchbarer Portscanner bekommt SSH ganz einfach und sicher raus (SSH meldet sich ja entsprechend). Also "indirekt gefährlich". Jetzt, wo Du weniger scans siehst, denkst Du vielleicht, kurze Passwörter reichen ja doch - oder sowas in der Art.
Wohl aber sind die Maßnahmen keineswegs wirkungslos: ich beobachte, daß die Anzahl der Unterhaltungsversuche mit dem sshd gegen Null geht, sobald ich irgend einen hohen Port einstelle.
Na ja, die Anfragen werden konstant sein, bloss schon vom IP Stack abgewiesen. Spart natürlich ein Fork, Traffic und CPU Last, klar.
Und das ist doch schon mal was, und wenn es nur die Übersichtlichkeit des Logfiles ist.
IMHO sollte man logfiles eh automatisch auswerten (lassen), ich verwende mein kleines logmail (http://sws.dett.de/logmail/) und lass den Kram gleich rausfiltern.
Davon abgesehen: Die Verwendung eines Paßwortes oder eines Public Keys ist letztlich auch nur Security by Obscurity.
Nein, ist es nicht. Selbst wenn Du das Verfahren kennst, nützt es Dir nichts. Wenn ich weiss, das Dein SSH auf Port 30000 läuft, kann ich ihn angreifen, wie wenn er auf 22 laufen würde. Der Einzige Unterschied hier ist, ob ich den Algorithmus (port + 29978) kenne, oder nicht. Keine Sicherheit, weil solche Geheimnisse selten welche bleiben. Vielleicht liest die Angreiferin mit und korrgiert gerade den auto-rooter :) Bei einem Public Key Verfahren ist der Algorithmus bekannt (sogar in Sourcen :)), aber es ist trozdem nicht so leichter angreifbar, als wäre es ein Geheimnis: die Sicherheit kommt nicht daher, sondern von einem individuellen Geheimnis (dem Schlüssel). Da muss man dann 1024 bit RSA oder vergleichbar "raten", was durchaus zu praktischen Problemen führt :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Steffen Dettmer, Mittwoch, 28. Dezember 2005 16:34:
Gefährlich an "Security by Obscurity" ist, dass es suggeriert, es wäre ein Unterschied - ist's aber nicht.
Man muß natürlich wissen, was man tut, klar.
Ein brauchbarer Portscanner bekommt SSH ganz einfach und sicher raus (SSH meldet sich ja entsprechend). Also "indirekt gefährlich". Jetzt, wo Du weniger scans siehst, denkst Du vielleicht, kurze Passwörter reichen ja doch - oder sowas in der Art.
Im Gegenteil - Leute, die meinen sshd auf einem krummen Port finden, sind gefährlicher als die, die es nur bis zum Port 22 schaffen.
Davon abgesehen: Die Verwendung eines Paßwortes oder eines Public Keys ist letztlich auch nur Security by Obscurity.
Nein, ist es nicht. Selbst wenn Du das Verfahren kennst, nützt es Dir nichts. Wenn ich weiss, das Dein SSH auf Port 30000 läuft, kann ich ihn angreifen, wie wenn er auf 22 laufen würde. Der Einzige Unterschied hier ist, ob ich den Algorithmus (port + 29978) kenne, oder nicht. Keine Sicherheit, weil solche Geheimnisse selten welche bleiben. Vielleicht liest die Angreiferin mit und korrgiert gerade den auto-rooter :)
Doch, es ist Security by Obscurity. Wenn ich den Port des sshd nicht kenne, dann muß ich ihn suchen. Das ist soviel wie ein brute force Angriff auf ein Paßwort mit 3-4 Stellen (26^3 = ca. 17.000, 26^4 = ca. 450.000; es gibt ca. 65.000 Ports). Nimm an, ich hätte ein Paßwort mit einem Buchstaben an Länge. Dann muß ich diesen Buchstaben finden, indem ich alle durchprobiere. Irgendwann habe ich ihn. Wären es zwei Buchstaben, dann suche ich eben etwas länger. Bei drei Stellen suche ich etwa so lange, wie ich brauche, den richtigen Port rauszufinden. Bei zehn Buchstaben suche ich dann eben noch etwas länger, und spätestens bei 30 Buchstaben wirds ungemütlich, aber ich brauche nur zu suchen, irgendwann habe ich auch dieses Paßwort geknackt, und zwar mit Sicherheit. Ebenso verhält es sich bei Public Key Verfahren. Algorithmus hin, Bekanntheit her: ich brauche nur zu suchen: irgendwann habe ich den Key erraten. Zwar reicht die gesamte verfügbare Energie dafür vermutlich nicht. Aber das ändert nichts am Prinzip. Es bleibt security by obscurity. -- Andre Tann
* Andre Tann wrote on Wed, Dec 28, 2005 at 17:36 +0100:
Steffen Dettmer, Mittwoch, 28. Dezember 2005 16:34:
Gefährlich an "Security by Obscurity" ist, dass es suggeriert, es wäre ein Unterschied - ist's aber nicht.
Man muß natürlich wissen, was man tut, klar.
Ja, genau. Die Idee hier war ja nur, dass der Portwechsel nichts "sicherer" macht. Du hast das ja auch nicht gemacht, damit es sicherer wird, sondern um die Logfiles zu entlasten. Du weisst also, was Du tust.
Ein brauchbarer Portscanner bekommt SSH ganz einfach und sicher raus (SSH meldet sich ja entsprechend). Also "indirekt gefährlich". Jetzt, wo Du weniger scans siehst, denkst Du vielleicht, kurze Passwörter reichen ja doch - oder sowas in der Art.
Im Gegenteil - Leute, die meinen sshd auf einem krummen Port finden, sind gefährlicher als die, die es nur bis zum Port 22 schaffen.
Wieso "Gegenteil", sind IMHO zwei Sachen. Solange Du die Sicherheit nicht vernachlässigst, weil ja "weniger Scans" gemacht werden, ist ja alles in Ordnung. Andere könnten möglicherweise denken: meinen Port findet ja eh keiner, also wozu 8 stellige Passwörter, 4 Zeichen reichen ja auch. Oder sowas. Das wäre dann IMHO ein Beispiel für Gefahren von "Security by Obscurity". Aber wenn Du trotzdem gute Passwörter oder noch besser, gar keine und nur Keys verwendest, ist natürlich alles in Butter. [...]
Der Einzige Unterschied hier ist, ob ich den Algorithmus (port + 29978) kenne, oder nicht. Keine Sicherheit, weil solche Geheimnisse selten welche bleiben. Vielleicht liest die Angreiferin mit und korrgiert gerade den auto-rooter :)
Doch, es ist Security by Obscurity. Wenn ich den Port des sshd nicht kenne, dann muß ich ihn suchen. Das ist soviel wie ein brute force Angriff auf ein Paßwort mit 3-4 Stellen (26^3 = ca. 17.000, 26^4 = ca. 450.000; es gibt ca. 65.000 Ports).
Na ja, nicht ganz. Zum einen kann man Scans parallelisieren. Weiterhin könnte man durch traffic-Mitschnitte den SSH-Port "sehen" - "im Klartext", da in so einem Fall ja der Port im TCP Paket übertragen werden würde (was bei Passwörtern von SSH ja nie gemacht wird). Weiterhin sind (langsame, multi-source, ...) Portscans schwieriger zu erkennen, also erfolglose SSH-Authentifizierungsversuche - und es geht mit viel weniger Rechenaufwand (sprich: eine Angreiferin kann vielleicht drei SSH Passwörter brute-forcen, weil sie nur einen P500 am E3 hat, mit der gleichen Ausstattung aber zwanzig oder hundert hosts Portscannen). Ist natürlich recht theoretisch, klar.
Bei zehn Buchstaben suche ich dann eben noch etwas länger, und spätestens bei 30 Buchstaben wirds ungemütlich, aber ich brauche nur zu suchen, irgendwann habe ich auch dieses Paßwort geknackt, und zwar mit Sicherheit.
Bei 1000 Versuchen pro Sekunde sind das: 26^30/1000/60/60/24/356 == 91.461.158.619.588.337.470.694.868.056.074 Jahre. Das Universum ist aber nur 15.000.000.000 Jahre alt und möglicherweise in schon 15.000.000.000.000 Jahren so kalt, dass Du keinen Strom mehr für den PC bekommst :-) Daher würde ich ein 30-Zeichen-Passwort als "praktisch unerratbar" einstufen. Aber natürlich hast Du Recht, man könnte ja zufällig "OkWXEJUJ0WT*Dz+EdLgQxihnKb6kCZ" als Passwort haben und als ersten Versuch raten, obwohl es statistisch natürlich 45.730.579.309.794.168.735.347.434.028.037 Jahre dauern würde :)
Ebenso verhält es sich bei Public Key Verfahren. Algorithmus hin, Bekanntheit her: ich brauche nur zu suchen: irgendwann habe ich den Key erraten. Zwar reicht die gesamte verfügbare Energie dafür vermutlich nicht.
Ja, das mit der Universums-Gesammt-Energie ist aber ein ernstes Problem... Auch preislich: für diese Kosten (also kurz: alles) macht es keinen Sinn, Dein Geheimnis zu erraten, weil es ungleich billiger ist, sich das komplette Sonnensystem atomgenau (oder auch Quantenzustandsgenau) nachzubauen. Man kann Dich auch einfach entführen und Dir eine Pistole an den Kopf setzen, ist sicherlich für wenige tausend Dollar zu machen, vielleicht ne Million, egal, alles Spielgeld im Vergleich zu "alles" :-) Sicherheit muss nur deutlich teurer als der Wert der zu schützendes Geheimnisses sein. Ist es teurer, eine Bank anzugreifen als sie zu kaufen, wird man sie nicht angreifen (sondern kaufen) :-) Ein anderes Beispiel eines RSA Angriffs besagte in etwa folgendes: Wenn man einen ganz leichten Speicher hätte (also Tesafilm mit superhoher Speicherdichte), müsste man dennoch so viele Zwischenergebnisse speichern (bei dictionary-style-attack), dass man so viele Tesafilmrollen bräuchte, dass deren Masse (um Grössenordnungen!) über der kritischen Masse eines schwarzen Lochs läge, so dass man das Ergebnis am Ende auch nicht so recht nutzen könnte :-)
Aber das ändert nichts am Prinzip. Es bleibt security by obscurity.
Was ist an 45.730.579.309.794.168.735.347.434.028.037 Jahren obskur? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Moin Steffen, ich denke, wir sehen die Dinge ähnlich. Eines aber will ich doch noch sagen;) Steffen Dettmer, Donnerstag, 29. Dezember 2005 16:54:
Aber das ändert nichts am Prinzip. Es bleibt security by obscurity.
Was ist an 45.730.579.309.794.168.735.347.434.028.037 Jahren obskur?
ob'scurity s 1. Unklarheit f. 2. Unbekanntheit f. An der von Dir genannten Anzahl von Jahren ist also nichts obskur. BTW: wie hast Du denn diese Zahl ausgerechnet? Mein Taschenrechner zeigt irgendwie nicht ganz so viele Stellen an. -- Andre Tann
* Andre Tann wrote on Thu, Dec 29, 2005 at 17:59 +0100:
Steffen Dettmer, Donnerstag, 29. Dezember 2005 16:54: [...]
45.730.579.309.794.168.735.347.434.028.037 Jahren [...] BTW: wie hast Du denn diese Zahl ausgerechnet? Mein Taschenrechner zeigt irgendwie nicht ganz so viele Stellen an.
Taschenrechner? Du sitzt vor'm Linux-PC und kramst einen Taschenrechner raus? :-) Für grosse Zahlen ist bc ("An arbitrary precision calculator language") IMHO gut geeignet: $ echo "26^30/2/1000/60/60/24/356"|bc 45730579309794168735347434028037 oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Quoting Steffen Dettmer
* Andre Tann wrote on Wed, Dec 28, 2005 at 17:36 +0100:
Steffen Dettmer, Mittwoch, 28. Dezember 2005 16:34:
Gefährlich an "Security by Obscurity" ist, dass es suggeriert, es wäre ein Unterschied - ist's aber nicht.
Man muß natürlich wissen, was man tut, klar.
Ja, genau. Die Idee hier war ja nur, dass der Portwechsel nichts "sicherer" macht. Du hast das ja auch nicht gemacht, damit es sicherer wird, sondern um die Logfiles zu entlasten. Du weisst also, was Du tust.
Logfiles entlasten geht einfacher. Nur die wirklich benötigten Informationen überhaupt loggen, logrotate , Quotas setzen oder Logs in ein eigenes Filesystem packen.
Ein brauchbarer Portscanner bekommt SSH ganz einfach und sicher raus (SSH meldet sich ja entsprechend). Also "indirekt gefährlich". Jetzt, wo Du weniger scans siehst, denkst Du vielleicht, kurze Passwörter reichen ja doch - oder sowas in der Art.
Im Gegenteil - Leute, die meinen sshd auf einem krummen Port finden, sind gefährlicher als die, die es nur bis zum Port 22 schaffen.
Der Zeitgewinn ist bei relevanten Angriffen marginal. Auf die Abwehr ohnehin irrelevanter Angriffe sollte man keine Zeit verschwenden. Angriffe, die an Authentifizierungsmechanismen scheitern, sind irrelevant, denn genau dazu sind Authentifizierungsmechanismen da.
Wieso "Gegenteil", sind IMHO zwei Sachen. Solange Du die Sicherheit nicht vernachlässigst, weil ja "weniger Scans" gemacht werden, ist ja alles in Ordnung. Andere könnten möglicherweise denken: meinen Port findet ja eh keiner, also wozu 8 stellige Passwörter, 4 Zeichen reichen ja auch. Oder sowas. Das wäre dann IMHO ein Beispiel für Gefahren von "Security by Obscurity". Aber wenn Du trotzdem gute Passwörter oder noch besser, gar keine und nur Keys verwendest, ist natürlich alles in Butter.
Man sollte wenn möglich Passwörter _und_ Keys verwenden, denn Private Keys können durchaus abhanden kommen. Wenn das nicht geht (z.B. automatisierter Login), benutzt man entsprechend lange Schlüssel. Wenn das auch nicht geht (z.B. Login von nicht kontrollierbaren Rechnern aus), sollte man sich _sehr_ gut überlegen, ob man üerhaupt noch eine Authentifizierung braucht.
Der Einzige Unterschied hier ist, ob ich den Algorithmus (port + 29978) kenne, oder nicht. Keine Sicherheit, weil solche Geheimnisse selten welche bleiben. Vielleicht liest die Angreiferin mit und korrgiert gerade den auto-rooter :)
Doch, es ist Security by Obscurity.
Ist es, in der Tat.
Wenn ich den Port des sshd nicht kenne, dann muß ich ihn suchen. Das ist soviel wie ein brute force Angriff auf ein Paßwort mit 3-4 Stellen (26^3 = ca. 17.000, 26^4 = ca. 450.000; es gibt ca. 65.000 Ports).
Es gibt viele Möglichkeiten, das rauszukriegen. Der "Brute Force Angriff" ist aber bereits in wenigen Sekunden durchführbar, und es gibt dafür mit Sicherheit auch schon Baukasten-Software zum Zusamenklicken.
Na ja, nicht ganz. Zum einen kann man Scans parallelisieren. Weiterhin könnte man durch traffic-Mitschnitte den SSH-Port "sehen" - "im Klartext", da in so einem Fall ja der Port im TCP Paket übertragen werden würde (was bei Passwörtern von SSH ja nie gemacht wird).
Eben.
Weiterhin sind (langsame, multi-source, ...) Portscans schwieriger zu erkennen, also erfolglose SSH-Authentifizierungsversuche - und es geht mit viel weniger Rechenaufwand (sprich: eine Angreiferin kann vielleicht drei SSH Passwörter brute-forcen, weil sie nur einen P500 am E3 hat, mit der gleichen Ausstattung aber zwanzig oder hundert hosts Portscannen).
Genau.
Ist natürlich recht theoretisch, klar.
Nein. Das ist die Praxis. Bevor man Port Knocking einführt, verlängert man lieber das Passwort um 4 Zeichen, das ist viel weniger Aufwand und erreicht ein höheres Sicherheitsniveau.
Bei zehn Buchstaben suche ich dann eben noch etwas länger, und spätestens bei 30 Buchstaben wirds ungemütlich, aber ich brauche nur zu suchen, irgendwann habe ich auch dieses Paßwort geknackt, und zwar mit Sicherheit.
Bei 1000 Versuchen pro Sekunde sind das: 26^30/1000/60/60/24/356 == 91.461.158.619.588.337.470.694.868.056.074 Jahre. Das Universum ist aber nur 15.000.000.000 Jahre alt und möglicherweise in schon 15.000.000.000.000 Jahren so kalt, dass Du keinen Strom mehr für den PC bekommst :-)
Daher würde ich ein 30-Zeichen-Passwort als "praktisch unerratbar" einstufen.
Du solltest in die Rechnung einbeziehen, daß laut Moores Gesetz die Rechenkapazität (und damit die Anzahl der Versuche pro Sekunde) sich ungefähr jedes Jahr verdoppelt. Außerdem ist die Aufgabe gut parallelisierbar und 1000 Versuche/Sekunde sind schon heute lächerlich.
Aber natürlich hast Du Recht, man könnte ja zufällig "OkWXEJUJ0WT*Dz+EdLgQxihnKb6kCZ" als Passwort haben und als ersten Versuch raten, obwohl es statistisch natürlich 45.730.579.309.794.168.735.347.434.028.037 Jahre dauern würde :)
Das nennt man "kalkuliertes Restrisiko". Der Punkt ist: man kann exakt ausrechnen, wie groß dieses ist. Bei "Security by Obscurity" kann man exakt das nicht.
Ebenso verhält es sich bei Public Key Verfahren. Algorithmus hin, Bekanntheit her: ich brauche nur zu suchen: irgendwann habe ich den Key erraten. Zwar reicht die gesamte verfügbare Energie dafür vermutlich nicht.
Ja, das mit der Universums-Gesammt-Energie ist aber ein ernstes Problem...
Der Punkt ist ein anderer: auch hier ist das Restrisiko berechenbar. Und es ist _sehr_ klein. Das Restrisiko von "Obscurity"-Maßnahmen ist gerade nicht berechenbar. Und muß damit als unendlich groß angenommen werden.
Sicherheit muss nur deutlich teurer als der Wert der zu schützendes Geheimnisses sein.
Du meinst, der erfolgreiche Angriff muß teurer sein als der Schutzwert. Das stimmt nur bedingt. Manchmal muß ein erfolgreicher Angriff teurer sein als der anrichtbare Schaden, was nicht das gleiche ist. Und manchmal hat man es mit Angreifern zu tun (Skriptkiddies sind dafür ein Beispiel), denen der mit dem Angriff erzielbare materielle Gewinn oder Verlust völlig egal ist.
Ist es teurer, eine Bank anzugreifen als sie zu kaufen, wird man sie nicht angreifen (sondern kaufen) :-)
Es sei denn, man begreift das Angreifen von Banken als Sport und tut es nicht wegen des Geldes. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Quoting Andre Tann
Erhard Schwenk, Mittwoch, 28. Dezember 2005 11:11:
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Was ist daran gefährlich?
Zunächst einmal ist es wirkungslos. Falsche SSH-Logins ablehnen kann SSH ganz alleine, da braucht man nicht noch irgendwas davor. Es erhöht aber die Komplexität, erschwert die eigene Diagnose - und schafft damit potentielle Fehlerquellen, die per se eine Gefahr für die Sicherheit darstellen.
Wenn der sshd an Port 30000 statt an Port 22 lauscht, dann ergibt sich doch kein Risikounterschied. Worin besteht die Gefahr beim Portknocking?
Portknocking ist nichts anderes als der Versuch, eine Abfolge von Ports als Schlüssel zu verwenden. Mehr als ein gescheites Passwort ohnehin erreicht, kann man damit prinzipell nicht gewinnen. Allerdings wird dieser "Schlüssel" bei Portknocking ungesichert übertragen (jeder kann den "Schlüssel" mit einem einfachen IP-Sniffer mitlesen), und es wird auf beiden Seiten der Verbindung deutlich komplexere Logik gebraucht als bei einer Passwort- oder Public-Key-Prüfung. Zusätzliche Komplexität bedeutet zwangsläufig zusätzliche Fehlerquellen und damit zusätzliches Risiko. Anstatt umständlich Portknocking aufzusetzen, ist es viel einfacher und aus Sicherheitsgesichtspunkten wirkungsvoller, die verwendeten Passwörter zu verlängern oder die Länge des Public Key.
Wohl aber sind die Maßnahmen keineswegs wirkungslos:
Doch, natürlich sind sie das.
ich beobachte, daß die Anzahl der Unterhaltungsversuche mit dem sshd gegen Null geht,
Die Anzahl der Unterhaltungs_versuche_ mit Deinem SSH ist aus Sicherheitsgesichtspunkten völlig irrelevant. Relevant wäre einzig und alleine die Anzahl der unauthorisierten Logins und die der erfolgreichen Exploits. Die verändert sich aber bei Verschieben auf einen anderen Port oder Portknocking erstmal nicht. Das maximale was bei abgewiesenen SSH-Connects passieren kann ist ein Log-Überlauf. Dagegen muß man sich aber ohnehin absichern - und das geht am besten mit quotas und logrotate oder durch Verlagern von /var/log auf ein eigenes Volume.
sobald ich irgend einen hohen Port einstelle. Und das ist doch schon mal was, und wenn es nur die Übersichtlichkeit des Logfiles ist.
Die Übersichtlichkeit des Logfiles schfft man sich bei Bedarf mit grep. Ob da noch ein bißchen SSH-Rauschen gefiltert wird, ist sowas von egal.
Davon abgesehen: Die Verwendung eines Paßwortes oder eines Public Keys ist letztlich auch nur Security by Obscurity.
*seufz* [ ] Du hast verstanden, was "Security by Obscurity" bedeutet. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Am Don, 29 Dez 2005, schrieb Erhard Schwenk: [...]
Portknocking ist nichts anderes als der Versuch, eine Abfolge von Ports als Schlüssel zu verwenden. Mehr als ein gescheites Passwort ohnehin erreicht, kann man damit prinzipell nicht gewinnen.
Es ist eine zusätzliche Sicherung des Servers!
Allerdings wird dieser "Schlüssel" bei Portknocking ungesichert übertragen (jeder kann den "Schlüssel" mit einem einfachen IP-Sniffer mitlesen), und es wird auf beiden Seiten der Verbindung deutlich komplexere Logik gebraucht als bei einer Passwort- oder Public-Key-Prüfung. Zusätzliche Komplexität bedeutet zwangsläufig zusätzliche Fehlerquellen und damit zusätzliches Risiko. Anstatt umständlich Portknocking aufzusetzen, ist es viel einfacher und aus Sicherheitsgesichtspunkten wirkungsvoller, die verwendeten Passwörter zu verlängern oder die Länge des Public Key.
Was sprich denn deiner Meinung nach dagegen, beides einzusetzen? Meiner Meinung nach hast du einen erheblichen Sicherheitsgewinn. Ausserdem fallen sämtliche ssh-Angriffe flach. Schließlich kannst du mit Portknocking den ssh-Port komplett dicht machen und nur nach Bedarf öffnen. Somit wird für die meisten Angreifer dein Rechner eh uninteressant. Grüße PeteR
Quoting Peter Soltau
Am Don, 29 Dez 2005, schrieb Erhard Schwenk:
Portknocking ist nichts anderes als der Versuch, eine Abfolge von Ports als Schlüssel zu verwenden. Mehr als ein gescheites Passwort ohnehin erreicht, kann man damit prinzipell nicht gewinnen.
Es ist eine zusätzliche Sicherung des Servers!
Die weniger bringt als ein simples Verlängern der Passwort-Policy um drei Zeichen Mindestlänge oder eines Public SSH-Key um 16 Bit.
Allerdings wird dieser "Schlüssel" bei Portknocking ungesichert übertragen (jeder kann den "Schlüssel" mit einem einfachen IP-Sniffer mitlesen), und es wird auf beiden Seiten der Verbindung deutlich komplexere Logik gebraucht als bei einer Passwort- oder Public-Key-Prüfung. Zusätzliche Komplexität bedeutet zwangsläufig zusätzliche Fehlerquellen und damit zusätzliches Risiko. Anstatt umständlich Portknocking aufzusetzen, ist es viel einfacher und aus Sicherheitsgesichtspunkten wirkungsvoller, die verwendeten Passwörter zu verlängern oder die Länge des Public Key.
Was sprich denn deiner Meinung nach dagegen, beides einzusetzen?
Wozu? Ein definiertes Sicherheitslevel erreicht man gut mit ausreichend langen Passwörtern. Jedes beliebige Level, das man mit Knocking erreichen würde, kann durch einfache Schlüsselverlängerung mit weniger Aufwand erreicht werden.
Meiner Meinung nach hast du einen erheblichen Sicherheitsgewinn.
Nein. Er ist marginal und steht in einem miserablen Verhältnis zum Aufwand.
Ausserdem fallen sämtliche ssh-Angriffe flach.
Nein. Sie werden nur geringfügig verzögert. Man braucht nur das Knocking zu belauschen oder die Portkombinationen zu Bruteforcen (ist nicht sehr aufwendig, da die "Schlüssellänge" für das Knocking aus Performancegründen kurz bleiben muß). Zusätzlich erhält man potentielle Angriffe auf den Knocking-Mechanismus,
Schließlich kannst du mit Portknocking den ssh-Port komplett dicht machen und nur nach Bedarf öffnen.
Nein. "Nach Bedarf" bedeutet hier einfach "wenn einer mit der richtigen Port-Kombination kommt". Das unterscheidet sich mathematisch nicht von "wenn einer den richtigen Public Key hat" oder von "wenn einer das richtige Passwort nennt" und bringt daher exakt Null. SSH benutzt solide Authentifizierung und sichert den Port mit harter Kryptographie ab. Ein Angreifer, der daran wirklich vorbei kommt, kann über sowas wie Port-Knocking nur müde grinsen. Ein Angreifer, der daran nicht vorbei kommt, braucht nicht anderweitig aufgehalten zu werden.
Somit wird für die meisten Angreifer dein Rechner eh uninteressant.
Das ja nun schon gleich gar nicht. Warum sollte ein Rechner weniger interessant werden, weil sein eingehendes TCP zum Teil kaputt ist? -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Erhard Schwenk, Donnerstag, 29. Dezember 2005 18:39:
Wozu? Ein definiertes Sicherheitslevel erreicht man gut mit ausreichend langen Passwörtern. Jedes beliebige Level, das man mit Knocking erreichen würde, kann durch einfache Schlüsselverlängerung mit weniger Aufwand erreicht werden.
Du gehst bei Deiner Argumentation davon aus, daß eine Verbreiterung des Schlüssels gleichbedeutend ist mit einer Erhöhung der Sicherheit. Ist das denn tatsächlich so, bzw. ist denn immer der Schlüssel das schwächste Glied in der Kette? Oder andersrum gefragt: wie sicher ist denn ein sshd, wenn nur die Schlüsselbreite beliebig groß ist? -- Andre Tann
Andre Tann wrote:
Erhard Schwenk, Donnerstag, 29. Dezember 2005 18:39:
Wozu? Ein definiertes Sicherheitslevel erreicht man gut mit ausreichend langen Passwörtern. Jedes beliebige Level, das man mit Knocking erreichen würde, kann durch einfache Schlüsselverlängerung mit weniger Aufwand erreicht werden.
Du gehst bei Deiner Argumentation davon aus, daß eine Verbreiterung des Schlüssels gleichbedeutend ist mit einer Erhöhung der Sicherheit. Ist das denn tatsächlich so, bzw. ist denn immer der Schlüssel das schwächste Glied in der Kette?
Bei ordentlichen Verfahren und Implementierungen ist davon auszugehen.
Oder andersrum gefragt: wie sicher ist denn ein sshd, wenn nur die Schlüsselbreite beliebig groß ist?
Innerhalb der Spezifikation (und die erlaubt _sehr_ große Schlüssellängen) von sshd und abgesehen von Implementierungsfehlern ist er exakt als so sicher einzustufen wie das der Schlüssel hergibt. Implementierungsfehler kann aber dein Port-Knocking-Daemon genauso haben. Nur ist dessen Authentifizierung potentiell deutlich schwächer (u.a. weil der "Schlüssel" abgehört werden kann). -- Erhard Schwenk k-itx informationssysteme - http://www.k-itx.net/ Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
Erhard Schwenk, Freitag, 30. Dezember 2005 08:02:
Bei ordentlichen Verfahren und Implementierungen ist davon auszugehen.
Das klingt, als würdest Du sagen: wenn nicht etwas anderes schwächer ist, dann ist der Schlüssel das schwächste Glied. Wie ordentlich ist denn das Verfahren und die Implementierung des sshd zB auf einer SuSE 9.3? Mir ist nämlich mal eine Maschine außer Kontrolle geraten, auf der nichts anderes lief (und installiert war) als ein sshd. Das Paßwort war eine zufällige 12stellige Kette, und gemischt aus Groß-/Kleinbuchstaben und Ziffern. Einen Key habe ich nicht benutzt. Nach einiger Zeit sind auf der Maschine Dinge passiert, die dort überhaupt nichts verloren hatten, sodaß ich das System plattmachen und neu aufsetzen mußte. Ich bin dem nicht weiter nachgegangen. Aber da ich mein Paßwort für ziemlich sicher halte, nehme ich an, daß der sshd als solcher eine Schwachstelle hatte. Oder kann das nicht sein?
Innerhalb der Spezifikation (und die erlaubt _sehr_ große Schlüssellängen) von sshd
Was gäbe es denn für einen Grund, eine kleinere als die maximale Schlüssellänge zu verwenden? -- Andre Tann
Quoting Andre Tann
Erhard Schwenk, Freitag, 30. Dezember 2005 08:02:
Bei ordentlichen Verfahren und Implementierungen ist davon auszugehen.
Das klingt, als würdest Du sagen: wenn nicht etwas anderes schwächer ist, dann ist der Schlüssel das schwächste Glied.
Nein. Das heißt, wenn die Verfahren Mathematischen Grundsätzen standhalten und die Implementierungen sauber getestet und regelmäßig auf aktuellem Patch-Level gehalten werden.
Mir ist nämlich mal eine Maschine außer Kontrolle geraten, auf der nichts anderes lief (und installiert war) als ein sshd.
Du hattest einen Zero-Day-Exploit für SSH? Das bezweifle ich. Am ehesten hast Du Patches nicht eingespielt.
Das Paßwort war eine zufällige 12stellige Kette, und gemischt aus Groß-/Kleinbuchstaben und Ziffern. Einen Key habe ich nicht benutzt.
Wenn ein Angreifer ein 12-Stelliges SSH-Passwort kennt oder knacken kann, kann er erst Recht einen Port-Knocking-Mechanismus aushebeln.
Nach einiger Zeit sind auf der Maschine Dinge passiert, die dort überhaupt nichts verloren hatten, sodaß ich das System plattmachen und neu aufsetzen mußte.
Wie alt war der sshd und warum wurde er nicht aktualisiert?
Ich bin dem nicht weiter nachgegangen. Aber da ich mein Paßwort für ziemlich sicher halte, nehme ich an, daß der sshd als solcher eine Schwachstelle hatte. Oder kann das nicht sein?
Es gab in der Vergangenheit durchaus Exploits für SSH, aber nur sehr wenige Zero-Day-Exploits. Deshalb spielt man mindestens alle 14 Tage die aktuellsten Sicherheitspatches in seine Systeme ein. Die Wahrscheinlichkeit für einen Zero-Day-Exploit in SSH ist genauso hoch wie die für jeden anderen Daemon, also auch für Deinen Port-Knocker. Du gewinnst mit ihm exakt gar nichts.
Innerhalb der Spezifikation (und die erlaubt _sehr_ große Schlüssellängen) von sshd
Was gäbe es denn für einen Grund, eine kleinere als die maximale Schlüssellänge zu verwenden?
Performance, Speicherplatz, Resourcenverbrauch, den Aufwand der Entropie-Generierung. Bei Passwörtern kommt noch dazu, daß der Benutzer sich die merken muß. Hast Du mal auf nem nicht ganz so neuen Rechner versucht, nen sagen wir 32000-Bit-SSH-Key zu generieren? Viel Spaß. Derzeit gelten bei den Keys 1024 bis 4096 Bit RSA als brauchbarer Kompromiss zwischen Performance und Sicherheit. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Erhard Schwenk, Freitag, 30. Dezember 2005 11:02:
Du hattest einen Zero-Day-Exploit für SSH? Das bezweifle ich. Am ehesten hast Du Patches nicht eingespielt.
Ich weiß nicht, was ein Zero-Day-Exploit ist. Ich weiß nur, daß auf der Maschine Dinge gelaufen sind, die da nichts verloren hatten. Patchmäßig war die Kiste halbwegs aktuell, das letzte Update vielleicht vier Wochen alt oder so.
Wie alt war der sshd und warum wurde er nicht aktualisiert?
Woher weißt Du, daß er nicht aktualisiert wurde? -- Andre Tann
Am Freitag, 30. Dezember 2005 11:35 schrieb Andre Tann:
Erhard Schwenk, Freitag, 30. Dezember 2005 11:02:
Du hattest einen Zero-Day-Exploit für SSH? Das bezweifle ich. Am ehesten hast Du Patches nicht eingespielt.
Ich weiß nicht, was ein Zero-Day-Exploit ist. Ich weiß nur, daß auf der Maschine Dinge gelaufen sind, die da nichts verloren hatten. Patchmäßig war die Kiste halbwegs aktuell, das letzte Update vielleicht vier Wochen alt oder so.
Wie der Name schon sagt, ein Exploit, der eine Sicherheitslücke ausnutzt, für die noch kein Patch existiert....also null Tage nach Entdeckung der Lücke, evtl. auch von demjenigen geschrieben, der die Lücke entdeckt hat. Mfg, Thomas
Quoting Thomas Gräber
Am Freitag, 30. Dezember 2005 11:35 schrieb Andre Tann:
Erhard Schwenk, Freitag, 30. Dezember 2005 11:02:
Du hattest einen Zero-Day-Exploit für SSH? Das bezweifle ich. Am ehesten hast Du Patches nicht eingespielt.
Ich weiß nicht, was ein Zero-Day-Exploit ist. Ich weiß nur, daß auf der Maschine Dinge gelaufen sind, die da nichts verloren hatten. Patchmäßig war die Kiste halbwegs aktuell, das letzte Update vielleicht vier Wochen alt oder so.
Wie der Name schon sagt, ein Exploit, der eine Sicherheitslücke ausnutzt, für die noch kein Patch existiert....also null Tage nach Entdeckung der Lücke, evtl. auch von demjenigen geschrieben, der die Lücke entdeckt hat.
Richtig. Gegen Zero-Day-Exploits hilft es in der Regel nicht, einen Daemon "vor" einen anderen zu pflanzen - man verlagert damit lediglich das bereits vorhandene Exploit-Risiko auf den vorderen Daemon und schafft sich ein zusätzliches durch das Zusammenspiel beider Daemons. Wenn überhaupt, müßte der weiter vorne stehende Daemon zumindest deutlich weniger komplex sein oder mit eingeschränkten Rechten laufen. Das ist bei sshd/Port-Knocking aber zumindest unter Linux gar nicht möglich. Port-Knocking braucht zur Manipulation der IP-Filter zwingend über weite Teile des Codes root-Rechte. Ein sshd kann bei public key auth bereits unmittelbar nach Übermittlung des Benutzernamens den root-Kontext verlassen, denn für den Zugriff auf authorized_keys, known_hosts und die Schlüsselprüfung reichen Rechte des jeweiligen Users aus. Selbt der Host-to-Host Handshake ließe sich in den Userspace von nobody verlagern, nachdem der Private Host Key und die Konfiguration gelesen wurde. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Am Mit, 28 Dez 2005, schrieb Erhard Schwenk: [...]
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Bitte ein Argument, welches gegen Portknocking spricht. PeteR
Am Mittwoch, 28. Dezember 2005 13:53 schrieb Peter Soltau:
Am Mit, 28 Dez 2005, schrieb Erhard Schwenk:
[...]
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Bitte ein Argument, welches gegen Portknocking spricht.
Das Script/Programm welches die Anfragen managed könnte einen Bug haben und keine Leute mehr annehmen. Das kommt besonders dann ärgerlich sein wenn der Rechnenknecht in einem entfernten RZ steht und man keinen direkten Zugriff hat. Keine Ahnung ob das besonders real ist, aber kam mir nur so gerade in den Kopf. Gruß Tim -- http://we-are-teh-b.org/~tim/
Zitat von Bernhard Bühler
unsere Systeme mit offenem ssh-Port werden laufend mit allen erdenklichen Namen gescannt, bzw. wird versucht ein login zu erreichen. Ich empfinde es als sehr störend und überlege nach Abhilfemassnahmen.
Eine Idee wäre nach jedem erfolglosen ssh-login einen grösseren delay einzuschalten. In dieser Zeit würden keine Anfragen mehr beantwortet. Eine solche Einstellmöglichkeit habe ich für Konsole-Logins bei Yast gefunden. Gibt es dies auch für ssh? Wie und wo ist es zu setzen?
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
Hallo, nach einem Hinweis in der SuSE Security Mailinglist vor ein paar Monaten habe ich das Perl Script login_sentry (http://www.lumiere.net/~j/login_sentry/login_sentry) bei mir installiert, und ich glaube, daß es auch in etwa Deinen Anforderungen entspricht: Nach einer einstellbaren Anzahl erfolgloser Login-Versuche wird die entsprechende IP-Adresse in die Datei /etc/hosts.deny eingetragen. Der Eintrag wird nach einer einstellbaren Zeitdauer wieder gelöscht, sodaß auch dynamisch vergebene Adressen nicht auf ewig geblockt werden. Gruß Wieland
Hallo Bernhard, Am Mittwoch, 28. Dezember 2005 10:08 schrieb Bernhard Bühler:
Hallo Liste
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken? Vieleicht ist das ja was für Dich http://denyhosts.sourceforge.net/ Mit diesem tool, welches auch als rpm gibt, werden die IPs der Angreifer für einen bestimmten Zeitraum geblockt. Herzlichen Dank für jede Antwort und ein gutes neues Jahr an Alle Auch von mir einen guten Rutsch für Dich und alle, die mitlesen Bernhard Thomas -- Mögen täten wir schon wollen, doch dürfen haben wir uns nicht getraut. Karl Valentin
Hallo Thomas danke für deine Antwort. Ich werde deine Variante und die von (s. Mail) von Tim Daniel Schumacher einmal umsetzten. Am Mittwoch, 28. Dezember 2005 15.54 schrieb Thomas Becker:
Hallo Bernhard,
Am Mittwoch, 28. Dezember 2005 10:08 schrieb Bernhard Bühler:
Hallo Liste
Hat jemand eine andere / bessere Idee um diesen unerwünschten Anfragen entgegenzuwirken?
Vieleicht ist das ja was für Dich http://denyhosts.sourceforge.net/ Mit diesem tool, welches auch als rpm gibt, werden die IPs der Angreifer für einen bestimmten Zeitraum geblockt.
Herzlichen Dank für jede Antwort und ein gutes neues Jahr an Alle
Auch von mir einen guten Rutsch für Dich und alle, die mitlesen
Bernhard
Thomas -- Mögen täten wir schon wollen, doch dürfen haben wir uns nicht getraut. Karl Valentin
Grüsse und ein gutes neues Jahr Bernhard
participants (9)
-
Andre Tann -
Bernhard Bühler -
Erhard Schwenk -
Peter Soltau -
Steffen Dettmer -
Thomas Becker -
Thomas Gräber -
Tim Daniel Schumacher -
Wieland Chmielewski