Werner Gast [u] wrote on 07/09/2004 19:49:
ich habe mich gerade ein wenig mit chroot beschaeftigt und ueberlege, ob
es nicht sicherer waere, pppoe und shorewall in einer chroot Umgebung laufen zu lassen. Wenn das moeglich waere, koennte die Hardware noch einige weitere
Dienste fuer die Produktion wie z.B. Faxserver-Dienste uebernehmen.
Ich sehe keinen Sinn darin, den pppd (f�r pppoe) in einem Jail laufen zu lassen. Und f�r shorewall d�rfte �hnliches gelten, allerdings kenne ich das Paket nicht, und weiss nicht, ob es neben der Firewall-Funktionalit�t noch weitere Dienste mitbringt. Wenn ja, _k�nnte_ es Sinn machen, die im chroot zu betreiben.
Fuer das Herstellen einer chroot-Umgebung gibt es ein paar schoene Howtos. Das wuerde ich mir zutrauen. Aber pppoe und shorewall muessten dann einem anderen user als root gehoeren - das ist wahrscheinlich viel Fummelei.
Wahrscheinlich w�rden sie ohne Root-Rechte garnicht funktionieren. Wie die meisten Programme, die direkte im Netzwerk agieren oder die Netzwerk-config des Kernels �ndern.
In einem Chroot Jail muessten nach dem, was ich aus dem gelesenen schliesse, Router/Firewall und eventuell VPNs genauso sicher sein, wie wenn sie auf einer eigenen Hardware laufen wuerden - oder nicht?
Nicht unbedingt. Es gibt einige Auswege aus einem chroot-Jail, zumindest bei einem ungepatchten Kernel. Erst mit Patches wie LIDS oder GRsecurity(2) machen das (fast?) unm�glich.
Bevor ich das in die Praxis umsetze, moechte ich Euch fragen, ob diese Gedankengaenge richtig oder vielleicht doch abwegig sind?
Ich halte sie f�r abwegig, weil diese beiden Pakete erstens kaum eigene Sicherheitsl�cken aufweisen d�rften und zweitens ist das Hauptproblem hier nicht, das die Software der Firewall (nach Deinem Gedankengang pppoe und shorewall) viele L�cken bieten w�rden, sondern dass Du eventuell unbeabsichtigt Dienste im/zum Internet anbietest, die Du besser nicht anbieten solltest.
Wenn Du auf der gleichen Hardware die Internetverbindung entgegen nehmen willst, aber auch andere Dienste anbieten m�chtest (zum lokalen Netzwerk), dann verlege Deine Energie lieber darauf, andere Sicherheitsma�nahmen zu ergreifen, als die in diesem Zusammenhang wohl unwichtigsten Dienste in chroot-Jails zu verlegen. So solltest Du zum Beispiel mal sehen, ob Du dem Kernel nicht mehr Sicherheit beibringst (insbesondere LIDS und grsecurity sind hier wichtig, ich benutze meist nur grsecurity). Au�erdem solltest Du viel Wert auf die Richtigkeit Deiner Firewall-Regeln legen.
Wenn Du unbedingt auf der gleichen Hardware die Firewall-Software logisch maximal gegen die sonstige Software abgrenzen m�chtest, dann hilft Dir vielleicht VMware oder evtl. auch UserModeLinux weiterhelfen (ich selbst habe einem Kunden mal eine Firewall in VMware eingerichtet: VMware nahm auf eth1 des hosts die Internetverbindung entgegen, �ber virtuelles Interface ging es dann an das Hostsystem weiter, das wiederum �ber eth0 ans lokale Netz angebunden war. Vorteil: Bei dem Verdacht eines Einbruchs in die Firewall konnte man einfach das DiskImage f�r eine Analyse kopieren und die Firewall aus dem letzten als sicher bekannten Snapshot wieder neu starten. Au�erdem sieht das hostsystem auf Wunsch ja die gesamte "Festplatte" der Firewall und kann sanity-Checks durchf�hren um einen Einbruch �berhaupt erst zu entdecken.)
Ciao, Sven
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
