HTTP/HTTPS: virtuelles Hosting, private Verzeichnisse, Bereitstellung eines CGI-Skripts, in Gruppen verwaltete Inhalte

Der Webserver Apache wird am besten durch Aufruf von

yum groupinstall "Web server"

installiert. Die Gruppe „Web server“ enthält die am meisten verwendeten Module und bietet alle Funktionen die für die Erfüllung der Prüfungsziele notwendig ist. In produktiven Systemen sollte natürlich nur installiert werden was auch genutzt wird.

Server starten

Durch Aufruf von service und chkconfig wird Apache gestartet und für den Start beim Hochfahren markiert:

service http start    # Apache jetzt starten
chkconfig httpd on    # beim Hochfahren starten

Ausnahme in die Firewall hinzufügen

Die Firewall wird am einfachsten mit dem Werkzeug system-config-firewall-tui angepasst. Eine Installation erfolgt durch

yum install system-config-firewall-tui

Aufruf der Werkzeugs zur Firewallkonfiguration:

system-config-firewall-tui

–> Anpassen –> „WWW (HTTP)“ und gegebenfalls „Sicheres WWW (HTTPS)“ markieren

–> Schließen

Welcome- und Manual-Seiten entfernen

Nach der Installation ist noch eine Test-Seite zu sehen die standardmäßig angezeigt wird, falls sich keine index.html im DocumentRoot befindet. Außerdem wird unter dem Alias manual (http://1.2.3.4/manual) die Dokumentation zu Apache angezeigt. Dieses Verhalten wird duch die Datei welcome.conf und manual.conf in /etc/httpd/conf.d gesteuert. Falls die Willkommens/Hilfeseite nicht angezeigt werden soll ist der Inhalt dieser Datei auszukommentieren oder auch einfach zu löschen:

rm /etc/httpd/conf.d/welcome.conf
rm /etc/httpd/conf.d/manual.conf
service httpd reload

Nach einem Reload des Servers wird nun eine Übersicht aller in DocumentRoot /var/www/html enthaltenen Dateien angezeigt.

Virtuelles Hosting

Für jeden virtuellen Host sollte ein eigenes Verzeichnis erstellt werden, das als DocumentRoot dienen soll. Sinnvollerweise sollte dazu der vollqualifizierte Domain-Namen des virtuellen Hosts verwendet werden. Zuerst wird das Verzeichnis erstellt unter dem der virtuelle Host liegen soll:

mkdir -p /www/docs/dummy-host.example.com

Außerdem wird die Direktive NameVirtualHost sowie der VirtualHost-Container für dummy-host.example.com in/etc/httpd/conf/httpd.conf aktiviert oder entsprechend abgeändert:

NameVirtualHost *:80
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
<VirtualHost *:80>
 ServerAdmin webmaster@dummy-host.example.com
 DocumentRoot /www/docs/dummy-host.example.com
 ServerName dummy-host.example.com
 ErrorLog logs/dummy-host.example.com-error_log
 CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>

Die Erstellung eines Directory-Containers für das DocumentRoot des virtuellen Hosts ist notwendig, um den Zugriff zu erlauben. Als Vorlage kann der bereits vorhandene Eintrag für /var/www/html dienen:

<Directory "/www/docs/dummy-host.example.com">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
 Options Indexes FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
 AllowOverride None
#
# Controls who can get stuff from this server.
#
 Order allow,deny
 Allow from all
</Directory>

Zuletzt muss der SELinux-Type des für den virtuellen Host erstellten Verzeichnisses angepasst werden.  Am einfachsten erfolgt die Bearbeitung von Sicherheitskontexten mit dem Werkzeug semanage, das im Paket policycoreutils-python enthalten ist.

yum install policycoreutils-python
semanage fcontext -a -t httpd_sys_content_t "/www(/.*)?"
restorecon -R /www

Wichtig ist hier der reguläre Ausdruck „/www(/.*)?“ – es wird das Verzeichnis /www sowie alle eventuell enthaltenen Unterverzeichnisse erfasst. Um eine Interpretation durch die Shell zu vermeiden ist der Ausdruck in Anführungszeichen gesetzt. Dateien und Verzeichnisse müssen vom Typ httpd_sys_content_t sein um von Apache gelesen werden zu können.

Einrichten privater Verzeichnisse

Um Verzeichnisse erst nach Eingabe eines Benutzernamens und des zugehörigen Kennworts einsehbar zu machen sind drei Schritte notwendig:

Erstellen des privaten Verzeichnisses

Das private Verzeichnis wird in diesem Beispiel im Verzeichnis /var/www/html erstellt:

mkdir /var/www/html/private

Konfiguration des Kennwortschutzes

Das Verzeichnis wird nun über einen zugehörigen Directory-Container in /etc/httpd/conf/httpd.conf konfiguriert. Da bei HTTP Basic Authentifizierung Benutzerdaten im Klartext übertragen werden ist die Verwendung von SSL sinnvoll. Durch Angabe der Direktive SSLRequireSSL wird die Verwendung von SSL erzwungen:

<Directory "/var/www/html/private">
    SSLRequireSSL
    AuthType basic
    AuthName "Authentifizierung erforderlich"
    AuthUserFile /etc/httpd/htusers
    Require valid-user
</Directory>

Erstellen der Benutzer

Benutzer werden mit dem Werkzeug htpasswd erstellt. Bei dem ersten Aufruf ist die Angabe des Parameters -c notwendig, um die Datei zu erstellen. Falls dieser bei einem weiteren Aufruf angeführt wird, wird die Datei überschrieben!

htpasswd -c /etc/httpd/htusers bob
htpasswd /etc/httpd/htusers alice

Nach zweimaliger Eingabe des Kennworts für den Benutzer ist das Konto erstellt und verwendbar. Nach einem erneuten Einlesen der Konfiguration ist der Kennwortschutz des privaten Verzeichnisses aktiv, die Übertragung der Benutzerdaten über eine sichere Verbindung wird erzwungen. Falls der Benutzer sich nicht über HTTPS verbunden hat, erscheint eine 403 Forbidden Nachricht.

Bereitstellung eines CGI-Skripts

CGI-Skripts werden per default im Verzeichnis /var/www/cgi-scripts dem Webserver zur Verfügung gestellt. Diese werden durch Aufruf von z.B. http://1.2.3.4/cgi-bin/myscript.sh ausgeführt. Um Apache die Ausführung von CGI-Skripts zu erlauben ist die Anpassung einer Zeile in httpd.conf erforderlich:

AddHandler cgi-script .sh .py .pl

Hier wäre die Ausführung von Shell-, Python- und Perl-Skripts erlaubt. CGI-Skripts müssen einer bestimmten Form genügen um fehlerfrei ausgeführt zu werden. Die Anzeige der Fehlerseite 500 internal server error ist in den meisten Fällen die Folge eines fehlerhaften Skripts.

Hello World CGI-Skript (BASH)

#!/bin/bash
echo -e "Content-type: text/html\n\n"
echo "Hello World!"

Wichtig sind hier vor Allem die ersten beiden Zeilen – die Angabe des Interpreters und die Ausgabe des Content-type mit zwei darauf folgenden Zeilenumbrüchen. Die Dateirechte müssen eine Ausführung des Skripts durch den Benutzer apache erlauben.

CGI-Skripts in anderen Verzeichnissen

Falls ein vom Standard abweichendes Verzeichnis für CGI-Skripte verwendet werden soll muss diesem Verzeichnis und den enthaltenen Skripts der SELinux-Typ httpd_sys_script_exec_t zugewiesen werden:

mkdir /www/myscripts
semanage fcontext -a -t httpd_sys_script_exec_t /www/myscripts
restorecon -R /www/myscripts

Außerdem ist eine Direktive ScriptAlias und ein entsprechender Directory-Container für das soeben erstellte Verzeichnis in httpd.conf einzutragen. Falls das Default-Verzeichnis für CGI-Skripts nicht genutzt wird kann der Pfad einfach umbenannt werden:

ScriptAlias /myscripts/ "/www/myscripts/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "/www/myscripts">
 AllowOverride None
 Options None
 Order allow,deny
 Allow from all
</Directory>

Nach einem Reload des Servers sind Skripts unter /www/myscripts nun ausführbar.

Konfiguration in Gruppen verwalteter Inhalte

Um die Verwaltung eines Verzeichnisses durch eine Gruppe zu ermöglichen sollte zuerst ein übergeordneter Benutzer angelegt werden, dessen Heimatverzeichnis als Basis zur Zusammenarbeit dient. Die User-ID des Benutzers sollte dabei höher sein als die vom System normalerweise verwendeten. Da dieser Benutzer sich nicht lokal auf dem Server anmelden muss wird als Login-Shell /sbin/nologin gewählt, als Eigentümer des Heimatverzeichnisses wird der Benutzer nobody gesetzt:

useradd -u 1025 -s /sbin/nologin design
chown nobody /home/design

Durch setzen des SELinux-Booleans httpd_enable_homedirs wird Apache der Zugriff auf Heimatverzeichnisse erlaubt:

setsebool -P httpd_enable_homedirs 1

Da die Direktive UserDir in httpd.conf standardmäßig deaktiviert ist muss diese noch von Hand angepasst werden. Außerdem muss der entsprechende Directory-Container aktiviert werden. Notwendige Änderungen sind fett dargestellt:

#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.
#
# The path to the end user account 'public_html' directory must be
# accessible to the webserver userid. This usually means that ~userid
# must have permissions of 711, ~userid/public_html must have permissions
# of 755, and documents contained therein must be world-readable.
# Otherwise, the client will only receive a "403 Forbidden" message.
#
# See also: http://httpd.apache.org/docs/misc/FAQ.html#forbidden
#
<IfModule mod_userdir.c>
 #
 # UserDir is disabled by default since it can confirm the presence
 # of a username on the system (depending on home directory
 # permissions).
 #
# UserDir disabled
#
 # To enable requests to /~user/ to serve the user's public_html
 # directory, remove the "UserDir disabled" line above, and uncomment
 # the following line instead:
 #
 UserDir public_html
</IfModule>
#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
 AllowOverride FileInfo AuthConfig Limit
 Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
 <Limit GET POST OPTIONS>
 Order allow,deny
 Allow from all
 </Limit>
 <LimitExcept GET POST OPTIONS>
 Order deny,allow
 Deny from all
 </LimitExcept>
</Directory>

Wie in den Kommentaren ersichtlich muss das Verzeichnis public_html mindestens die Berechtigung 711 haben, um von Apache gelesen werden zu können. Da das Verzeichnis aber von einer Gruppe zur Zusammenarbeit verwendet werden soll wird zusätzlich der Gruppe Schreib- und Leserechte gewährt sowie zusätzlich das Set Group-ID Bit gesetzt:

chmod -R 2771 /home/design
mkdir /home/design/public_html

Nun könne die eigentlichen Gruppenmitglieder erstellt werden, die am gemeinsamen Verzeichnis public_html arbeiten sollen. Im folgenden Beispiel hätten alle Benutzer das gleiche Heimatverzeichnis:

useradd -d /home/design -g design bob
useradd -d /home/design -g design sam
useradd -d /home/design -g design alice
passwd bob

Die so angelegten Benutzer können Dateien unter /home/design/public_html gemeinsam bearbeiten. Das Ergebnis lässt sich nach einem Reload der Serverkonfiguration unter http://1.2.3.4/~design einsehen.