IT-GSHB 2000 - Einsatz der Sicherheitsmechanismen von

M 5.19 Einsatz der Sicherheitsmechanismen von sendmail

Verantwortlich für Initiierung: IT-Sicherheitsmanagement, Administrator

Verantwortlich für Umsetzung: Administrator

Da die Übertragung von Mails die wohl am meisten verbreitete Anwendung in Netzen ist, sind die dafür zuständigen Prozesse von besonderer Bedeutung und einer der häufigsten Angriffspunkte in einem System. Hinzu kommt, daß diese Prozesse häufig das suid

Bit gesetzt haben und einem privilegierten Benutzer gehören (z. B. root oder bin ). Ein Fehler in sendmail war z. B. einer der Wege, über die sich der Internet-Wurm ausgebreitet hat.

Beim Starten von sendmail lassen sich sehr viele Optionen angeben, die zu Sicherheitsproblemen führen würden, wenn sie mit root -Rechten abliefen. Wenn sendmail von beliebigen Benutzern aufgerufen werden kann, sollte deshalb überprüft werden, ob es beim Start mit einer dieser Optionen das gesetzte suid- Bit ignoriert und mit der UID des Benutzers abläuft. Um Sicherheitsprobleme zu vermeiden, sollte der Administrator sicherstellen, daß sendmail nur mit den folgenden Optionen bei gesetztem suidroot -Bit von unprivilegierten Benutzern gestartet werden kann: 7, b, C, d, e, E, i, j, L, m, o, p, r, s und v.

Aufgrund der in der Vergangenheit aufgedeckten Sicherheitsdefizite des Programms sendmail muß stets die aktuellste Programmversion eingesetzt werden. Informationen über die aktuellen Versionen erteilen die in M 2.35 Informationsbeschaffung über Sicherheitslücken des Systems angegebenen Stellen wie BSI, CERT, DFN-CERT.

Der sendmail -Prozeß darf nicht im Debug-Modus betrieben werden können, da es sonst möglich wird, root -Rechte zu erlangen. Man kann dies testen, indem man den Befehl
eingibt, wobei localhost der zu überprüfende Rechnername sein kann und 25 die Portnummer, mit der der sendmail Prozeß angesprochen wird. Der Rechner bzw. der sendmail -Prozeß meldet sich dann mit
Wenn Sie nun den Befehl debug, showq oder bei sehr alten Versionen wizard eingeben, sollte dies der Prozeß mit
ablehnen. Sie können dann mit dem Befehl quit die Verbindung wieder beenden.

Die Befehle vrfy und expn dürfen nicht verfügbar sein, da sie zu einem Mailnamen den zugehörigen Login-Namen ausgeben, so daß sich dann durch Probieren evtl. das zugehörige Paßwort herausfinden läßt. Bei Version 8 von sendmail lassen sich diese Befehle z. B. durch die Option p (privacy) beim Starten abschalten. Ob diese Befehle verfügbar sind, läßt sich wie im vorigen Punkt beschrieben feststellen, also z. B. durch Eingabe des Befehl vrfy useralias .
Die Konfigurationsdatei sendmail.cf sollte root gehören und auch nur für root les- und schreibbar sein. Dasselbe gilt für die darüber stehenden Verzeichnisse, da sich sonst durch ein einfaches Umbenennen dieser Verzeichnisse eine neue sendmail.cf Datei erzeugen läßt.
Die Angabe von ausführbaren Programmen oder von Dateien als gültige Adressen für Empfänger oder Absender muß durch die Konfiguration von sendmail.cf verhindert werden oder durch geeignete Maßnahmen auf bestimmte, unbedenkliche Programme und Dateien eingeschränkt werden.
Das F -Kommando (also z. B. FX/path [^#]), mit dessen Hilfe Klassen definiert werden, sollte in der Konfigurationsdatei ( sendmail.cf) nur benutzt werden, um Dateien zu lesen, die sowieso systemweit lesbar sind, da es sonst möglich sein kann, daß sicherheitsrelevante Informationen aus geschützten Dateien frei verfügbar werden. Die Programmform des F -Kommandos (z. B. FX|/tmp/prg ) sollte nicht benutzt werden!
Bei der Definition des Delivery Agents (z. B. Mlocal ) dürfen nur absolute Pfade angegeben werden (z. B. P=/bin/mail ). Außerdem sollte das Flag S (suid) nur gesetzt werden, wenn die damit evtl. verbundenen Sicherheitsprobleme geklärt sind.
Jede Datei, in die sendmail schreiben könnte, wie z. B. sendmail.st für eine Statistik, sollte nur von root beschreibbar sein und auch nur in root gehörenden Verzeichnissen stehen. Dasselbe gilt für Dateien, die von sendmail ausgewertet werden wie z. B. :include: in Mailing Listen.
Privilegierte Benutzer wie bin oder root sollten keine .forward Datei besitzen. Sind nämlich die Benutzer- oder Gruppenschreibrechte für diese Datei falsch gesetzt oder gelingt es einem Benutzer, in eine privilegierte Gruppe zu gelangen, kann er sich eine Shell mit der privilegierten Benutzerkennung erzeugen.
Für normale Benutzer sollte die .forward Datei nur von dem Besitzer beschreibbar sein und muß sich in einem Verzeichnis befinden, das dem Besitzer gehört.

Falls ein Heimatverzeichnis systemweit beschreibbar sein muß, wie z. B. uucp , läßt sich auf folgende Weise verhindern, daß eine schädliche .forward Datei angelegt werden kann: Es muß ein Verzeichnis mit dem Namen .forward, den Rechten 000 und dem Besitzer root angelegt werden und in diesem eine Datei ebenfalls mit den Rechten 000 und dem Besitzer root , so daß niemand außer root diese Datei verändern oder löschen kann. Das Homedirectory von uucp sollte dann ebenfalls root gehören und mit dem Sticky-Bit (t) versehen sein. Eine analoge Vorgehensweise empfiehlt sich auch für andere Konfigurationsdateien (z. B. .login, .cshrc ) in systemweit beschreibbaren Verzeichnissen.
Aus der Alias-Datei sollte jedes ausführbare Programm entfernt werden, insbesondere auch uudecode . Außerdem sollte die Alias-Datei und die zugehörige Datenbank root gehören und auch nur für root beschreibbar sein.
Es muß beachtet werden, daß jede empfangene Mail verfälscht sein kann. Dies kann entweder in der Mailqueue geschehen oder durch ein Einloggen auf Port 25. Ersteres läßt sich vermeiden, wenn das Mailqueue-Verzeichnis root gehört und die Rechte 0700 besitzt. Die Queue-Dateien sollten die Berechtigung 0600 haben. Die Veränderung einer Mail während ihres Transportes läßt sich nicht vermeiden, so daß die Benutzer darüber aufgeklärt werden müssen, daß z. B. eine Mail von root , in der sie dazu aufgefordert werden, ihr Paßwort zu ändern, gefälscht sein kann.