Linux und Sicherheit Teil 7/2 Seite 1

7/2 Linux und Sicherheit

Autor: Holger Reibold

Linux genießt – wie andere Unix-Betriebssysteme auch – seit Vertraulichkeit,

jeher den Ruf eines besonders sicheren Betriebssystems. Mit Integrität,
Sicherheit ist in unserem Zusammenhang natürlich die Sys- Authentizität
temsicherheit gemeint. Doch auch das ist immer noch ein und Verfügbarkeit
recht schwammiger Begriff. Unter Systemsicherheit versteht
man im Allgemeinen all das, was mit Vertraulichkeit, Integ-
rität, Authentizität und Verfügbarkeit des Betriebssystems zu
tun hat. Systemsicherheit ist aber nicht per se vorhanden,
sondern muss erzeugt, gepflegt und gehegt werden.

Ob Linux gerade gegenüber Windows wirklich das sicherere Linux

Betriebssystem ist, darüber gibt es die unterschiedlichsten contra Windows
Äußerungen und Angaben. Verschiedenste Studien sind auch
zu unterschiedlichen Ergebnissen gelangt. Das gerade von
Linux-Anhängern gern verbreitete Statement, Linux sei das
sicherste Betriebssystem, ist in seiner allgemeinen Formulie-
rung sicherlich nicht haltbar. Dass bei Windows-Plattformen
und Programmen gemeinhin mehr sicherheitsrelevante Lü-
cken aufgedeckt werden, hat auch damit zu tun, dass sich
weit mehr Profis auf die Suche nach entsprechenden Lücken
machen, als es bei Linux-Systemen der Fall ist.

Auch werden Sicherheitslücken von Linux-Installationen we- Flexibler

niger breitgetreten. Zumindest steht fest, dass Linux-Betriebs- als Windows:
systeme eine Vielzahl von Konfigurationsmöglichkeiten und Systemkonfigura-
Programmen bieten, mit denen man Sicherheitslücken schlie- tion unter Linux
ßen kann. Auch die Verfügbarkeit des Quellcodes erleichtert
natürlich Systemanpassungen.

Wir wollen uns hier nicht unnötig an heftig geführten Glau-

benskriegen beteiligen, sondern Ihnen statt dessen mit Analy-
sen, Kochrezepten und Empfehlungen helfen, die Systemsi-
cherheit Ihrer Installation zu erhöhen.

5
Teil 7/2 Seite 2 Linux und Sicherheit

Sicherheit im Im professionellen Umfeld, also überall dort, wo Daten einen

Allgemeinen ... gewissen Wert oder womöglich den zentralen Wert darstel-
len, ist die Auseinandersetzung mit Sicherheitsrisiken Pflicht.
Die Auseinandersetzung mit diesem zugegebenermaßen nicht
immer einfachen Themenkomplex ist für moderne Unter-
nehmen längst lebensnotwendig. Datenverluste wären nicht
das erste Mal für den Zusammenbruch eines Unternehmens
verantwortlich. Die Auseinandersetzung mit möglichen Ge-
fahrenquellen setzt aber immer auch ein gewisses Basis-
Know-how voraus.

... und unter Linux Linux eignet sich aus vielerlei Gründen für den professio-
im Besonderen nellen Einsatz. Aus sicherheitstechnischen Überlegungen he-
raus sprechen insbesondere die Verfügbarkeit des Quellcodes
und das Engagement der Linux-Gemeinde für das freie Be-
triebssystem. Im Unterschied zu Windows, dessen Interna in
einer Hand liegen, kann sich jeder Interessierte beliebig tief
in die Betriebssystemkomponenten vorwagen – entsprechen-
des Know-how vorausgesetzt. Mögliche Sicherheitsrisiken
werden vergleichsweise schnell publik. Mit der Veröffentli-
chung geeigneter Patches, Updates & Co. ist die Linux-
Gemeinde ebenfalls schnell bei der Sache.

Sicherheit – hohe Vielfach scheuen Anwender und (angehende) Systemadmi-

Komplexität der nistratoren die Auseinandersetzung mit dem Themenkomplex
Thematik Systemsicherheit. Dafür gibt es viele Gründe. Wer sich das
erste Mal intensiver mit dieser Materie beschäftigt, bekommt
einen Eindruck von der Komplexität dieser Thematik.

Systemsicherheit berührt fast alle Bereiche, die mit einer Li-

nux-Installation zu tun haben, angefangen von sicherheitsre-
levanten Überlegungen bei der Systeminstallation über be-
nutzerspezifische Einstellungen, die Systemadministration
und systemimmanente Fehler und Mängel bis hin zu Kernel-
funktionen. Besondere Gefahren lauern insbesondere beim
Betrieb eines Linux-Systems in einem lokalen oder gar glo-
balen Netzwerk. Auch Linux-Systeme sind längst nicht mehr
vor Viren sicher. Sie sehen, mehr als genug Stoff für die in-
tensive Auseinandersetzung.
Linux und Sicherheit Teil 7/2 Seite 3

In diesem Kapitel werden wir uns insbesondere mit sicher-

heitstechnischen Überlegungen zu Systeminstallation, Au-
thentifizierung und PAM auseinander setzen.

Abbildung 7/2-1: Die Auseinandersetzung mit der Linux-Systemsicherheit setzt

nicht nur solide Grundkenntnisse voraus, sondern auch das Lesen aktueller
Informationen. Eine der wenigen lohnenden deutschsprachigen Sites ist
www.computer-security.de.

5
Teil 7/2 Seite 4 Linux und Sicherheit
Linux und Sicherheit Teil 7/2.1 Seite 1

Installation

7/2.1 Installation

Mit Systemsicherheit sollte man sich nicht erst auseinander Systemsicherheit

setzen, wenn bereits Angreifer das System zeitweise lahm beginnt bei der
gelegt haben oder Daten verloren gegangen sind, sondern be- Installation
reits im Vorfeld einer Installation. Man kann es auch nicht oft
genug wiederholen: Systemsicherheit fängt bereits mit der
Systeminstallation an. Zwingend erforderlich ist dabei ein
gewisses Umdenken für all jene, die bislang überwiegend mit
Windows-Betriebssystemen gearbeitet haben. Unter Windows
lautet das Motto meist „Je mehr, desto besser“.

Von dieser Einstellung sollte man sich als Administrator ei- Weniger ist mehr
nes Linux-Servers verabschieden. Unter Linux sollte man
sich an dem Leitsatz „Weniger ist manchmal mehr“ orientie-
ren. Schon vor der Systeminstallation sollte man sich Gedan-
ken darüber machen, welche Applikationen und Dienste tat-
sächlich gebraucht werden. Statt die Festplatten mit allem
Möglichen zuzumüllen, sollte man eine Minimalinstallation
vor Augen haben, die exakt den gestellten Anforderungen ge-
nügt. Bei einer solchen Grundinstallation ist die Installation
mehrerer Servern wie z. B. Web-, FTP- und Mail-Server
nicht erforderlich. Vielmehr sollte man die Dienste nach Be-
darf installieren und konfigurieren.

Dabei sollte man großzügigen Gebrauch von den vom Be- Installations-
triebssystem angebotenen Installationsvarianten machen. Red varianten
Hat stellt Ihnen z.B. fünf Installationsvarianten zur Auswahl:

Variante Beschreibung
Workstation Die Workstation-Installation ist für Neulinge geeignet.
Server Soll das System als Linux-basierter Server verwendet wer-
den, ist eine Server-Installation für Sie die geeignetste Ins-
tallationsklasse.
Laptop Die Laptop-Installation wurde entwickelt, um das Installieren
auf einem Laptop zu erleichtern.
Upgrade Soll eine bestehende Installation auf den neuesten Stand ge-
bracht werden, empfiehlt sich diese Variante.

5
Teil 7/2.1 Seite 2 Linux und Sicherheit

Installation

Variante Beschreibung
Benutzerdefiniert Die benutzerdefinierte Installation bietet die größtmögliche
Flexibilität während der Installation. Sie können u. a. wählen,
welches Partitionierungsschema Sie verwenden und welche
Pakete Sie installieren möchten. Die benutzerdefinierte In-
stallation ist besonders für Anwender geeignet, die bereits mit
Linux-Installationen vertraut sind.

Die benutzerdefi- Der erfahrene Linux-Anwender sollte auf jeden Fall die be-
nierte Installations- nutzerdefinierte Variante bevorzugen. Insbesondere die Work-
variante verspricht station- und die Server-Variante installieren meist mehr Ap-
mehr Sicherheit plikationen, als für den tatsächlichen Betrieb benötigt wer-
den. Zudem lassen diese Varianten dem Anwender kaum Ent-
scheidungsfreiraum bei der Auswahl der zu installierenden
Pakete. Das Schöne bei all diesen Varianten: der Installati-
onsassistent von Red Hat greift dem Anwender bei der Ein-
richtung unter die Arme. Das gilt auch für andere Linux-
Distributionen.

Abbildung 7/2.1-1: Alle heute gängigen Linux-Distribu-

tionen bieten verschiedene Installationsvarianten an.
Aus sicherheitstechnischen Überlegungen ist die benut-
zerdefinierte Variante meist die beste Wahl.
Linux und Sicherheit Teil 7/2.1 Seite 3

Installation

An die Auswahl der Installationsvarianten schließt sich in der Vorzüge

Regel die Einrichtung und Konfiguration von Partitionen an. von Partitionen
Diese physikalisch getrennten Bereichen sind eine Grundvor-
aussetzung für Systemsicherheit. Partitionen bieten eine gan-
ze Reihe von Vorteilen:

• Der Betrieb mehrerer Betriebssysteme auf einer Festplatte

ist möglich.
• Backups und Systemaktualisierungen werden erleichtert.
• Der Administrator hat eine bessere Kontrolle über die
mount-Vorgänge auf den einzelnen Partitionen.
• Durch die Trennung der Systembereiche verbessert sich
die Systemsicherheit.
• Durch die Trennung wird das Ausmaß des Datenverlusts
bei der Beschädigung oder beim Ausfall einzelner Partiti-
onen verringert.

Abbildung 7/2.1-2: Partitionen einrichten stellt unter Li-

nux längst kein größeres Problem mehr dar. Bei Red
Hat greift z. B. der Disk Druid dem Administrator unter
die Arme.

5
Teil 7/2.1 Seite 4 Linux und Sicherheit

Installation

Partitionseinteilung Die Liste der Vorzüge lässt sich sicherlich noch um den einen
oder anderen Punkt erweitern. Wichtig ist nur, sich abhängig
vom jeweiligen Verwendungszweck des Linux-Systems Ge-
danken über eine mögliche Partitionsaufteilung zu machen.
Gerade bei Server-Systemen, die womöglich auch noch über
eine dauerhafte Internet-Verbindung verfügen sollen, sollte
man besondere Sorgfalt beim Erzeugen von Partitionen wal-
ten lassen.

Standard- Standardmäßig gönnt man jeder Linux-Installation die drei

partitionen Hauptpartitionen Boot-, Root- und Swap-Partition. Außer-
dem sollte man die Verzeichnisse /home, /tmp und /var vom
übrigen System trennen. Für das usr-Verzeichnis sollte eben-
falls eine eigene Partition erzeugt werden.

Disk Druid Dem Bearbeiten der bestehenden Partitionseinteilung sowie

dem Hinzufügen und Entfernen neuer bzw. bestehender Par-
titionen dient unter Red Hat z. B. der Disk Druid. Wird eine
neue Partition erzeugt, präsentiert sich Ihnen der nachfolgen-
de Dialog, in den man unter Mount-Point den Namen der
neuen Partition, die Größe, den Partitionstyp und das Lauf-
werk angibt.

Abbildung 7/2.1-3: Eine neue Partition entsteht mit Hilfe

von Disk Druid. Neben der Bezeichnung definiert man
Größe, Typ und Laufwerk.
Linux und Sicherheit Teil 7/2.1 Seite 5

Installation

Allen Linux-Distributionen ist seit jeher gemein, dass sie mit Vorsicht bei
Unmengen an Programmen, Tools etc. ausgeliefert werden. der Paketauswahl
Im Server-Betrieb wird vieles nicht benötigt. Manche Pro-
gramme stellen sogar Sicherheitsrisiken dar. Beim Server-
Betrieb empfiehlt es sich z. B., auf eine grafische Schnitt-
stelle wie X-Window zu verzichten.

Abbildung 7/2.1-4: Bei der Paketauswahl sollte man

sorgsam vorgehen. Weniger ist meist mehr – zumindest
aus Sicht der Systemsicherheit.

Bei einer minimalen Grundinstallation kann man getrost auf Das Ziel: minimale
all den grafischen Schnickschnack wie Oberflächen, Spiele, Grundinstallation
Bildbearbeitung und irgendwelche multimedialen Dinge ver-
zichten. Stattdessen sollte man z. B. bei einer Red Hat-In-
stallation folgende Pakete auswählen:

• Networked Workstation
• Network Management Workstation
• Utilities

Auf verschiedene Server-Typen, z. B. finder-server und tel-

net-server, sollte man besser verzichten.

5
Teil 7/2.1 Seite 6 Linux und Sicherheit

Installation

Glücklicherweise stellt die Auswahl der gewünschten Pakete

über die von den Linux-Distributionen bereitgestellten As-
sistenten kein größeres Problem dar. Nach der erfolgreichen
Installation (inklusive Neustart) kann man über die Log-Datei
/tmp/install.log ersehen, welche Komponenten tatsächlich
installiert wurden.

Installationen über Als netzwerkorientiertes Betriebssystem bietet Linux auch

das Netzwerk die Möglichkeit, Installationen über ein bestehendes Netz-
werk auszuführen. Dabei können die Netzwerkdienste FTP,
NFS oder HTTP genutzt werden. Von Vorteil ist diese Form
der Installation z. B., wenn dem System ein CD-ROM-Lauf-
werk fehlt oder wenn Installationsdateien zentral im Netz-
werk abgelegt sind.

Abbildung 7/2.1-5: Ein typischer Dialog unter Red Hat

für die netzwerkbasierte Installation

Prinzipiell spricht nichts gegen diese Installationsform. Al-

lerdings sollte man sicherstellen, dass der Quell-Server als
„sicher“ bewertet werden kann, insbesondere, wenn es sich
um einen Server mit (permanenter) Internet-Anbindung han-
delt. Bei rein internen Servern ist eine netzwerkbasierte In-
stallation in der Regel unbedenklich.
Linux und Sicherheit Teil 7/2.2 Seite 1

Authentifikation

7/2.2 Authentifikation

Meist verschaffen sich „Angreifer“ über den normalen Weg Benutzer-

der Benutzerauthentifikation Zugang zu einem System. Dabei authentifikation
spielen sie mit Zugangskennungen und Passwörtern oder
greifen zu Passwort-Crackern. Der Angreifer muss bei derlei
Angriffen meist Kennung und Passwort herausfinden. Die
Kennung, auch Username genannt, besitzt zwischen einem
und acht Zeichen. Linux verwaltet die Account-spezifischen
Informationen in der Datei /etc/passwd. Dort sind der User-
name und das verschlüsselte Passwort abgelegt. Zudem sind
dort die UID (User Identication Number), die GID (Group
Identication Number), der tatsächliche Name des Users, sein
Home-Verzeichnis und die User-Shell abgelegt. Die einzel-
nen Einträge sind durch Doppelpunkte voneinander getrennt.

Neben dem klassischen Passwortsystem kann man natürlich Klassische

auch bei Linux-Systemen alternative Lösungen wie z. B. Passwortsystem
Keycard, Fingerabdruckscanner, Irisscanner, Stimmenanalyse
etc. einbinden. Der dafür erforderliche technische und finan-
zielle Mehraufwand und das damit verbundene Mehr an Si-
cherheit lohnt in kleinen und mittleren Firmen eher selten.
Die vom Betriebssystem mitgelieferten Funktionen gewähr-
leisten in aller Regel ein ausreichend hohes Maß an Sicher-
heit. Red Hat bietet z. B. die MD5-Verschlüsselung der
Passwörter. Es gilt daher, aus den mitgelieferten Tools ein
größtmögliches Maß an Sicherheit bei relativ geringem Auf-
wand zu realisieren.

Um einem möglichen Angreifer den Zugriff auf das System „Sicheres“

so schwer wie möglich zu machen, sollte man sich bei der Passwort
Wahl des Passwortes an einige einfache Regeln bzw. Verbote
halten. Kombinationen aus Groß- und Kleinbuchstaben, Zei-
chen und Sonderzeichen kann man generell als relativ sicher
bewerten, z.B. 6o§KcP! .Nicht verwenden sollte man:

• Vor-, Nach- oder Account-Name

• Namen im Allgemeinen
• Telefonnummern
• Geburtstage

5
Teil 7/2.2 Seite 2 Linux und Sicherheit

Authentifikation

• Autokennzeichen
• Fremdwörter oder Wörter aus anderen Sprachen
• reine Zahlenkombinationen
• Tastaturmuster wie asdf oder yxcvb
• Umkehrungen der oben aufgeführten Varianten

Wie bei anderen System, gilt auch hier: Ein System ist immer
nur so sicher wie sein schwächstes Passwort. Aus diesem
Grund sollte man als Administrator mit größter Aufmerk-
samkeit darauf achten, dass man den Usern möglichst „siche-
re“ Passwörter zuteilt.

Passwort-Checker

Haben auch eine Mit Hilfe von Passwort-Checkern kann man prüfen, ob die
gute Seite: gewählten Passwörter den Mindestanforderungen genügen.
Passwort-Checker Sie können neben unterschiedlichen Passwortlängen auch die
Abwechslung von Groß- und Kleinschreibung sowie die Ver-
wendung von Sonderzeichen berücksichtigen. Auch der Ver-
gleich mit Wortlisten ist in der Regel möglich. Das wohl be-
kannteste Programm dieser Art ist Cracklib. Daneben gibt es
eine Vielzahl weiterer Tools. Eine Auswahl finden Sie in der
nachstehenden Tabelle. Alle hier aufgeführten Tools stehen
über die Support-Seiten (www.interest.de/linux/) zum Down-
load bereit.

Passwort-Checker Kurzinfo
Cracklib Cracklib erlaubt unterschiedlichste Tests, z. B. die Über-
prüfung des Passwortes auf benutzerspezifische Infor-
mationen und auf leicht zu erratende Zahlen- oder Buch-
stabenmuster sowie den Vergleich mit Wortlisten.
passwd+ Dieser Checker bietet umfangreiche Protokollfunktionen,
(z. B. für fehlgeschlagene Passwortänderungen) sowie
das Festlegen der Anzahl signifikanter Zeichen in einem
Passwort und von Fehlermeldungen.
anlpasswd Dieses Tool unterstützt folgende Regeln: Zahlen mit
Leerzeichen, Leerzeichen mit Zahlen, Groß- und Klein-
schreibung mit Leerzeichen, Zahlen, Großbuchstaben
und Zeichen sowie Kombinationen aller dieser Regeln.
Linux und Sicherheit Teil 7/2.2 Seite 3

Authentifikation

Passwort Checker Kurzinfo

npasswd Dieser Checker unterzieht Passwörter Rateüberprüfun-
gen. Er eignet sich als Ersatz von Programmen wie
passwd, chfn und chsh.

Für das lästige Passwortproblem, dass die Datei /etc/passwd Shadow-Suite

für jeden User und Prozess zugänglich sein muss, bietet sich
eine elegante Lösungen an: Der Einsatz der Shadow Suite.
Beim sogenannten Password-Shadowing enthält die Datei
/etc/passwd/ an Stelle des Passworts einen Token, der als al-
ternative Darstellung des tatsächlichen Passworts verwendet
wird. Das tatsächliche Passwort wird an einer anderen Stelle
abgelegt, die eben vor unerwünschten Zugriffen sicher ist.

Authentifizierungseinstellungen am Beispiel Red Hat

Schauen wir uns exemplarisch an, welche Konfigurations- Authentifizierung

möglichkeiten Red Hat bietet. Bereits während der Systemin- unter Red Hat
stallation kann man die verschiedenen Sicherheitsfunktionen
aktivieren. Red Hat unterstützt insbesondere MD5, Shadow-
Passwörter, NIS, LDAP und Kerberos. Wenn die NIS-Option
verwendet werden soll, muss der Computer an ein NIS-
Netzwerk angeschlossen sein. Gleiches gilt für LDAP. Auch
in diesem Fall muss ein LDAP-Server im Netzwerk verfügbar
sein. Abbildung 7/2.2-1 zeigt den zugehörigen Dialog. Die
Einstellungen ähneln denen anderer Distributionen und Be-
triebssysteme.

5
Teil 7/2.2 Seite 4 Linux und Sicherheit

Authentifikation

Abbildung 7/2.2-1: Konfiguration der System-Authentifi-

zierung unter Red Hat Linux

Die nachstehende Tabelle fasst die unter Red Hat verfügbaren

Optionen zur Sicherheitsprüfung zusammen:

Option Beschreibung
MD5-Passwörter aktivieren Mit dieser Einstellung können lange Passwörter (bis
zu 256 Zeichen) statt der standardmäßigen Pass-
wörter mit maximal 8 Zeichen verwendet werden.
Shadow-Passwort Diese Option stellt eine sichere Methode für das
aktivieren Speichern von Passwörtern zur Verfügung. Die
Passwörter werden im Verzeichnis /etc/shadow ge-
speichert, auf die man nur als Root zugreifen kann.
NIS aktivieren Eine Gruppe von Rechnern lässt sich mit einer ge-
meinsamen Passwort- und Gruppendatei in dersel-
ben Network Information Service-Domain betreiben.
NIS-Domäne Hier gibt man an, zu welcher Domäne oder Gruppe
von Computern das System gehören soll.
Broadcast zur Suche nach Erlaubt das Versenden einer Meldung an das LAN,
NIS-Server verwenden um einen verfügbaren Server zu finden.
Linux und Sicherheit Teil 7/2.2 Seite 5

Authentifikation

Option Beschreibung
NIS-Server Erlaubt den Zugriff auf einen NIS-Server, statt eine Broad-
cast-Anforderung an das lokale Netzwerk auszugeben,
um nach verfügbaren Servern für das System zu fragen.
LDAP aktivieren Weist den Rechner an, LDAP für einen Teil oder die ge-
samte Authentifizierung zu verwenden.
LDAP-Server Durch die Angabe einer IP-Adresse kann man auf einen
Server zugreifen, der das LDAP-Protokoll ausführt.
LDAP-Basis-DN Erlaubt die Suche anhand des eindeutigen Namens
(Distinguished Name, ND) nach Benutzerinformationen.
TLS (Transport Layer Mit dieser Option kann LDAP verschlüsselte Benutzerna-
Security) Lookups men und Passwörter an einen LDAP-Server senden, be-
vor die Authentifizierung ausgeführt wird.
Kerberos aktivieren Kerberos ist ein sicheres System, das Authentifizierungs-
dienste für Netzwerke zur Verfügung stellt.
Bereich Erlaubt den Zugriff auf ein Netzwerk, das Kerberos ver-
wendet und aus einem oder einigen Servern (die auch als
KDC bezeichnet werden) sowie einer potenziell sehr gro-
ßen Zahl von Clients besteht.
KDC Erlaubt den Zugriff auf das Key Distribution Center (KDC).
Dies ist das Gerät, das Kerberos-Tickets ausgibt.
Admin-Server Mit dieser Option kann man auf einen Server zugreifen,
der kadmind ausführt.

Pluggable Authentication Modules

Einem Linux-User steht in der Regel eine Vielzahl von An- Anwendungen und
wendungen zur Verfügung. Ein Arbeiten mit diesen Pro- Authentifizierungs-
grammen ist allerdings erst möglich, wenn die Programme mechanismen
dem Benutzer Zugriffsrechte einräumen. Benutzer müssen
sich also authentifizieren können. In der Regel erfolgt die
Anmeldung durch Angabe des Namens und eines Passworts.
Der Anmeldeprozess verwendet diese, um die Anmeldung zu
authentifizieren.

5
Teil 7/2.2 Seite 6 Linux und Sicherheit

Authentifikation

Dieses Verfahren bringt eine ganze Reihe von Nachteilen mit

sich:

• Da jede Anwendung die Identifikation und Authentifizie-

rung durchführen muss, ist ein hoher Bearbeitungsaufwand
erforderlich.
• Änderungen an Authentifizierungsmechanismen sind nur
durch den Austausch ganzer Anwendungen möglich.
• Neu entwickelte Authentifizierungsmechanismen sind nur
schwer integrierbar.
• Es besteht eine hohe Fehleranfälligkeit.

Die Lösung: Die Lösung aller dieser Probleme: Pluggable Authentication

Pluggable Modules, kurz PAM. Mit deren Hilfe kann der Systemadmi-
Authentication nistrator die Authentifizierungsregeln festlegen, ohne die Au-
Modules thentifizierungsprogramme neu kompilieren zu müssen. Be-
stimmte Authentifikationsmodule können in ein Programm
eingefügt werden, indem Sie die entsprechende PAM-Konfi-
gurationsdatei dieses Programms in /etc/pam.d bearbeiten.

Abbildung 7/2.2-2: Das Zusammenspiel von Applikationen und PAM-Modulen

Linux und Sicherheit Teil 7/2.2 Seite 7

Authentifikation

PAM bringt Ihnen als Systemadministrator eine ganze Reihe Vorzüge von PAM
von Vorteilen:

• ein gemeinsames Authentifikationsschema, das für viele

verschiedene Anwendungen verwendet werden kann
• die Möglichkeit, verschiedene Anwendungen zu implemen-
tieren, ohne die Anwendungen für PAM neu kompilieren
zu müssen
• mehr Flexibilität und Kontrolle der Authentifizierung für
Administratoren und Entwickler von Anwendungen
• Anwendungsentwickler müssen ihre Programme nicht
speziell für die Verwendung bestimmter Authentifikati-
onsschemata entwickeln

Die PAM-Konfigurationsdateien finden Sie im Verzeichnis PAM-Kon-

/etc/pam.d. Jede Anwendung besitzt eine eigene Datei. Diese figurationsdateien
Datei besteht aus fünf Elementen: Dienstname, Modultyp,
Steuer-Flags, Modulpfad und Argumente.

Der Dienstname jeder PAM-aktiven Anwendung ist der Na- PAM-Dienstname

me der Konfigurationsdatei der Anwendung in /etc/pam.d.
Jedes Programm, das PAM verwendet, definiert seinen eige-
nen Dienstnamen. Das Programm login definiert den Dienst-
namen login, ftpd definiert den Dienstnamen ftp etc.

PAM beinhalten vier verschiedene Modultypen für die Zu- PAM-Module

griffskontrolle auf Dienste:

Modul Beschreibung
auth Nimmt die eigentliche Authentifizierung vor.
Ist z. B. für die Abfrage und Überprüfung
des Passworts zuständig.
account Prüft, ob die Authentifizierung erlaubt ist.
password Dient dem Setzen von Passwörtern.
session Stellt sicher, dass ein Benutzer nach seiner
Authentifizierung seinen Account benutzen
kann.

5
Teil 7/2.2 Seite 8 Linux und Sicherheit

Authentifikation

Stapelbildung Das Interessante an diesen Modulen ist, dass sie stapelbar

sind. Das heißt, es können mehrere Module verwendet wer-
den. Dabei spielt die Reihenfolge der gestapelten Module für
den Authentifikationsprozess eine zentrale Rolle.

PAM am Beispiel rlogin verwendet vier gestapelte Authentifizierungsmetho-

rlogin den, wie anhand der PAM-Konfigurationsdatei erkennbar ist.

auth required /lib/security/pam_nologin.so

auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth

Bevor rlogin ausgeführt wird, stellt PAM fest, dass die

/etc/nologin-Dateien nicht existieren, dass Sie auch nicht als
Root angemeldet sind und dass alle Umgebungsvariablen
geladen werden können. Wenn die rhosts-Authentifizierung
erfolgreich ist, wird die Verbindung zugelassen. Ist die Au-
thentifizierung nicht erfolgreich, wird zur Standardauthentifi-
zierung mit Passwort übergegangen.

PAM-Steuer-Flags PAM-Module erstellen bei ihrer Ausführung Fehler- oder Er-

folgsmeldungen. Die Steuer-Flags geben an, was mit diesen
Ergebnissen geschehen soll. Während Module in einer be-
stimmten Reihenfolge gestapelt werden können, kann man
mit den Steuer-Flags die Wertigkeit eines Moduls in Bezug
auf die nachfolgenden Module bestimmen.

Steuer-Flag-Typen Ist der Modultyp festgelegt, entscheidet das Steuer-Flag, wie

wichtig ein bestimmtes Modul in Bezug auf das Gesamtziel
ist. Dabei sind standardmäßig vier Arten von Steuer-Flags für
PAM festgelegt:

• Mit required gekennzeichnete Module müssen erfolgreich

überprüft werden, bevor die Authentifizierung möglich ist.
Linux und Sicherheit Teil 7/2.2 Seite 9

Authentifikation

• Mit requisite gekennzeichnete Module müssen ebenfalls

überprüft werden, bevor die Authentifizierung möglich ist.
• Bei als sufficient gekennzeichneten Modulen werden Feh-
ler ignoriert.
• Optional gekennzeichnete Module sind für die erfolgreiche
oder fehlgeschlagene Authentifizierung dieses Modultyps
nicht von Bedeutung.

Wenn Sie mehr über PAM und seinen Praxiseinsatz wissen Linux-PAM System
wollen, besuchen Sie The Linux-PAM System Administrators’ Administrators’
Guide unter www.kernel.org/pub/linux/libs/pam/Linux-PAM- Guide
html/pam.html.

5
Teil 7/2.2 Seite 10 Linux und Sicherheit

Authentifikation
Linux und Sicherheit Teil 7/2.3.1 Seite 1

Syntax der Konfigurationsdatei

7/2.3 PAM für Profis

Autor: Holger Reibold

Wie wir im einführenden PAM-Artikel gesehen haben, lösen Mehr Sicherheit

PAM (Pluggable Authentication Modules) eine Vielzahl von durch Pluggable
Problemen bei der Benutzerauthentifizierung. Der Systemad- Authentication
ministrator kann mit ihrer Hilfe Authentifizierungsregeln fest- Modules
legen, ohne dass die Authentifizierungsprogramme neu kom-
piliert werden müssen. Bestimmte Authentifikationsmodule
können in ein Programm eingefügt werden, indem man die
PAM-Konfigurationsdatei dieses Programms in /etc/pam.d
bearbeitet. In diesem Kapitel werden wir uns detaillierter mit
der PAM-Konfigurationsdatei und nicht zuletzt mit einigen
PAM-spezifischen Sicherheitsaspekten auseinander setzen.

PAM ist gerade aufgrund seiner vielen Schalter, Optionen etc. Eine der Stärken
äußerst flexibel. Die lokale Konfiguration ist dabei entweder von PAM: die
in der Konfigurationsdatei /etc/pam.cf oder im Konfigura- Flexibilität
tionsverzeichnis /etc/pam.d/ abgelegt. Im Folgenden werden
Syntax und Optionen der Konfigurationsdateien und Ver-
zeichnisse beschrieben.

7/2.3.1 Syntax der Konfigurationsdatei

Bevor wir uns Feinheiten zuwenden, etwas Wichtiges vor- Groß- und
weg: Bei den in der Konfigurationsdatei verwendeten Zei- Kleinschreibung
chen ist es gleichgültig, ob es sich um Groß- oder Klein-
schreibung – oder einen Mix – handelt. PAM macht hier keine
Unterschiede. Aber Vorsicht: Bei der Pfadangabe der Module
unterscheidet PAM sehr wohl zwischen Groß- und Klein-
schreibung, da es sich hierbei um betriebssystemspezifische
Informationen handelt.

6
Teil 7/2.3.1 Seite 2 Linux und Sicherheit

Syntax der Konfigurationsdatei

Außerdem sind zwei Sonderzeichen vorgesehen. Kommenta-

ren wird die Raute (#) vorangestellt, Modulspezifikationen
können durch einen Backslash in einer neuen Zeile weiterge-
führt werden.

Allgemeine Syntax Die allgemeine Syntax für die Konfiguration von /etc/
pam.conf besitzt folgende Form:

service-name module-type control-flag module-path arguments

Setzen wir uns zunächst mit den einzelnen Elementen aus-

einander, bevor wir im anschließenden Abschnitt auf die
Konfiguration über ein Konfigurationsverzeichnis zu spre-
chen kommen.

service-name Mit service-name definiert man die Bezeichnung, die mit ei-
nem Eintrag verknüpft ist. Dabei handelt es sich meist um
Namen von Applikationen, die für das Zusammenspiel mit
PAM vorbereitet werden, z. B. ftpd, rlogind, su etc.

Außerdem gibt es einen Sonderfall mit der Bezeichnung

OTHER. Er dient der Definition des Standardauthentifizie-
rungsmechanismus. Statt der hier verwendeten Großschrei-
bung kann auch die kleingeschriebene Variante other ver-
wendet werden (siehe oben).

module-type Mit module-type bestimmt man einen von bislang vier ver-
fügbaren Modultypen. Die vier Modultypen tragen die Be-
zeichnungen auth, account, session und password. Die Ein-
zelheiten zu den verschiedenen Typen:

Modultyp Beschreibung
auth Dieses Modul deckt zwei Aspekte der User-Authentifikation ab. Zum
einen stellt es über die Abfrage von Kennung und Passwort fest, wer
der User ist, zum anderen kann es Gruppenzugehörigkeiten und an-
dere Privilegien feststellen.
account Dieses Modul ist für die Zugriffe zuständig, die unabhängig vom Ac-
count-Management gewährt werden. Dabei kann es sich z. B. um
zeitlich begrenzte Zugriffe für alle User handeln.
Linux und Sicherheit Teil 7/2.3.1 Seite 3

Syntax der Konfigurationsdatei

Modultyp Beschreibung
session Dieses Modul ist für Aktionen zuständig, die nach bzw. vor dem
Zugriff auf bestimmte Dienste erfolgen. Beispiele hierfür sind die Ak-
tivierung von Log-Vorgängen bei bestimmten User-Aktivitäten wie
etwa dem Datenaustausch.
password Dieser Modultyp sorgt für die Aktualisierung von Authentifizierungs-
zeichen der User.

Das control-flag zeigt an, wie die PAM-Bibliothek auf die er- control-flag
folgreiche oder misslungene Ausführung damit verknüpfter
Module reagiert. Da Module stapelbar sind, bestimmt con-
trol-flag die relative Wichtigkeit der Module zueinander. Die
Anwendung, die es zu sichern gilt, bekommt keine Einzel-
heiten mit, sondern wird lediglich mit einer Erfolgs- bzw.
Fehlermeldung informiert.

Die Reihenfolge der Ausführung der Module entspricht der

Reihenfolge der Nennung in der Konfigurationsdatei /etc/
pam.cf. Das control-flag stellt vier Schlüsselwörter zur Ver-
fügung: required, requisite, sufficient und optional. Deren
Bedeutung ist in nachstehender Tabelle beschrieben:

Schlüsselwort Beschreibung
required Zeigt an, dass die erfolgreiche Ausführung des Moduls für
module-type erforderlich ist.
Requisite Schlägt die Ausführung eines Moduls fehl, wird die Steuerung
direkt an die Applikation übergeben.
Sufficient Die erfolgreiche Ausführung eines Moduls genügt der PAM-
Bibliothek.
Optional Module, die mit diesem Schlüsselwort gekennzeichnet sind,
sind nicht kritisch für die User-Authentifizierung.

In neueren Versionen unterstützt PAM eine weitere Syntax Alternative

für die Steuerung der Benutzerauthentifizierung. Bei dieser Konfiguration
Form von control-flag handelt es sich um eine durch Leerzei- durch Klammerung
chen getrennte Wert=Zeichen-Folge, die in eckigen Klam-
mern zusammengefasst wird:

6
Teil 7/2.3.1 Seite 4 Linux und Sicherheit

Syntax der Konfigurationsdatei

[wert1=aktion1 wert2=aktion2 ...]

In diesem Fall ist wert1 einer der folgenden Rückgabewerte:

• success • open_err
• symbol_err • service_err
• system_err • buf_err
• perm_denied • auth_err
• cred_insufficient • authinfo_unavail
• user_unknown • maxtries
• new_authtok_reqd • acct_expired
• session_err • cred_unavail
• cred_expired • cred_err
• no_module_data • conv_err
• authtok_err • authtok_recover_err
• authtok_lock_busy • authtok_disable_aging
• try_again • ignore
• abort • authtok_expired
• module_unknown • bad_item
• default

Der letzte Wert (default) wird für die Aktionen definiert, die
nicht expliziert spezifiziert wurden.

Aktion1 nimmt dabei entweder einen positiven Integer-Wert

oder einen der folgenden Werte an: ignore, ok, done, bad, die,
reset. Die Bedeutung der Werte ist in nachstehender Tabelle
zusammengefasst:
Linux und Sicherheit Teil 7/2.3.1 Seite 5

Syntax der Konfigurationsdatei

Wert Beschreibung
ignore Kommt dieser Wert in Verbindung mit einem Modulstapel zum Einsatz,
wird der Return-Status nicht den an die Applikation zurückgegebenen
Code enthalten.
Bad Zeigt an, dass der ausgegebene Code als Fehlermeldung beurteilt wer-
den sollte.
Die Entspricht dem Wert bad. Einziger Unterschied: Der Modulstapel wird
aufgelöst.
ok Zeigt an, dass der Rückgabecode an den Rückgabecode des gesamten
Stapels gehängt wird.
done Entspricht weitgehend ok, allerdings wird der Stapel aufgelöst und direkt
zur Applikation zurückgekehrt.
reset Löscht den Status des Modulstapels.

Die neuere control-flag-Variante erlaubt z. B. mittels Client-

Plug-in-Agents die Maschine-zu-Maschine-Authentifizierung,
die ein von der Client-Server-Applikation geerbtes Transport-
protokoll verwendet. Über die Klammerkontrollsyntax kann
man z. B. binäre Authentifizierung verwenden.

Bei module-path handelt es sich um den Pfadnamen der dy- module-path

namischen, ladbaren Objektdatei, also um das Pluggable-Mo-
dul selbst. Das erste Zeichen ist immer ein Schrägstrich (/).
Außerdem ist die Angabe des kompletten Pfades empfeh-
lenswert. Ist das nicht der Fall, sucht das jeweilige Modul im
Standardmodulpfad (/usr/lib/security).

Bei den Argumenten (arguments oder kurz args), handelt es args

sich um eine Zeichenfolge, die beim Aufruf eines Moduls an
dieses übergeben wird. Sie haben viel mit den Linux-typi-
schen Shell-Kommandos gemein. Mehr zu Argumenten er-
fahren Sie im übernächsten Abschnitt.

6
Teil 7/2.3.1 Seite 6 Linux und Sicherheit

Syntax der Konfigurationsdatei

Linux und Sicherheit Teil 7/2.3.2 Seite 1

Verzeichnisbasierte Konfiguration

7/2.3.2 Verzeichnisbasierte Konfiguration

Noch mehr Flexibilität bietet die Konfiguration auf Basis ei- Mehr Komfort durch
nes Konfigurationsverzeichnisses. In diesem Fall wird die verzeichnisbasierte
Konfiguration über das Verzeichnis /etc/pam.d/ bestimmt. Konfiguration
Das Verzeichnis füllt man einfach mit maximal vier Dateina-
men (in Kleinschreibung), die mit dem oben eingeführten
Servicenamen identisch sind. Die Konfiguration wird also an
Stelle einer mächtigen Konfigurationsdatei auf vier einzelne
Dateien verteilt.

PAM kann auf zwei Arten kompiliert werden. Der bevorzugte

Modus verwendet entweder /etc/pam.d/ oder /etc/pam.conf
für die Konfiguration, nicht aber beide. Wird das Verzeichnis
/etc/pam.d/ verwendet, greift die PAM-Bibliothek lediglich
auf die dort enthaltenen Dateien zurück. Fehlt indes das Ver-
zeichnis /etc/pam.d/, wird das Verzeichnis /etc/pam.conf ver-
wendet. Im zweiten Modus werden beide Verzeichnisse ab-
wechselnd eingesetzt. In diesem Fall überschreiben die Ein-
träge in /etc/pam.d/ die von /etc/pam.conf.

Die Syntax für jede Konfigurationsdatei in /etc/pam.d ist ähn- Syntax

lich wie für die /etc/pam.conf-Konfigurationsdatei:

module-type control-flag module-path arguments

Der einzige Unterschied: service-name ist nicht enthalten, da

diese Information im Konfigurationsdateinamen enthalten ist.
So enthält /etc/pam.d/login z. B. die Konfiguration für den
Login-Service. Für die Konfiguration und deren mögliche
Optionen sei auf den vorangegangenen Abschnitt verwiesen,
denn die Einstellungen sind identisch.

Die Aufspaltung der Konfiguration in mehrere Konfigurati-

onsdateien bringt verschiedene Vorteile. Letztlich muss aber
jeder Administrator selbst entscheiden, welche Konfigura-
tionsmethode er bevorzugt. Nachfolgend finden Sie einen
Überblick über die wichtigsten Vorzüge.

6
Teil 7/2.3.2 Seite 2 Linux und Sicherheit

Verzeichnisbasierte Konfiguration

Vorzüge der ver- • Die Gefahr von fehlerhaften Konfigurationen (insbesondere

zeichnisbasierten durch unachtsame manuelle Eingriffe) sinkt.
Konfiguration
• Die Verwaltung der Konfigurationsdateien gestaltet sich
einfacher. Einzelne PAM-geschützte Anwendungen kön-
nen ohne größere Gefahren neu konfiguriert werden.
• Unterschiedliche Service-Konfigurationen können per
Symbolic Link mit einer Datei verknüpft werden. Das er-
leichtert natürlich die Pflege von Systemrichtlinien für den
Zugriff über mehrere Applikationen hinweg.
• Das Parsen der Konfigurationsdateien kann schneller
durchgeführt werden, da lediglich die relevanten Einträge
geparst werden.
• Für einzelne Konfigurationsdateien können unterschiedli-
che Zugriffsrechte vergeben werden, indem man auf die
Schutzmechanismen des Betriebssystems zurückgreift.
• Das Paketmanagement vereinfacht sich. Bei jeder Neuins-
tallation kann sie mit einer /etc/pam.d/xxx-Datei verknüpft
werden.

Bevor wir uns einige beispielhafte Konfigurationsschnipsel

ansehen, wollen wir uns noch mit den PAM-Argumenten
auseinandersetzen. Dabei handelt es sich um Zeichenfolgen,
die beim Aufruf eines Moduls an dieses übergeben werden.
Linux und Sicherheit Teil 7/2.3.3 Seite 1

Optionale Argumente

7/2.3.3 Optionale Argumente

PAM stellt eine Vielzahl von Argumenten bereit. In nachste- Modul-

hender Übersicht sind optionale Argumente zusammenge- übergreifende
fasst, die von allen Modultypen unterstützt werden. Es han- Argumente
delt sich wie gesagt um optionale Argumente, deren Einsatz
nicht zwingend, aber je nach Applikation und gewünschter
Konfiguration durchaus sinnvoll ist.

Argument Beschreibung
debug Verwendet den syslog-Aufruf, um Debugging-Informationen
in die System-Logdatei zu schreiben.
no_warn Unterdrückt die Ausgabe von Warnmeldungen.
use_first_pass Das Modul soll keine Abfrage des User-Passworts durch-
führen. Statt dessen soll es das zuletzt getippte Passwort
(des vorangehenden auth-Moduls) verwenden. Gelingt dies
nicht, kann der User nicht authentifiziert werden.
try_first_pass Das Modul soll die Authentifizierung mit dem zuletzt ge-
tippten Passwort versuchen. Gelingt das nicht, erfolgt die
Abfrage des User-Passworts per Prompt.
use_mapped_pass Das Modul verwendet Verschlüsselungstechniken für die
Authentifizierung.
Dieses Argument wird bislang leider nicht von allen PAM-
Distributionen unterstützt. Der Grund sind die restriktiven
US-Exportgesetze für Verschlüsselungstechnologien. Inner-
halb der USA kann es unbeschränkt implementiert werden.
expose_account Dieses Argument ist ein Standardargument, das einen we-
niger strengen Umgang mit Account-Informationen erlaubt.

6
Teil 7/2.3.3 Seite 2 Linux und Sicherheit

Optionale Argumente
Linux und Sicherheit Teil 7/2.3.4 Seite 1

Beispielkonfiguration

7/2.3.4 Beispielkonfiguration

In diesem Abschnitt zu den PAM-Konfigurationsdateien sehen Beispiele …

wir uns einige typische Ausschnitte näher an. Ein hohes Maß
an Sicherheit bei der Benutzerauthentifizierung erreicht man
mit dem Standardauthentifizierungsmechanismus OTHER.
Ein Beispiel für die sehr restriktiven Standardeinstellungen:

# Standard, Zugriff verweigern

#
OTHER auth required /usr/lib/security/pam_deny.so
OTHER account required /usr/lib/security/pam_deny.so
OTHER password required /usr/lib/security/pam_deny.so
OTHER session required /usr/lib/security/pam_deny.so

Allerdings ist das Modul pam_deny nicht sehr leistungsfähig, … und Beispiele …
da es z. B. kein Logging seiner Aufrufe unterstützt. Ein User
müsste schon selbst bei der fehlgeschlagenen Ausführung
eine Nachricht an den Systemadministrator schicken. Diese
Einschränkung behebt man mit folgenden Zeilen:

# Warnung an Admin: Diese Anwendung ist nicht konfiguriert!

#
OTHER auth required /usr/lib/security/pam_warn.so
OTHER password required /usr/lib/security/pam_warn.so

Auf einem System, das die /etc/pam.d/-Konfiguration ver- … und noch mehr
wendet, kann die Standardeinstellung durch folgende Datei Beispiele
erreicht werden:

# Standardkonfiguration: /etc/pam.d/other
#
auth required /usr/lib/security/pam_warn.so
auth required /usr/lib/security/pam_deny.so
account required /usr/lib/security/pam_deny.so
password required /usr/lib/security/pam_warn.so
password required /usr/lib/security/pam_deny.so
session required /usr/lib/security/pam_deny.so

6
Teil 7/2.3.4 Seite 2 Linux und Sicherheit

Beispielkonfiguration

Auf Systemen, die weniger stark geschützt werden müssen,

reicht die folgende Konfiguration vollkommen aus:

# Standardzugriff
#
OTHER auth required /usr/lib/security/pam_unix_auth.so
OTHER account required /usr/lib/security/pam_unix_acct.so
OTHER password required
/usr/lib/security/pam_unix_passwd.so
OTHER session required
/usr/lib/security/pam_unix_session.so

Sicherheit für ftpd Leider genügt obige Konfiguration nicht allen Applikationen
und ihrer Funktionalität. Soll z. B. ftpd auch anonymen Zu-
griff erlauben, sind einige Ergänzungen erforderlich:

# ftpd-spezifische Einstellungen, die auch anonymen Zugriff

# erlauben.
#
ftpd auth sufficient /usr/lib/security/pam_ftp.so
ftpd auth required /usr/lib/security/pam_unix_auth.so
use_first_pass
ftpd auth required /usr/lib/security/pam_listfile.so \
onerr=succeed item=user sense=deny
file=/etc/ftpusers
Linux und Sicherheit Teil 7/2.3.5 Seite 1

PAM-spezifische Sicherheitsaspekte

7/2.3.5 PAM-spezifische Sicherheitsaspekte

Zum Abschluss dieses Kapitels wollen wir uns noch einigen Gefahrenquelle
PAM-spezifischen Sicherheitsfragen widmen. PAM hat zwei- unsaubere
fellos das Potenzial, um die Sicherheit einer Linux-Installa- Konfiguration
tion deutlich zu verbessern. Man kann auch zwischen den
beiden Extremen „keine Sicherheit“ und „fast absolute Sicher-
heit“ wählen – immer vorausgesetzt, der Administrator weiß
mit dem Sicherheitsmechanismus umzugehen. Allerdings ist
durch fehlerhafte oder versehentlich falsch vorgenommene
Einstellungen die vermeintliche Sicherheit schnell dahin.

Im Extremfall, wenn man z. B. die Konfigurationsdateien Ausgesperrt

/etc/pam.d/* und/oder /etc/pam.conf löscht, schließt man sich
selbst aus. In diesem Fall führt man einen Neustart im Single-
User-Modus durch.

LILO boot: linux single

Gesetzt den Fall, es wurden lediglich die Konfigurationsda-

teien, nicht aber die gesamte Installation gelöscht, führt man
folgende Kommandos durch:

cd /etc
mv pam.conf pam.conf.orig
mv pam.d pam.d.orig
mkdir pam.d
cd pam.d

Anschließend erzeugt man eine neue Datei mit der Bezeich-

nung other. Sie sollte folgende vier Zeilen beinhalten:

auth required pam_unix_auth.so

account required pam_unix_acct.so
password required pam_unix_passwd.so
session required pam_unix_session.so

6
Teil 7/2.3.5 Seite 2 Linux und Sicherheit

PAM-spezifische Sicherheitsaspekte

Dabei handelt es sich um eine einfache PAM-Konfiguration.

In der Regel kann man sich auf Konsolenebene wieder ein-
loggen und anschließend die ursprüngliche Konfiguration
wiederherstellen. Dabei hilft ein Blick in die Logfiles.

Sichere Other- Other-Konfigurationen in den Standardeinstellungen stellen

Konfiguration außerdem ein gewisses Risiko für Attacken dar. Man sollte
sie besser schützen. Im nachfolgenden Beispiel verhindert
das pam_deny-Modul den Zugriff, und das pam_warn-Modul
sorgt für die Ausgabe einer Warnmeldung an auth.notice.

# PAM-Konfigurationsdatei für den OTHER-Service

#
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam _deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so

Zusätzliche Details finden Sie zudem in der Referenz des Li-

nux-PAM System Administrators’ Guide (www.kernel.org/
pub/linux/libs/pam/Linux-PAM-html/pam-6.html). Dort fin-
det man auch eine ausführliche Beschreibung aller Module
und verfügbaren Schalter. In der Dokumentation ist auch der
Einsatz so interessanter Module wie des Filter-, Kerberos-4-,
Mail-, Password-Database-, RADIUS- und userdb-Moduls
beschrieben.

Weiterführende Informationsquellen

Für weiterführende Informationen sei auf die folgenden Web-

sites verwiesen. Unabhängig davon werden wir das Thema
Sicherheit in nachfolgenden Aktualisierungen vertiefen.
Linux und Sicherheit Teil 7/2.3.5 Seite 3

PAM-spezifische Sicherheitsaspekte

Website Adresse Kurzinfo

SuSE Linux Security www.suse.de/de/support/ Sicherheitswarnungen von
Announcements security/ SuSE
RedHAT Linux www.redhat.com/mailing- Sicherheitsberichte von
Security lists/linux-security/ Red Hat
Allgemeine Infos zur www.rz.uni-wuerzburg.de/ Allgemeine Sicherheitsinfos
Computersicherheit security/
Aktuelle www.rz.uni-wuerzburg.de/ Aktuelle Sicherheitshinweise
Sicherheitshinweise security/aktuell/ der Uni Würzburg
Linux Security securityportal.com/frame- Jede Menge Sicherheitsin-
linux.html formationen zu Linux
Securityfocus.com www.securityfocus.com Sicherheitsrelevante Mel-
dungen aller Art für viele
Betriebssysteme
SecurityNews.ORG www.securitynews.org Site über Security-Themen
LinuxSecurity.COM www.linuxsecurity.com Alles rund um Linux-
Sicherheit
Cert Coordination www.cert.org Homepage des CERT Coor-
Center dination Center
InSecure.ORG www.insecure.org Informationen über aktuelle
Sicherheitsprobleme
Computer- www.computer-security.de Forum für Computersicher-
Security.de heit. Täglich News und Si-
cherheitslücken und über
600 Dateien zum Thema Si-
cherheit

6
Teil 7/2.3.5 Seite 4 Linux und Sicherheit

PAM-spezifische Sicherheitsaspekte