nicht angemeldet
Hi,
("Das war jetzt etwas viel", sagte das Forum *grmpf* ;-)
Und gerade in besonders alten Versionen kann ich mir gut vorstellen dass ein Patch nicht immer 100% "übertragbar" ist.
Wenn es verschiedene Versionen sind, besteht auch die Möglichkeit, das der Fehler dort überhaupt nicht auftritt. Außerdem: wenn jemand für einen Fehler einen Patch gebastelt hat, ist es auch kein Problem, den anzupassen. Das sind sehr selten mehr als nur ein paar Zeilen Code, mitunter sogar nur eine. Insbesondere Debian ist da sehr konservativ und flickt immer nur _genau_ den/die Fehler und nicht mehr. (sofern das denn geht. Wenn nicht, wird das aber ausführlich beschrieben)
Also bei jedem größeren Update führe ich hinterer einen reboot durch, alleine um zu testen dass es "im Fall der Fälle" keine Probleme gibt.
Zulange mit Windows gearbeitet, was? ;-)
Nein, außer bei einem Kernelupdate ist ein Reboot nicht nötig. Eine einfacher Reboot ist auch sowieso nicht als Test anzusehen. Etwaige Tests _müssen_ auf einem anderem System stattfinden. Das ist aber natürlich etwas blöd, wenn ich da mal so untertreiben darf, denn ein Kernel ist natürlich Hardwarespezifisch und würde eine exakte Kopie derselben als Testmaschine verlangen. Das ist aber ein ziemlicher Aufwand, vor allem, wenn die Produktionsmaschine ein Big-Iron ist. Und wenn dann nur Geld für eine da war: Fehler im System, es muß schon mindestens ein Ersatz da sein, nur eine zu kaufen ist rausgeschmissen Geld. (Ich vertrete auch die Meinung, das es zwei verschiedene Maschinen sein sollten, da dadurch die MTTF verschieden ist. Ansonsten bestünde das leicht erhöhte Risiko, das beide Maschinen zeitnah - zu zeitnah nach Murphy - ausfallen könnten. Aber das ist sehr strittig)
Das einzige Problem sind Schreibzugriffe auf die Datenbank. Dies lässt sich nicht so einfach verteilen/skalieren.
Ja, das ist etwas schwieriger. Ich würde das händisch machen: DB-Betrieb analysieren und so aufteilen, das Du mehr als eine DB betreiben kannst. Das ist dann so grob, das die Firewall das leicht übernehmen kann.
Auch wenn da einige SIcherheitsexperten aufschreien, das das keine Aufgabe für die Firewall wäre, aber das bischen Parsen sollte kein Problem darstellen, macht dei Applikationfirewall ja eh schon, braucht nur eine zusätzliche Regel.
Du könntest Diese Frage auch hier im Forum stellen, hier gibt es einige gute Leute für DB-Fragen.
Aber wem sage ich das, Du bist ja auch kein Neuling mehr ;-)
Wenn allerdings jede DB auch Schreibzugriffe [...] entsteht ein erheblicher Overhead durch die notwendige Synchronisation der DBs.
Nicht unbedingt, wie ich weiter unten beschrieben hatte. Ist dann aber nur eine Art Raid-1. Oder wie weiter oben beschrieben als eine Art Aufgabenverteilung, die aber leider nur eine statische Lastverteilung erlaubt. Bei veränderten Bedingungen müßtest Du jedesmal mühsam etwas neues ausklamüsern.
Außerdem bin ich nicht 100%ig sicher ob hier beim Umschalten - trotz Transaktionen - keine Daten verloren gehen können, oder Inkonsistenzen entstehen können.
Selbstverständlich wird das Ärger geben, es ist nur die Frage, ob Du das reparieren kannst und wie kompliziert das wird.
Denn dies würde IMHO voraussetzen, dass eine Transaktion erst zu Ende ist,[...] und wenn diese dann die Arbeit übernimmt, haben wir ein Problem. Oder mache ich hier einen Denkfehler?
Evt. Du stellst hier Überlegungen an, die bei _vollständiger_ Umsetzung mit Sicherheit ein Oracle-System für jede Menge gutes Geld erforderlich machen würden. Du solltest Dir die Frage stellen, was denn im Schadensfall passieren könnte und vor allem: was das kostet.
Was kostet ein, in Worten: 1 verlorener Datensatz?
Am Tag, in der Woche, im Monat, im Jahr?
Was kosten 5 Minuten Downtime?
Am Tag, in der Woche, im Monat, im Jahr?
Dito für 10, 15 und 60 Minuten.
Das heißt, die Distribution aktualiesiert das Kernel-Paket mehrmals, ohne dass Du diese Updates mitmachst. [...] und dann hoffen dass auf der Live-Maschine alles gut geht.
Ja, das mußt Du natürlich verfolgen und Deine Kernel-Quellen stets aktuell halten und auch immer daraus einen passenden Kernel bauen. ChangeLog und README der Patches ja nicht vergessen sich sorgfältig zu Gemüte zu führen! Das mit dem ausführlichem Testen entfällt im Grunde genommen, wenn Du auf Distributionen setzt (und auch keine andere Software benutzt wg evt Seiteneffekte) sollte aber eigentlich trotzdem durchgeführt werden. Ja, das erfordert üblicherweise eine identische Maschine. Hast Du die nicht wg zu knappem Budgets, mußt Du halt dem Distributor vertrauen. Bei Debian und noch mehr bei OpenBSD würde ich das sogar machen. Wenn auch mit Magengrummeln.
Aber das ist normalerweise das tägliche Brot eines Admins: mit viiiel zuwenig Geld Wunder vollbringen zu müssen ,-)
Wenn ich alleine überlege wieviel zur Zeit noch am 2.6er Kernel verändert wird, wundere ich mich dass der schon so viel eingesetzt wird.
Nein, eigentlich nicht, das täuscht. Auf Produktionssystemen mit wertvollen,sprich teuren Daten läuft mit Sicherheit noch ein 2.4er oder gar noch ein 2.2er und noch wahrscheinlicher erst gar kein Linux.
In jedem Fall ist das Leben etwas einfacher, wenn man eine Maschine fast täglich mehrere Stunden warten kann.
Weiter oben hast Du noch gesagt, das Du das nicht kannst, weil die Maschine zu 100% benötigt wird?
Ja eben, genau das meinte ich damit, das Du nicht den Durchschnitt nehmen kannst. Auch wenn Du nur für ein paar Stunden so eine hohe Verfügbarkeit haben mußt, mußt Du genauso arbeiten, als ob es das ganze Jahr so laufen muß. Es nützt Dir dabei nicht die Bohne, das Du die ganze Nacht reparieren kannst, wenn Dir die Maschine zwischendurch abschmiert, wenn sie nicht darf.
Ich kann Dir aus eigener leidvoller Erfahrung heraus versichern, das sie das auf jeden Fall zu dem ungünstigstem Zeitpunkt tun wird. ;-)
In einem Flugzeug sind auch alle Teile doppelt und dreifach (und noch mehr teilweise), obwohl zwischendurch immer genügend Zeit für eine Wartung ist.
Hm. Es ist aber schon was anderes ob ich irgendwelche wildfremden Leute auf den Rechner lasse, wie z.B. im Shared Hosting mit SSH-Zugang, oder ob das 2 Admins der eigenen Firma sind.
Nein, es ist _nichts_ anderes!
Ich würde sogar eher noch behaupten wollen, das die Admins das höhere Risiko darstellen!
Gut, auch einer von denen kann Schaden anrichten, wenn er sauer ist... aber die Gefahr dass jemand "aus Versehen" einen lokalen Exploit ausnutzt halte ich doch eher für theoretisch, oder?
Wieviele Beispiel aus meiner Praxis möchtest Du dazu haben?
Was ist mit meinem Beispiel mit dem Exploit im Browser?
Vor allem wenn die beiden Personen bereits Root-Rechte haben ist man eh ausgeliefert.
Nein, nicht ganz. (es gibt da noch Mittel und Wege, aber das ist sehr aufwendig)
Aber eines ist dabei natürlich nicht schlecht: man hat zwei Leute, denen man die Schuld geben kann! >;->
Und wer weiß was die Admins der Firmen die hierfür bezahlen in der Freizeit treiben...
Man muß schon wissen, was man tut, wenn man Sicherheit outsourced.
Bei OpenSource wird aber normalerweise der Grundsatz beherzigt, alle Sicherheitslücken _sofort_ zu veröffentlichen. Dein Szenario trifft eher auf geschlossene System zu.
Einen gewissen Schutz versprechen ja Patches für proaktive Sicherheit, wie pax/grsecurity etc. Verwendest Du sowas?
Nein, der Effekt ist zu klein. Aber ich verfolge selbstverständlich deren Bemühungen und habe schon hin und wieder etwas übernommen, ja.
Oder sowas wie RSBAC und SELinux? Ich finde den Aufwand bei letzteren allerdings sehr hoch,
Ich finde den Ansatz nicht ganz gelungen, da ich ACLs z.B. als ziemlich miesen Workaround ansehe. Das ist etwas, was der Kudne verlnagt hatte und nnur saumäßig implementiert wurde. Erweiterte Rechte alleine reichen nicht, man muß schon alles einzeln verschlüsseln.
außerdem würde ich keinem kompromittierten System mehr vertrauen, egal wie sicher ich mir bin dass weiter nichts passiert ist.
Das ist ein Grundsatz, den ich gar nicht genügend unterstützen kann! Wenn nur alle so handeln würden!
Das heißt die Server behalten die öffentlichen IPs, es wird nur intern zu einer anderen IP weitergeleitet?
Ja.
Wie beim Schwan: oben gleitet er dahin, was unten strampelt interessiert keinen ;-)
Keine Ahnung. Ich kann mir nicht vorstellen dass dies ein Rootserver-Hoster ermöglicht. Vor allem nicht automatisiert.
Zwei Rootserver müssen nicht notwendigerweise auch zwei verschiedene Kisten sein.
Die einfachste Lösung die ich kenne ist durch Übernahme der IP, also im Prinzip arp-spoofing, aber genau deswegen ist das von den Hostern nicht erlaubt.
Warum bieten eigentlich die Hoster von sich aus nichts an?
Soweit ich weiß - wenn Du sowas auf einem Server im Schlund-Rechenzentrum probierst,
Äh .. Schlund? Junger Mann, ich dachte, wir reden von Hostern? >;->
Die Trennung verstehe ich, aber dass dies gleichzeitig den Einsatz einer Firewall erfordert ist mir nicht klar.
Wie willst Du das denn sonst machen?
Ich würde den DB-Server in einem internen Netz laufen lassen, physikalisch getrennt von dem ans Internet angeschlossenen LAN. Allerdings macht dies die Remote-Wartung nicht gerade einfacher.
Dafür unter anderem die Firewall. Die ermöglicht ja erst die tatsächliche Trennung von DB und Netz (denn wie kommst Du sonst an die Daten der DB?) Ist ähnlich eines Trenntrafos bei Elektrik.
Du kannst dann eine zweite Netzkarte in den DB-Server einbauen und die zur Wartung nutzen. Soll die Wartung übers Netz oder sonstwie unter Nutzung öffentlicher Wege möglich sein, ist selbstverständlich auch da zwischen eine Firewall zu setzen. Macht also zusammen zwei Stück.
Das ist natürlich der ideale Zustand, der aber recht teuer ist.
Wie machst Du das? Den DB-Server über einen 2. Netzanschluss ans Internet anbieten wäre wohl dämlich,
Warum nicht? Wenn da eine Firewall zwischen ist?
Ist zwar nach Möglichkeit zu vermeiden, aber das geht ja leider selten.
oder Wartung komplett über eine Konsole?
Ja, das wäre natürlich ideal.
Oder von anderen, verbundenen Servern im DB-LAN aus?
Mmh ... nein, wäre mir zu risikoreich, wenn z.B. irgendwo Daten serverübergreifend repliziert werden.
Aber zur Firewall - würdest Du hier eine extra-Pizzabox einsetzen?
Zwei, um genau zu sein und mit unterschiedlichen Betriebsystemen. Es muß aber keine Pizzabox sein, es reicht auch deutlich weniger.
Und Administration nur lokal!
Dies birgt in meinen Augen ein nicht zu vernachlässigendes zusätzliches Ausfallrisiko.
Ja, da ist korrekt.
Aber es sei hier noch einmal erwähnt: Ausfallsicherheit und Sicherheit gegen Schädigung sind zwei verschiedene paar Schuhe, die sollte man nicht zusammenschmeißen.
Also spezialisierte Hardware? Das ist aber wieder nicht ganz billig.
Doch, das ist genauso teuer wie eine Pizzabox, eher noch billiger.
Wenn Du aber den DB-Server von Remote aus administrieren willst - was soll diese Firewall dann bringen? Wogegen willst Du Dich hiermit schützen? Gegen Fehler in der Anwendung? Das stell ich mir aber sehr kompliziert vor.
Ja, das _ist_ kompliziert ;-)
Es gibt aber noch mehr Angriffspunkte, wogegen eine Firewall schützen kann und auch muß.
so short
Christoph Zurnieden