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.
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.
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.
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.
Mann sollte nur die Pakete installieren, die tatsächlich benötigt werden. Hintergrund dieser Forderung sind:
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.
vi /etc/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:
Als professioneller SQL Server Support und zertifizierter Microsoft Partner unterstützen wir Sie in allen Fragen und individuellen Problemen rund um Ihre Serverumgebung, egal ob vor Ort oder remote. Überzeugen Sie sich selbst von unserem vielfältigen Angebot und den individuellen Leistungspaketen.
chown root:root /etc/fstab
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:
vi /etc/sysctl.conf
#<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:
vi /etc/sysctl.conf
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:
sysctl -p
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.
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:
0 - ASLR deaktivieren. Diese Einstellung wird angewendet, wenn der Kernel mit dem Boot-Parameter norandmaps gebootet wird.
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.
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.
cat /proc/sys/kernel/randomize_va_space
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
Oracle Linux bietet vier verschiedene integrierte vordefinierte kryptografische Richtlinien:
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.Die Standard-Einstellung auf Oracle Linux ist DEFAULT, es muss also nichts geändert werden, folgendes Befehl zeigt die Einstellung:
$ update-crypto-policies --show
STANDARD
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:
$ update-crypto-policies --set FUTURE
Setting system policy to FUTURE
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.
dnf -y update
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:
dnf list --installed
Deinstallieren von Paketen
dnf remove <Paketname>
Das Deaktivieren der unnötigen Dienste verringert die Anzahl der Angriffsflächen.
Liste der Dienste:
systemctl list-units | grep service
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:
Deaktivieren des automatischen Fehlerberichtstools (Automatic Bug Reporting Tool)
sudo systemctl disable --now abrtd
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:
vi /etc/sysctl.conf
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 = 0Annahme von ICMP-Umleitungen deaktivieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0Schutz 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:
firewall-cmd --permanent --add-port=<SSH-Port>/tcp
firewall-cmd --permanent --add-port=<Listener-Port>/tcp
systemctl stop firewalld
systemctl start firewalld
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.
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.
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.
sed -i s/SELINUX=enforcing/SELNUX=permissive/g /etc/selinux/config
setenforce Permissive
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:
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
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:
/usr/sbin/faillock --user <userlocked> --reset
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.
vi /etc/login.defs
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
vi /etc/pam.d/su
Pam_Wheel Parameter ändern:
auth required pam_wheel.so use_uid
Ä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.
chown root:root /etc/anacrontab
chmod og-rwx /etc/anacrontab
chown root:root /etc/crontab
chmod og-rwx /etc/crontab
chown root:root /etc/cron.hourly
chmod og-rwx /etc/cron.hourly
chown root:root /etc/cron.daily
chmod og-rwx /etc/cron.daily
chown root:root /etc/cron.weekly
chmod og-rwx /etc/cron.weekly
chown root:root /etc/cron.monthly
chmod og-rwx /etc/cron.monthly
chown root:root /etc/cron.d
chmod og-rwx /etc/cron.d
Berechtigungen für “/var/spool/cron
” und “root crontab
”
chown root:root <crontabfile>
chmod og-rwx <crontabfile>
Berechtigungen und Besitzer für die passwd-
, group-
, shadow-
und gshadow-Datei
ändern
chmod 644 /etc/passwd
chown root:root /etc/passwd
chmod 644 /etc/group
chown root:root /etc/group
chmod 600 /etc/shadow
chown root:root /etc/shadow
chmod 600 /etc/gshadow
chown root:root /etc/gshadow
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:
Herunterladen der neuesten OVAL-Definitionen für Ihr System:
wget -O - wget https://linux.oracle.com/security/oval/com.oracle.elsa-ol8.xml.bz2 | bzip2 --decompress > ol-8.oval.xml
Ausführung der Evaluierung:
oscap oval eval --report vulnerability.html rhel-8.oval.xml
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.
#Installation
dnf -y install aide
# Aktivieren
aide --init
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:
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Nachdem Sie eine Datenbank erstellt haben, können Sie die Dateiintegrität jederzeit überprüfen, indem Sie Folgendes ausführen:
aide --check
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!!
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!
Kontaktieren Sie uns gerne über das
Kontaktformular und vereinbaren ein unverbindliches
Beratungsgespräch mit unseren Berater:innen zur
Bedarfsevaluierung. Gemeinsam optimieren wir Ihre
Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!