SelfLinux Sicherheit Grundlagen Sicherheit Abschnitt 4 | SelfLinux-0.13.0

| Grundlagen Sicherheit | Autoren Formatierung GFDL

#### 4 Allgemeine Schutzmaßnahmen

An dieser Stelle sollen nun ganz grundsätzliche Sicherungsmöglichkeiten aufgezeigt werden, die ohne komplexe Systemeingriffe nachvollzogen werden können. Sicherlich ist der Einsatzzweck des Rechners (Desktop-System, Mail-Server, Firewall, ...) relevant für die Auswahl geeigneter Methoden, deshalb können die hier vorgestellten Maßnahmen weder ausreichend noch vollständig sein!

#### 4.1 Absicherung des Boot-Vorgangs (System-V-Init-Process)

Zuerst sollten die physischen Zugänge (Disketten, CD-ROM, USB/Netzwerk-Boot) gesichert werden. Das kann man ganz einfach im BIOS erledigen. (Passwortschutz für das BIOS ist ebenfalls zu aktivieren!) Einziges physisches Restrisiko bleibt der Ausbau der festplatte. Damit ist man allerdings noch längst nicht am Ende...

Linux Systeme lassen sich im Single User Modus starten, indem man z.B. beim LILO-Bootmanager die Option single angibt:

lilo: linux single

Im ungünstigsten Fall benötigt man nicht einmal ein Passwort und erlangt Superuser-Rechte. Diese Schwachstelle ist folgendermaßen zu beseitigen:

- Editieren der Datei /etc/inittab

/etc/inittab

    ....
    id:3:initdefault:
    ~~:S:wait:/sbin/sulogin
    ....

- Editieren der Datei /etc/lilo.conf

/etc/lilo.conf

    ....
    prompt
    timeout=00
    default=linux
    restricted
    passwort=GEHEIM

    image=/boot/vmlinuz-2.4.20
        label=linux
    ....

- bei Auswahlmöglichkeit aus mehreren Betriebssystemen z.B. Windows, Linux den Parameter timeout auf 50 setzen
- Zugriffsrechte setzen (chmod 600 /etc/lilo.conf)
- Die neue Boot-Konfiguration aktivieren (lilo -v)
- Die /etc/lilo.conf vor Manipulation schützen (siehe Abschnitt " Erweiterte ext2-Dateiattribute")

Jetzt sollte ein Einbruch durch Ausnutzen der Schwachstellen im Boot-Prozess wesentlich schwieriger zu realisieren sein.

#### 4.2 Nicht benötigte Pakete

Die großen Distributionen SuSE und RedHat installieren standardmäßig dutzende Pakete, die zum nicht unbedingt notwendig sind und nur zusätzliche Funktionen bieten. Da sichere Systeme immer nach dem Prinzip des Minimalismus zu entwerfen sind, sollten diese Pakte deinstalliert werden. Solche Pakete sind bei RedHat z.B.

apmd, anacron, at, bc, eject, getty_ps, gd, gpm, isapnptools, kernel-pcmcia-cs, kudzu, linuxconf, mailcap, mouseconfig, mt-st, pump, pciutils, raidtools, redhat-logos, redhat-release, setserial, XFree86-SVGA

Hinweis: Natürlich beinhaltet jedes dieser Pakete sinnvolle Programme, und möglicherweise benötigen Sie sogar eines von den oben angegebenen.

#### 4.3 Nicht benötigte Benutzer und Gruppen

Die meisten Distributionen legen nicht benötigte Nutzer und Gruppen an bzw. vergessen beim Deinstallieren von Softwarepaketen (z.B. apache-http-server) das Entfernen der Einträge in den Passwortdateien.

Solche Kennungen sind zum Beispiel: adm, lp, sync, mail (bei sendmail benötigt!), ftp (bei anonymous ftp benötigt),... Folgende Gruppen sind unter Umständen obsolet: adm, lp, news, pppusers, popusers.

Man sieht, dass solche Benutzer manchmal doch benötigt werden.

#### 4.4 Differenzierter Superuser-Zugriff (root)

Die Sicherheit des root-Kennworts ist unbedingt an den Regeln im Kapitel sichere Passwörter auszurichten.

Viele Programme benötigen nicht unbedingt root-Rechte. Oftmals reicht es aus, eine privilegierte Gruppe anzulegen und mittels der Gruppenrechte den Zugriff zu ermöglichen.

Wenn zum Beispiel das Wechseln der Benutzerkennung nur für bestimmte Benutzer erlaubt werden soll, legt man eine neue Gruppe "security" an und ändert die Zugriffsrechte des Programms su.

root@linux # groupadd security root@linux # chgrp security /bin/su root@linux # chmod 4750 /bin/su

Feiner abgestimmte Restriktionen bieten Capability-Mechanismen des Kernels, die den root-Zugriff weiter einschränken.

#### 4.5 Capability Mechanismus des Kernels

Der Entzug von Capabilities (Systemfähigkeiten) erlaubt bei Systemstart bestimmte Restriktionen durchzusetzen und ermöglicht damit unter anderem eine Beschränkung der Superuser-Rechte. Nach dem Boot-Vorgang sind standardmäßig alle Capabilities gesetzt.

Der Capability Mechanismus wurde in POSIX 1003.1e und IEEE 1003.2c beschrieben und festgelegt.

Folgende Übersicht beschreibt ganz kurz einige Capabilities (Systemfähigkeiten):

CAP_LINUX_IMMUTABLE | Ändern von Dateiberechtigungen (siehe Abschnitt Erweiterte ext2-Dateiattribute)
CAP_SYS_RAWIO | direkten Zugriff auf Speichermedien (Festplatten)
CAP_SETGID | setgid setzen
CAP_SETUID | suid setzen
CAP_SYS_MODULE | Kernelmodule laden
CAP_SYS_ADMIN | mounten/unmounten und andere administrative Tätigkeiten
CAP_NET_ADMIN | Netzwerkkarten konfigurieren, Firewall administrieren, Routing administrieren

Mittels des Programmes lcap können dem System einzelne Fähigkeiten entzogen werden:

lcap CAP_LINUX_IMMUTABLE
lcap CAP_SYS_RAWIO

Nun ist es auch für root nicht mehr möglich, durch +i oder +a geschütze Dateien im ext2 Dateisystem zu löschen. (siehe Abschnitt Erweiterte ext2-Dateiattribute)

An dieser Stelle sei darauf hingeweisen, dass CAP_SYS_RAWIO unbedingt sehr frühzeitig entfernt werden sollte, da ansonsten mittels direktem Zugriff auf das /dev/kmem device der Capability Schutz umgangen werden kann.

#### 4.6 Pfadvariable PATH

Die Shell-Variable PATH beinhaltet eine Liste an Verzeichnissen, die beim Aufruf eines Programmes durchsucht werden.

user@linux $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11

Die Verzeichnisse werden mit einem Doppelpunkt getrennt. Aus Bequemlichkeit beinhaltet die Pfadvariable oftmals das aktuelle Verzeichnis. Es ist darauf zu achten, dass dieses immer am Ende steht (Bedrohung: Hackerprogramme in allgemein zugänglichen Verzeichnissen wie z.B. /tmp oder /usr/share/firmaXYZ tarnen sich als su oder passwd)

user@linux $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:.

#### 4.7 Namensauflösung

In der Datei /etc/hosts.conf wird festgelegt, WIE die Zuordnung der Namen zu IP-Adressen erfolgen soll. Das Beispiel zeigt eine relativ sichere Variante.

/etc/hosts.conf

    # Reihenfolge der Domain Namens Auflösung
    #     (vorausgesetzt DNS/BIND verfügbar)
    order hosts, bind
    # Multiple IP Adressen werden nur bei Routern benötigt
    multi off
    #Anti IP-Spoofing
    nospoof on

#### 4.8 Festlegung vertrauenswürdiger Rechner / Netzwerke

Aus Sicherheitsgründen ist von einer Benutzung der r-Dienste (z.B. rsh, rcp, rexec) unbedingt abzuraten. Demzufolge sollten auch keine .rhosts Dateien auf dem Rechner zu finden sein, dies kann man folgendermaßen überprüfen:

user@linux $ find /home -name .rhosts

Unbedingt sollte man sich mit allen Möglichkeiten von ssh vertraut machen, insbesondere mit dem Umgang von Schlüsselpaaren. Ein guter Einstieg in dieses Thema ist auf den Web Seiten des Linux-Magazins zu finden.

#### 4.9 Festlegung (nicht) benötigter Protokolle (/etc/services)

In der Datei /etc/services werden alle Dienste ihren Ports zugewiesen. Eine Manipulation kann einem Angreifer Hintertürchen öffnen und sollte deshalb unbedingt unterbunden werden (siehe Abschnitt Erweiterte ext2-Dateiattribute).

#### 4.10 Verwaiste und rechtelose Dateien

Dateien, die von jedermann beschrieben werden können, stellen ein sehr großes Sicherheitsrisiko dar. Deshalb sollten so wenig wie möglich solcher Dateien existieren (Gruppenrechte einsetzen!). Mit find lassen sich solche Dateien aufspüren und nach sorgfältiger Kontrolle kontrolliert löschen:

root@linux # find / -perm -o+w -a ! -type l -ls >/tmp/rechtlose-files

Verwaiste Dateien gehören keinem Nutzer oder keiner Benutzergruppe an. Dies deutet auf einen erfolgreichen Einbruch hin und sollte kontinuierlich untersucht werden:

root@linux # find / -nouser -o -nogroup >/tmp/verwaiste_files

#### 4.11 shadow Passwörter

Bei Verwendung der Shadow Suite werden Passwörter verschlüsselt in der Datei /etc/shadow abgelegt. Diese kann nur vom Superuser root und von der Gruppe shadow gelesen werden. Kein realer Benutzer hat also Zugang und kann die Passwörter lesen und versuchen, diese mit Hilfe eines Crack-Programmes (z.B. John the Ripper) zu entschlüsseln. Empfehlenswert ist das Abspeichern der Passwörter als MD5-Hash, da dadurch ein potentieller Angriff schwerer durchzuführen ist und längere Passwörter verwendet werden können. Weiterführende Informationen sind im Abschnitt Authentisierung, Autorisierung und Zugriffssteuerung mit PAM zu finden.

#### 4.12 Schutz der Protokolldateien (Systemlog-Files)

Eine einfache Absicherung bieten die erweiterten Dateiattribute wie beispielsweise das append-only Attribut bei ext2-Filesystemen (siehe Abschnitt Erweiterte ext2-Dateiattribute). Eine Alternative dazu besteht darin, die Logfiles auf einem dafür bestimmten Rechner zu sammeln. In diesem Zusammenhang sei auf den ssyslogd und den syslog-ng verwiesen, die zusätzlich Integrität und Verschlüsselung bieten.

#### 4.13 Bastille Linux

Diese Sammlung von Perl-Skripten erhöht die Sicherheit durch eine automatische Änderung der Konfigurationseinstellungen. Vor jeder Modifikation wird man sehr ausführlich über die Konsequenzen informiert und kann nach dem Abschätzen des Für und Wider die Änderungen akzeptieren oder auch nicht. Das System ist kostenlos und kann unter http://bastille-linux.org heruntergeladen werden. Das Ausführen sollte im Single-User Modus erfolgen:

root@linux # mv Bastille-XXX.tar.gz /root root@linux # cd /root root@linux # tar zxvpf Bastille-XXX.tar.gz root@linux # init 1 root@linux # cd /root/run-Bastille root@linux # ./Bastille1.pl

Zum Schluss noch ein Zitat, auf das mich Steffen Dettmer ( steffen@dett.de) hingewiesen hat:

> "The only secure computer system in the world is unplugged, locked in a vault at the bottom of the ocean and only one person knows the location and combination of that vault. And he is dead."
> --Bruce Schneier in "Applied Cryptography"