nicht angemeldet
Hi,
Diese Tabellen kann man aufgrund von Joins oder Views oft nicht teilen.
Ja, manchmal hilft nur noch neu aufsetzen, wenn das schon so eine "Perücke" ist, wie der Angler zu dem Ergebnis einer wildgewordenen Spule zu sagen pflegt.
Das ist dann so grob, das die Firewall das leicht übernehmen kann.
Das Aufteilen? Wie soll dass den gehen?
Einfach forken: zweimal das Gleiche an zwei verschiedene DBs. Simples RAID-1.
Wie beziffert man das? Wenn ein Datensatz verloren geht, dann ist ein Kunde sauer, und darf irgendeine Aktion erneut ausführen.
Ja, das ist z.B. ein Kostenpunkt. Könnt ihr euch dsa leisten? Sprich: kündigt der Kunde euch die Freundschaft und damit auch den Zugriff auf seine Kohle, wenn er das machen muß? Täglich, wöchentlich, jährlich? Oder ist er auch mit einem Schnaps zufrieden, wenn das nur ab und zu einmal vorkommt?
Was würde ein gröberer Schaden (keine fehlenden sondern veränderte oder allzu bekannte Daten) kosten? (Ich möchte nicht versäumen darauf hinzuweisen, das Du für besonders grobe Verstöße gegen den Datenschutz durchaus in den Knast wandern kannst!)
Gibt es eine Versicherung dagegen und was kostet die? (Ist nur rein der Vollständigkeit halber aufgezählt. Es gibt zwar ein paar, aber die sind schweineteuer und bringen trotzdem nichts)
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!
Meinst Du Updates durch den Distributor?
Würde ich nicht so eng sehen, könnte man aber, ja.
so ziemlich alle AMD64-Server benötigen einen 2.6er Kernel (und davon gibt es inzwischen nicht wenige!)...
Nein, der ist da nur besser.
Aber da selbst Debian im Fall 64-Bit (AMD & Intel sowie 32er Emu) einen 2.6er empfiehlt, würde ich da mal eine Ausnahme machen ;-)
Auf Produktionssystemen mit wertvollen,sprich teuren Daten
also sowas wie dieses Forum? ;-)
Ähmmm ... ;-)
läuft mit Sicherheit noch ein 2.4er oder gar noch ein 2.2er und noch wahrscheinlicher erst gar kein Linux.
hier läuft aber 2.6 - q.e.d ;-)
Also ist das der Beweis, das man es nicht tun sollte? ;-)
Weiter oben hast Du noch gesagt, das Du das nicht kannst, weil die Maschine zu 100% benötigt wird?
Nein. 100% geht natürlich nicht. Ich sags mal so, zwischen 8 und 20 Uhr sollte die Maschine eine "möglichst hohe" Verfügbarkeit haben, dazwischen kann man im Prinzip machen was man will.
Du kannst Dich aber nur nach "möglichst hohe Verfügbarkeit" - was auch immer das sein soll - richten, was DU in der restlichen Zeit machts, interessiert keine Sau, höchstens die Statistik.
Nein, tut mir leid, aber "ein bischen schwanger" gibt's nicht ;-)
Das heißt, wenn ich um 20 Uhr irgendwas problematisches mache, habe ich noch 12 Stunden Zeit das in Ordnung zu bringen ;-)
Und wenn das morgens passiert und Du gar keine Zeit mehr hast, das in Ordnung zu bringen?
Bei richtigen™ HA-Systemen hast Du diese Möglichkeit nicht, eben nur mit Hilfe eines Clusters etc.
HA-Systemen sind normalerweise hochredundant ausgelegt, da kannst Du jederzeit ein(e) Hälfte/Drittel updaten, während die andere(n) Hälfte/Drittel ausliefern.
Waisman will den Fehler bereits im Mai im Rahmen des so genannten
[...]
Informationen nicht weiter zu geben (Non Disclosure Agreement).
Genau das meine ich aber. Sowas ist hahnebüchener Unsinn, gemeingefährlich (und das meine ich wörtlich!) und um es mal mit einem gutem uramerikanischem Ausdruck zu belegen: Bullshit!
Man müßte sogar einmal überlegen, ob sowas nicht strafrechtlich verfolgt werden kann und sollte.
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.
Verwendest Du nur selber gepatchte Kernel?
Nicht ausschließlich, aber meistens, ja.
Ich verwende eigentlich immer die originalen vanilla-sources mit grsec-patch. 2.4 natürlich :)
Warum?
Ich finde den Ansatz nicht ganz gelungen, da ich ACLs z.B. als ziemlich miesen Workaround ansehe.
Warum? Das Standard-Berechtigungskonzept ist nunmal in machen Fällen etwas zu einfach, oder?
Ja, aber Mikroptimierung bringt es nur extrem selten.
Das eigentlice Problem ist root, nicht die Grobheit der Aufteilung. Das beseitigt ACL nicht wirklich. SELinux ist da auf ebsserem Wege, aber noch viel zu komplex und damit Fehlbedienungsanfällig. Fehlbedienungsanfälligkeit ist auch ein Sicherheitsloch vid. Windows.
Du kannst halt sehr genau festlegen was ein User oder Programm darf, und was nicht. Wofür ist das ein Workaround? Wie macht man es denn ordentlich?
Man müßte den Superuser (root) entfernen, sowas braucht man normalerweise überhaupt nicht mehr. Dann reichen keine Rechteverteilungen, da muß ordentlich verschlüsselt werden.
Meinst Du jetzt konkret die beiden genannten Patches? Hm, gerade SELinux wird doch wirklich von vielen eingesetzt und von vielen entwickelt, unter anderem von der NSA (oh, gefährlich) ;-)
(Da die Quellen offenliegen, ist das nicht unbedingt gefährlich)
Nein, ich meine eher Algemein die Mode mit den ACLs und anderer Mikrooptimierung. Wenn das System Scheiße ist, dann muß eben ein besseres her und wenn man dafür das Alte nicht mehr weiterverwenden kann, soll man es eben wegwerfen und etwas Neues bauen und nicht einen Flicken
auf den anderen kleben.
Erweiterte Rechte alleine reichen nicht, man muß schon alles einzeln verschlüsseln.
Was hat das damit zu tun? Was denn verschlüsseln? Daten? Dateisysteme?
Beides am besten. Aber Daten reichen erstmal. Bei geschickter Art der Verschlüsselung können dei Rechte atomar gesetzt werden. Nicht nur pro Datei sodnern auch in der Datei selber. Die Passage, die Karl August drucken darf, darf Ernst-Willhelm noch nicht einmal sehen, die gibt es für ihn gar nicht. ACLs können sowas nicht und es wäre ziemlicher Aufwand, das möglich zu machen. Mit Verschlüsselung wäre es recht einfach.
Außerdem: ohne Verschlüsselung nützt das schönste ACL nix, wenn einer die Platte klaut.
Zwei Rootserver müssen nicht notwendigerweise auch zwei verschiedene Kisten sein.
Hm? Was denn sonst?
Laut IBM kann so eine voll ausgebaute AS/400 einige hundert Linuxsysteme fahren, kein Problem. Das geht natürlich auch einige Nummern kleiner.
Wenn es keine 2 Kisten sind, kannst Du nicht so gut an der einen arbeiten, wenn die andere läuft,
Natürlich, die sind komplett getrennt, den Unterschied kannst Du von außen nicht feststellen.
auch hast Du keine erhöhte Ausfallsicherheit bzgl. Hardware.
Ja, das ist natürlich der Nachteil, aber auch der einzige.
Und Du kannst nicht besonders schnell zwischen 2 Systemen umschalten.
Ähm, so schnell, wie der Bus es eben zuläßt, das sollte _sehr_ schnell sein, ich befüchte, so schnell kannst Du nicht zwischen zwei Pizzaschachteln umschalten ,-)
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?
Weil [...]
Nein, das war eine rethorische Frage, ich kenne die Antwort *sigh* (< dieser Seufzer hätte wohl hintendran gesollt, aber ich dachte, das war auch schon so klar, bitte um Entschuldigung)
Äh .. Schlund? Junger Mann, ich dachte, wir reden von Hostern? >;->
Ist das keiner?
Nun, sagen wir mal: für seeeehr weite Begriffe von "Host" >;->
Was wäre denn ein guter "Hoster" in Deiner Interpretation des Begriffes?
Einer, der zu genehmen Preisen genau das macht, was ich möchte. Er muß preiswert sein und nicht billig.
Ja, sowas ist leider nur sehr schwer zu finden.
Wie willst Du das denn sonst machen?
Ich verwende für den/die "Applikations-Server" halt 2 Netzwerkkarten, eine für Internet und eine für DB-Verbindung. Dieses 2. LAN ist ein geswitchtes Netz im privaten Adressraum, an das der DB-Server angeschlossen wird. Das ist für mich bereits eine physikalische Trennung.
Ja, das reicht auch normalerweise. Wäre mir aber zuwenig, finde das vor eine DB nunmal eine Firewall gehört.
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?
Aber auch hier - was bringts? Sagen wir es ist nur der sshd an diese Netzwerkkarte gebunden, akzeptiert nur das public-key Verfahren, ssh2, kein root... wie sich das gehört ;-)
Soweit eine Paktefirewall (die dann aber auch noch vor (D)DoS schützen würde und auch in die andere Richtung schützen kann, auf das auch nicht ungenehmigt etwas hinasuposaunt werden kann) Es gibt aber auch noch Applikationsfirewalls, die noch eine ganze Menge mehr machen können.
Aber wenn er eh schon so weit ist, dann ist doch sowieso alles zu spät.
Da verhindert werden kann, das Daten nach Außen dringen können, ist das schon noch sehr sinnvoll.
Also spezialisierte Hardware? Das ist aber wieder nicht ganz billig.
Doch, das ist genauso teuer wie eine Pizzabox, eher noch billiger.
Hättest Du da mal einen Link für mich? ;-)
Ebay? ,-)
Aber Scherz beiseite (obwohl so ein alter 486er meistens tatsächlich auseicht). Es gibt neuerdings einige kleine All-in-One Platinen von verschiedenen Herstellern, die nur sehr wenig Strom verbrauchen (im Schnitt so 20 Watt aber inkl. allem!) für runde 100 EUR. Dazu noch ein paar Kleinteile, macht runde 150EUR, eine Pizzabox ist dagegen nicht unter ca 250EUR zu bekommen. Dazu hat obige Lösung keine beweglichen Teile und wird wg des niedrigen Stromvberbrauchs auch nicht sonderlich warm.
Eine ideale Lösung für die kleine Firewall zwischendurch ;-)
Es gibt aber noch mehr Angriffspunkte, wogegen eine Firewall schützen kann und auch muß.
Was zum Beispiel? Wenn auf dem Server nur 1 Dienst läuft, z.B. Apache/mod_php, evtl. plus sshd, der sauber konfiguriert ist. Was gibt es dann noch für eine Firewall zu tun - außer den 2 Kleinigkeiten die ich oben schon genannt habe (remote-shell verhindern, nachladen verhindern), die evtl. einiges erschweren, aber nicht wirklich viel verhindern?
Erst einmal wird alleine schon die ganze Sache auf die benötigten Ports begrenzt und das auch noch in beide Richtungen. Der Server hat damit schon mal nichts mehr zu tun. Dann kann der Datenstrom geparsed werden und damit auch noch einige Sauereien verhindert. Ein Problem ist dabei natürlich SSH, da die stets anzustrebende End2End Veschlüsselung eine Entschlüsselung auf der Firewall eigentlich verbietet. Wäre dann eine Frage von Kosten/Nutzen/Gesetz.
(D)DoS hatte ich schon erwähnt?
So eine Firewall ist also eine Art Vorfilter, nach dem genau beschreibbar sein muß, was beim Server ankommen kann bzw rausgehen anstatt "alles". (Mir ist natürlich klar, das so eine Whitelist nicht wirklich funktioniert und es mehr oder weniger eine Blacklist wird, aber man darf ja mal den angestrebten Idealzustand beschreiben, oder? ;-)
Tja, und dann gibt es noch das Problem, wenn der Kunde seine Windowsserver an's Netz bringen will, aber das ist dann nur für die ganz Harten und Abgebrühten >;->
so short
Christoph Zurnieden