Im dritten Teil der Artikelserie wird die Abwandlung von Diensten zur Maximierung der Systemsicherheit fortgeführt. Neben entsprechenden Änderungen von Dateiinhalten erläutert dieser Teil auch den Einsatz von entsprechenden Kommandos sowie die Benutzung von Quota und die Prüfung der Integrität des Dateisystems.
Die Artikelserie basiert auf dem Kapitel 14 des Standardwerks „Debian GNU/Linux Anwenderhandbuch für Einsteiger, Umsteiger und Fortgeschrittene“ von Frank Ronneburg aus dem Verlag Addison-Wesley. Sie können dieses über 750 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
Weitere Details zur Maximierung der Systemsicherheit im Betrieb |
|
Teil 4 |
Benutzung von su und sudo
Sollte es einmal notwendig sein, Arbeiten am System als Administrator durchzuführen, so kann das Kommando su benutzt werden, um die benötigten Rechte zu erlangen. Versuchen Sie, allen Benutzern klarzumachen, dass Arbeiten als Administrator nur in Ausnahmefällen gestattet sind. In jedem Fall ist ein Login als root zu vermeiden und stattdessen das Kommando su zu benutzen. Noch besser ist es jedoch, das Kommando su komplett zu entfernen und stattdessen das Kommando sudo zu benutzen, das eine ganze Reihe weiterer Funktionen bietet. Der Befehl su ist aber weithin bekannt, da er auch auf vielen anderen Unix-Systemen eingesetzt wird.
sudo erlaubt einem Benutzer, Kommandos unter der ID eines anderen Benutzers auszuführen, gegebenenfalls auch als Administrator. Wenn der Benutzer in der Datei /etc/sudoers aufgeführt ist und sich authentifiziert hat, können Kommandos ausgeführt werden, die ebenfalls in dieser Datei aufgeführt sind. Verletzungen dieser Regel, wie beispielsweise ein falsches Passwort oder die versuchte Ausführung eines unerlaubten Programms, werden aufgezeichnet und per E-Mail an den Administrator (root) geschickt.
Benutzung von chroot
Der Befehl chroot ist eine leistungsfähige Möglichkeit, um ein Programm oder einen Daemon oder einen Benutzer zu beschränken. Man kann sich das wie in einem Gefängnis vorstellen, aus dem ein Ausbruch unmöglich ist (normalerweise … aber einige Leute schaffen es ja doch manchmal ...). Wenn einem Benutzer nicht vollkommen vertraut wird, so kann für diesen eine chroot-Umgebung eingerichtet werden. Dies kann einiges an Festplattenplatz beanspruchen, wenn alle benötigten Binaries und Bibliotheken in diese Umgebung kopiert werden müssen. Aber wenn es dem Benutzer gelingt, Schaden anzurichten, so bleibt dieser auf die durch das Kommando chroot definierte Umgebung beschränkt.
Ein gutes Beispiel für eine solche Anwendung ist folgende: Die Authentifizierung erfolgt nicht gegen die Datei /etc/passwd, sondern gegen LDAP oder/und eine MySQL-Datenbank. Ein verwendeter FTP-Daemon benötigt das Binary und ein paar Bibliotheken. Hier bildet eine chroot-Umgebung eine exzellente Verbesserung der Sicherheit, falls eine Sicherheitslücke in diesem FTP-Daemon auftaucht. In diesem Fall ist lediglich die Benutzer-ID des FTP-Daemons betroffen und keine anderen Benutzer des Systems. Natürlich können auch viele andere Dienste von solch einer Umgebung profitieren.
Hinweis: Bisher wird bei keiner Debian-Version eine chroot-Umgebung für die Dienste und Server verwendet.
Kernel-Features
Viele Funktionen des Kernels können während der Laufzeit verändert werden, beispielsweise indem mit dem Kommando echo ein Wert in die entsprechende Datei geschrieben wird, oder mit dem Kommando sysctl. Mit dem Kommando sysctl -A kann angezeigt werden, welche Einstellungen verändert werden können und welche Optionen verfügbar sind. In seltenen Fällen muss etwas verändert werden, aber auf diesem Weg kann die Sicherheit des Systems erhöht werden.
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts = 0
Wird diese Variable auf den Wert 1 gesetzt, so verhält sich das System nach außen wie ein Windows-System, wenn ein Broadcast-ping-Kommando das System erreicht.
/proc/sys/net/ipv4/icmp_echo_ignore_all = 0
Wenn ICMP-Pakete auf der vorgeschalteten Firewall nicht geblockt werden sollen, so ist diese Variable auf den Wert 0 zu setzen.
/proc/sys/net/ipv4/tcp_syncookies = 1
Diese Option ist ein zweischneidiges Schwert: Einerseits schützt sie gegen „Syn-Flooding-Attacken“, andererseits entspricht dies nicht den RFCs. Diese Option beschäftigt die angreifende Seite ebenso mit „Syn-Floods“, so dass diese gleichermaßen beschäftigt ist. Diese Option kann auch in /etc/network/options verändert werden, indem die Option syncookies auf yes gesetzt wird.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Mit dieser Option werden Pakete mit unerlaubten Adressen, beispielsweise wegen eines fehlerhaften Routings, im Netzwerk protokolliert.
Benutzung der svgalib und sichere Übertragung von Dateien
SVGAlib ist eine schöne Einrichtung für Liebhaber der Konsole. In der Vergangenheit sind jedoch immer wieder Sicherheitslücken bekannt geworden. So wurden Sicherheitslücken in zgv bekannt, mit denen Administratorrechte erlangt werden konnten. Wenn möglich, sollten Sie auf die Verwendung der SVGAlib verzichten.
Die Übertragung zwischen zwei Rechnern sollte auf keinen Fall mit Programmen wie ftp oder rcp erfolgen, da diese den Benutzernamen und das Passwort unverschlüsselt übertragen. Als sichere Alternative steht das Programm scp zur Verfügung, das im Paket ssh enthalten ist. Hier werden sowohl der Benutzername als auch das Passwort und auch die Daten selbst in verschlüsselter Form übertragen.
Benutzung von Quota
Eine saubere Definition von Benutzerquota ist wichtig, um zu verhindern, dass Benutzer ein komplettes Dateisystem mit Daten füllen können. Es können grundsätzlich zwei verschiedene Quota-Systeme eingesetzt werden: benutzer- oder gruppenorientierte Quota. Dies ist bei der Planung zu berücksichtigen. Einige Punkte sind bei der Benutzung von Quota zu beachten:
Quota sollten in der Summe so klein gewählt werden, dass nicht der gesamte Festplattenplatz belegt werden kann.
Quota sollten so groß gewählt werden, dass die Benutzer nicht bei der Arbeit behindert werden. Beispielsweise sollte das Spoolverzeichnis für Mail nicht zu knapp bemessen werden.
Quota müssen auf allen von Benutzern beschreibbaren Bereichen eingerichtet werden, beispielsweise /home und /tmp.
Für jede Partition beziehungsweise jedes Verzeichnis, auf die beziehungsweise das Benutzer Schreibzugriff haben, sollten Quota aktiviert werden. Für diese Bereiche ist ein sinnvoller Wert zu errechnen, der eine Balance zwischen Sicherheit und Benutzbarkeit des Systems schafft.
Doch nun zur Benutzung von Quota: Zunächst müssen Sie prüfen, ob die Quota-Unterstützung im Kernel aktiviert ist. Wenn dies nicht der Fall ist, muss ein neuer Kernel erzeugt werden. Danach ist sicherzustellen, dass das Paket quota installiert ist.
Quota werden aktiviert, indem in der Datei /etc/fstab der Eintrag für das entsprechende Dateisystem in der Spalte „Options“ um den Eintrag usrquota erweitert wird. Wenn statt Benutzer-Quota Gruppen-Quota benutzt werden sollen, lautet der Eintrag grpquota. Natürlich können auch beide gleichzeitig verwendet werden. Nun müssen im Root-Verzeichnis des Dateisystems leere Dateien quota.user und/oder quota.group erzeugt werden.
Das Quota-System muss nun neu gestartet werden. Dies geschieht durch die Kommandos /etc/init.d/quota stop und /etc/init.d/quota start. Nun können die gewünschten Grenzwerte gesetzt werden.
Um Quota für einen Benutzer (beispielsweise fr) zu setzen, wird das Kommando edquota -u fr benutzt. Gruppen-Quota werden mit dem Kommando edquota -g gruppe gesetzt. Nun können die Grenzwerte für „soft“ und „hard“ sowie für die Inodes gesetzt werden.
Zugriffsrechte von Logdateien
Einige Logdateien sind nach der Installation nicht perfekt. Zunächst ist es nicht notwendig, dass die Dateien /var/log/lastlog und /var/log/faillog von jedem Benutzer gelesen werden können. In der Datei lastlog sind Benutzer verzeichnet, die sich in der letzten Zeit am System angemeldet haben; in der Datei faillog finden sich fehlgeschlagene Loginversuche.
Bei beiden Dateien sollten die Zugriffsrechte auf 660 verändert werden. Prüfen Sie genau, ob Logdateien mit unnötigen Zugriffsrechten versehen sind. Meist sind Lese- und Schreibrechte für den Administrator und für die Gruppe adm oder root ausreichend.
setuid-Überprüfungen
Debian wird mit einem täglichen Cronjob installiert, der in /etc/cron.daily/standard zu finden ist. Der Aufruf von /usr/sbin/checksecurity fährt eine Überprüfung des Systems auf Änderungen des Flags setuid an allen Dateien auf dem System durch.
Um diese Überprüfung zu aktivieren, muss die Variable CHECKSECURITY_DISABLE in der Datei /etc/checksecurity.conf auf FALSE gesetzt sein. Dies ist auch die Voreinstellung, so dass hier eigentlich keine Änderungen erforderlich sind.
Kommandos chattr und lsattr
Diese beiden Kommandos sind auf einem ext2-Dateisystem sehr sinnvoll. Die Attribute einer Datei können mit lsattr angezeigt und mit chattr verändert werden. Attribute unterscheiden sich von Zugriffsrechten! Es gibt viele verschiedene Attribute, hier werden nur die sicherheitsrelevanten aufgeführt. Zwei Attribute können nur vom Administrator gesetzt werden.
Zunächst wäre das „a“-Flag zu nennen. Wenn dieses Attribut gesetzt ist, können an die entsprechende Datei nur Daten angehängt (append) werden. Dieses Attribut kann auf einige Dateien in /var/log/ angewendet werden; beachten Sie jedoch, dass einige Dateien von Zeit zu Zeit „rotiert“ werden (unter „rotieren“ versteht man das tägliche Umkopieren und von Logdateien. Dabei werden Dateien vom Vortag komprimiert. Nach einer bestimmten Zeit, meist eine Woche, werden ältere Dateien gelöscht).
Das zweite wichtige Flag ist „i“, das für „immutable“ steht. Wenn dieses Flag gesetzt wird, kann eine Datei weder verändert noch gelöscht oder umbenannt werden. Auch kann kein Link auf diese Datei erzeugt werden. Wenn Benutzern die Einsicht in Logdateien verwehrt werden soll, so können Sie dieses Flag setzen und die Leserechte entfernen. Dies bietet auch eine etwas höhere Sicherheit gegen Eindringlinge, da diese sich sicher darüber wundern, dass die Datei nicht gelöscht werden kann. Trotzdem sollten Sie sich nicht darauf verlassen, dass ein Eindringling diese Funktion nicht kennt. In jedem Fall ist es ihm zu diesem Zeitpunkt bereits gelungen, in das System einzudringen ...
Integrität des Dateisystems
Sind Sie sicher, dass die auf einem bereits seit Wochen oder Monaten ans Internet angeschlossenen System installierten Programme noch die ursprünglichen sind? Oder kann es sein, dass bereits das Programm /bin/login durch eine veränderte Variante ersetzt wurde, die einen unbemerkten Login als Administrator erlaubt ...?
Die einzige Methode, ein System gegen solche Veränderungen zu schützen, ist, die installierten Dateien täglich, wöchentlich oder beispielsweise monatlich (je häufiger dieser Test durchgeführt wird, umso weniger Zeit bleibt einem Eindringling, auf dem System zu agieren) mittels einer Checksumme zu dokumentieren und diese mit vorab gespeicherten Werten zu vergleichen.
Pakete, die einen regelmäßigen Check der installierten Pakete ermöglichen, sind: sXid, AIDE (Advanced Intrusion Detection Environment) und Tripwire (die aktuelle Version befindet sich im Bereich non-free, eine der nächsten Versionen wird unter der GPL stehen).
Mit dem Paket debsums können alle MD5-Checksummen der installierten Pakete mit den Original-Checksummen der Dateien in den Ursprungspaketen der Distribution verglichen werden.
Mittels debsums -a können die Checksummen aller Pakete des Systems verglichen werden, wogegen Sie mit debsums <paketname> die Checksummen bestimmter Pakete vergleichen. Hierbei ist zu beachten, dass es einem versierten Eindringling durchaus möglich ist, auch diese Kontrolle der Checksummen zu beeinflussen. Die ursprünglichen Checksummen der Pakete liegen in den Dateien /var/lib/dpkg/info/<paketname>.md5sums und können vom Angreifer auch angepasst werden. Eine höhere Sicherheit bietet das Paket Tripwire.
Die Programme locate und slocate
Um die Sicherheit des Programms locate zu erhöhen, kann alternativ das Programm slocate verwendet werden. slocate ist eine verbesserte Version von locate aus dem GNU-Projekt.
Wenn slocate verwendet wird, werden dem Benutzer nur Dateien angezeigt, auf die dieser Benutzer auch tatsächlich Zugriff hat. Weiterhin können per Konfiguration auch Dateien und Verzeichnisse gezielt ausgeschlossen werden, so dass diese nicht von locate in der Datenbank erfasst werden.
Ausblick
Der vierte und letzte Teil unserer Artikelserie: Linux: Systemsicherheit unter Debian GNU/Linux behandelt die Themengebiete Sichere Dienste und welche Möglichkeiten Sie sonst noch haben, um das System so sicher wie möglich vor unbefugten Zugriffen abzuschotten.
Zusätzlich erläutern wir, was Sie tun müssen, wenn es bereits zu spät ist. Darüber hinaus beschäftigt sich der vierte Teil mit dem Erkennen von Rootskits und welche Auswirkungen sie auf das System haben können. (hal)