Apache Chroot

Aus Gentoo Linux Wiki

[Bearbeiten] Apache2

Der folgende Artikel geht davon aus, das Sie ein lauffähiges apache2 installiert und für PHP und SSL konfiguriert haben. die folgenden Anweisungen beruhen auf apache-2.0.55-r1 und php-5.1.4

echo "apache mpm-prefork" >> /etc/portage/package.use
echo "dev-lang/php unicode" >> /etc/portage/package.use
emerge -av apache dev-lang/php

[Bearbeiten] separate chroot-Partition

Das chroot-Verzeichnis sollte möglichst auf einer separaten Partition liegen, die als "nosuid" gemountet werden kann. Da Dateien mit gesetztem suid-Bit von Angreifern genutzt werden können, um aus dem chroot-Gefängnis auszubrechen, sollte man im chroot-Bereich niemals Dateien mit suid-Bit verwenden. Eine mit "nosuid" gemountete Partition kann insofern helfen, Konfigurationsfehler auszugleichen.

/dev/xyz    /chroot    auto    noatime,nosuid    0  2

[Bearbeiten] Härten der chroot

Der Ausbruch aus einer "normalen" chroot ist mit verschiedenen Tricks möglich. Möglichkeiten, sich davor zu schützen, werden im Anhang beschrieben. Da der Apache hierzu neu kompiliert werden muss, sollte man dies vor Einrichtung der chroot tun, um die gehärteten Binaries dort verwenden zu können. Ob diese spezielle Härtung erforderlich ist, hängt vom Einsatzgebiet des Webservers und auch etwas von Ihrer "Paranoidität" ab.

[Bearbeiten] Installation von "jail"

"jail" ist ein sehr nützliches Tool zur Einrichtung von chroot-Umgebungen.

emerge -av app-misc/jail

[Bearbeiten] Definieren der Variablen CHROOT

Um ein Copy und Paste der folgenden Befehle zu ermöglichen, wird die Variable CHROOT definiert. Den Pfad müssen Sie an Ihre Gegebenheiten anpassen.

CHROOT=/chroot/apache

[Bearbeiten] Erstellen einer Basis chroot-Umgebung für Apache

Der folgende Befehl erstellt das Verzeichnis "apache" und wenige elementare Dateien darin. Je weniger Dateien sich in der chroot-Umgebung befinden, desto besser. Etwas Nacharbeit ist erforderlich.

mkjailenv $CHROOT
mknod -m 444 $CHROOT/dev/random c 1 8 
mkdir $CHROOT/lib
cp /lib/ld-linux.so.2 $CHROOT/lib
cp /etc/mime.types $CHROOT/etc/
mkdir -p $CHROOT/var/www/localhost/htdocs
chown apache:apache $CHROOT/var/www/localhost/htdocs
chmod 550 $CHROOT/var/www/localhost/htdocs
mkdir -p $CHROOT/var/{log,cache,run}
install -d -o apache -g apache -m 750 $CHROOT/var/{log,cache}/apache2

[Bearbeiten] Anlegen des Users "apache" in der chroot

Außer einem root-Prozess, der die Verwaltungsarbeit erledig, startet Apache mehrere Sub-Prozesse, die aus Sicherheitsgründen unter dem User "apache" laufen sollten. Der folgende Befehl legt diesen in den Dateien passwd, shadow und group in der chroot-Umgebung an. Die Werte für Homeverzeichnis (/dev/null) und Shell (/usr/sbin/nologin) sind absichtlich "ungültig".

addjailuser $CHROOT /dev/null /usr/sbin/nologin apache

[Bearbeiten] Herausfinden, welche Dateien der Apache benötigt

Um dies herauszubekommen, muss der Apache wie üblich gestartet werden. Dem Programm "addjailsw" wird hierfür außer dem Pfad der chroot-Umgebung der komplette Programmaufruf als Parameter übergeben. Er arbeitet als "wrapper". addjailsw startet den Apache, analysiert, welche Dateien geöffnet werden und kopiert diese automatisch in die chroot-Umgebung. Die ersten beiden Anweisungen (s.u.) dienen dazu, herauszubekommen, wie der Apache-Programmaufruf genau aussieht. Dazu wird das Apache-Init-Script der "normalen" Apache-Installation gestartet. Gegebenenfalls vorher Port 80 und 443 in der lokalen Firewall nach außen blockieren, falls Sie Ihrem nicht-chroot Apache nicht trauen.

/etc/init.d/apache start          # Starten des "normalen" Apache
ps aux | grep apache2 | grep root # wie sieht der Programmaufruf aus? (/usr/sbin/apache2 ...)
/etc/init.d/apache stop           # das war's. Kann wieder gestoppt werden
addjailsw $CHROOT -P /usr/sbin/apache2 "-D DEFAULT_VHOST -D PHP5 -D SSL -D SSL_DEFAULT_VHOST -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start"

[Bearbeiten] Überprüfung des Ergebnisses

Nach dem Aufruf von addjailsw sollten Sie prüfen, ob der Apache problemlos gestartet ist. Dazu dienen die folgenden Befehle. Nach den Tests können Sie den Apache wieder stoppen, sofern er gestartet ist.

echo $?			# Returncode=0?
ps aux | grep apache2	# Prozesse gestartet?
killall -TERM apache2	# falls ja, wieder sanft beenden
cd $CHROOT/etc
ls passwd shadow group hosts host.conf resolv.conf mime.types nsswitch.conf
# alle Dateien sollten gefunden werden

[Bearbeiten] Kopieren fehlender Dateien

Einige Dateien müssen manuell in die chroot hineinkopiert werden, da sie von "addjailsw" nicht entdeckt wurden.

cd $CHROOT/etc
rm apache2 -rf
cp -a /etc/apache2 $CHROOT/etc/	# Konfigurationsdateien kopieren
cd $CHROOT/usr/lib/apache2/ 
rm logs conf -rf
cp -d /usr/lib/apache2/* $CHROOT/usr/lib/apache2/ # fehlende Links kopieren
# die Meldung "cp: omitting directory..." können Sie ignorieren

[Bearbeiten] wichtige Überprüfungen

Es sollte überprüft werden, ob die Links aus dem vorigen Absatz richtig kopiert wurden.

ls -l $CHROOT/usr/lib/apache2/
# Die Ausgabe sollte etwa so aussehen (3 Links und 1 Verzeichnis):
#...conf -> /etc/apache2
#...lib -> /usr/lib
#...logs > /var/log/apache2
#...modules

Ferner sollte überprüft werden, ob die x509-Server-Zertifikate richtig übernommen wurden.

cd $CHROOT/etc/apache2/ssl
ls -l    # server.crt und server.key gefunden?
openssl x509 -in server.crt -text | less    # ist es das richtige Zertifikat?

[Bearbeiten] Dateiberechtigungen überprüfen und korrigieren

Die Dateiberechtigungen sollten unbedingt überprüft werden, denn wenn er hierbei Fehler gibt, nützt die ganze chroot nichts!

find $CHROOT/etc -type f -exec chmod -x {} ';' #Berechtigungen korrigieren
find $CHROOT/lib -not -perm 0755 # es dürfte nichts gefunden werden
find $CHROOT/usr/{lib,sbin} -not -perm 0755  # es dürfte nichts gefunden werden
find $CHROOT/etc -type f -perm -6000 # gibt es suid- bzw. guid-Dateien?
find $CHROOT -perm -0002 -or -perm -0020 # Schreibberechtigung für "world" bzw. "group"?

Die Ausgabe des letzten Befehls sollte etwa so aussehen:
.../dev/null	# 0666, OK
.../dev/zero	# 0666, OK
.../tmp		# 1777, OK
.../var/tmp	# 1777, OK
.../usr/lib/apache2/lib  # link, daher ist 0777 OK
.../usr/lib/apache2/conf # link, daher ist 0777 OK
.../usr/lib/apache2/logs # link, daher ist 0777 OK

[Bearbeiten] unnötige User/Gruppen löschen

Die chroot sollte so spartanisch wie möglich sein. Daher sollen alle Benutzer und Gruppen bis auf "apache" gelöscht werden:

# alle User/Gruppen löschen außer "apache" in folgenden Dateien
# Vorsicht bei folgenden Befehlen!
# Sie müssen im Verzeichnis $CHROOT/etc sein, nicht im Verzeichnis /etc!
cd $CHROOT/etc
if [[ $PWD != "/etc" ]]
then 
   sed -i -n '/^apache.*/p' passwd
   sed -i -n '/^apache.*/p' group
   sed -i -n '/^apache.*/p' shadow
fi

[Bearbeiten] Probe aufs Exempel

Nachdem alle Vorarbeiten abgeschlossen sind, kann der Versuch unternommen werden, Apache in der chroot-Umgebung zu starten. Wie Sie den in Ihrem System gültigen Startbefehl herausbekommen, wurde oben beschrieben.

chroot $CHROOT /usr/sbin/apache2 -D DEFAULT_VHOST -D PHP5 -D SSL -D SSL_DEFAULT_VHOST -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
echo $?  		# Returncode = 0?
ps aux | grep apache2	# Prozesse gestartet?
less $CHROOT/var/log/apache2/error_log # was sagt das Logfile?
ls -la $CHROOT/var/run/  # "apache2.pid" und "cgisock" vorhanden?

[Bearbeiten] Erfolg gehabt?

Als letztes sollte geprüft werden, ob die Prozesse tatsächlich in der chroot-Umgebung laufen. Sonst wäre alle Mühe umsonst gewesen.

APACHE_PIDS="$(pgrep apache2)" # welches sind die Prozess-IDs?
for process in $APACHE_PIDS; do ls /proc/$process/root; done

Der letzte Befehl prüft, wie die "root" (also das, was man sieht, wenn man "ls /" eingibt) für die Apache-Prozesse aussieht. Wenn sie die "normale" root sehen, dann laufen Sie nicht in der chroot-Umgebung. Wenn sie jedoch die abgespeckte root sehen, dann ist alles OK. Diese müsste so aussehen:

dev	etc	lib	tmp	usr	var

Wer immer noch misstrauisch ist, kann sich ausgeben lassen, wie die passwd aussieht, die die Prozesse sehen:

APACHE_PIDS="$(pgrep apache2)" # welches sind die Prozess-IDs?
for process in $APACHE_PIDS; do cat /proc/$process/root/etc/passwd; done

Der letzte Befehl müsste für jeden Prozess die abgespeckte, nur aus einer Zeile bestehende passwd ausgeben.

apache:x:81:81:added by portage for apache:/dev/null:/usr/sbin/nologin

[Bearbeiten] neues Init-Script schreiben

An dieser Stelle sollte man ein angepasstes Init-Script für den chroot-Start schreiben. Ich würde das vorhandene gentoo apache-Init-Script nicht abändern, damit man den nicht chrooteten Apache weiterhin starten kann, wenn man ihn braucht. Das neue Script unterscheidet sich im Prinzip nur dadurch, dass "chroot $CHROOT..." vor den üblichen Programmaufruf gesetzt werden muss.

CHROOT=/chroot/apache
chroot $CHROOT /usr/sbin/apache2 ...

Ich (Slalomsk8er) würde es möglichst nach dem Original gestalten, also mit den selben Funktionen, wie zum Beispiel einer Konfiguration in einer externen Datei im /etc/conf.d Verzeichniss. Aber das ist eine Geschmacksfrage.

#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

opts="${opts} reload configtest"

# this next comment is important, don't remove it - it has to be somewhere in
# the init script to kill off a warning that doesn't apply to us
# svc_start svc_stop

depend() {
        need net
        use mysql dns logger netmount postgresql
        after sshd
}

configtest() {
        ebegin "Checking Apache Configuration"
        checkconfig
        eend $?
}

checkconfig() {

        SERVERROOT="${SERVERROOT:-/usr/lib/apache2}"
        if [ ! -d "${CHROOT}/${SERVERROOT}" ]; then
                eerror "SERVERROOT does not exist: ${SERVERROOT}"
                return 1
        fi

        CONFIGFILE="${CONFIGFILE:-/etc/apache2/httpd.conf}"
        [ ${CONFIGFILE:0:1} != "/" ] && CONFIGFILE="${SERVERROOT}/${CONFIGFILE}"
        if [ ! -r "${CHROOT}/${CONFIGFILE}" ]; then
                eerror "Unable to read configuration file: ${CONFIGFILE}"
                return 1
        fi

        # check to see if the old config files exist and aren't used
        #if [[ "${CONFIGFILE}" != "/etc/apache2/conf/apache2.conf" &&
        #               -e "/etc/apache2/conf/apache2.conf" ]]; then
        #       eerror "Found old apache2.conf in /etc/apache2/conf. Configuration locations \n have moved, please check ${CONFIGFILE} to make sure it is correct, \n and remove /etc/apache2/conf/apache2.conf.\n\n Please see http://www.gentoo.org/doc/en/apache-upgrading.xml\n for more information."
        #       return 1
        #fi

        [ -n "${SERVERROOT}" ] && APACHE2_OPTS="${APACHE2_OPTS} -d ${SERVERROOT}"
        [ -n "${CONFIGFILE}" ] && APACHE2_OPTS="${APACHE2_OPTS} -f ${CONFIGFILE}"
        [ -n "${STARTUPERRORLOG}" ] && APACHE2_OPTS="${APACHE2_OPTS} -E ${STARTUPERRORLOG}"

        # set a sane default for KEEPENV and OLDENV
        KEEPENV=${KEEPENV:-PATH}
        OLDENV=

        for env_var in ${KEEPENV}; do
                OLDENV="${OLDENV} ${env_var}=`printenv ${env_var}`"
        done

        APACHE_ENV="env -i ${OLDENV}"
        APACHE2="/usr/sbin/apache2"

        $APACHE_ENV chroot ${CHROOT} ${APACHE2} ${APACHE2_OPTS} -t 1>/dev/null 2>&1
        ret=$?
        if [ $ret -ne 0 ]; then
                eerror "Apache2 has detected a syntax error in your configuration files:"
                chroot ${CHROOT} ${APACHE2} ${APACHE2_OPTS} -t
        fi

        return $ret
}

start() {
        checkconfig || return 1
        ebegin "Starting apache2"
        [ -f /var/log/apache2/ssl_scache ] && rm /var/log/apache2/ssl_scache
        $APACHE_ENV chroot ${CHROOT} ${APACHE2} ${APACHE2_OPTS} -k start
        eend $?
}

stop() {
        checkconfig || return 1
        ebegin "Stopping apache2"
        $APACHE_ENV chroot ${CHROOT} ${APACHE2} ${APACHE2_OPTS} -k stop
        killall -TERM apache2 # This is a ugly fix that ends apached for shure
        eend $?
}

reload() {
        if ! service_started "${myservice}" ; then
                eerror "Apache is not running! Please start it before trying to reload it."
        else
                checkconfig || return 1
                ebegin "Reloading apache2"
                $APACHE_ENV chroot ${CHROOT} ${APACHE2} ${APACHE2_OPTS} -k graceful
                eend $?
        fi
}

Dazu die angepasste Konfigurationsdatei. Die Konfigurationsdatei vom nicht-chrooteten Apache kann unverändert bleiben. Nicht vergessen, die CHROOT-Variable am Ende anzupassen!

# /etc/conf.d/apache2_chroot: config file for /etc/init.d/apache2_chroot

APACHE2_OPTS="-D DEFAULT_VHOST -D PHP5 -D SSL -D SSL_DEFAULT_VHOST"
CONFIGFILE=/etc/apache2/httpd.conf
STARTUPERRORLOG="/var/log/apache2/startuperror.log"
KEEPENV="PATH"
CHROOT=/chroot/apache

[Bearbeiten] Alternative zu Initscript abändern

Eine Alternative die bei mit besser lief, da untenstehendes script immer mit einem "apache2 has already been started" abgebrochen wurde. Auf jeden Fall ist das Gentoo System danach sauberer.

emerge www-apache/mod_chroot

CHROOT="/chroot/apache" # hier das change root eintragen

Nun ist nur noch in dem apache module die Variable "ChrootDir" auf den richtigen Wert zu setzen und fertig.

[Bearbeiten] Arbeitsergebnisse sichern und Dateien nach Update synchronisieren

Wenn alles funktioniert, sollte man das chroot-Verzeichnis sichern, damit man im Notfall auf eine ältere Version zurückgreifen kann. Das ganze lässt sich natürlich automatisieren, worauf ich hier aber nicht eingehen kann.

killall -TERM apache2  # vorher alle Prozesse stoppen
cp -a $CHROOT /home/xyz/backups/chroot/apache-2006-06-18 # mit Datumssuffix!

Um Aktualisierungen von Apache bzw. PHP bequem vom normalen ins chroot-System übernehmen zu können, solle man eine Dateiliste erstellen, die dann von rsync zur Synchronisierung verwendet werden kann.

cd /chroot/apache # cd ins chroot-Verzeichnis ist hierbei wichtig!!
find . -type f | sed 's/^\.//' > /root/apache-chroot-files-complete.txt # sed löscht "." am Anfang
cp /root/apache-chroot-files-complete /root/apache-chroot-files-for-update.txt

Von der erstellten Datei wird eine Kopie erstellt. Die Kopie dient rsync zur Synchronisation. Dazu müssen alle Zeilen gelöscht werden, deren Inhalt nicht synchronisiert werden soll. Bei den Zeilen "/etc/apache2/*" und "/var/www/*" muss überlegt werden, ob nicht-chroot- und chroot-Apache identisch konfiguriert sein sollen. Falls ja, kann man die Zeilen löschen.

#folgende Zeilen löschen, soweit vorhanden. Dateien werden dann nicht synchronisiert
/etc/nsswitch.conf
/etc/group
/etc/shadow
/etc/passwd
/etc/ld.so.cache
/etc/apache2/*  # eventuell lassen, falls beide Apaches gleich sein sollen.
/tmp/*
/var/tmp/*
/var/log/apache2/*
/var/run/*
/var/www/*  # eventuell lassen, besser ist aber ein symbolischer Link
/var/cache/apache2/*

Statt die www-Root zu synchronisieren, könnte man einen Link anlegen. Dazu muss vorher das www-Verzeichnis in der nicht-chroot-Umgebung umbenannt werden. Auf jeden Fall sollte man an dieser Stelle sehr sorgfältig vorgehen, um zu vermeiden, dass es zu einer ungewollten Vermischung von Dateien zwischen nicht-chroot und chroot-Apache kommt, v.a. dann, wenn die www-Root des nicht-chroot-Apache zu Testzwecken verwendet wird. Also vorher unbedingt genau überlegen, wie man es organisatorisch handhaben will.

mv /var/www /var/www-nicht-chroot
ln -s $CHROOT/var/www /var/www

Nach einem wichigen Update des nicht-chroot-Apaches sollten die geänderten Programmdateien in die chroot übernommen werden. Dies ist deshalb zu empfehlen, weil durch Updates oft Sicherheitslücken beseitigt werden. Wenn man die chroot nicht aktualisiert, ergibt der ganze Aufwand keinen Sinn.

emerge -av --update --newuse apache # Update auf dem nicht-chroot-System
cd /root
rsync -tvuL --files-from=apache-chroot-files-for-update.txt  /  /chroot/apache/   # "/" = Quelle

[Bearbeiten] Anhang: Härten der chroot

[Bearbeiten] Stack Smashing Protection (SSP)

SSP hilft, Bufferoverflow-Angriffe abzuwehren. SSP lässt sich in ein ausführbares Programm einbauen, indem man es mit dem "hardened" gcc neu kompiliert. Dazu müssen zunächst gcc und glibc neu kompiliert werden mit dem USE-flag "hardened". Ich empfehle, das flag zu den USE-flags in der /etc/make.conf hinzuzufügen, da es sich auch auf andere Programme auswirkt. Das Sicherheitsfeature "PIE", das hierbei ebenfalls installiert wird, wird erst aktiv wenn die PAX-Funktionen im gehärteten Kernel aktiviert werden. Bei PIE geht es um "Position Independent Execution", also um das Laden von Code an zufällige Positionen im Hauptspeicher. Dies erschwert es Hackern, Code durch einen Bufferoverflow an die gewünschte Stelle im Haupspeicher zu positionieren. Ich verweise auf folgenden Artikel: http://www.gentoo.org/proj/en/hardened/grsecurity.xml

USE="hardened ..."

emerge -av --update --newuse gcc glibc

Anschließend kann man durch den Befehl "gcc-config" prüfen, welche gcc-Version aktiv ist.

gcc-config -l
# Ausgabe z.B.
# [1] i686-pc-linux-gnu-3.4.6*  # "*" bedeutet: diese Version ist aktiv
# [2] i686-pc-linux-gnu-3.4.6-hardenednopie
# usw.

Falls die gewünschte Version nicht aktiv ist, kann man dies durch Eingabe von "gcc-config 1" erreichen. Die erste Zeile bezeichnet die normale "hardened"-Version, also ohne Deaktivierung von PIE und/oder SSP.

gcc-config 1  # -> 1. Zeile aktivieren
env-update
source /etc/profile

emerge -av apache

[Bearbeiten] grsecurity

grsecurity enthält einige ausgefeilte Funktionen, um die chroot abzusichern. Um sie zu aktivieren, müssen die hardened-sources installiert und der Kernel neu kompiliert werden.

emerge -av hardened-sources
cd /usr/src/linux-2.6.16-hardened-r10/
make menuconfig
make && make modules_install
mount /boot
cp System.map /boot/System.map-2.6.16-hardened-r10
cp arch/i386/boot/bzImage /boot/kernel-2.6.16-hardened-r10
cp .config /boot/config-2.6.16-hardened-r10
vim /boot/grub/grub.conf  # erstellen Sie einen zusätzlichen Eintrag und rebooten Sie

Kernel-Konfiguration

--> Security-Options
   --> Grsecurity
      --> Filesystem Protections
         --> chroot jail restrictions
             [alles darunter aktivieren]

Leider kann ich auf die vielen anderen Sicherheitsoptionen hier nicht eingehen, das dies den Umfang dieses Howtos sprengen würde.

[Bearbeiten] Ausblick

Dies kann nur der Anfang der Absicherung Ihrer Apache-Installation sein. Mindestens genauso wichtig ist die richtige Konfiguration der conf- bzw. ini-Dateien (httpd.conf, php.ini usw.). Auch die Installation von mod_security kann die Sicherheit weiterhin erhöhen. Obwohl ich die Idee des chroot prinzipiell richtig finde, möchte ich auch auf gewisse Nachteile hinweisen: Aufgrund der diversen manuellen Eingriffe, besteht die Gefahr der Fehlkonfiguration, die das System u.U. unsicherer macht als eine nicht-chroot Standardinstallation. Wer die Materie nicht "perfekt" beherrscht, sollte doch eher Abstand von der Sache nehmen. Ein weiterer Nachteil ist, dass es recht aufwändig ist, ein chroot-System auf dem Laufenden zu halten. Nach einem Update des Apache in der normalen Umgebung, das per rsync in die chroot eingespielt wird, besteht die Gefahr, dass die chroot z.B. aufgrund fehlender Dateien nicht mehr richtig funktioniert. Für den Profi wird es kein Problem sein, die Dinge zurechtzubiegen, aber wer nur wenig Zeit hat, wird möglicher Weise an seine Grenzen stoßen. Aber selbst wenn man im Endeffekt kein chroot-System produktiv verwenden wird, kann man doch unendlich viel lernen bei der Einrichtung eines solchen Systems.

SK, Ostfildern, den 30.7.2006