LinuxFocus article number 225 http://linuxfocus.org

von Mark Nielsen (homepage) Über den Autor: Mark arbeitet als freischaffender IT Consultant and verbringt Zeit mit seinem Engagement für Dinge wie GNUJobs.com, Artikel und Freie Software schreiben und er arbeitet als Freiwilliger bei eastmont.net mit. Übersetzt ins Deutsche von: Sebastian Stein (homepage)

Chroot für alle Dienste unter Linux nutzen Zusammenfassung: Über chroot abgesicherte Systemdienste verbessern die Systemsicherheit, da bei erfolgreichem Einbruch in das System der mögliche Schaden begrenzt wird. _________________ _________________ _________________

Einleitung

Wozu ist das nützlich? Wenn jemand in einen Computer einbricht, sieht er nicht alle Dateien des Systems. Auf Dateien, die man aber nicht kennt, kann man nur schwer Kommandos anwenden und man kann sich weiterhin nicht den Inhalt jeder unsicheren Datei anzeigen lassen. Der einzige Nachteil ist, dass dies die Einbrecher nicht davon abhalten dürfte, den Netzverkehr und andere Dinge weiterhin zu belauschen. Man sollte deshalb noch weitere Sicherheitsmaßnahmen ergreifen, die aber nicht Umfang dieses Artikels sein können:

• Absicherung der Netzwerk-Ports
• alle Dienste sollten unter einem nicht Root Account laufen. Weiterhin sollte jeder Dienst über chroot abgesichert sein.
• Systemlog-Dateien sollten auf einen anderen Computer weitergeleitet werden.
• Analyse der Log-Dateien
• Analyse über die Leute, die nach offenen Ports des Systems suchen
• CPU und Speicher Ressourcen für jeden Dienst begrenzen
• Quotas für jeden Account aktivieren

BITTE DRANDENKEN, dass mein Vorgehen nicht unbedingt 100%ig genau ist. Es ist mein erster Versuch sowas darzustellen, aber wenn der Hauptteil funktioniert, sollte der Feinschliff für jeden möglich sein. Das hier ist eigentlich nur die Roadmap für ein chroot HowTo, an der ich arbeite.  

Wie können wir chroot anwenden?

• Syslogd wird für jeden Dienst bereitgestellt
• Apache installieren unter /chroot/httpd
• Ssh installieren unter /chroot/sshd.
• PostgreSQL installieren unter /chroot/postmaster.
• Sendmail kann ebenfalls mit chroot gesichert werden, aber es kann leider nicht unter einem nicht Superuser Account ausgeführt werden.
• ntpd installieren unter /chroot/ntpd
• named installieren unter /chroot/named

Mein Perl Skript um chroot Umgebungen zu erzeugen

1. chroot Verzeichnis anlegen:
   mkdir -p /chroot/Config/Backup
2. Download von Config_Chroot.pl.txt als /chroot/Config_Chroot.pl
3. Die $Home Variable im Perl Skript muss angepasst werden, wenn /chroot nicht als Home Verzeichnis verwendet wird.
4. Download meiner Konfigurationsdateien

Deshalb muss man eventuell das Perl Skript an die eigene Distribution anpassen.

Zuerst schrieb ich an einem gigantisch riesigen Artikel zu chroot, aber mit dem Perl Skript konnte ich ihn wesentlich kürzen. Denn nachdem ich viele Dienste mit chroot abgesichert hatte, stellte ich fest, dass viele Ähnlichkeiten bestehen. Der einfachste Weg herauszufinden, welche Dateien angepasst werden müssen, ist in die entsprechende manpage zu schauen und "ldd /usr/bin/file" bei Programmen, die Bibliotheken benutzen, einzugeben. Man kann natürlich auch den Dienst einfach mit chroot in eine neue Umgebung zwingen und schauen, welche Fehlermeldungen z.B. in den Log-Dateien angezeigt werden.

Um einen Dienst abzusichern, sollte man folgendermaßen vorgehen:

cd /chroot
./Config_Chroot.pl config  SERVICE
./Config_Chroot.pl install SERVICE
./Config_Chroot.pl start   SERVICE

Chroot für Ntpd

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
#./Config_Chroot.pl config  ntpd
./Config_Chroot.pl install ntpd
./Config_Chroot.pl start   ntpd

Chroot für DNS oder named

Oder man nutzt mein Skript:

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
#./Config_Chroot.pl config  named
./Config_Chroot.pl install named
./Config_Chroot.pl start   named

Chroot für Syslog mit Diensten und einigen Kritikpunkten von mir

• Chroot Umgebung für syslogd mit jedem Dienst. Es ist dann zwar möglich Log-Dateien zu erstellen, aber mir gefällt die Lösung nicht, da syslogd als Superuser laufen muss.
• vielleicht kann man ein anderes System zum Erstellen der Log-Dateien nutzen.
• Man kann natürlich auch Daten einfach in Dateien loggen lassen ohne syslogd zu verwenden. Das hat den Nachteil, dass eine Manipulation der Dateien durch einen Einbrecher möglich ist.
• Den Hauptdämon von syslogd so konfigurieren, dass er an verschiedenen Stellen nach allen Diensten schaut. Dazu muss man die -a Option von syslogd nutzen.

Möchte man nicht je einen seperaten syslogd für jeden Dienst, dann sollte man folgende Zeile beim Start von syslogd hinzufügen:

syslogd -a /chroot/SERVICE/dev/log

syslogd -a /chroot/ssh/dev/log -a /chroot/named/dev/log -a /dev/log

Letzter Hinweis zu syslogd: ich wünschte, es wäre möglich, es unter einem nicht priviligierten Account laufen zu lassen. Ich habe verschiedene Sachen probiert, aber letztendlich aufgeben müssen. Wenn ich syslogd aber dazu bewegen könnte, wäre ein weiteres Sicherheitsrisiko beseitigt und ich würde mich wohler fühlen. Das Gleiche gilt für ein mögliches loggen per externen Rechner.  

Chroot für Apache

$dbh ||= DBI->connect('dbi:Pg:dbname=DATABASE',"","", {PrintError=>0});

if ($dbh ) {$dbh->{PrintError} = 1;}
else
  {$dbh ||= DBI->connect('dbi:Pg:dbname=DATABASE;host=127.0.0.1',"","",
      {PrintError=>1});}

Quelle: http://httpd.apache.org/dist/httpd/

Zuerst Apache auf dem Hauptsystem unter /usr/local/apache kompilieren und installieren. Danach das Perl Skript nutzen:

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
# ./Config_Chroot.pl config  httpd
./Config_Chroot.pl install httpd
./Config_Chroot.pl start   httpd

ExtendedStatus On

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

Chroot für Ssh

Es sei nochmal darauf hingewiesen, dass wir nur ssh absichern und jeder sich selber über die Konsequenzen im Klaren sein muss (ein Zugang zum System ist nach der Änderung nicht mehr möglich). Weiterhin interessant wäre, die Log-Dateien auf einem anderen Rechner speichern zu lassen. Weiterhin sollte man OpenSSH verwenden, auch wenn ich hier die kommerzielle Variante benutzt habe aus Gründen der Einfachheit (eine schlechte Ausrede, ich weiß).

Quelle: http://www.ssh.com/products/ssh/download.cfm

Installation von ssh unter /usr/local/ssh_chroot. Dann das Perl Skript:

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
 # ./Config_Chroot.pl config  sshd
./Config_Chroot.pl install sshd
./Config_Chroot.pl start   sshd

Chroot für PostgreSQL

Quelle: ftp://ftp.us.postgresql.org/source/v7.1.3/postgresql-7.1.3.tar.gz

PostgreSQL unter /usr/local/postgres kompilieren und installieren. Dann noch das Perl Skript:

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
# ./Config_Chroot.pl config  postgres
./Config_Chroot.pl install postgres
./Config_Chroot.pl start   postgres

Chroot für Sendmail

cd /chroot
 # die nächste Zeile unkommentieren, wenn nicht meine Konfigurationsdatei
 # verwendet wird
# ./Config_Chroot.pl config  sendmail
./Config_Chroot.pl install sendmail
./Config_Chroot.pl start   sendmail

Das gute daran ist, dass man immer Mails verschicken kann, aber mit dem Empfang gibt es Probleme. Deshalb habe ich sendmail mit apache installiert. Einige Perl Skripte versenden nun Mails und deshalb war eine Installation von sendmail in der apache Umgebung notwendig.  

Andere Dinge mit chroot

1. alles sollte mit chroot abgesichert werden wie sendmail, ssh, apache postgresql, syslog und jeder andere auf dem Computer laufende Dienst
2. Alles sollte unter einem nicht priviligierten Account ausgeführt werden. Dazu muss man eventuell geschützte Ports auf nicht geschützte weiterleiten. (so geschehen z.B. bei sendmail und syslog)
3. Log-Dateien außerhalb sichern lassen
4. Für jeden Dienst eine eigene Partition bereitstellen, damit Cracker nicht soviel Festplattenspeicher haben, falls sie sich entscheiden, Dateien zu schreiben. Dateisysteme können ebenfalls über das Loopback Device gemountet werden.
5. Root sollte Besitzer von allen Dateien sein, die nicht geändert werden

Syslog habe ich gar nicht erst probiert, aber auch hier sehe ich keinen Grund, warum es nicht möglich sein sollte, Log-Dateien als nicht Superuser zu schreiben. Wenigstens habe ich es geschafft, syslog in abgesicherte Umgebungen zu zwingen.

Alle Dienste sollten als nicht root Accounts eingestellt werden. Sogar NFS. Wirklich alle!  

Vorschläge

• Man sollte 2 Logins für ssh und zwei ssh Dämons benutzen
• Man sollte herausfinden, wie man sendmail und andere Dienste als nicht root laufen lässt.
• Man sollte die unnötigen Bibliotheken unter /lib rauswerfen. Ich habe einfach alle rauskopiert. Die meisten braucht man nämlich nicht.
• Log-Dateien sollte man auf einem entfernten System sichern und man sollte herausfinden, ob man syslog an einen Netzwerk Port binden kann. Auch sollte syslog als nicht root ausgeführt werden.

Schlussfolgerung

Ich unterstütze die Idee der kompletten chroot Umgebungen 100%ig, genauso wie die nicht root Accounts für die Dienste. Jede Distribution sollte dies eigentlich bieten, zumindest wenn sie im produktiven Umfeld eingesetzt werden soll.

Ich plane eine HowTo über chroot zu erstellen. Vielleicht kann mir ja jemand dabei helfen diesen Artikel in das LyX Format umzuwandeln, damit es in die Linux HowTo aufgenommen werden kann.  

Hinweis

1. Falls eine Aktualisierung dieses Artikels notwendig wird, wird sie hier unter http://www.gnujobs.com/Articles/23/chroot.html verfügbar sein.

2005-01-14, generated by lfparser_pdf version 2.51