Archiv

Archive for Februar 2012

Authentifizierung an einem vorhandenen Kerberos V‑Realm (provisorisch)

2012/02/16 Kommentare aus

Die Authentifizierung an einem vorhandenen Kerberos V-Realm kann sehr einfach über das vom System bereitgestellte Werkzeug authconfig-tui konfiguriert werden. Voraussetzung dafür ist außerdem ein installiertes PAM-Modul: pam_krb5.

yum install authconfig
yum install pam_krb5

Den Namen dieses Moduls muss man sich nicht unbedingt auswendig merken, authconfig-tui erinnert automatisch daran, falls dieses Modul nicht im System vorhanden ist. Nach erfolgter Installation von pam_krb5 kann nun die Authentifizierung durch Kerberos aktiviert werden:

authconfig-tui

Dieses Werkzeug bietet eine sehr komfortable Möglichkeit die Authentifizierung durch Kerberos zu konfigurieren. Unter anderem kann damit auch der Beitritt einer Windows-Domain problemlos durchgeführt werden. Einzutragen ist in Großbuchstaben der Kerberos V-Realm, das KDC sowie der Admin Server.

Advertisements
Kategorien:RHCE Schlagwörter: , ,

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.

Weiterleitung von IP-Verkehr und Verwendung von iptables für NAT

2012/02/10 Kommentare aus

Um IP-Forwarding permanent zu aktivieren ist ein Eintrag in /etc/sysctl.conf erforderlich:

# IP-Forwarding aktivieren
net.ipv4.ip_forward = 1
# IPv6-Forwarding aktivieren
net.ipv6.conf.default.forwarding = 1

Nach geänderter Konfiguration ist die Datei /etc/sysctl.conf neu einzulesen:

sysctl -p

NAT

NAT ist durch Hinzfügen zweier einfacher Firewallregeln zu aktivieren, schneller ist jedoch wahrscheinlich die Konfiguration mit Hilfe des Werkzeugs system-config-firewall-tui:

yum install -y system-config-firewall-tui
system-config-firewall-tui

Anpassen -> 3x Weiter ->Device(s) für NAT (Masquerade) markieren -> Schließen

Kategorien:RHCE Schlagwörter:

Nutzung von iptables zur Implementierung von Paketfiltern

2012/02/10 Kommentare aus

Mit iptables lassen sich sehr komplexe Firewallregeln erstellen, jedoch verlangt die Konfiguration ein detailliertes Wissen über die zugrundeliegenden Netzwerkprotokolle. Es gibt auch eine ganze Menge von kommerziellen Firewalls die auf iptables basieren (z.B. Astaro, Fortigate). Diese sind fast alle mehr oder weniger einfach über eine graphische Oberfläche konfigurierbar.

Ein tiefergehendes Verständnis von Linux-Firewalls und die Fähigkeit, Firewallregeln manuell erstellen oder verändern zu können sollte aber auf jeden Fall zum Grundwissen eines Administrators gehören. Auf der Webseite des netfilter Projekts ist eine recht gute (englischsprachige) Dokumentation zu iptables verfügbar. Die beste deutschsprachige Literatur zu iptables ist sicher Linux-Firewalls (amazon.de) von Ralf Spenneberg.

Kategorien:RHCE Schlagwörter:

Festlegung statischer IP-Routen

2012/02/08 Kommentare aus

Falls statische Routen benötigt werden sind diese für jede Netzwerkschnittstelle einzeln zu konfigurieren. Um z.B. eine statische Routing-Tabelle für eth0 einzutragen, ist die Datei /etc/sysconfig/network-scripts/route-eth0 zu erstellen:

default via 192.168.100.10 dev eth0
10.176.61.0/24 via 192.168.100.20 dev eth0

Jede Zeile gibt das Netzwerk/die Netzwerkmaske und das Gateway sowie die Netzwerkschnittstelle an, über die Pakete geroutet werden sollen. Die Default-Route darf nur einmal vorkommen. Nach Änderung der Datei route-eth0 ist das Netzwerk neu zu starten um die Einträge auch wirksam zu machen:

service network restart

Die Routing-Tabelle kann zur Kontrolle mit route abgerufen werden:

route -n
Kategorien:RHCE Schlagwörter: , ,

SMTP: Null-Client, ausgehendes Smarthost-Relay, Annahme eingehender Verbindungen

2012/02/03 Kommentare aus

Der Mail Transfer Agent postfix ist bereits in der Standardinstallation enthalten. Falls das aber nicht der Fall sein sollte lässt sich dieser durch Aufruf von

yum groupinstall "E-mail server"

nachinstallieren. Die Korrekte Funktion von DNS für den Betrieb eines Mail-Servers ist unbedingt vorher sicherzustellen! Da im folgenden Szenario keine „echte“ Domain zu Einsatz kommt sollte der Hostname sowie die Domain in /etc/hosts eingetragen werden:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1 localhost localhost.localdomain localhost6 localhost6.localdomain6
127.0.0.1 test test.example.com

Durch Aufruf von getent hosts wird die Datei /etc/hosts neu eingelesen. Da für die Namensauflösung lokale Dateien zuerst beachtet werden bevor eine DNS-Abfrage ausgesendet wird ist sichergestellt dass Test-Mails an die Domain example.com auch von unserem System entgegengenommen werden.

Null-Client

Ein Null-Client ist ein System, das e-Mails nur absenden, nicht jedoch empfangen oder weiterleiten kann. Diese Anforderung ist bereits nach der Installation von postfix erfüllt. Die Funktion lässt sich am Besten mit dem Werkzeug mail überprüfen:

yum install mailx

Nach Installation von mail wird testweise eine Mail versandt:

mail -s "Test Nachricht - SMTP Null-Client"
Dies ist eine Test-Nachricht von test.example.com.

Durch Drücken der Tasten [CTRL] + [D] weiss mail, dass die Eingabe des Nachrichtentexts beendet ist und versendet die e-Mail.

Es ist wichtig das SMTP-Protokoll zu verstehen um eine Fehlersuche oder einen Funktionstest effektiv durchführen zu können. Durch Installation des Telnet-Clients kann man sich direkt mit dem Mail Server unterhalten:

yum install telnet

Telnet öffnet im folgenden Beispiel eine Verbindung zum lokalen Host auf Port 25 (SMTP). Benutzereingaben sind fett dargestellt.

[root@test ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 test.example.com ESMTP Postfix
helo test.example.com
250 test.example.com
mail from: <root@example.com>
250 2.1.0 Ok
rcpt to: <meine.mailadresse@gmail.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Test-Nachricht
Dies ist eine Test-Nachricht von root auf test.example.com
.
250 2.0.0 Ok: queued as D117633F2
quit
221 2.0.0 Bye
Connection closed by foreign host.

Postfix hat hier die Nachricht akzeptiert und in die Warteschlange zum Versenden eingereiht. Ein Aufruf von mailq fragt den Status der Warteschlange ab – diese sollte jedoch bereits leer sein falls Verbindung zum Internet besteht und die DNS/Netzwerkkonfiguration in Ordnung ist.

Ausgehendes Smarthost-Relay

Um e-Mails von Clients aus dem lokalen Netz entgegenzunehmen und gegebenenfalls weiterzuleiten sind einige wenige Anpassungen in der Konfiguration notwendig. Gezeigt werden hier nur die notwendigen Änderungen in /etc/postfix/main.cf:

myhostname = test.example.com
myorigin = $mydomain
inet_interfaces = all
mynetworks = 192.168.100.0/24 127.0.0.0/8
#relay_host = [mailserver.isp.tld]   # Smarthost ISP

Gesetzt wird der Hostname, die Netzwerkschnittstellen auf denen postfix lauschen soll sowie das Netzwerk von dem aus Mails akzeptiert werden. $myorigin bestimmt, wie ausgehende Mails aussehen – im Beispiel würde nur die Domain an den Benutzernamen (user@example.com) angehängt, ohne Angabe dieses Parameters wird der volle Hostname (also z.B. user@test.example.com) des Servers angehängt. Die Angabe von mynetworks kann entfallen falls nur dem Subnetz vertraut werden soll in dem sich der Server befindet. Falls Mails nicht direkt an den Empfänger verschickt sondern über einen Smarthost (z.B. des Service Providers) laufen sollen ist der Eintrag von relay_host erforderlich. Nach Änderung der Konfiguration ist postfix neu zu starten bzw. die Konfiguration neu einzuladen:

service postfix reload   # Konfiguration neu einlesen
service postfix restart  # Service neu starten
service postfix check    # Konfiguration prüfen

Fehlermeldungen können unter

/var/log/maillog

nachgelesen werden. Die Ausführung von postconf -n zeigt geänderte Parameter in main.cf an.

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 –> „Mail (SMTP)“ markieren –> Schließen

Nun kann der Versand einer Mail von einem Client aus versucht werden, Benutzereingaben sind wieder fett dargestellt:

user@client:~$ telnet 192.168.100.161 25
Trying 192.168.100.161...
Connected to 192.168.100.161.
Escape character is '^]'.
220 test.example.com ESMTP Postfix
helo client.example.com
250 test.example.com
mail from: <user@example.com>
250 2.1.0 Ok
rcpt to: <meine.mailadresse@gmail.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Test-Nachricht 
Dies ist eine Test-Nachricht von user auf client.example.com
.
250 2.0.0 Ok: queued as 24F7F23D6
quit
221 2.0.0 Bye
Connection closed by foreign host.

Die Mail wird nach erfolgreichem Versand höchstwahrscheinlich im Spam-Folder des Empfängers zu finden sein.

Annahme eingehender Verbindungen

Um Mails für Benutzer empfangen zu können müssen diese dem System bekannt sein. Im einfachsten Fall durch Erstellung lokaler Benutzer:

useradd -s /sbin/nologin bob
useradd -s /sbin/nologin alice

Durch Angabe des Parameters -s wird den angelegten Benutzern die Login-Shell /sbin/nologin zugewiesen, ein Login auf dem lokalen System ist nicht möglich. Eine Anpassung der Konfiguration von postfix in /etc/postfix/main.cf ist noch notwendig, um Mails für unsere Domain zu akzeptieren:

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

Wir versenden nun nach Neustart/Reload des Mail-Servers eine Mail von einem Client aus an alice@example.com.

telnet 192.168.100.161 25
Trying 192.168.100.161...
Connected to 192.168.100.161.
Escape character is '^]'.
220 test.example.com ESMTP Postfix
helo client.example.com
250 test.example.com
mail from: <user@example.com>
250 2.1.0 Ok
rcpt to: <alice@example.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Dies ist eine Test-Nachricht von user auf client.example.com
an alice@example.com
.
250 2.0.0 Ok: queued as 831203685
quit
221 2.0.0 Bye
Connection closed by foreign host.

Auf dem Mail-Server kann der Empfang der Mail nun kontrolliert werden:

cat /var/spool/mail/alice  # Mailbox von alice ansehen

Da eine Bereitstellung der Mails für Benutzer via POP oder IMAP nicht für das RHCE-Examen gefordert ist sind alle Anforderungen an die Funktion des Mail-Servers bereits erfüllt. In der Praxis wird man durch Installation von z.B. Dovecot diese Funktionen bereitstellen.

Kategorien:RHCE Schlagwörter: , , , , ,