Admin Login

[Andreas Korthaus]

Hallo Christoph!

http://www.psw.net/ssl.cfm Da gibt es sowohl ein günstiges freessl Zertifikat, und seit kurzem auch ein erstaunlich günstiges Thawte-Zertifikat!

Was denn, Thawte? Ah, deren Lightangebot, nein, das kann ich leider nicht gebrauchen.

Warum nicht? Der Unterschied besteht doch lediglich in der Form der Prüfung des "zu Zertifizierenden", oder?

Darum auch meine herzlichsten Dank für den Link!

immer gerne ;-)

Ja, gut, sind natürlich keine Minuten, können schon ein paar Stunden werden. Bei sicherheitsrelevanter Software ist meines Wissens aber in den letzten Jahren noch nie "ein Tag" überschritten worden.

Kann sein. Zumindest kommt das Advisory oft etwas später.

Kommt immer drauf an wieviel früher die davon erfahren.

Gar nicht, es sei denn, die finden den selber früher.

das meinte ich.

Aber dieser Zeitunterschied beträgt dann wirklich nur Minuten, sowas geht nach Fund _sofort_ raus (wann der Entwickler die Mail abholt ist natürlich eine andere Sache)

Hatte gedacht die nutzen die Zeit ganz gerne um als erstes Patches bereitstellen zu können, macht sich ja ganz gut.

Außerdem kann man nicht immer hier und jetzt neue Module im Webserver installieren, oder sogar einen neuen Kernel!

Dann hast Du ein Problem mit Deinem System. Es _muß_ möglich sein am offenen Herzen operieren zu können! Wenn Dich die 5-10 Minuten Downtime für ein Reboot der einzelnen(!) Maschine oder gar nur ein Neustart eines einzelnen Progammes ernsthaft verletzen können ist 'was faul im System.

Gut, ich kann Patches in einem anderen System testen, aber ich habe keine 100% identischen Systeme, die nur für Tests zur Verfügung stehen. Bei bestimmten Anwendungen kann ich mir es z.B. nicht leisten, dass der Apache nach einem Neustart nicht mehr korrekt startet. Uns selbst wenige Sekunden downtime will ich nach Möglichkeit vermeiden. Gut, wenn da jetzt ein übler Remote-Exploit im Apache oder einem von mir eingesetzten Modul bekannt würde, der sich auch in meiner Konfiguration ausnutzen ließe, dann würde ich reagieren. Aber sonst erst Abends, denke ich.

Selbst die five-niner, die mit den 99,999% Uptime haben das mit eingerechnet!

Zum Glück habe ich in diese Richtung noch keine ernsthaften Festlegungen geplant ;-)
Aber bei mir ist dieses auch nicht nötig. Vermutlich würde eine Uptime von gut 50% ausreichen, wichtig ist eben dass es genau dann "up" ist, wenn es genutzt wird. Und das ist eigentlich nur über den Tag verteilt.

Immerhin finden sich die von Dir angesprochenen Fehler ja nicht alleine, irgendeiner muß sie ja schließlich erstmal gefunden haben bevor er sie veröffentlichen konnte.

Natürlich! Interessant finde ich wie bestimmte Leute hier immer wieder neue Fehler finden, und auch wie viele Leute nach bekannt werden eines Fehlers in eigenem/vergleichbarem Code nach ähnlichen Fehlern suchen - und auch finden!

Ich glaube nicht, das man "Sicherheitsrisiko" quantifizieren sollte. Entweder ist eines da oder nicht. Anders natürlich die Wahrscheinlichkeit des Vorhandenseins eines Sicherheitslochs. Die steigt mit der Menge der eingesetzten Programme. Aus diesem Grunde sollte man eben so wenig wie möglich einsetzen. Es ist aber relativ egal, welches Programm das ist. Relativ deshalb, weil noch ein kleiner Unterschied besteht, ob das Programm mit dem Netz kommunizieren kann oder nur ein lokales Helferlein ist.

Auch die Größe/Komplexität ist nicht unwichtig.

Sowas ist aber eher selten der Fall, das sich da überhaupt trennen läßt.
Aber ich schweife ab.

Sehr gerne ;) Ich finde das Thema sehr interessant!

Ich wollte nämlich zu Ausdruck bringen, das schon die Unterscheidung zwischen "gefährlicher" und "harmloser" ein Sicherheitsrisiko birgt. Das würde ja bedeuten, das zwischen "remote exploit" und "local exploit" ein Unterschied besteht und der besteht nicht bzw ist vernachlässigbar, da eines zum anderen führen kann.

Das sehe ich nicht so. Zumindest wenn man lokalen Benutzern vertrauen kann.  Ohne Remote Exploit bekommt doch niemand Zugriff auf das System, um überhaupt Schaden anrichten zu können. Wenn jemand aber über einen Remote-Expoit erstmal Zugriff erhält, wird es erheblich gefährlicher, da es hier viel mehr "Angriffsfläche" gibt.

Da man dies nicht mit Sicherheit sagen kann - dafür ist so eine System einfach zu komplex - muß man davon ausgehen, das aus einem lokalem Exploit einer von Ferne werden kann.

Wie das? Gut, es passiert ja immer mal wieder, dass die Entwickler die Tragweite eines Fehlers unterschätzen, das stimmt schon. Daher bin ich da z.B. beim Apache vorsichtiger als bei lokalen Diensten. Trotzdem ist ein bekannter(!) Remote Exploit IMHO ein größeres Risiko. Zum einen gibt es erheblich mehr Leute die darüber Bescheid wissen, oft gibt es Beispiel-Code zum Ausnutzen des Exploits...

Ein Fehler in einer Software ist also automatisch als Sicherheitsrisiko anzunehmen, die Beweislast des Gegenteils liegt beim anderem. Konsequenz: Patchen oder ausschalten. Kommst Du mit beidem in Teufels Küche ist ein Fehler im System vorhanden.

Naja, angenommen man kann sich in bestimmten Zeitabschnitten keine Downtime erlauben. Dann hilft hier nur ein HA-System. Aber dies funktioniert ja in der Regel nicht mit gemieteten Root-Servern, mir wäre jedenfalls kein Anbieter bekannt, der so Dinge wie "Übernahme der IP" erlauben würde. Das heißt, man braucht "was eigenes".

Schwieriger wird es wenn es um den DB-Server geht. Man könnte höchstens einen nebenherlaufen lassen, der im Fall der Fälle die IP und Anfragen übernimmt, wo man dann aber für Replikation und einen konsistenten Datenbestand sorgen muss. Ich bin mir nicht sicher ob sich dies mit MySQL oder PostgreSQL überhaupt "wasserdicht" realisieren lässt. Sonst braucht man sowas wie einen DB2 oder Oracle Cluster, die können sowas bestimmt ;-) Aber das ist zumindest in den meisten Fällen zu teuer.

Viele Grüße
Andreas