In einigen kleineren IT-Abteilungen wird das Thema Sicherheit trotz vieler Hinweise in den Medien auf Angriffe sehr stiefmütterlich behandelt. Die Einstellung “uns wird das schon nicht treffen” kann hier zu einem enormen Problem führen.

In diesem Artikel werden einige Punkte behandelt, die zur Absicherung eines Linux Servers berücksichtigt werden sollten.

BIOS-Passwort

Das BIOS-Passwort schützt vor Änderungen an den BIOS-Einstellungen. Wenn ein Angreifer Zugriff auf das BIOS hat, kann er es so einstellen, dass es das Betriebssystem von einer CD-ROM oder einem Flash-Laufwerk startet. Dadurch kann er in den Rettungsmodus wechseln, wo er dann beliebige Prozesse starten oder sensible Daten kopieren kann.
Das Passwort kann den Systemstart auch verhindern. Einige BIOS-Implementierungen erlauben einen Passwortschutz des Startvorgangs. Bei Aktivierung wird ein Angreifer gezwungen, ein Passwort einzugeben, bevor das BIOS den Bootloader startet.

Separate Partitionen

Red Hat empfiehlt separate Partitionen für die Verzeichnisse /, /boot, /home, /tmp und /var/tmp/ zu erstellen.

Wenn Benutzerdaten (/home) in der Root-Partition (/) statt in einer separaten Partition gespeichert werden, kann sich die Partition füllen, wodurch das Betriebssystem instabil wird. Das gleiche gilt auch für die /tmp und /var/tmp Verzeichnisse, in denen temporäre Dateien gespeichert werden, wenn sie zur Root-Partition gehören und sie von Daten überschwemmt werden.

Einschränken der Netzwerkkonnektivität während des Installationsvorgangs

Bei der Installation von Red Hat Enterprise Linux 8 repräsentiert das Installationsmedium einen Snapshot des Systems zu einem bestimmten Zeitpunkt. Aus diesem Grund ist es möglicherweise nicht auf dem neuesten Stand der Sicherheitsupdates und anfällig für Probleme, die erst behoben wurden, nachdem das vom Installationsmedium bereitgestellte System veröffentlicht wurde.

Wenn möglich, beschränken Sie den Zugriff bei der Installation nur auf die nächste notwendige Netzwerkzone. Die sicherste Wahl wäre kein Netzwerk was bedeutet, dass die Installation offline gesetzt werden sollte. In einigen Fällen reicht eine LAN- oder Intranet-Verbindung aus, während die Internetverbindung am Riskantesten ist. Im Anschluss an die Installation sollten die neuesten Patches installiert werden.

Beschränkung der Anzahl von Paketen

Mann sollte nur die Pakete installieren, die tatsächlich benötigt werden. Hintergrund dieser Forderung sind:

1. Jede Software die installiert wird kann eine Schwachstelle darstellen.
2. Mit jedem zusätzlichen Paket das installiert wird, wächst unter Umständen der Wartungsaufwand für Updates und Patch-Installationen.

Bootverzeichnis sperren

Das Boot-Verzeichnis enthält wichtige Dateien, die sich auf den Linux-Kernel beziehen. Daher sollten Sie sicherstellen, dass dieses Verzeichnis schreibgeschützt ist. Am Einfachsten geht das mit Änderung der Datei fstab.

Suchen Sie den /boot eintrag und fügen sie ",ro" für read only nach dem Wort defaults ein:

UUID=31db6b1a-6b0d-4dab-94a1-f5295fde63c4 /boot xfs defaults,ro 0 0

Zur Absicherung der fstab-Datei stellen wir nun sicher, dass nur der root-User Zugriff darauf hat:

Core-Dumps deaktivieren

Ein Core-Dump wird erstellt, wenn ein Prozess unerwartet beendet wird. Der Core-Dump enthält ein Abbild des Prozessspeichers. Damit kann man Fehler debuggen und den Status des Programms beim Beenden überprüfen. Core-Dumps können daher Informationen enthalten, die ein Angreifer ausnutzen könnte. Um zu verhindern, dass das System Core-Dumps erstellt, muss die folgende Zeile zu /etc/security/limits.conf hinzugefügt werden:

#<domain> <type> <item> <value>
hard core 0

Standardmäßig verhindert das System, dass die Programme setuid und setgid, (Programme mit geänderten Anmeldeinformationen und Programme mit Binärdateien, die keine Leseberechtigung haben) Core Dumps generieren. Um sicherzustellen, dass die Einstellung dauerhaft ist, muss auch die Datei /etc/sysctl.conf die folgenden Zeile erhalten:

Disallow core dumping by setuid and setgid programs

fs.suid_dumpable = 0

Anschließend sollte man folgenden Befehl ausführen, um das sysctl-File neu einzulesen:

Konfigurieren und Verwenden von Kernel-Sicherheitsmechanismen

Der Linux-Kernel verfügt über einige zusätzliche Sicherheitsmechanismen, die die Sicherheit eines Systems erhöhen. Diese Mechanismen randomisieren das Layout des Adressraums für einen Prozess oder verhindern, dass Code im nicht ausführbaren Speicher ausgeführt wird.

Randomisierung des Layouts des Adressraums

Address Space Layout Randomization (ASLR) kann dabei helfen, bestimmte Arten von Pufferüberlaufangriffen abzuwehren. ASLR kann die Basis, die Bibliotheken, den Heap und den Stapel an zufälligen Positionen im Adressraum eines Prozesses lokalisieren, was es einem angreifenden Programm erschwert, die Speicheradresse der nächsten Anweisung vorherzusagen. ASLR ist in den Linux-Kernel eingebaut und wird durch den Parameter /proc/sys/kernel/randomize_va_space gesteuert.

Der Parameter randomize_va_space kann die folgenden Werte annehmen:

1. 0 - ASLR deaktivieren. Diese Einstellung wird angewendet, wenn der Kernel mit dem Boot-Parameter norandmaps gebootet wird.
2. 1 - Randomisieren der Positionen des Stapels, der Seite des virtuellen dynamischen gemeinsam genutzten Objekts (VDSO) und der Bereiche des gemeinsam genutzten Speichers. Die Basisadresse des Datensegments befindet sich unmittelbar nach dem Ende des ausführbaren Codesegments.
3. 2 - Randomisieren der Positionen des Stapels, der VDSO-Seite, der gemeinsam genutzten Speicherbereiche und des Datensegments. Dies ist die empfohlene Einstellung.

Die Standard-Einstellung auf Oracle Linux ist 2, hier muss also nichts geändert werden. Zur Überprüfung kann der folgende Befehl verwendet werden, der den empfohlenen Wert 2 liefern sollte. Der Wert liefert die aktuelle, eventuell nur temporäre Einstellung des Betriebssystems.

Um den Wert permanent, also auch nach einem eventuellen Neustart einzustellen muss in der Datei /etc/sysctl.conf die folgende Zeile enthalten sein. Nach einer Änderung der Datei sysctl.conf muss diese, wie wie bereits im Kapitel zur Aktivierung von Core-Dumps dargestellt, neu eingelesen werden.

kernel.randomize_va_space = 2

Konfigurieren von kryptografischen Systemrichtlinien

Oracle Linux bietet vier verschiedene integrierte vordefinierte kryptografische Richtlinien:

• LEGACY: Aktiviert bestimmte Legacy-Protokolle, um die Kompatibilität mit Legacy-Systemen zu maximieren. Es umfasst die Aktivierung von 3DES, RC1, DSA, TLSv1.0 und TLSv1.1. Es ermöglicht auch eine minimale Parametergröße von 1024 Bit für DH und RSA. Die in dieser Richtlinie angegebenen Protokolle und Werte gelten nicht als sehr sicher, sind aber nicht leicht ausnutzbar.
• DEFAULT: Aktiviert moderne Standardprotokolle einschließlich TLSv1.2 und TLSv1.3 , IKEv2 und SSH2. Es ermöglicht eine minimale Parametergröße von 2048 Bit für DH und RSA.
• FIPS: Erfüllt die Anforderungen von FIPS 140-2 für kryptografische Richtlinien. Diese Richtlinie wird durch den Befehl fips-mode-setup aktiviert, der zum Aktivieren des FIPS-Modus auf einem Oracle Linux-System verwendet wird. Weitere Informationen zur Verwendung dieser Richtlinie finden Sie unter Konfigurieren eines Systems im FIPS-Modus.
• FUTURE: Eine konservative Richtlinienebene, die SHA-1 und CBC deaktiviert und eine minimale Parametergröße von 3072 Bit für DH und RSA zulässt. Diese Richtlinie kann die Kommunikation mit vielen älteren Systemen deaktivieren, weil diese die geforderten Mechanismen nicht kennen. Es lohnt sich jedoch zu prüfen, welche Maßnahmen Sie möglicherweise in Zukunft ergreifen müssen, um sicherzustellen, dass Ihre Anwendungen weiterhin sicher funktionieren.

Die Standard-Einstellung auf Oracle Linux ist DEFAULT, es muss also nichts geändert werden, folgendes Befehl zeigt die Einstellung:

Für mehr Sicherheit sollte man entweder FIPS oder FUTURE wählen wenn die Applikationen damit kompatibel sind. Die Einstellung kann mit den folgenden Befehl geändert werden:

OS Update

Um Software-Schwachstellen und bekannte Angriffsflächen zu vermeiden bzw. sich davor zu schützen ist die regelmäßige Aktualisierung der Systemsoftware von großer Bedeutung.

Überprüfung der installierten Pakete und Dienste

Bei einer Server-Installation werden nur die nötigsten Pakete installiert. Trotzdem sollte man die Pakete regelmäßig überprüfen und je nach Verwendungszweck des Systems löschen, was nicht nötig ist. Um die Überprüfung zu erleichtern, sollte für jeden Server genau dokumentiert werden, wofür/warum welches der installierten Pakete benötigt wird.
Eine Liste der installierten Pakete liefert folgendes Kommando:

Deinstallieren von Paketen

Das Deaktivieren der unnötigen Dienste verringert die Anzahl der Angriffsflächen.

Liste der Dienste:

Die folgenden Legacy-Dienste sollten nach vorheriger Überprüfung der Erfordernis für Ihre Applikationen entfernt werden. Werden sie noch benötigt, so sollten die entsprechenden Applikationen zuvor aktualisiert werden, sodass sie diese Dienste nicht mehr benötigen:

• Telnet-Server
• RSH-Server
• NIS-Server
• TFTP-Server
• TALK-Server

Deaktivieren des automatischen Fehlerberichtstools (Automatic Bug Reporting Tool)

Netzwerkkonfiguration und Firewall einschalten

Man darf nicht davon ausgehen, dass sich die Firewall um alles kümmert. Hier sind einige wichtige Funktionen, die für die Sicherung des Host-Netzwerks berücksichtigt werden sollten:

Folgende Parameter hinzufügen:

IP-Weiterleitung deaktivieren

net.ipv4.ip_forward = 0

Send Packet Redirects deaktivieren

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

Annahme von ICMP-Umleitungen deaktivieren

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

Schutz vor fehlerhaften Fehlermeldungen aktivieren

net.ipv4.icmp_ignore_bogus_error_responses = 1

Anschließend sollte man noch benötigte Ports freischalten. Der folgende Codeblock zeigt ein Beispiel für einen Server auf dem eine Oracle Datenbank betrieben wird und auf dem eine Secure-Shell Verbindung benötigt wird:

Um die Sicherheit - geringfügig - zu erhöhen, können im angenommenen Fall (Oracle DB und SSH) die Standard-Ports 1521 bzw. 22 geändert werden.

SSH sichern

Die Secure Shell (SSH) ermöglicht eine geschützte, verschlüsselte Kommunikation mit anderen Systemen. Da SSH ein Einstiegspunkt in das System ist, sollte man es deaktivieren wenn es nicht benötigt wird. Alternativ kann die Datei /etc/ssh/sshd_config bearbeitet werden, um seine Verwendung einzuschränken.

Um den SSH-Zugriff weiter einzuschränken kann man den Zugriff auf den Root-Benutzer sowie den Fernzugriff auf bestimmte Benutzer und Gruppen beschränken - oder so konfigurieren, dass der SSH-Client nach einer bestimmten Zeit der Inaktivität automatisch abläuft. Die Änderungen werden in der Datei /etc/ssh/sshd_config durchgeführt.

Folgende Parameter sollten bei einer Absicherung in Betracht genommen werden:

Root login durch ssh verweigern:
PermitRootLogin no

Nur ein admin account kann sich anmelden:
AllowUsers mdfadmin

Das neueste SSH Protokoll ist SSH2 auf den neuesten Linux Distributionen ist es standardmäßig schon eingestellt:
Protocol 2

Der Parameter IgnoreRhosts gibt an, dass .rhosts- und .shosts-Dateien nicht in RhostsRSAAuthentication oder HostbasedAuthentication verwendet werden, damit der Benutzer gezwungen ist ein Passwort einzugeben:
IgnoreRhosts yes

Es wird nicht empfohlen, dass Hosts einander einseitig vertrauen, nicht einmal innerhalb einer Organisation. Andernfalls könnte bei einem erfolgreichen Angriff auf einen unsicheren Server auch sicherer Server angegriffen werden:
HostbasedAuthentication no

Leere Passwörter verweigern:
PermitEmptyPasswords no

Es besteht ein geringes Risiko, dass die Benutzer, die sich über SSH mit X11-Weiterleitung an den entfernten X11-Servern angemeldet haben, von anderen Benutzern, die am X11-Server angemeldet sind, kompromittiert werden. Es wird empfohlen, die X11-Weiterleitung zu deaktivieren, es sei denn, es besteht eine betriebliche Anforderung:
X11Forwarding no

Maximale Anzahl von Authentifizierungsversuchen
MaxAuthTries 6

Anzahl Sekunden, die der Server wartet, bevor er ein Nullpaket an den Client sendet (um die Verbindung am Leben zu erhalten):
ClientAliveInterval 0

Anzahl der Client-Alive-Nachrichten, die gesendet werden können, ohne dass sshd Nachrichten vom Client zurückerhält:
ClientAliveCountMax 3

Es ist gängige Praxis, auch die passwortbasierte Authentifizierung für SSH zu deaktivieren und stattdessen die Authentifizierung mit öffentlichem Schlüssel zu verlangen. Auf diese Weise können Sie den Zugriff auf Benutzer beschränken, die einen privaten Schlüssel besitzen:
PasswordAuthentication no

Nachdem Sie Änderungen an der Konfigurationsdatei vorgenommen haben, müssen Sie den sshd-Dienst neu starten, damit die Änderungen wirksam werden.

Aktivieren von SELinux

Auf Oracle Linux ist SELinux standardmäßig aktiviert.

Herkömmliche Linux-Sicherheit basiert auf einer Discretionary Access Control (DAC)-Richtlinie, die minimalen Schutz vor fehlerhafter Software oder Malware bietet, die als normaler Benutzer oder als Root ausgeführt wird. Der Zugriff auf Dateien und Geräte basiert ausschließlich auf der Identität und dem Eigentum des Benutzers. Malware oder defekte Software kann mit Dateien und Ressourcen alles tun, was der Benutzer tun kann, der den Prozess gestartet hat. Wenn der Benutzer root ist oder die Anwendung mit setuid oder setgid auf root gesetzt ist, kann der Prozess Root-Zugriffskontrolle über das gesamte Dateisystem haben.

Deshalb wurde von der National Security Agency das Security Enhanced Linux (SELinux) entwickelt, um eine feinere Kontrolle über Dateien, Prozesse, Benutzer und Anwendungen im Linux-Betriebssystem zu ermöglichen. Die SELinux-Erweiterung des Linux-Kernels implementiert die Mandatory Access Control (MAC)-Richtlinie, mit der Sie eine Sicherheitsrichtlinie definieren können, die granulare Berechtigungen für alle Benutzer, Programme, Prozesse, Dateien und Geräte bereitstellt.
Die Zugriffssteuerungsentscheidungen des Kernels basieren auf allen verfügbaren sicherheitsrelevanten Informationen und nicht nur auf der authentifizierten Benutzeridentität.

Bei sicherheitsrelevanten Zugriffen, etwa wenn ein Prozess versucht, eine Datei zu öffnen, fängt SELinux die Operation im Kernel ab. Wenn eine MAC-Richtlinienregel die Operation zulässt, wird sie fortgesetzt. Andernfalls blockiert SELinux die Operation und gibt einen Fehler an den Prozess zurück. Der Kernel prüft und erzwingt DAC-Richtlinienregeln vor MAC-Regeln, sodass er SELinux-Richtlinienregeln nicht überprüft, wenn DAC-Regeln bereits den Zugriff auf eine Ressource verweigert haben.

SELinux konfigurieren:

Security-Enhanced Linux prüft die Berechtigungen und Zugänge der Applikationen zu Dateien, “permissive” loggt nur, “enforcing” erzwingt die Regeln.

Das heißt enforcing sorgt für mehr Sicherheit aber für eine Oracle Umgebung sollte man Permissive auswählen. Obwohl Oracle Linux standard mäßig mit SELINUX im Enforcing Modus installiert wird, kann es aber auch verhindern, dass Oracle ausgeführt wird, oder nicht ordnungsgemäß gestartet wird.

Als Workaround kann man statt Enforcing Permissive wählen.

Passwortrichtlinien verwalten

Menschen verwenden ihre Passwörter oft wieder, was eine schlechte Sicherheitspraxis ist. Die alten Passwörter werden in der Datei /etc/security/opasswd gespeichert.

Zwei Zeilen müssen zu der Datei /etc/pam.d/common-password zugefügt werden, um zu verhindern dass die Benutzer ihre letzten vier Passwörter wiederverwenden:

auth sufficient pam_unix.so likeauth nullok
password sufficient pam_unix.so remember=4

Starke Kennwörter

Das PAM-Modul bietet eine pam_cracklib, die den Server vor Wörterbuch- und Brute-Force-Angriffen schützt. Folgende Zeile muss zu der Datei /etc/pam.d/system-auth hinzugefügt werden.

Die Parameter sind:

• retry - wie der Name schon sagt für die Anzahl der Versuche,
• minlen - die Minimale Passwortlänge,
• lcredit - Großbuchstaben
• ucredit - Kleinbuchstaben
• dcredit - Nummer
• ocredit - Sonderzeichen

Das Setzen dieser Parameter auf eine negative Zahl bedeutet, dass man einige dieser Zeichentypen im Passwort haben muss, damit es akzeptabel ist. Zum Beispiel lcredit=-1 bedeutet man muss mindestens eine Großbuchstabe angeben.

/lib/security/$ISA/pam_cracklib.so retry=3 minlen=20 lcredit=-1 ucredit=-2 dcredit=-2 ocredit=-1

Das Passwort wird von Linux gehasht, um zu vermeiden, dass es im Klartext gespeichert wird.

Sperren des Kontos nach Fehlversuchen

Parameter, die das Verhalten nach Fehllogins steuern, werden in der Datei /etc/pam.d/password-auth spezifiziert. Hier kann beispielsweise eingestellt werden, dass

1. der Login nach fünf Fehlversuchen gesperrt wird
2. die durch Fehllogins verursachte Sperre nach x Sekunden wieder freigegeben wird
3. Weitere Parameter und Beispiel Dateie kann man auf RedHats Seite für PAM finden

Hierzu können die folgenden Zeilen verwendet werden:

auth required pam_env.so
auth required pam_faillock.so preauth audit silent deny=5 unlock_time=600
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=600
auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=600
auth required pam_deny.so

vi /etc/pam.d/system-auth

Folgende Zeilen hinzufügen:

auth required pam_env.so
auth required pam_faillock.so preauth audit silent deny=5 unlock_time=604800
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=604800
auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=604800
auth required pam_deny.so

Nach fünf fehlgeschlagenen Versuchen kann nur ein Administrator das Konto mit dem folgenden Befehl entsperren:

Ablauf der Kennwörter

Das BSI (Bundesamt für Sicherheit in der Informationstechnik) rät schon seit längerer Zeit vom regelmäßigen Ändern von Passwörtern ab. Bei ausreichender Komplexität und Sperren nach Fehlversuchen mit Wartezeiten im Bereich einiger Minuten, sind die Passwörter vor Brute-Force Angriffen sicher.

Passwörter die besonders oft gewechselt werden müssen werden auch besonders oft irgendwo aufgeschrieben oder evtl. vergessen.

Parameter PASS_MAX_DAYS ist standardmäßig auf 99999 gestellt. Wenn man trotzdem den Ablauf ändern möchte, kann man diesen Wert kleiner nehmen.

Zugriff auf den su-Befehl einschränken

Pam_Wheel Parameter ändern:

auth required pam_wheel.so use_uid

Berechtigungen und Überprüfung

Änderung der User/Group Besitzer und Berechtigungen auf /etc/anacrontab, /etc/crontab und /etc/cron.

Cron und Anacron werden verwendet, um Befehle regelmäßig mit angegebenen Häufigkeit auszuführen. Im Gegensatz zu Cron geht Anacron nicht davon aus, dass die Maschine kontinuierlich läuft. Daher kann es auf Maschinen verwendet werden, die nicht 24 Stunden am Tag laufen, um regelmäßige Jobs als tägliche, wöchentliche und monatliche Jobs zu steuern.

Cron und Anacron verwenden eine Reihe von Konfigurationen und Verzeichnissen. Die System-Crontabs dürfen nur von root bearbeitet werden und Benutzer-Crontabs werden mit dem Befehl setuid root crontab bearbeitet. Wenn nicht privilegierte Benutzer die Systemkonfiguration ändern können, können sie möglicherweise erhöhte Berechtigungen erhalten, daher sollte jeder unnötige Zugriff auf diese Dateien deaktiviert werden.

Berechtigungen für “/var/spool/cron” und “root crontab”

Berechtigungen und Besitzer für die passwd-, group-, shadow- und gshadow-Datei ändern

Scannen des Systems auf Schwachstellen

Mit oscap können Sie das System scannen, den Inhalt der Konfigurationskonformität validieren und basierend auf diesen Scans, Security-Berichte erstellen. Zum Ausführen wird das Paket openscap-scanner und bzip2 gebraucht, diese sind standardmäßig mit Oracle Linux installiert.

Das Securityassessment von Openscap wird hier detailiert mit Beispielen beschrieben und wie man den Report evaluieren kann:

Vulnerability Assessment

Herunterladen der neuesten OVAL-Definitionen für Ihr System:

Ausführung der Evaluierung:

Installation von AIDE

Advanced Intrusion Detection Environment (AIDE) ist eine Anwendung, welche Änderungen an bestimmten Dateien erkennt, darüber berichtet und dabei hilft nicht autorisierte Änderungen und potenzielle rootkits zu erkennen.

AIDE speichert seine aktuellen Informationen über den Konfigurationsstatus eines Systems in einer Datenbank, die sich unter /var/lib/aide/aide.db befindet. Idealerweise sollten Sie eine Kopie dieser Datenbankdatei an einem externen Ort speichern, damit Sie sie durch einen bekannten sicheren Zustand ersetzen können, wenn Sie ein Audit durchführen möchten. Wenn die Datei noch nicht existiert, können Sie eine für den aktuellen Systemzustand erstellen, indem Sie Folgendes ausführen:

Nachdem Sie eine Datenbank erstellt haben, können Sie die Dateiintegrität jederzeit überprüfen, indem Sie Folgendes ausführen:

Wenn alles OK ist, sollte AIDE folgendes zurückgeben:

Start timestamp: 2023-02-21 16:29:42 +0100 (AIDE 0.16)
AIDE found NO differences between database and filesystem. Looks okay!!

Fazit

In diesem Artikel haben wir Ihnen ausführlich einige Möglichkeiten zur Absicherung Ihrer Linux Server aufgeschlüsselt und näher gebracht. Gerne stehen Ihnen unsere Linux Experten gerne zur Seite und helfen Ihnen bei Ihrer individuellen Absicherung Ihrer Umgebung.
Vereinbaren Sie gerne ein unverbindliches Gespräch mit uns per Kontaktformular, um alle Möglichkeiten zu evaluieren.

Wir freuen uns von Ihnen zu hören!