Bis jetzt ist unser Server recht sicher. Es läuft nur ein Dienst, alle anderen Ports sind durch die Firewall blockiert. In Zukunft sollen da aber ein paar Dienste mehr drauf, und es soll auch mehr Nutzer als nur mich selbst geben. Ein paar vorbereitende Sicherheitsmaßnahmen können sofort getroffen werden.
Automatische Updates
Einerseits sind Updates wichtig. Jederzeit können neue Sicherheitslücken entdeckt werden, und gelegentlich werden sehr schnell Fixes für die Software entwickelt, veröffentlicht und sogar in die benutzte Distribution übernommen. Da könnte man auf die Idee kommen, mehrfach am Tag automatisch auf Updates zu prüfen und die dann einzuspielen.
Heute scheint dieser Gedanke nicht mehr ganz so idiotisch zu sein wie damals früher. Opa erzählt euch jetzt mal ausm Krieg: Meine erste Distribution war SuSE, dann kam Debian, und jedesmal bei einem Versionswechsel hat der Update-Mechanismus das System zerschossen. Paket A v2 verlangt Paket B v3, aber Paket B v3 verlangt Paket A v1. Solche Dinge. Schlecht umgesetzt, noch schlechter getestet. Chaos pur. Versionswechsel ging eigentlich nur, wenn man komplett neu installiert hat, was sorgfältige Backups und viel Zeit vorausgesetzt hat. Gelegentlich reichte auch ein Update eines einzigen Pakets aus, um diesen Effekt zu bewirken. Updates waren nur möglich, wenn man drei Tage Urlaub hatte. Automatische Updates? Rechner ausschalten war einfacher. Ok, das ist besser geworden. Kostenlose Distributionen beteiligen die Community an den Tests, die sich aus Eigeninteresse gerne als unbezahlte Tester einspannen lässt. Kostenpflichtige Distributionen haben den Begriff „Schadenersatz“ kennengelernt. Updates sind erstaunlich schmerzfrei, selbst bei größeren Versionssprüngen. Aber automatische, unbeaufsichtigte Updates? Dafür waren die Schmerzen in der Vergangenheit zu stark.
Inzwischen gibt es einen Kompromiss. Das Ubuntu-Paket unattended-upgrades installiert nur Updates aus bestimmten Quellen. Das Programm ist umfangreich konfigurierbar. Unter anderem kann eMail-Benachrichtigung eingestellt werden. Nicht mehr benötigte Pakete können automatisch entfernt werden. Wird ein Reboot nötig, kann man zwischen automatischen Neustart (bei Servern nicht zu empfehlen) und Anlage des Files /var/run/reboot-required, das von Nagios o.ä. überwacht werden kann.
unattended-upgrade wird über den standardmäßigen apt-Cronjob ausgeführt, der in /etc/cron.daily/apt-compat liegt und einmal täglich ausgeführt wird.
Passwortsicherheit, Logins
Absichern gegen äußere Angriffe schön und gut. Irgendwann möchte ich nicht nur virtuellen Usern Webspace und eMail bieten, sondern einigen, wenigen, ausgewählten, vertrauenswürdigen Usern einen echten Linux-Account mit SSH-Login und einer bash geben. Und damit habe ich mir den Feind ins Haus geholt. Nicht alle diese User haben Admin-Kenntnisse oder auch nur das Bewusstsein für Sicherheitsfragen, und Systemabschüsse können auch schon mal ganz ohne bösen Willen durch Tippfehler entstehen.
Die klassische usergenerierte Sicherheitslücke: Unsicheres Passwort. Google will wissen, dass 2021 das beliebteste Passwort 123456 war. Linux lässt solche Passwörter zu. Das kann man abstellen mit dem Paket libpam-pwquality. Es erlaubt, dem User bestimmte Mindestanforderungen an sein Passwort durch Parameter in /etc/pam.d/common-password vorzuschreiben. Zu den gut dokumentierten Möglichkeiten zählt u.a. eine Mindestlänge, Zusammensetzung aus Klein- und Großbuchstaben, Ziffern und Sonderzeichen und ein Check gegen das cracklib-Wörterbuch. Die Empfehlung des BSI, Passwörter regelmäßig zu wechseln (und auch Gültigkeitsdauern festzulegen), wurde 2020 abgeschafft, wobei jeder selbst entscheiden muss, was Empfehlungen des BSI wert sind. Usern empfehle ich einen Passwortmanager wie KeePass, der nicht cloud-basiert ist: Einer der Hauptkonkurrenten mit Cloud-Nutzung machte neulich Schlagzeilen, weil manche Passwörter mancher Nutzer für jeden offen zugreifbar waren.
In einem Mehrbenutzersystem ist es wichtig, dass eine Rechteverwaltung festlegt, welcher Nutzer was mit welcher Datei oder welchem Verzeichnis machen darf. Linux bringt in den standardmäßigen ext-Dateisystemen eine gute Verwaltung mit: Jedes File gehört einem User und einer Gruppe; die Rechte Lesen, Schreiben und Ausführen (für Verzeichnisse: Hineinwechseln) werden jeweils für den User, die Gruppe und alle Anderen (other) festgelegt. Standardmäßig werden jedem alle Rechte gewährt; mit einer umask können Rechte abgeschaltet werden. In /etc/login.defs wird die umask für neu anzulegende Home-Verzeichnisse mit 022 definiert, also ohne Schreib-, aber mit Lese- und Ausführungszugriff für Gruppe und andere. Das ist zu unsicher. Die Gruppe des Homeverzeichnisses ist i.d.R. die Standardgruppe des Users, in der er das einzige Mitglied ist, das ist unkritisch. Alle anderen haben aber im Home-Verzeichnis genau gar nichts zu suchen, daher sollte die umask 027 sein. Bereits angelegte Home-Verzeichnisse (/root, /home/*) sollten mit chmod o-rwx -R name angepasst Für alle anderen Dateien und Verzeichnisse kann eine umask vorgegeben werden. Der ideale Ort dafür ist /etc/profile bzw. eine eigene Datei in /etc/profile.d/. Ein User, der weiß, was er tut, kann in ~/.profile eine eigene umask setzen.
AppArmor
AppArmor ist ein Sicherheits-Framework, das in den Ubuntu-Kernel einkompiliert ist. Viele Pakete bringen ihr apparmor-Profil mit, händisches Nacharbeiten ist selten nötig. Mit AppArmor können Zugriffsrechte von Programmen filigraner verteilt werden als mit dem klassischen Linux-System. So kann verhindert werden, dass z.B. ein Webserver-Prozess, der in fremde Hände fällt, auf Verzeichnisse zugreifen kann, die nicht Webseiten enthalten. Wenig Arbeit, großer Nutzen.
Auditing
Eine ganze Menge weiterer Sicherheitsverbesserungen sind möglich, die aufzulisten den Rahmen einer Webseite sprengen würden. Ich habe das Audit-Tool lynis kennengelernt, das ein bestehendes System sehr gründlich analysiert und Verbesserungsvorschläge macht. Die sollte man allerdings mit Vorsicht genießen. Für manche „unsicheren“ Dinge hat man sich entschieden, um das System benutzbar zu halten. Andere Dinge werden kontrovers diskutiert; so ist der Nutzen des von lynis empfohlenen Einsatzes von malware scannern AKA Anti-Virus-Programmen nicht nachgewiesen, es gibt aber Hinweise, dass sich dadurch neue Angriffswege eröffnen. Es bleibt also auch hier der eigene Verstand und das eigene Wissen gefragt, die Nutzenabwägung muss immer auch aufgrund des konkreten Einsatzes des Rechners erfolgen. Solange ich nur SSH laufen habe, brauche ich keinen Virenscanner. Betreibe ich aber einen Mailserver, sind die User möglicherweise froh über einen clamavd, der ihnen die Arbeit abnimmt, einkommende Mails selbst zu scannen.