Admin Login

[Magnus]

Hy! Ich hab vor kuren angefangen mit PHP und MySQL zu arbeiten und es hat soweit schon gut geklappt, hab ja auch Unterstützung von meiner Ausbilderin aber wir sind jetzt irgendwie beide an die Grenzen gestoßen, denn eigentlich müsste es klappen aber es geht einfach nicht.
Ich hab ein Newsscript für meine Homepage gemacht und will einen Adminlogin einbauen, damit halt nicht jeder News eintragen kann.
Das Formular mit (name="loginname") und (name="loginpass") hab ich gemacht, es wird auch an die Datei login_result.php3 übergeben und folgendes steht nun in der Datei.
Quellcode:
<?php

$host = "localhost";
$user = "username";
$pass = "password";
$database = "daten";

if($_POST[loginname] && $_POST[loginpass]) {

$db = mysql_connect($host, $user, $pass);
      mysql_select_db($database, $db);
$result = mysql_query("SELECT * FROM login WHERE loginname='$_POST[loginnamedb]' AND loginpass='$_POST[loginpassdb]'", $db);

if(loginname=='$_POST[loginnamedb]' && loginpass=='$_POST[loginpassdb]') {

echo "<div align="right"><font color="#FFFFFF">[</font><a href="add.php3" class="newslink">News hinzuf&uuml;gen</a><font color="#FFFFFF">]</font></div>";
}
else {
  echo "Falscher Login!";
}
}

?>

Wenn ich das passwort eingebe steht da "Falscher Login!" und wenn ich es falsch eingebe auch, ich komm einfach nicht rein, woran liegt das?
In der MySQL Datenbank müsste auch alles stimmen. Wie gesagt nicht nur ich sondern auch meine Ausilderin hilft mir.

[Christoph Zurnieden]

Hi,

$host = "localhost";
$user = "username";
$pass = "password";
$database = "daten";

if($_POST[loginname] && $_POST[loginpass]) {

versuch's mal mit:
if(isset($_POST['loginname']) AND isset($_POST['loginpass']) ...

Wichtig sind die Anführungszeichen. Das isset() gibt zurück, ob eine angegebene Variable mit Wert belegt ist.

In der MySQL Datenbank müsste auch alles stimmen. Wie gesagt nicht nur ich sondern auch meine Ausilderin hilft mir.

Solltest Dir das Lehrgeld wiedergeben lassen.

BTW: Passwörter sollten verschlüsselt verschickt werden, wenn das über's Netzt geht. Hier geht's nur mit Javascript, ansonsten würde ich ein simples Login via .htaccess empfehlen.

so short

Christoph Zurnieden

[wahsaga]

hi,

BTW: Passwörter sollten verschlüsselt verschickt werden, wenn das über's Netzt geht. Hier geht's nur mit Javascript, ansonsten würde ich ein simples Login via .htaccess empfehlen.

falls du von HTTP AUTH mit Type Basic redest - da werden die daten ebenfalls unverschlüsselt übertragen.

gruß,
wahsaga

[Christoph Zurnieden]

Hi,

BTW: Passwörter sollten verschlüsselt verschickt werden, wenn das über's Netzt geht. Hier geht's nur mit Javascript, ansonsten würde ich ein simples Login via .htaccess empfehlen.

falls du von HTTP AUTH mit Type Basic redest - da werden die daten ebenfalls unverschlüsselt übertragen.

Nein, natürlich nicht. Ich habe allerdings auch vorher gesagt, das sowas verschlüsselt übertragen werden muß, AUTH_BASIC fällt also sowieso flach.

so short

Christoph Zurnieden

[Andreas Korthaus]

Hallo!

Nein, natürlich nicht. Ich habe allerdings auch vorher gesagt, das sowas verschlüsselt übertragen werden muß, AUTH_BASIC fällt also sowieso flach.

Wozu gibt es SSL?

Grüße
Andreas

[Christoph Zurnieden]

Hi,

Nein, natürlich nicht. Ich habe allerdings auch vorher gesagt, das sowas verschlüsselt übertragen werden muß, AUTH_BASIC fällt also sowieso flach.
Wozu gibt es SSL?

Damit Verizone und Konsorten sich eine güldne Nase verdienen?
Aber Scherz beiseite (obwohl: so witzig finde ich das Gehabe bei denen gar nicht, aber egal), SSL kostet entweder Geld oder einen Aufwand, den einen die ganzen Browser nur damit danken, das sie ein Fensterchen aufmachen, das den normalen User total verunsichert.
Außerdem ist hier nur ein Paßwort zu verschlüsseln, dafür braucht man keine vollständig verschlüsselte Verbindung, die ja schließlich nicht nur Geld sondern auch kostbare Entropie verbraucht. Die kann man für andere Sachen (Shopbestellung, Webmail, etc) besser nutzen.

so short

Christoph Zurnieden

[Andreas Korthaus]

Hallo Christoph!

Damit Verizone und Konsorten sich eine güldne Nase verdienen?

Naja, inzwischen bekommt man ja Zertifikate die die meisten aktuellen Browser (IE 5, Moz. 1) unterstützen für unter 20 EUR.

Aber Scherz beiseite (obwohl: so witzig finde ich das Gehabe bei denen gar nicht, aber egal), SSL kostet entweder Geld oder einen Aufwand, den einen die ganzen Browser nur damit danken, das sie ein Fensterchen aufmachen, das den normalen User total verunsichert.

Mit einem "ordentlich signierten" Zertifikat ja nicht.

Außerdem ist hier nur ein Paßwort zu verschlüsseln, dafür braucht man keine vollständig verschlüsselte Verbindung, die ja schließlich nicht nur Geld sondern auch kostbare Entropie verbraucht.

Aber das was Du vorschlägst (wenn ich das richtig interpretiere) ist ja keine wirkliche Verschlüsselung. Wenn Du z.B. per Javascript einen md5-Hash des Passworts sendest, bekommt man zwar kein Klartext-Passwort mehr, aber auch mit diesem Hash kann man Zugriff erhalten. Digest Auth ist in "Nicht kontrollierbaren Umgebungen" AFAIK noch nicht wirklich geeignet da es viele weit verbreitete Browser nicht ordentlich unterstützen. Außerdem gilt mod_auth_digest selber noch als "experimental".

Die kann man für andere Sachen (Shopbestellung, Webmail, etc) besser nutzen.

Da sowieso ;-)

Ein Problem sehe ich darin, dass mod_ssl/openssl letzte Zeit des öfteren durch mehr oder weniger gefährliche Bugs aufgefallen sind -> zusätzliches Risiko.

Grüße
Andreas

[Christoph Zurnieden]

Hi,

Damit Verizone und Konsorten sich eine güldne Nase verdienen?
Naja, inzwischen bekommt man ja Zertifikate die die meisten aktuellen Browser (IE 5, Moz. 1) unterstützen für unter 20 EUR.

Bist Du Dir sciher, das es sich dabei nicht um Hoster handelt, die das im Paket mit anbieten? Dagegen ist natürlich nichts zu sagen, beileibe nicht, aber es ist nunmal nicht das Gleiche wie eines, das auf die eigene Firma ausgeschrieben ist.

Außerdem ist hier nur ein Paßwort zu verschlüsseln, dafür braucht man keine vollständig verschlüsselte Verbindung, die ja schließlich nicht nur Geld sondern auch kostbare Entropie verbraucht.
Aber das was Du vorschlägst (wenn ich das richtig interpretiere) ist ja keine wirkliche Verschlüsselung. Wenn Du z.B. per Javascript einen md5-Hash des Passworts sendest, bekommt man zwar kein Klartext-Passwort mehr, aber auch mit diesem Hash kann man Zugriff erhalten.

Naja, das das nicht so einfach ist, ist klar. Aber auch kein wirkliches Problem, da z.B. bei der Lösung mit Javascript Einmalhashes verwendet werden bzw sogar ein kompletter Handshake durchgeführt werden kann.

Digest Auth ist in "Nicht kontrollierbaren Umgebungen" AFAIK noch nicht wirklich geeignet da es viele weit verbreitete Browser nicht ordentlich unterstützen. Außerdem gilt mod_auth_digest selber noch als "experimental".

Auch nach all den Jahren noch? RFC 2617 ist immerhin von 1999!
Aber was soll man außer SSL sonst nehmen?
Kerberos? Ist ein Standard den MS erfolgreich verhunzt hat.
Nein, AUTH-Digest ist für eine reine Paßwortübertragung ausreichend sicher. Aber mehr auch nicht, _nur_ für die halbwegs sichere Übertragung des Paßwortes! Man muß dann selber dafür sorgen, ds das PW ausreichend sicher ist (Einwegpaßwörter z.B., die haben dann aber wieder andere Probleme)

Die kann man für andere Sachen (Shopbestellung, Webmail, etc) besser nutzen.
Da sowieso ;-)

Ein Problem sehe ich darin, dass mod_ssl/openssl letzte Zeit des öfteren durch mehr oder weniger gefährliche Bugs aufgefallen sind -> zusätzliches Risiko.

Ähmm, Du implizierst also, das es keine Bugs gibt, wenn keine bekannt sind? Bist Du Dir sicher, das Du das _so_ meintest? ;-)

so short

Christoph Zurnieden

[Andreas Korthaus]

Hallo!

Bist Du Dir sciher, das es sich dabei nicht um Hoster handelt, die das im Paket mit anbieten?

Ja, ich hab so eins, sogar mehrere ;-) http://freessl.com/, dafür gibts auch noch günstigere Reseller in D :)

Dagegen ist natürlich nichts zu sagen, beileibe nicht, aber es ist nunmal nicht das Gleiche wie eines, das auf die eigene Firma ausgeschrieben ist.

Jepp. Aber wie gesagt, die Zertifikate wurden direkt auf mich ausgestellt, keine Zwischenzertifikate, genau so wie von den "Großen", halt mit schlechterer Browser-Unterstützung...  aber für bestimmte Zwecke reicht es (kommt AFAIK irgendwo von GeoTrust). Und selbst für IE4 und NN4 gibt es für deutlich unter 100 USD.

Naja, das das nicht so einfach ist, ist klar. Aber auch kein wirkliches Problem, da z.B. bei der Lösung mit Javascript Einmalhashes verwendet werden bzw sogar ein kompletter Handshake durchgeführt werden kann.

Habe sowas allerdings noch nie "live und in Farbe" gesehen. Weißt Du wo sowas eingesetzt wird?

Auch nach all den Jahren noch? RFC 2617 ist immerhin von 1999!

Von wann war noch gleich der IE5/6? ;-)

Aber was soll man außer SSL sonst nehmen?

nen SSH-Tunnel? ;-)

Kerberos? Ist ein Standard den MS erfolgreich verhunzt hat.
Nein, AUTH-Digest ist für eine reine Paßwortübertragung ausreichend sicher.

das bezweifel ich nicht.

Aber mehr auch nicht, _nur_ für die halbwegs sichere Übertragung des Paßwortes!

jepp.

Ein Problem sehe ich darin, dass mod_ssl/openssl letzte Zeit des öfteren durch mehr oder weniger gefährliche Bugs aufgefallen sind -> zusätzliches Risiko.

Ähmm, Du implizierst also, das es keine Bugs gibt, wenn keine bekannt sind?

mache ich das? Ich sage nur, dass es mir so vorkommt, dass mod_ssl in letzter Zeit des öfteren aufgefallen ist. Und ich befürchte halt, dass wenn in einer so populären Software über einen längeren Zeitraum regelmäßig Lücken gefunden werden, dass dies evtl. mehr oder weniger so weitergeht ;-)
Und ich rechne auch damit, dass die Lücken bekannt werden bevor meine Distribution ein Patch bereit stellt...

Und ja, ich rechne auch damit dass noch viele Fehler enthalten sind, die noch nicht bekannt sind, oder nicht öffentlich...

Was ich damit aber meine, ist dass mod_ssl merklich ein zusätzliches Sicherheitsrisiko birgt, und dass ich drauf verzichten würde, wenn ich es nicht wirklich brauche.

Grüße
Andreas

[Christoph Zurnieden]

Hi,

Dagegen ist natürlich nichts zu sagen, beileibe nicht, aber es ist nunmal nicht das Gleiche wie eines, das auf die eigene Firma ausgeschrieben ist.

Jepp. Aber wie gesagt, die Zertifikate wurden direkt auf mich ausgestellt, keine Zwischenzertifikate, genau so wie von den "Großen", halt mit schlechterer Browser-Unterstützung...  aber für bestimmte Zwecke reicht es (kommt AFAIK irgendwo von GeoTrust). Und selbst für IE4 und NN4 gibt es für deutlich unter 100 USD.

Hast Du da Adressen? Kenne da nur die üblichen Verdächtigen (kann aber auch eigentlich keinen anderen nutzen, da es wirklich _überall_ funktionieren muß) und die sind zwar etwas billiger geworden, aber unter rund 250 EUR ist da eigentlich nichts Vernünftiges zu bekommen.

Naja, das das nicht so einfach ist, ist klar. Aber auch kein wirkliches Problem, da z.B. bei der Lösung mit Javascript Einmalhashes verwendet werden bzw sogar ein kompletter Handshake durchgeführt werden kann.
Habe sowas allerdings noch nie "live und in Farbe" gesehen. Weißt Du wo sowas eingesetzt wird?

Höchstens in einem "Proof of Concept", da der Aufwand für den Effekt einfach zu groß ist. Kryptographie erfordert nunmal einen Profi bei der Implementation, da nimmt man doch besser fertige Lösungen, wenn man es nicht selber kann und selbst dann.
Acho: nein, mir ist tatsächlich keine fertige Implementation bekannt. Wäre vielleicht mal 'was für die kommenden langen Winterabende? ;-)

Auch nach all den Jahren noch? RFC 2617 ist immerhin von 1999!
Von wann war noch gleich der IE5/6? ;-)

Ja gut, ich ziehe zurück ;-)

Ein Problem sehe ich darin, dass mod_ssl/openssl letzte Zeit des öfteren durch mehr oder weniger gefährliche Bugs aufgefallen sind -> zusätzliches Risiko.

Ähmm, Du implizierst also, das es keine Bugs gibt, wenn keine bekannt sind?
mache ich das?

Es machte zumindest den äußerlichen Anschein.

Ich sage nur, dass es mir so vorkommt, dass mod_ssl in letzter Zeit des öfteren aufgefallen ist. Und ich befürchte halt, dass wenn in einer so populären Software über einen längeren Zeitraum regelmäßig Lücken gefunden werden, dass dies evtl. mehr oder weniger so weitergeht ;-)

Hast Du ein Glück, dsa Du da ein Smiley hintergesetzt hast. Wäre Dir doch beinahe auf den Leim gegangen ;-)

Und ich rechne auch damit, dass die Lücken bekannt werden bevor meine Distribution ein Patch bereit stellt...

Ja, das können schon ein paar Minuten sein, bis ein Patch bereitsteht, wenn eine Sicherheitslücke bekannt wird. Denn diese Lücke muß ja schließlich erst mal bekannt sein, damit ein Patch gebastelt werden kann.

Und ja, ich rechne auch damit dass noch viele Fehler enthalten sind, die noch nicht bekannt sind, oder nicht öffentlich...

Es hält Dich keiner, danach Auschau zu halten. Adresse zum Bezug der Quellen ist ja bekannt.

Was ich damit aber meine, ist dass mod_ssl merklich ein zusätzliches Sicherheitsrisiko birgt, und dass ich drauf verzichten würde, wenn ich es nicht wirklich brauche.

Jedes Programm, das Du betreibst ohne es zu benötigen und zwar wirklich _jedes_ birgt ein zusätzliches Sicherheitrisiko, da hast Du recht.

so short

Christoph Zurnieden

[Andreas Korthaus]

Hallo Christoph!

Jepp. Aber wie gesagt, die Zertifikate wurden direkt auf mich ausgestellt, keine Zwischenzertifikate, genau so wie von den "Großen", halt mit schlechterer Browser-Unterstützung...  aber für bestimmte Zwecke reicht es (kommt AFAIK irgendwo von GeoTrust). Und selbst für IE4 und NN4 gibt es für deutlich unter 100 USD.

Hast Du da Adressen? Kenne da nur die üblichen Verdächtigen (kann aber auch eigentlich keinen anderen nutzen, da es wirklich _überall_ funktionieren muß) und die sind zwar etwas billiger geworden, aber unter rund 250 EUR ist da eigentlich nichts Vernünftiges zu bekommen.

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!

Acho: nein, mir ist tatsächlich keine fertige Implementation bekannt. Wäre vielleicht mal 'was für die kommenden langen Winterabende? ;-)

;-)

Und ich rechne auch damit, dass die Lücken bekannt werden bevor meine Distribution ein Patch bereit stellt...

Ja, das können schon ein paar Minuten sein, bis ein Patch bereitsteht, wenn eine Sicherheitslücke bekannt wird.

Naja. Meiner Erfahrung nach dauert es deutlich länger bis Distributoren wie Suse, Red Hat, Gentoo... entsprechende stabile Pakete aktualisiert haben. Kommt immer drauf an wieviel früher die davon erfahren. Außerdem kann man nicht immer hier und jetzt neue Module im Webserver installieren, oder sogar einen neuen Kernel!

Und ja, ich rechne auch damit dass noch viele Fehler enthalten sind, die noch nicht bekannt sind, oder nicht öffentlich...

Es hält Dich keiner, danach Auschau zu halten. Adresse zum Bezug der Quellen ist ja bekannt.

Ich weiß, aber hierfür reicht mein Wissen leider noch nicht wirklich.

Jedes Programm, das Du betreibst ohne es zu benötigen und zwar wirklich _jedes_ birgt ein zusätzliches Sicherheitrisiko, da hast Du recht.

Ja, und manche Programme möglicherweise ein verhältnismäßig großes ;-)

Viele Grüße
Andreas

[Christoph Zurnieden]

Hi,

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. Aber das Vollangebot ist ebenfalls billiger und meine Kunden freuen sich immer, wenn ich Preissenkungen anbiete ;-)
Darum auch meine herzlichsten Dank für den Link!

Und ich rechne auch damit, dass die Lücken bekannt werden bevor meine Distribution ein Patch bereit stellt...

Ja, das können schon ein paar Minuten sein, bis ein Patch bereitsteht, wenn eine Sicherheitslücke bekannt wird.
Naja. Meiner Erfahrung nach dauert es deutlich länger bis Distributoren wie Suse, Red Hat, Gentoo... entsprechende stabile Pakete aktualisiert haben.

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.

Ich kenne aber einige kommerzielle Anbieter, die dafür teilweise Monate oder gar Jahre brauchen.

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

Gar nicht, es sei denn, die finden den selber früher. 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)
Das ist übrigens mitunter der Grund dafür, das kein Patch vorhanden ist: der Fehler ist für die distributionsspezifische Version nicht relevant.

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. Selbst die five-niner, die mit den 99,999% Uptime haben das mit eingerechnet!

Und ja, ich rechne auch damit dass noch viele Fehler enthalten sind, die noch nicht bekannt sind, oder nicht öffentlich...

Es hält Dich keiner, danach Auschau zu halten. Adresse zum Bezug der Quellen ist ja bekannt.
Ich weiß, aber hierfür reicht mein Wissen leider noch nicht wirklich.

Das spielt überhaupt keiner Rolle, es sind genügend da, die dieses Wissen haben und es auch entsprechend einsetzen. 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.

Jedes Programm, das Du betreibst ohne es zu benötigen und zwar wirklich _jedes_ birgt ein zusätzliches Sicherheitrisiko, da hast Du recht.
Ja, und manche Programme möglicherweise ein verhältnismäßig großes ;-)

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. Sowas ist aber eher selten der Fall, das sich da überhaupt trennen läßt.
Aber ich schweife ab. 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. 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.

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.
BTW: das das in letzter Zeit mit wenigen Ausnahmen nur noch bei Produkten der Firma Microsoft vorkommt ist natürlich keine Ausrede von ausführlichen Tests von Patches abzusehen, wenn's nicht von MS ist! Das können auch andere ganz gut!

so short

Christoph Zurnieden

[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

[Christoph Zurnieden]

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

[Andreas Korthaus]

Hallo!

Ja, und genau das ist das Problem: es reicht gerade mal so eben nicht.

Hm, mir reicht das ;-)

Ist aber auch egal: ich verkauf' was verlangt wird, wenn es nur besser(!) ist, da kenn' ich nix ;-)

*g*

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.

Aber viele Distributionen arbeiten ja nicht mit denselben Versionen wie die Entwickler der Software, sondern arbeiten mit backports. Vor allem die "Enterprise Versionen" von Red Hat und Suse, aber auch Debian. Gentoo arbeitet (IMHO zum Glück) meist mit den weitgehend originalen Versionen. Und gerade in besonders alten Versionen kann ich mir gut vorstellen dass ein Patch nicht immer 100% "übertragbar" ist.

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?

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. Danke Apache/mod_php ("fire & forget") und DB-Transaktionen sollte es nach einen Reboot keine Probleme geben. Aus diesem Grund skaliert das ganze auch recht gut, das heißt ich könnte "Pizzaboxen" dazu packen, die über einen Loadbalancer angesprochen werden, ich kann jederzeit eine Box rausnehmen, updaten, hinzufügen... ohne Probleme. Allerdings bin ich noch nicht so weit ;-) Das einzige Problem sind Schreibzugriffe auf die Datenbank. Dies lässt sich nicht so einfach verteilen/skalieren. Lese-Zugriffe sind nicht so wild, das kann recht einfach per Master->Slave Replikation passieren, aber hier kann es bei MySQL und PostgreSQL AFAIK nur einen Master geben. Wenn allerdings jede DB auch Schreibzugriffe bearbeiten können soll - abgesehen davon dass das bei den genannten RDBMS nicht geht - entsteht ein erheblicher Overhead durch die notwendige Synchronisation der DBs. Daher fällt mir an dieser Stelle nur ein, den Master-Server z.B. per Heartbeat zu überwachen, und ggfs. dessn IP und Aufgaben zu übernehmen. Aber das bringt nur was für Verfügbarkeit, Skalierung ist hier nicht so einfach möglich. 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. Denn dies würde IMHO voraussetzen, dass eine Transaktion erst zu Ende ist, wenn diese auch auf der Slave-Maschine erfolgreich durchgeführt wurde. Sonst kann es passiert, das die Transaktion eigentlich als abgeschlossen angesehen/gemeldet wird, auf der Slave-Maschine allerdings noch nicht, und wenn diese dann die Arbeit übernimmt, haben wir ein Problem. Oder mache ich hier einen Denkfehler?

Ja, ich schweife wohl auch etwas ab ;-)

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?

Ja. Aber ich würde es nicht unbeding "hier und jetzt" bei jedem Fehler machen, der sich wenn überhaupt nur lokal ausnutzen ließe. Sowas dann abends. Aber mal folgendes Beispiel: Du hast einen Kernel der gut läuft, der Distributor bringt hin und wieder kleine Updates raus, die Du nicht einspielst weil Du es nicht brauchst weil es Dich nicht betrifft, oder weil es nicht so wichtig ist... Das heißt, die Distribution aktualiesiert das Kernel-Paket mehrmals, ohne dass Du diese Updates mitmachst. Dann taucht eine Lücke auf, die auch sofort gepatched wird, aber eben nur in den aktuellen Versionen. Also kannst Du entweder den Rechner abschalten oder Deine Sourcen manuell patchen oder auf einer möglichst identischen Maschine testen, und dann hoffen dass auf der Live-Maschine alles gut geht. Was würdest Du machen? Gut, Du redest wie es aussieht immer von HA-Szenarien, das macht solche Dinge in der Tat deutlich erträglicher. Aber auch teurer und komplexer. Aber da muss man ja gegenrechnen ob es auch teurer ist als downtime weil der Kernel dann doch nicht so gebootet hat wie er sollte ... ;-)
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. Zum einen findet dort noch die Entwicklung statt, und alleine das changelog von 2.6.8.1 -> 2.6.9 hat 1,2 MB! Und AFAIK lassen Distributoren gerne mal neue Features mit in ältere Kernel einfließen.

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%?

Das wäre ideal, ja ;-)

Nein, da kannst Du nicht den Durchschnitt nehmen, so funktioniert das leider nicht ;-)

Naja, wenn ich die Verfügbarkeit über das Jahr rechne, schon :) Aber ich weiß was Du meinst.

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.

In jedem Fall ist das Leben etwas einfacher, wenn man eine Maschine fast täglich mehrere Stunden warten kann. Das geht halt bei den 99,9..% Systemen nicht. Wenn man nicht gerade einen Cluster da stehen hat.

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?

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. 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? Vor allem wenn die beiden Personen bereits Root-Rechte haben ist man eh ausgeliefert.

Was passiert denn, wenn der 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 ;-)

Klar! Es gibt ja auch Firmen wo Du dafür bezahlen kannst dass Du Lücken die diese Firma findet vorher bekommst, die dann erst deutlich später veröffentlicht wird. Und wer weiß was die Admins der Firmen die hierfür bezahlen in der Freizeit treiben...
Einen gewissen Schutz versprechen ja Patches für proaktive Sicherheit, wie pax/grsecurity etc. Verwendest Du sowas? Oder sowas wie RSBAC und SELinux? Ich finde den Aufwand bei letzteren allerdings sehr hoch, außerdem würde ich keinem kompromittierten System mehr vertrauen, egal wie sicher ich mir bin dass weiter nichts passiert ist.

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.

Im Switch? Das heißt die Server behalten die öffentlichen IPs, es wird nur intern zu einer anderen IP weitergeleitet? Keine Ahnung. Ich kann mir nicht vorstellen dass dies ein Rootserver-Hoster ermöglicht. Vor allem nicht automatisiert. 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. Soweit ich weiß - wenn Du sowas auf einem Server im Schlund-Rechenzentrum probierst, wird Dir automatisch Deine Leitung gekappt, eben weil man es auch mißbrauchen kann. Und die sagen selber, Rootserver sind nicht das richtige wenn Du eine HA-Lösung willst. Mir ist kein Hoster bekannt der das erlauben würde. Daher sehe ich nur den Weg über Housing von eigenen Servern, wo man erheblich mehr Möglichkeiten hat, wie etwa bei den SELF-Servern.

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.

Da aber ein DB-Server eh physikalisch vom Netz getrennt sein muß, kannst Du auch die Firewall zur Replikation mißbrauchen.

Die Trennung verstehe ich, aber dass dies gleichzeitig den Einsatz einer Firewall erfordert ist mir nicht klar. 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. Wie machst Du das? Den DB-Server über einen 2. Netzanschluss ans Internet anbieten wäre wohl dämlich, oder Wartung komplett über eine Konsole? Oder von anderen, verbundenen Servern im DB-LAN aus?

Aber zur Firewall - würdest Du hier eine extra-Pizzabox einsetzen? Dies birgt in meinen Augen ein nicht zu vernachlässigendes zusätzliches Ausfallrisiko. Also spezialisierte Hardware? Das ist aber wieder nicht ganz billig. 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.

Viele Grüße
Andreas

PS: ich war mal so frei das topic etwas anzupassen :)

[Christoph Zurnieden]

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

[Andreas Korthaus]

Moin!

("Das war jetzt etwas viel", sagte das Forum *grmpf* ;-)

OK, ich machs ganz kurz ;-)

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 aber schwierig wenn die Anwendung genau für eine DB programmiert wurde. Dann müsste man da schon ordentliche Eingriffe vornehmen, außerdem ist dies auch nur sehr begrenzt möglich. Im Normalfall verursachen relativ wenige Queries über relativ wenige, dafür große Tabellen einen verhältnismäßig großen Teil der Last. Diese Tabellen kann man aufgrund von Joins oder Views oft nicht teilen.

Das ist dann so grob, das die Firewall das leicht übernehmen kann.

Das Aufteilen? Wie soll dass den gehen? Inzwischen kann ja sogar MySQL ein binäres Kommunikations-protokoll verwenden, was willst Du da per Firewall noch machen? Du siehst nur -  "Application Server X schickt TCP-Paket an DB-Server Y". Was genau hier passiert kannst Du ja nicht so ohne weiteres parsen/interpretieren!

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.

Was ich meine ist das was Oracle & Co. mit den Clustern machen. Das hört sich zwar alles prima an, nur verschlingt die Synchronisation hierbei sehr, sehr viel Zeit und Performance, gegenüber einer einfachen Master->Slave Replikation. Dafür hast Du dann bei einem Ausfall aber auch konsistente Daten im Cluster - ist ja auch nicht unbedingt schlecht ;-)

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.

Wenn Daten im Nirvana sind kann man es schlecht reparieren. Irgendjemand muss dann halt das was er kurz vorm Ausfall gemacht hat, nocheinmal machen. Gut, man könnte noch das Log von der ausgefallenen Maschine haben, wenn nicht gerade diese Datei oder die Festplatte kaputt ist. Aber auch wenn man an die Daten kommt - wie schnell ist es denn dann wiederhergestellt? Ich denke, der Anwender wird den Fehler sehen, sauer sein, und die Eingabe erneut machen. Selber einspielen macht IMHO nur Sinn, wenn man die Anwendung sperrt bis alles wieder konsistent ist. Aber sowas geht ja schonmal gar nicht automatisch, und gerade das (lange downtime) wollen wir ja vermeiden.

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?

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?

Wie beziffert man das? Wenn ein Datensatz verloren geht, dann ist ein Kunde sauer, und darf irgendeine Aktion erneut ausführen.

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?

Aber das ist normalerweise das tägliche Brot eines Admins: mit viiiel zuwenig Geld Wunder vollbringen zu müssen ,-)

*g*

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.

AFAIK ist der aber auf den meisten Root-Servern die heute gemietet werden vorinstalliert. Gut, das sind natürlich nicht die Server mit den unternehmenskritischen Anwendungen, aber auch Suse Enterprise Linux verwendet einen 2.6er Kernel, die kommende Red Hat Server-Version wird 2.6 verwenden, die aktuelle verwendet schon seit sehr langer Zeit von 2.5/6 portierte Features wie NPTL, O(1) Scheduler..., so ziemlich alle AMD64-Server benötigen einen 2.6er Kernel (und davon gibt es inzwischen nicht wenige!)...

Auf Produktionssystemen mit wertvollen,sprich teuren Daten

also sowas wie dieses Forum? ;-)

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 ;-)

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?

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. Das heißt, wenn ich um 20 Uhr irgendwas problematisches mache, habe ich noch 12 Stunden Zeit das in Ordnung zu bringen ;-)
Bei richtigen™ HA-Systemen hast Du diese Möglichkeit nicht, eben nur mit Hilfe eines Clusters etc.

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.

Aber bei einer Web-Anwendung sterben auch keine 300 Leute wenn was kaputt geht ;-)

Vor allem wenn die beiden Personen bereits Root-Rechte haben ist man eh ausgeliefert.
Aber eines ist dabei natürlich nicht schlecht: man hat zwei Leute, denen man die Schuld geben kann! >;->

*g*

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.

Das meine ich nicht. Ich meine sowas:

Waisman will den Fehler bereits im Mai im Rahmen des so genannten

Vulnerability Sharing Club von Immunity veröffentlicht haben. Für eine

Mitgliedsgebühr ab 50.000 US-Dollar können sich dort Firmen vorab über

Schwachstellen informieren lassen, die Immunity gefunden hat. Für die

Mitgliedschaft muss sich der Kunde allerdings verpflichten, die

Informationen nicht weiter zu geben (Non Disclosure Agreement).

http://www.heise.de/newsticker/meldung/53729

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? Ich verwende eigentlich immer die originalen vanilla-sources mit grsec-patch. 2.4 natürlich :)

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.

Warum? Das Standard-Berechtigungskonzept ist nunmal in machen Fällen etwas zu einfach, oder? 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?

Das ist etwas, was der Kudne verlnagt hatte und nnur saumäßig implementiert wurde.

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) ;-)

Erweiterte Rechte alleine reichen nicht, man muß schon alles einzeln verschlüsseln.

Was hat das damit zu tun? Was denn verschlüsseln? Daten? Dateisysteme?

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.

Hm? Was denn sonst? Wenn es keine 2 Kisten sind, kannst Du nicht so gut an der einen arbeiten, wenn die andere läuft, auch hast Du keine erhöhte Ausfallsicherheit bzgl. Hardware. Und Du kannst nicht besonders schnell zwischen 2 Systemen 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 deren Kundschaft zum größten Teil aus Leuten besteht, die nur sehr wenig Ahnung von Linux haben, aber gerne etwas mehr Traffic hätten, gerne Wohnzimmer-Provider spielen, und evtl. einen netten Game-Server installieren möchten ;-)
Und dann passiert eben regelmäßig sowas https://forum.selfhtml.org/?t=95658&m=580503, oder https://forum.selfhtml.org/?t=95641&m=580399, oder...

Soweit ich weiß - wenn Du sowas auf einem Server im Schlund-Rechenzentrum probierst,

Äh .. Schlund? Junger Mann, ich dachte, wir reden von Hostern? >;->

Ist das keiner? Ich rede von einigermaßen großen Rechenzentren mit hervorragender Anbindung, und bei "Root-Servern" meine ich mietbare Pizzaboxen. Aber wie gesagt, gerade die größeren sind hier recht wenig flexibel. Was wäre denn ein guter "Hoster" in Deiner Interpretation des Begriffes?

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 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.

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 ;-)
Was bringt Dir jetzt noch eine Firewall dazwischen für einen zusätzlichen Vorteil? Der einzige Vorteil den ich vielleicht sehe, wäre, wenn es irgendjemand schafft, evtl. über einen verwundbaren Applikations-Server Zugriff auf den DB-Server zu erhalten, könnte eine Firewall verhindern, dass er eine remote-shell aufmachen kann. Man könnte auch verhindern dass er irgendwas aus dem Netz nachläd - zumindest auf direktem Weg. Aber wenn er eh schon so weit ist, dann ist doch sowieso alles zu spät. Also was bringt es? Ich stecke meine Energie eigentlich da rein, genau diese Situation zu verhindern, und ich wüßte nicht wie eine Firewall dabei helfen könnte. Eine Firewall ist schön und gut um verschiedene Netze sauber voneinander zu trennen, aber um einzelne, direkt aus dem Internet erreichbare Server zu schützen - wo ist da der Sinn?

Ist zwar nach Möglichkeit zu vermeiden, aber das geht ja leider selten.

ja.

Aber zur Firewall - würdest Du hier eine extra-Pizzabox einsetzen?
[...]
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? ;-)

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?

Viele Grüße
Andreas

PS: naja, ich habs wirklich versucht mit dem "kurz fassen" :)

[Christoph Zurnieden]

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).

http://www.heise.de/newsticker/meldung/53729

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

[wahsaga]

hi,

$result = mysql_query("SELECT * FROM login WHERE loginname='$_POST[loginnamedb]' AND loginpass='$_POST[loginpassdb]'", $db);

if(loginname=='$_POST[loginnamedb]' && loginpass=='$_POST[loginpassdb]') {

bitte informiere dich, was mysql_query für einen rückgabewert hat, und was du zu tun hast, um die ergebnismenge auszuwerten.
so einfach, wie du es versucht hast, ist es nicht.
stichwort: die mysql_fetch-funktionen.

aber die brauchst du hier gar nicht unbedingt - es würde ja auch genügen, sich anzuschauen, ob die abfrage keinen ergebnisdatensatz zurücklieferte - dann waren die logindaten wohl nicht in der DB vorhanden. stichwort mysql_num_rows().

und informiere dich bitte auch _dringend_ zum thema sql injections - denn dein code oben ist stark gefährdet diesbezüglich.

gruß,
wahsaga

[Götz]

Hallo Magnus!

Das Formular mit (name="loginname") und (name="loginpass") hab ich gemacht, es wird auch an die Datei login_result.php3 übergeben und folgendes steht nun in der Datei.

Benutzt ihr _wirklich_ noch PHP3?
(Wenn ich mir Deinen Quellcode anschaue kann ich mit Sicherheit sagen: Nein. Warum also .php3 als Dateiendung?)

Quellcode:
[...]
if($_POST[loginname] && $_POST[loginpass]) {

Hier würde ich empty() bevorzugen.
Das gibt wenigstens einen boolschen Wert zurück.

[...]
$result = mysql_query("SELECT * FROM login WHERE loginname='$_POST[loginnamedb]' AND loginpass='$_POST[loginpassdb]'", $db);

In dieser Zeile stehen gleich mehrere Sachen, die man vermeiden sollte.
Siehe dclp FAQ: 16.14. Warum soll ich nicht SELECT * schreiben? und dclp FAQ: 16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?.

if(loginname=='$_POST[loginnamedb]' && loginpass=='$_POST[loginpassdb]') {

Da der String $_POST[loginname] wohl kaum dem Inhalt der (gar nicht gesetzten) Konstanten loginname entspricht ist schon allein der erste Ausdruck falsch. Wg. fauler Auswertung ist der zweite unerheblich (ist aber genauso falsch).
Du solltest Dir auf jeden Fall mal PHP Manual: Types / Strings durchlesen.
Außerdem solltest Du dringend das error_reporting hochsetzen, dann bekommst Du wenigstens brauchbare Meldungen angezeigt.

Es sollte vielleicht eher
if ($_POST['loginname'] == $loginpass && [...])
heißen.

Wobei im geposteten Code-Stück weder $loginname noch $loginpass gesetzt werden.
Außerdem verwendest Du einmal den Index loginname und einmal loginnamedb. Was soll das?

Kurz zusammengefaßt: Dein Code ist von vorn bis hinten kaputt.
Ihr solltet euch beide mal genauer mit PHP befassen, denn die Fehler sind derart offensichtlich, daß ich mich wirklich wundere, daß einer "Ausbilderin" das nicht auf den ersten Blick auffällt.
Daß der Code unübersichtlich ist und das die Fehlersuche nicht unbedingt vereinfacht muß man gar nicht mehr dazusagen.
Deswegen empfehle ich Euch auch gleich noch die Lektüre der PEAR Documentation: Chapter 4. Coding Standards empfehlen. Man muß ja nicht alles übernehmen, aber sie sind auf jeden Fall ein guter Ausgangspunkt.

MfG
Götz