nicht angemeldet
Hi,
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?
Ja, und genau das ist das Problem: es reicht gerade mal so eben nicht. Ist aber auch egal: ich verkauf' was verlangt wird, wenn es nur besser(!) ist, da kenn' ich nix ;-)
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.
Ja, Mail und Patch geht hin und wieder gleichzeitig raus, aber der Distributor dürfte seinen Patch vorher noch testen wollen, falls es nicht gerade eine Kleinigkeit war (und es sind meist nur Kleinigkeiten, die den Ärger bereiten). Es kann daher sein, das der Distributionspatch später rauskommt, als der vom Maintainer obwohl beides das Selbe ist. Das passiert aber alles normalerweise innerhalb eines Tages.
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.
Dann hast Du einen Fehler im System. Was passiert denn bei Stromausfall?
Es ist aber kein Windows o.ä., reguläre Patches beheben normalerweise _nur_ den einen Fehler (bei Debian z.B. wird da sehr streng unterschieden), mehr nicht. Wenn dann der Apache nicht mehr startet lag's nicht am Apachen. Du kannst also davon ausgehen, das ein Patch nicht viel ändert. Steht auch immer in der Beschreibung zum Patch. Du liest doch immer die Beschreibung zum Patch? ;-)
Es kommt nur sehr selten vor, das der Fehler im Design lag und sehr viel geändert werden muß, so das nachher einiges nicht mehr so funktioniert, wie vorher. Dann kommt der Admin aber endlich mal an's Schwitzen >,->
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.
Wofür möchtest Du denn sonst einen Patch _sofort_ einspielen? Doch nur bei sicherheitsrelevanten Fehlern und nicht jedesmal, wenn ein neues Gimmik in den Sourcetree wandert, oder?
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.
Das wäre dann über den Tag verteilt 100% und nachts 0%? Nein, da kannst Du nicht den Durchschnitt nehmen, so funktioniert das leider nicht ;-)
Ich kann Dir sagen, das Du selbst mit einer Uptime von 99,5% noch graue Haare kriegen würdest, das ist zu wenig, das würdest Du nämlich schon mit Win98 schaffen.
Du kommst aber ganz gut mit zwei Maschinen zurecht, wenn es nur um das Aufspielen von Patches ohne Unterbrechung des Betriebes geht. Drei wären noch besser, noch mehr bringen aber dann nicht mehr viel. Umschalten einfach über Firewall/Router. Bei den Preisen für eine Pizzaschachtel ist das sogar bei engem Budget möglich.
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.
Ähm, nein. Ich kann einen remote exploitbaren Fehler in etwas über 100 Opcodes unterbringen. Nimmt man es ganz genau, ist sogar nur ein einziger Wert. Das ist weder groß noch komplex. Dann gibt es den riesigen und hochkomplexen Linuxkernel, wieviele remote Exploits finden sich da im Jahr?
[Und hier überspringt der Autor großmütig eine weite Schlucht ohne den Leser mit Einzelheiten weiter zu behelligen]
Nein, Größe und Komplexität eines Programmes spielen für die Sicherheit desselben keine entscheidende Rolle.
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.
Du müßtest ihnen so weit vertrauen, das sie auch keine Fehler machen! Das kannst Du noch nicht einmal bei Dir selber, wieso dann bei anderen?
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.
Das ist ein gefährlicher Trugschluß. Ein lokaler Exploit kann auch unwissentlich - durch einen Fehler z.B. - zu einem remote Exploit ausgebaut werden. Da können durchaus zwei lokale Exploits im Zusammenspiel zu einem remote Exploit werden. Was ist denn mit Borwserfehlern, die "nur" lokal wirksam werden können? Wenn es dann noch einen anderen lokalen Exploit gibt, dann kann eine Angreifer über den Browserexploit einen lokalen Exploit ausnutzen, der evt zu Privilege Escalation führt und damit ist die Box dann "officially r00ted".
"Rumms!" säht de Buer un driet de Kath in de Aftensupp.
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 bekannter Fehler ist eigentlich kein Fehler mehr. Da ihn jeder kennt ist auch jeder selber schuld, wenn er damit auf die Schnauze fällt. Da kannst Du ruhig PoCs (Proof of Concepts) veröffentlichen, dsa ist egal. Entweder gibt es einen Patch, oder der Service ist ausgeschaltet. Der Rest? Tja: was springst Du auch von der Brücke obwohl Dir schon jeder gesagt hatte, das da unten Krokodile wohnen?
Was passiert denn, wennder Fehler nicht veröffentlicht wird? Du weißt nichts davon, das es überhaupt einen Fehler gibt. Aber gilt das auch für _alle_ anderen? Wirklich alle? Oder ist es möglich, das dank der Nichtveröfentlichung ein Schwarzhut ganz still und heimlich den Exploit ausnutzen kann? Wie er den überhaupt gefunden hat, wo doch gar nichts veröffentlicht wurde? Nun, diese Frage zu beantworten überlasse ich einmal den werten Leser ;-)
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.
Das kann passieren, aber das ist nur sehr aufwendig zu regeln. Theoretisch sogar unmöglich, da 100% Uptime nicht erreichbar sind.
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".
Ja: drei gemietete Rootserver. Aber ich glaube nicht, das ein anständiger Host keine Möglicheit hat, den Switch nach Anweisung auf zwei Boxen umzuschalten. Dafür ist so ein Dingen ja unter anderem da. Kann Dein Host das nicht, oder ist er nicht Willens, dann wechsel den Anbieter. Kosten mittlerweile eh alles das Gleiche, da tut sich nicht mehr viel. Nur ist das natürlich vielfach leichter gesagt als getan, das mit dem "einfach wechseln", ich weiß.
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.
Ja, ist mittlerweile gut und stabil. PostgreSQL sogar schon recht lange.
Da aber ein DB-Server eh physikalisch vom Netz getrennt sein muß, kannst Du auch die Firewall zur Replikation mißbrauchen. Ist deutlich einfacher. Allerdings auch etwas gefährlicher, da dann ein evt Datenmurks natürlich automatisch auf beide Server wandert.
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.
Ja, das könnte ein klein wenig teuerer werden, da hast Du Recht ;-)
so short
Christoph Zurnieden