Archiv

Posts Tagged ‘httpd’

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

2012/02/14 Kommentare aus

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.

Advertisements

Konfiguration der host- und benutzer-basierten Sicherheit des Dienstes

2012/01/30 Kommentare aus

vsftpd

Die Standard-Konfiguration von vsftpd sieht vor allen in der Datei /etc/vsftpd/user_list angeführten Benutzern den Zugriff zu verweigern. Alle Benutzer, die nicht in dieser Datei enthalten sind können sich also am FTP-Server einloggen. Umgekehrt – Benutzer denen der Zugriff verweigert werden soll werden hier eingetragen.

# vsftpd userlist
# If userlist_deny=NO, only allow users in this file
# If userlist_deny=YES (default), never allow users in this file, and
# do not even prompt for a password.
# Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers
# for users that are denied.

# ...

# Verweigere folgende Benutzer:
bill
steve

Dieses Verhalten macht auch meistens Sinn – vom Login ausgeschlossen sind nur System-Accounts und root. Gelegentlich will man aber nur einigen wenigen Benutzern den Zugriff auf den FTP-Server erlauben. In diesem Fall ist es praktischer die Bedeutung der Datei /etc/vsftpd/user_list umzukehren, um ausschließlich darin enthaltenen Benutzern FTP-Zugriff zu erlauben. Dazu wird der Eintrag userlist_deny in /etc/vsftpd/vsftpd.conf auf NO gesetzt:

userlist_deny=NO

Es folgt der Eintrag erlaubter Benutzer in /etc/vsftpd/user_list:

# Erlaube folgende Benutzer:
alice
bob
sam

Es können sich nun ausschließlich die Benutzer alice, bob und sam an dem FTP-Server anmelden.

Host-basierte Sicherheit

Die Direktive tcp_wrappers in /etc/vsftpd/vsftpd.conf sollte bereits standardmäßig aktiv sein:

tcp_wrappers=YES

Es können nun Host-basierte Zugangsbeschränkungen über die Dateien /etc/hosts.allow und /etc/hosts.deny gesetzt werden:

/etc/hosts.allow

vsftpd : 192.168.100.0/255.255.255.0 EXCEPT 192.168.100.12

/etc/hosts.deny

vsftpd : ALL

Auf diese Weise abgewiesene Clients bekommen die Antwort

421 Service not available

Samba

Host- und Benutzerbasierte Sicherheit wird am einfachsten in der Konfigurationsdatei des Samba-Servers, /etc/samba/smb.conf festgelegt. Unter global eingetragene Beschränkungen gelten global, unter den einzelnen Freigaben eingetragene Beschränkungen ausschließlich für die jeweilige Freigabe. Verwendet werden dazu die Direktiven hosts allow, hosts deny sowie valid users und invalid users.

Die localhost Addresse 127.0.0.1 ist immer erlaubt (wenn nicht explizit in hosts deny angeführt).

Erlaube alle IPs in 150.203.*.* außer einer

hosts allow = 150.203. EXCEPT 150.203.6.66

Erlaube gesamtes Netzwerk

hosts allow = 150.203.15.0/255.255.255.0

Erlaube einige Hosts

hosts allow = lapland, arvidsjaur

Erlaube Hosts in NIS netgroup „foonet“, verweigere einen bestimmten Host

hosts allow = @foonet
hosts deny = pirate

Erlaube Benutzer bob, sam, alice und lokale Gruppe team2, verweigere bill den Zugriff

valid users = bob sam alice +team2
invalid users = bill

SSH

User-basierte Sicherheit für SSH wird in der Konfigurationsdatei /etc/ssh/sshd_config festgelegt. Am wichtigsten ist dabei die Direktive AllowUsers – falls diese angegeben wird können sich ausschließlich die hier angegebenen Benutzer anmelden. Es ist auch möglich, Benutzer ein Login nur von bestimmten Hosts aus zu erlauben.

AllowUsers john fred
AllowUsers bob@192.168.100.102 michael@192.168.150.12
AllowGroups team1
DenyUsers steve bill alice
DenyGroups team2

Benutzer, denen der Zugriff nicht erlaubt ist bekommen nach Eingabe ihres Kennwortes die Meldung

Permission denied, please try again.

Es ist dabei nicht ersichtlich, ob das eingegebene Kennwort falsch war oder dem Benutzer das Login verweigert wurde.

Host-basierte Sicherheit wird am einfachsten über die Dateien /etc/hosts.allow und /etc/hosts.deny konfiguriert:

/etc/hosts.allow

sshd : 127. 192.168.100. EXCEPT 192.168.100.101

/etc/hosts.deny:

sshd : ALL

Per TCP-Wrappers abgelehnte Verbindungsversuche werden mit

ssh_exchange_identification: Connection closed by remote host

beantwortet. Es wird gar nicht erst die Eingabe eines Kennwortes verlangt.

NFS

Host-basierte Zugriffssteuerung sollte bereits bei der Erstellung von NFS-Freigaben konfiguriert sein.

/etc/exports

/mynfsshare   192.168.100.0/255.255.255.0(rw) 192.168.12.1(ro)
/projects       proj*.local.domain(rw)
/usr            *.local.domain(ro) @trusted(rw)
/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            *(ro,insecure,all_squash)

Beschränkungen auf Benutzerebene werden über das Dateisystem festgelegt, entweder über die normalen UNIX-Rechte oder auch unter Verwendung von ACLs.

HTTP

Benutzer- und Hostbasierte Sicherheit wird in der Konfigurationsdatei /etc/httpd/conf/httpd.conf festgelegt. Erlaubte bzw. zu verweigernde Hosts werden über die Direktiven Order, Allow from und Deny from für jedes Verzeichnis einzeln angegeben. Ein Eintrag innerhalb <Directory „/var/www/html“> wird jedoch an alle Unterverzeichnisse vererbt, soweit dort nicht anders angegeben.

<Directory "/var/www/html">
# ...
#
# Controls who can get stuff from this server.
#
 Order allow,deny
 Allow from all
 Deny from 192.168.100.103
</Directory>

Host 192.168.100.103 bekommt nun beim Versuch die Seite anzuzeigen den HTML-Error 403:

Forbidden
You don't have permission to access / on this server.

Benutzerbasierte Sicherheit wird ebenfalls für jedes Verzeichnis einzeln konfiguriert. In folgendem Beispiel wird das Verzeichnis myprivatedir nur nach Eingabe eines gültigen Benutzernamens und des zugehörigen Kennwortes angezeigt:

<Directory "/var/www/html/myprivatedir">
AuthType Basic
AuthName "Eingabe eines Kennwortes erforderlich"
AuthUserFile /etc/httpd/users
require valid-user
</Directory>

Möglich nach require sind valid-user, valid-group, user und group.

Bei Verwendung von Gruppen ist zusätzlich zu AuthUserFile das AuthGroupFile bekanntzugeben:

AuthType Basic
AuthName "Geschützte Ressource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin

Benutzer anlegen:

htpasswd -c /etc/httpd/users alice
htpasswd /etc/httpd/users bob
htpasswd /etc/httpd/users sam

Gruppen werden in einer einfachen Textdatei verwaltet, z.B. /etc/httpd/groups:

admin: bob sam alice
team1: bill steve
Kategorien:RHCE Schlagwörter: , , , , ,

mit HTTP/FTP Dateifreigabedienste einrichten

2010/12/26 Kommentare aus

HTTP

Zur nachträglichen Installation des Apache Webservers:

yum install httpd

Service starten/beim hochfahren starten:

service httpd start
chkconfig httpd on

Die Konfigurationsdateien des Webservers befinden sich unter /etc/httpd/, die default-Einstellungen sind aber für eine einfache Dateifreigabe via HTTP durchaus ausreichend und bedürfen keiner weiteren Anpassung.

Dateien unter /var/www/html sind nach Aktivieren des Webservers bereits automatisch verfügbar. Das Ziel der Freigabe von Dateien über HTTP ist damit bereits erreicht. Zu beachten ist dass der Webserver auch die Rechte haben muss, die Dateien zu lesen! Falls keine index.html/index.php und keine Dateien in diesem Verzeichnis vorhanden sind wird eine Standardseite angezeigt.

FTP

Neuinstallation:

Basis Server -> Jetzt anpassen

Server -> FTP-Server

Web Dienste -> Web-Server

Installation von der Kommandozeile

yum install vsftpd

Konfiguration

Standardmäßig sind anonyme und Benutzerlogins aktiviert. Read-only Freigabe ist damit bereits gegeben. Um Dateien freizugeben diese einfach in das Heimatverzeichnis des Benutzers „ftp“ kopieren, standardmäßig ist das /var/ftp.

Um anonyme Uploads zu erlauben sind die folgenden Zeilen in /etc/vsftpd/vsftpd.conf einzutragen:

anon_upload_enable=YES
anon_mkdir_enable=YES

Der Benutzer hat damit das Recht Dateien hinaufzuladen und Verzeichnisse zu erstellen, darf jedoch weder  Dateien oder Verzeichnisse löschen noch diese umbenennen. Um Vollzugriff und damit das auch das Löschen und Verändern von Dateien und Verzeichnissen zu erlauben ist noch die Zeile

anon_other_write_enable=YES

einzutragen.

Die Linux-Dateirechte müssen Schreibzugriffe auf das Verzeichnis ebenfalls erlauben.

chmod a+w /var/ftp/pub

Außerdem muß der SELinux Kontext geändert werden, um anonyme Schreibzugriffe zu ermöglichen:

semanage –a –t public_content_rw_t /var/ftp/pub
restorecon /var/ftp/pub
setsebool allow_ftpd_anon_write 1

Die geänderte Konfiguration ist nun mit

service vsftpd reload

neu einzulesen, damit diese wirksam wird.

Netzwerk konfigurieren:

/etc/sysconfig/network

NETWORKING=”yes”

/etc/sysconfig/network-scripts/ifcfg-eth0

BOOTPROTO=”dhcp” ONBOOT=”yes”

Dienst starten

chkconfig vsftpd on
service vsftpd start

Ausnahmen in Firewall hinzufügen

Firewall: Zugriff auf FTP erlauben

system-config-firewall -> Anpassen -> FTP

Kategorien:RHCSA Schlagwörter: , , , , ,