Vielen Untersuchungen und Aufrufen kompetentem Personals zum Trotz geht seit Jahren das Gespenst der regelmäßigen Passwortänderungen in der IT-Welt herum. Millionen von Usern werden dank einer vor Jahrzehnten kurzzeitig herausgegebenen und inzwischen zurückgezogenen Empfehlung der US-Amerikanischen IT-Standardisierungsbehörde NIST (Vergleichbar mit einer Fußion aus PTB und BSI) regelmäßig vollkommen unnötig dazu genötigt, ihre Passwörter zu ändern. Für User, die einen Passwortmanager verwenden ist es einfach eine nervige Angelegenheit, die Anwender ohne Passwortmanager werden dadurch regelrecht zur Unsicherheit gedrängt, Passwörter entweder nach leicht zu merkenden Mustern zu wählen oder diese irgendwo aufzuschreiben.
Aufgrund all der Nachteile wurde die Empfehlung auch schon länger zurückgezogen, aber in Unternehmen gibt es ja leider immer die eine Etage, in der technisches Know-how leider Mangelware ist. Dies wird dann meist mit einem umso größeren Willen zur Entscheidung kompensiert und diese Praxis wird mit allen Mitteln am Leben erhalten. Daher sah sich das NIST wohl nun gezwungen, die Richtlinie explizit umzukehren und einen Passwortwechsel zu untersagen:
Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Mit anderen Worten: Eine Passwortänderung soll nicht erzwungen werden, es sei denn, es besteht der begründete Verdacht auf eine Kompromittierung.
Dies sollte in Diskussionen um die Abschaffung einer solchen Richtlinie einen guten Hebel liefern, dieses alte Relikt endlich ad Acta legen zu können.
Dies ist der erste Beitrag einer Blogreihe über meine Infrastruktur, die ich nutze, um so unabhängig wie möglich selbst zu hosten. Den Anfang möchte ich mit einem kleinen Beitrag über meine Server machen, da diese natürlich das Gerüst für alles Weitere bereitstellen. Für sich selbst genommen ist dieser Beitrag vermutlich nicht ganz so spannend, aber im Laufe der Serie wird natürlich immer mal wieder auf die Server verwiesen, daher dachte ich, eine kleine Vorstellung könne nicht schaden.
Seit meinem Einstieg in die Webhosting-Welt mittels eines kleinen Pakets bei dem 2016 eingestellten Hoster DomainGo habe ich viele Dienste probiert und Hardwareiterationen hinter mir. Inzwischen bin ich bei einem Setup angekommen, mit dem ich sehr zufrieden bin.
Domain-Registrar
Meine Domains habe ich inzwischen alle bei INWX, einem Dienstleister, der sich auf Domains spezialisiert hat. Es werden auch einige Hosting-Pakete angeboten, zu denen kann ich aber nichts sagen. Preislich bin ich sehr zufrieden, pro .de-Domain fallen jährlich 4,65 € an. Die Auswahl an TLDs ist auch beachtlich, Stand heute gibt es 2226 verschiedene zur Auswahl! >
INWX selbst bietet eigentlich alles, was man braucht, inklusive einer API, um alle Änderungen an Domains auch automatisiert durchführen zu können.
Virtueller privater Server
Als zentrales Standbein der Infrastruktur außerhalb meines privaten Netzwerkes nutze ich einen VPS bei Netcup. Netcup bietet neben einer großen Paketauswahl mit wirklich kleinen Preisen die Möglichkeit, ein Betriebssystem eigener Wahl aus einem hochgeladenen ISO auf dem eigenen Server zu installieren, so das man nicht von einer meist kleinen Distributionsliste abhängig ist und auch wechsel zwischen Distributionen oder gar Betriebssystemen einfach jederzeit selbst durchführen kann. Selbst Windows wäre möglich, um die Lizenz müsste man sich hier jedoch selbst kümmern. Ich nutze aktuell ein VPS 3000 aus der 9. Generation, hier habe ich 600 GB SSD-Festplattenspeicherplatz, 24 GB RAM und eine 6-Core-CPU. Leistungstechnisch hatte ich hier noch nie Probleme. Sollte ich in Zukunft das Paket wechseln wäre ggf. auch die neue ARM-Linie interessant - als ich das Paket buchte gab es diese noch nicht.
Angefangen mit einem Raspberry Pi hat sich mein Setup über ein Intel-Atom-Board zu einem Supermicro Server mit einem Intel Xeon E3-1515M v5, 64 GB RAM, einer 500 GB NVM Platte für System und Datenbanken. Zur Datenablage ist noch ein RAID 6 mit einer Nettokapazität von 8.2 TB verbaut.
Hier laufen die meisten Dienste und für Familienmitglieder gibt es Shares.
Als Betriebssystem kommt auch hier ArchLinux1 zum Einsatz.
Sicherungsspeicher
Die wichtigsten Daten auf den Servern werden auf dem jeweils anderen synchronisiert, bei 8.2 TB kann ich aber natürlich nicht alles irgendwo in die Cloud speichern, daher habe ich noch ein NAS mit knapp 10 TB Nettokapazität, auf das der Homeserver regelmäßig gesichert wird.
Fußnoten
Ich möchte an dieser Stelle keine Diskussion um das Für und Wider von Rolling-Release Distributionen starten, aber ich betreibe persönlich mehrere Systeme und hatte noch nie die angeblich dauernd auftretenden Probleme damit - dafür habe ich aber ein immer aktuelles System. ↩︎↩︎
wenn Paketsignaturen nicht validiert werden können
Tokk 131 Wörter ~1 Min.
Privat nutze ich auf meinem Laptop Arch Linux. Derzeit ist der Laptop allerdings nicht viel in Verwendung, da ich mich meist an den PC setze um zu arbeiten. Dies führt dazu, das Systemupdates, derer es bei einer Rolling-Release-Distribution ja nicht gereade wenige gibt, ein wenig mehr hinterherhängen als sie eigentlich sollten. Dies kann dann dazu führen, dass beim Update folgende Fehlermeldungen erscheinen:
Fehler: <Paketname>: signature from "Mr. Maintainer maintainer@archlinux.org" is unknown trust
:: Datei /var/cache/pacman/pkg/paket-version-x86_64.pkg.tar.zst ist beschädigt (Ungültiges oder beschädigtes Paket (PGP-Signatur)).
Soll die Datei entfernt werden? [J/n]
Dies liegt dann zumeist am veralteten archlinux-keyring, der zum verifizieren der Pakete verwendet wird und nicht alle aktuellen Schlüssel enthält. Die Lösung ist einfach, zunächst muss das Paket mittels
pacman -S archlinux-keyring
upgedatet werden, dann kann das Systemupdate wieder wie gewohnt durchgeführt werden.
Ein elementarer Teil der Betriebssicherheit eines IT-Systems ist die Datensicherung. Spätestens wenn man Dienste auch Freunden und Familie zur Verfügung stellt ist die Sicherung ein Muss. Wem seine eigenen Daten lieb sind, sollte sich natürlich auch schon vorher damit beschäftigen. Ein Mailserver ist hier ein Paradebeispiel, der Grundgedanke sollte aber auf alle anderen Dienste übertragen werden.
Die Mailcow-Dokumentation zur Datensicherung ist ein guter Einstiegspunkt, beschäftigt sich allerdings nur mit der periodischen Ausführung mittels cron. Auf meinem Server habe ich kein Cron installiert, da ich im laufe der Zeit die Vorteile von Systemd-Timern schätzen gelernt habe.
Einrichtung
Zunächst erstellen wir einen Systemd-Service, der beim Starten ein Backup von Mailcow erstellt und sich dann wieder beendet. Hierzu legen wir die Datei /etc/systemd/system/mailcowBackup.service mit folgendem Inhalt an:
[Unit]Description=Mailcow Backup[Service]Type=oneshotEnvironment="MAILCOW_BACKUP_LOCATION=/opt/backup"ExecStart=/opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 5[Install]WantedBy=multi-user.target
Type=oneshot bedeutet hierbei, dass es sich um einen Prozess handlet der gestartet wird und sich nach getaner Arbeit beendet - das ist wichtig, das Backup soll ja nicht direkt wieder gestartet werden. Die Environment-Variable MAILCOW_BACKUP_LOCATION steuert den Ausgabepfad des fertigen Backups, daher muss diese Variable natürlich gesetzt und entsprechend angepasst werden
Sobald diese Service-Unit existiert kann der Backup-Prozess mittels systemctl start mailcowBackup.service jederzeit manuell gestartet werden.
Die Ausgabe des Backup-Skriptes wird im Systemlog erfasst und kann daher über systemctl status mailcowBackup.service und journalctl -f -u mailcowBackup.service eingesehen werden.
[user@server]$ sudo systemctl status mailcowBackup.service
○ mailcowBackup.service - Mailcow Backup
Loaded: loaded (/etc/systemd/system/mailcowBackup.service; disabled; preset: disabled) Active: inactive (dead)Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/ib_buffer_pool
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/aria_log.00000001
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/aria_log_control
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_checkpoints
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/backup-my.cnf
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_info
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_binlog_pos_innodb
Aug 07 07:32:16 mailcow.url systemd[1]: mailcowBackup.service: Deactivated successfully.
Aug 07 07:32:16 mailcow.url systemd[1]: Finished Mailcow Backup.
Aug 07 07:32:16 mailcow.url systemd[1]: mailcowBackup.service: Consumed 1.056s CPU time, 14.1M memory peak.sudo
Periodische Ausführung mittels Timer
Der nächste Schritt ist die Anlage eines Timers, der die neu angelegte Unit zu definierten Zeitpunkten startet. Hierzu legen wir die Datei /etc/systemd/system/mailcowBackup.timer wie folgt an:
[Unit]Description=Starts the Mailcow Backup every nightRequires=mailcowBackup.service[Timer]Unit=mailcowBackup.serviceOnCalendar=*-*-* 00:30:00[Install]WantedBy=timers.target
Wichtig ist hier neben der Angabe der entsprechenden Service-Unit die Zeile OnCalendar=*-*-* 00:30:00, die besagt, dass der Timer An jedem Tag jeden Monats jeden Jahres um 00:30 aktiv werden soll. Der Timer muss abschließend noch aktiviert und gestartet werden. Dies erfolgt analog zu Service Units: systemctl enable --now mailcowBackup.timer. Mittels systemctl list-timers können aktive Timer eingesehen werden. Der Befehl zeigt eine Auflistung aller Timer inklusive dem absoluten und relativen Zeitpunkt der nächsten sowie vorherigen Ausführung.
[tokk@mx-web backup]$ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
[...]Thu 2024-08-08 00:30:00 UTC 16h - - mailcowBackup.timer mailcowBackup.service
Wed 2024-08-14 07:05:57 UTC 6 days Wed 2024-08-07 07:05:57 UTC 33min ago certbot-renewal.timer certbot-renewal.service
[...]
Auch hier landet die Ausgabe des Backups im System-Log und kann via journalctl eingesehen werden. Die komplette Ausgabe der tagesaktuellen Sicherung lasen sich zum Beispiel mittels journalctl -S today -u mailcowBackup.service anzeigen.
Weiterführende Gedanken
Nach der Einrichtung des Timers wird jede Nacht ein Backup unter dem spezifizierten Pfad angelegt. Sollte die Festplatte des Servers oder der ganze Server jedoch ausfallen ist dadurch jedoch nicht nur Mailcow betroffen, sondern auch das Backup. Daher ist es dringend notwendig, die Backups automatisiert noch anderweitig abzulegen.
Von Zeit zu Zeit habe ich das zweifelhafte Vergnügen, mit SLES-Systemen arbeiten zu dürfen. Dabei muss natürlich auch mit yast bzw. yast2 interagiert werden, um das System und einige Dienste zu konfigurieren. Von der Philosophie, die eigentlichen Konfigurationsdateien hinter einer GUI zu verstecken kann man halten was man will, ich halte davon nichts - aber das nur am Rande.
Bei meinem letzten Ausflug in die Welt dieser Enterprise Distribution ist mir dann ein kurioser Fehler aufgefallen. Ich habe mich in das System eingeloggt, meinen Benutzerkontext auf root geändert und YaST2 gestartet. Dabei wurde ich von folgender Meldung begrüßt:
YaST2 Control Center is not running as root.
You will only see modules which do not require root privileges.
Mit meiner Anmeldung war aber alles in Ordnung, wie ein kurzer Check ergab:
$# whoami
root
Nach einigem Googeln fand ich dann mehrere Threads, die mit dem gleichen Problem zu kämpfen hatten. Anscheinend tritt die Fehlermeldung relativ häufig und bei einer Vielzahl von Problemen auf. Es könnte daran liegen, dass zu wenig RAM zur Verfügung steht - aber das war bei mir nicht das Problem. In einem anderen Thread hatte ein Benutzer ebenfalls das obige Problem, hier lag es an einem fehlenden Logverzeichnis /var/log/YaST2. Bei mir war das Verzeichnis zwar vorhanden, aber der Thread brachte mich auf die richtige Spur - offensichtlich tritt der Fehler auf, wenn YaST2 keine Logdateien schreiben kann. Ein Check mit df -h ergab eine Festplattenauslastung von 100% - damit konnten natürlich auch keine Dateien geschrieben werden. Nach einer Bereinigung der Festplatte konnte YaST2 wieder normal ausgeführt werden. Ob es in diesem speziellen Fall daran liegt, dass keine Logfiles geschrieben werden konnten oder ob eine volle Festplatte auch andere Probleme mit sich bringt, kann ich natürlich nicht mit Sicherheit sagen, da keine Logfiles geschrieben wurden.
Zusammenfassend kann man sagen, dass die obige Meldung relativ generisch zu sein scheint und nicht unbedingt auf fehlende Rechte hinweist.