Mail-server-upgrade to Opensuse Leap 15 – and some hours with authentication trouble …

Some of my readers know that the mail server in my private LAN resides in an encrypted KVM/qemu guest. It provides IMAP- and SMTP-services to mail-clients - and receives emails from several hosted servers on the Internet via a fetchmail system in a DMZ. It was/is my policy that any access to a mail service account on my private mail server requires authentication against user entries on a separate LDAP-server. The accounts the IMAP/SMTP-service-daemons deal with are not to be confused with Linux user accounts: On the mail server NO Linux user accounts are required for mail handling. I regard the absence of standard Linux user accounts on the mail-server as a small, but effective contribution to security. No mail user can login into the mail server as a Linux user. Nevertheless authentication for the use of mail services is required.

Upgrade top Leap 15 resulted in unusable mail services

The manual upgrade of the mail server system from OS Leap 42.3 to Leap 15 seemed to work perfectly. I got no serious warnings. As root I could login to the virtual KVM guest via ssh - and systemd had started all required services: Fetchmail operated on external servers in the DMZ and transferred new mails to the upgraded mail server. There my postfix queues and secondary services for virus and spam checks seemed to work perfectly. Regarding IMAP I could also see that new entries for new mails appeared in various email accounts (more precisely: in related spool directories). Everything looked great ...

However, the big surprise came pretty soon: No mail user could login to the IMAP-service - neither with Kmail, nor Mutt, nor Thunderbird. Access to the SMTP service for sending email was not possible either. System messages appeared on the GUIs saying that there was an authentication error. A very unpleasant situation which required analysis ....

In the meantime I had to start a backup copy of the old mailserver guest installation. On this front
virtualization proved its strengths and simplicity - I had made a copy of the whole KVM guest before the upgrade and just had to include the copy as a virtualization domain into the KVM setup of the virtualization host. But, as the upgraded server had already processed some new mails, I needed to transfer these mails between the servers and reconstruct and reindex some IMAP accounts ... A simple, but a task which can be done by some scripts ....

Error analysis

It took me quite a while to figure out where the origin of the upgrade problem was located. I first checked my local firewall protocols both on the mail server and on the LDAP server. Nothing special there ... Then I checked the LDAP access protocols - there were successful data requests from various systems - but astonishingly not from the mail server. So it seemed that the mail services did not even try to authenticate their users ... strange ....
I then created a new IMAP test user based on a new local Linux user account, i.e. with an entry in "/etc/passwd" and "/etc/shadow". Guess what? This user could work without any problems. So, obviously the communication of the mail services with the LDAP service for authentication was not triggered or failed in a strange way. I, therefore, tried a manual data request to the LDAP server from the mail server - and got a perfect answer. So, there seemed to be no fundamental problem with the required sssd-daemon and client-configurations. What else was wrong? A bit of despair was in the air ...

The role of PAM in the game

Then I tried to remember what I had done in the past to separate the email accounts from the Linux user accounts. Over the last years I had actually forgotten how I had treated this problem. After some reading in old diaries my attention eventually turned to PAM ...

The PAM-layer offers Linux admins the possibility of fine-tuning access/authentication conditions for the usage of a service; among other things you can request certain PAM-modules to authenticate a user via given credentials against defined resources. A sequential series of required, sufficient or optional criteria can be set up. ( When a service needs additional Linux user account information during a session NSS can in addition request information from name resolution backends as "/etc/passwd". However, this is NOT required for mail services. )

Linux mail services often use the SASL-framework and the saslauthd daemon to perform authentication. SASL can communicate with a variety of authentication backends directly - but it can also use PAM as an intermediate layer. And, in fact, I had used PAM to access my independent LDAP-server with mail account credentials via the PAM-module for SSSD.

I have described my simple approach in a previous article
https://linux-blog.anracom.com/2014/03/15/cyrus-imap-mit-sasl-pam-sssd-und-ldap-opensuse-12-313-1-ii/
Unfortunately, only in German. I, therefore, summarize the basic ideas shortly (see also the graphics in the referenced article).

The things one has to do to force IMAP and/or a SMTP services to use LDAP, but other services to use local authentication resources is:

  • We direct local login-services, ssh-services, etc. on the server via PAM to local resources, only.
  • We eliminate any UIDs corresponding to email account names from local resources as "/etc/passwd" and "/etc/shadow" (and NIS if used).
  • We do not create any local home-directories for email account names.
  • We eliminate LDAP as a usable NSS resource from nsswitch.conf; i.e. we eliminate all LDAP references there.
  • We setup special PAM files in "/etc/pam.d" for the IMAP-service and the SMTP-service. These files will necessarily include pam-modules for the "sss"-service (pam_sss.so).
  • We select entries on the LDAP server for users which for any reasons shall NOT or NO LONGER get access to the mail service accounts, set the "host"-attribute for these entries and configure sssd to use the host-attribute. Or deny certain user names access to the IMAP-service by the help of IMAP -configuration files; cyrus e.g offers the maintenance of a list "userdeny_db".

This strategy worked very conveniently already on an Opensuse 12.3 platform. Examples for the required special files "/etc/pam.d/imap" and "/etc/pam.d/smtp" are given in the article named above. The mix and sequence of the statements there is due to the fact that locally defined system users as "cyrus" must get access to the IMAP-service, too.

What had happened during the Leap 15 upgrade?

My configuration had survived multiple upgrades of the virtualized server in the past. But not the one to Leap 15! What had happened?

After having remembered the importance of the PAM configuration, I eventually had a look into the directory "/etc/pam.d" on the upgraded system and compared it to the respective directory on the original system. Whereas during previous upgrades "personal" PAM configuration files for services had been respected, the upgrade to Leap 15 simply had removed my PAM configuration files for SMTP and IMAP - without a backup! Incredible, but true! Actually and astonishingly, the contents of some other standard PAM files had been transferred to a backup ....

A restoration of my PAM files for the mail services lead to an immediate success - authentication for the access of mail accounts on the upgraded server was possible again. Some hours in the hell for Linux admins came to an end.

Conclusion

Never (!) trust a standard upgrade of a whole Linux system procedure to keep configuration files in "/etc/pam.d" untouched. Keep an admin or system diary for unusual approaches. And - of course: Full backups of critical systems before backups are a MUST ....

Ausgehende HTTP-Anfragen von E-Mail Servern, Spamassassin und sa-learn

Es ist grundsätzlich gut, Server abzuschotten. Das gilt natürlich auch für E-Mail-Server unter Linux. Wie meine Leser wissen, ist meine Politik dabei regelmäßig die, nicht nur eingehende sondern auch ausgehende Verbindungen kritischer Systeme so weit wie möglich einzuschränken.

Vor kurzem hatte ich deshalb die Möglichkeiten für Verbindungen von unseren (virtualisierten) Mailservern im LAN ins Internet weiter begrenzt. Das führte dann leider zum Ausfall des Spamassassin-Daemons auf einem Server; da auf dem betroffenen System AmaVis nicht lief, hatte das durchaus spürbare Konsequenzen. Der Grund für den Ausfall ist vielleicht auch für andere Freelancer und Entwickler interessant, die eigene Mailserver im Hausnetz betreiben.

Notwendige ausgehende Verbindungen

Zur Sicherstellung der Kern-Funktionalitäten eines Mailservers im eigenen LAN (mit virtualisierten Segmenten) sind ja eigentlich nur sehr wenige ausgehende Verbindungen erforderlich:

  • Man muss Mails von Servern diverser Provider oder ggf. auch eigenen Servern, die im Internet positioniert sind, abholen. Das ist unter Linux durch Nutzung von Fetchmail und des IMAP- oder POP-Protokolls möglich.
  • Man muss Mails über Relay-Server bei Providern (oder eigene Relay-SMTP-Server im Internet) versenden. Hierzu reicht ein eigener MTA im LAN, der SMTP beherrscht. Unter Linux kommt etwa Postfix in Frage.

Die zu adressierenden Server sind von ihrer Anzahl her in der Regel überschaubar. Die zu nutzenden Ports ergeben sich aus der Absicherung der Verbindung mit STARTTLS/TLS/SSL - je nachdem, was der Provider so anbietet. Also kein Problem mit der Begrenzung der Verbindungsaufnahme durch einen Perimeter-Paketfilter im Segment der Mailserver und/oder an der LAN-Grenze vor dem Router ins Internet. (Natürlich kann auch eine lokale Firewall auf dem Linux-Host die Filterung stützen.)

Natürlich sind das aber nicht alle ausgehenden Verbindungen eines MTA wie Postfix im LAN. Hinzu kommen ggf. auch Verbindungen zu MDAs im LAN - etwa Dovecut oder Cyrus. Oft genug sitzen die aber auf demselben Linux-Host oder im gleichen LAN-Segment. Diese zu Systemen im LAN ausgehenden sowie auch eingehende Verbindungen durch Mail-Clients sind in einem strukturierten, segmentierten LAN leicht durch interne Firewalls an der Grenze von Segmenten zu kontrollieren.

Zusätzliche HTTP- odr HTTPS-Verbindungen ins Internet

Leider reicht eine Begrenzung auf Zieladressen von definierten IMAP- und SMTP-Servern im Internet nicht. Der Hauptgrund ist folgender:

Der Linux-Host, der den Unterbau für die Mail-Server-Komponenten (z.B. Postfix, Dovecot, Cyrus, Amavis, Spamassassin, Virusfilter plus TLS-, SASL-, LDAP-Komponenten) stellt, muss als solcher regelmäßig upgedated werden. Für den Freelancer ist die bequemste Methode sicher die, sich die notwendigen Pakete über einen Paketmanager von Repository-Servern des Linux-Distributors seines Vertrauens oder entsprechenden Mirror-Servern herunter zu laden. Auch die Anzahl solcher Server ist begrenzt. Typischerweise kommt für den Pakettransfer das HTTP- oder das HTTPS-Protokoll zum Einsatz. Aus Sicherheitsperspektive gibt es Vor- und Nachteile beider Varianten (sichere Server-Authentifizierung vs. nicht mehr einsehbarer Datentransfer über die nach außen initiierte Verbindung). In jedem Fall kann man aber auch hier die Zieladressen begrenzen UND den HTTP(S)-Kanal ggf. nur zeitweise öffnen. Konsequenterweise habe ich ausgehende HTTP(S)-Verbindungen der Mail-Server beschnitten.

Erwähnt sei an dieser Stelle der Vollständigkeit halber auch Folgendes:

Je nach Ausbau der Spam- und Virus-Bekämpfung kommen weitere Komponenten ins Spiel (Spamassassin, Razor2, Pyzor, ...). Dieser Punkt ist dann schon ein wenig heikler. So schön und hilfreich Razor2 und Pyzor von ihrer Grundidee her auch sein mögen; man überträgt bei der Nutzung solcher Dienste mindestens mal Hashes, die Inhalte in besonderer Weise differenzieren und vergleichbar machen; im ersten Fall an kommerzielle und abgeschottete Server in den USA. Genutzt werden im Fall von Razor2 die TCP-Ports 2703, ggf. auch Port 7 für ausgehende Verbindungen. Pyzor nutzt UDP-Port 24441; ich möchte mich hier nicht weiter über Sicherheitsprobleme offener UDP-Kanäle auslassen :-). Im Zuge der DSGVO sollte man beim Mailaustausch mit Kunden aber in jedem Fall mal nachfragen, ob der Kunde das Versenden von Hashes zu seinen Mails an Razor/Pyzor-Server erlauben will.

Ich betreibe deswegen eine eigene (virtualisierte) Mail-Server-Instanz für den kritischen Mailaustausch mit Kunden; dabei nutze ich ferner spezielle Mail-Accounts bei Providern. Der zugehörige MTA unterlässt den Einsatz von Razor2/Pyzor; das ist sinnvoll, da von Kunden ja hoffentlich keine SPAM-Mails kommen.

Hinweis: Deaktivieren muss man die Nutzung von Razor/Pyzor im Rahmen von Spamassassin übrigens durch Auskommentieren folgender Zeilen in der Konfigurationsdatei "/etc/mail/spamassassin/v310.pre" (die kennt auch nicht jeder 🙂 ):
"loadplugin Mail::SpamAssassin::Plugin::Razor2"     und     "loadplugin Mail::SpamAssassin::Plugin::Pyzor".

Von Bedeutung sind bei Einsatz eines Virenscanners auch auch ausgehende HTTP(S)-Verbindungen zu Update-Servern. Im Fall von clamav etwa zu: db.de.clamav.net, database.clamav.net.

Fehler beim Start des Spamassassin-Dämons "spamd" wegen "sa-learn"

Wir nutzen auf unseren Linux-Systemen primär Spamasassin zur Spam-Bekämpfung. Abhängig von der Linux-Distribution, vom Einsatz von AmaVis und eigenen Einstellungen wird auf einem Mailserver dabei der Spamassassin-Daemon gestartet oder nicht.

Amavis nutzt Spamassassin über ein eigenes internes (perl-basiertes) Modul (siehe https://wiki.centos.org/HowTos/Amavisd oder https://help.ubuntu.com/community/PostfixAmavisNew). Obwohl spamd für Amavis nicht gestartet werden muss, greift AmaVis aber auf die vorhandene Spamassassin-Installation und bestimmte zugehörige Einstellungen zu; u.a. Update-Einstellungen (s.u.). Man darf die Spamassassin-Pakete also nicht deinstallieren, wenn man AmaVis in seinen MTA integriert.

Zudem bietet eine zusätzlich laufende Instanz des Spamasassin-Daemons weitere Filtermöglichkeiten, die man etwa im Rahmen von procmail nutzen kann. (Siehe hierzu etwa https://serverfault.com/questions/845712/what-to-do-with-spamassassin-after-installing-amavis und die dortigen Kommentare).

Auf einem meiner Mail-Server wird der Spamassassin-Dämon "spamd" jedenfalls explizit gestartet. Nach dem letzten Hochfahren der betreffenden (virtuellen) Server-Instanz musste ich allerdings ein komisches Verhalten der gesamten Mail-Installation feststellen, was sich nach ein wenig Analyse auf den gescheiterten Start des "spamd"-Dämons zurückführen ließ. Was war da los?

Ich musste eine Weile graben, bis mir klar wurde, dass das Starten des spamd-Services auf einem Suse-Unterbau einige Dinge ablaufen, die man bei der KOnfiguration von Paketfilter-Einstellungen besser nicht vergessen oder ignorieren sollte:

So zeigt die systemd-Service-Konfiguration für "spamd" etwa Folgendes:

mymails # cat /usr/lib/systemd/system/spamd.service
# This file is part of package amavisd.
#
# Copyright (c) 2011 SuSE LINUX Products GmbH, Germany.
# Author: Werner Fink
# Please send feedback to http://www.suse.de/feedback
#
# Description:
#
#  Used to start the spamd the daemonized version of spamassassin
#       spamassassin adds a header line that shows if the mail has been
#       determined spam or not. This way, you can decide what to do with the
#       mail within the scope of your own filtering rules in your MUA (Mail
#       User Agent, your mail program) or your LDA (Local Delivery Agent).
#

[Unit]
Description=Daemonized version of spamassassin
Wants=remote-fs.target network.target
After=remote-fs.target network.target
Before=mail-transfer-agent.target

[Service]
Type=forking
PIDFile=/var/run/spamd.pid
ExecStartPre=/bin/bash -c "sa-update || true"
EnvironmentFile=-/etc/sysconfig/spamd
ExecStart=/usr/sbin/spamd $SPAMD_ARGS -r /var/run/spamd.pid
ExecReload=/usr/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Die interessante Zeile ist hier "ExecStartPre=/bin/bash -c "sa-update || true". Sie legt fest, dass "sa-update" vorab gestartet werden soll.

"sa-update" hat den Zweck, bestimmte Regeln für "spamassassin" automatisch zu erneuern. Dazu wird auf sog. "channels" zugegriffen, hinter denen bestimmte Server im Internet stehen. Siehe hierzu:
https://spamassassin.apache.org/full/3.1.x/doc/sa-update.html. Die Regeln etc. - und damit deren Erneuerung - werden übrigens auch von AmaVis genutzt!. "sa-update" ist somit auch für ein MTA-System mit AmaVis-Dienst relevant; ggf. verlässt sich die Installation dabei aber auf einen durch cron veranlassten Start!

Leider hatte ich "sa-update" in meinem Kopf völlig verdrängt. Da sich die Fehlermeldungen, die ein "systemctl status spamd.service" ausspuckte u.a. auf die nicht erreichbare Adresse "spamassassin.apache.org" und auch "1.4.3.updates.spamassassin.org" bezogen, war klar, dass ich die Begrenzung der ausgehenden Verbindungen wohl etwas übertrieben hatte.

sa-update kann man auch manuell ausführen. Zum Testen eignet sich der Befehl "sa-update --refreshmirrors -vvvvv -D":

mymails # sa-update --refreshmirrors -vvvvv -D
Oct 20 13:44:59.164 [4580] dbg: logger: adding facilities: all
Oct 20 13:44:59.164 [4580] dbg: logger: logging level is DBG
Oct 20 13:44:59.164 [4580] dbg: generic: SpamAssassin version 3.4.1
Oct 20 13:44:59.164 [4580] dbg: generic: Perl 5.018002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin
Oct 20 13:44:59.164 [4580] dbg: config: timing enabled
Oct 20 13:44:59.171 [4580] dbg: config: score set 0 chosen.
Oct 20 13:44:59.181 [4580] dbg: generic: sa-update version svn1652181
Oct 20 13:44:59.181 [4580] dbg: generic: using update directory: /var/lib/spamassassin/3.004001
.....
....
Oct 20 13:44:59.588 [4580] dbg: channel: attempting channel updates.spamassassin.org
Oct 20 13:44:59.588 [4580] dbg: channel: using existing directory /var/lib/spamassassin/3.004001/updates_spamassassin_org
Oct 20 13:44:59.589 [4580] dbg: channel: channel cf file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Oct 20 13:44:59.589 [4580] dbg: channel: channel pre file /var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Oct 20 13:44:59.590 [4580] dbg: channel: metadata version = 1844313, from file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
....
.....

Das oben ist ein Auszug aus einer funktionierenden Konfiguration. Auf dem fehlerhaften System kamen dagegen viele Fehlermeldungen zu diversen durchprobierten channel-Verbindungen. Das betraf dann doch eine ganze Reihe von Servern - wie sich später herausstellte waren das Mirror-Server. Ein Blick in das Protokoll der Firewalls offenbarte dann, dass zu all diesen Servern der Reihe nach wiederholte "http"-Anfragen abgesetzt wurden. Das bestätigte, dass eine zu rigorose Unterbindung von ausgehenden HTTP-Verbindungen für einen Mail-Server mit Spamassassin nicht unbedingt gut ist.

Welche Haupt- und Mirror-Server für "sa-update" sind in der Firewall zu berücksichtigen?

Nun will man ja nicht unbedingt Fehlerprotokolle und Firewall-Logs studiweren, um herauszufinden, zu welchen sa-channel-Servern man HTTP-Verbindungen zulassen sollte. Dass der Hauptchannel "updates.spamassassin.org" sein soll, geht aus der sa-update Doku zwar hervor, nicht aber der oder die zugehörige Server. Ein "ping updates.spamassassin.org" bringt jedenfalls nichts.

Der aktuelle Server, der im Moment tatsächlich (per DNS!) angefragt wird, ist vielmehr "1.4.3.updates.spamassassin.org". Darauf sollte man sich aber auf Dauer nicht verlassen. Was ist also bzgl. der Firewall zu tun?

Folgende DNS-Namen sind für Firewall-Regeln wichtig:

  • Ein relevanter Server für HTTP ist in jedem Fall: spamassassin.apache.org
  • Weitere Mirror-Server für ausgehende HTTP-Verbindungen sind z.Z. gelistet unter
    "/var/lib/spamassassin/3.004001/updates_spamassassin_org/MIRRORED.BY".
    Da kann man ja einige vertrauenswürdige DNS-Namen zulassen. Z.B. "sa-update.spamassassin.org".

Die zuständige Firewall sollte so konfiguriert werden, dass die IP-Adressen für oben angegebenen DNS-Namen zur Laufzeit aufgelöst werden können. Mit iptables ist das problemlos möglich.

Bzgl. der rules und der Datei MIRRORED.BY noch ein Tip: Man sollte nach Server-Updates oder gar Upgrades immer mal kontrollieren, ob unter "/var/lib/spamassassin/" nicht ein neueres Verzeichnis des Typus 3.00X000Y mit Konfigurations- und Rules-Files aufgetaucht ist. Das relevante Verzeichnis verändert sich im Lauf der Jahre; die alten Verzeichnisse werden oft aber nicht gelöscht.

Bzgl. der Firewall ist in jedem Falle aber auch Folgendes zu beachten:

Der Mailserver muss grundsätzlich DNS-Abfragen stellen können.

Nicht nur, um ggf. die obigen Namen auflösen zu können; sondern auch weil die Überprüfung der Update-Notwendigkeit über DNS-Abfragen erfolgt. Man schaue sich mal mit Wireshark die Kommunikation an! Das Zulassen von DNS in der Firewall erscheint auf den ersten Blick trivial. Aber wer die Kommunikation seines Mail-Server begrenzt, arbeitet ggf. bzgl. SMTP, IMAP, etc. zu externen Servern direkt mit IP-Adressen und lässt DNS außen vor. Im besonderen, wenn diese Server im Internet selbst verwaltete sind.

Dauerhaft laufender Mail-Server und sa-update

Natürlich muss der Update Dienst auch auf einem dauerhaft laufenden System funktionieren. Das wird mittels des "cron"-Dienstes erledigt. Hier ist z.B. auch unter Opensuse ein Eintrag für "sa-update" vorhanden. Vorgaben, die das Update-Verhalten für spamd steuern, findet man bei Opensuse übrigens in der Datei "/etc/sysconfig/spamd".

Fazit

Bei der Einschränkung ausgehender Verbindungen von E-Mail-Servern sollte man nicht vergessen, dass Spamassassin ebenso wie Virenscanner automatische Updates von grundlegenden Filterregeln vornehmen. In vielen Linux-Distributionen ist ein solcher Update sogar täglich vorgesehen. Für Spamassassin sind in diesem Zusammenhang HTTP-Verbindungen zu "channel"-Servern zu ermöglichen. Daneben sind DNS-Abfragen zuzulassen. Das Scheitern des Startens von "spamd" beim Hochfahren von Mailservern aufgrund von Firewall-Beschränkungen ist möglich.

Links

https://wiki.centos.org/HowTos/Amavisd
https://help.ubuntu.com/community/PostfixAmavisNew
https://serverfault.com/questions/845712/what-to-do-with-spamassassin-after-installing-amavis
https://www.howtoforge.com/community/threads/spamassassin-automated-update.72393/
https://www.faqforge.com/linux/keep-the-spamassassin-filter-rules-up-to-date-in-ispconfig-3/

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – III

Das Thema der vorhergehenden Artikel dieser Serie

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I
DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

war eine allgemeine Diskussion darüber, warum man sich spätestens nach der DSGVO als Freelancer um Schutzmaßnahmen für E-Mails und um entsprechende vertragliche Vereinbarungen kümmern sollte. Eine reine Verschlüsselung von Transportwegen ist meiner Meinung nach nicht hinreichend; eine Lagerung von Mails in verschlüsselten Dateicontainern ist mit zu vielen Gefahrenpunkten verbunden. An einer Verschlüsselung von Volumes oder Partitionen der mail- und datei-verarbeitenden Systeme führt bei der Aufbewahrung von Mails und Anhängen kein Weg vorbei.

Als Freelancer steht man also womöglich vor der Aufgabe, sowohl den eigenen Mail-Server im LAN als auch Clients zur Mail- und Auftragsbearbeitung auf einen Unterbau aus verschlüsselte Partitionen umzustellen. Als Linuxer, die auf effiziente Ressourcennutzung bedacht sind, greifen wir zur Lösung auf virtualisierte Systeme zurück. Sprich: Meine Reaktion auf die von etlichen Kunden an mich gestellten pauschalen DSGVO-Anforderungen ist, die Auftragsverarbeitung für Kunden nur noch über besonders geschützte virtualisierte Systeme auf verschlüsselten Volumes durchzuführen. Der aufmerksame Leser hat sicher bemerkt, dass dieser Gedanke über die Mail-Verarbeitung hinaus weist.

Ich gehe kurz auf die Grenzen eines solchen Vorgehens ein; anschließend kümmern wir uns (endlich) um den Umzug eines bereits virtualisierten Mailservers auf eine verschlüsselte HD/SSD-Plattform.

Ist Volume- und Partitionsverschlüsselung einer Systeminstallation für Datensicherheit hinreichend?

Der Grundgedanke einer Partitions- oder Volume-Verschlüsselung ist: Nur verschlüsselte Daten sollen über verschiedene Zugriffsschichten Plattencontroller und Magnet- wie Flash-Speicher erreichen; eine vollständige Entschlüsselung von Dateien soll ausschließlich im RAM des Betriebssystems [OS] stattfinden. So schön das sein mag - es hilft nicht, wenn sich jemand bereits unbefugt auf dem System eingenistet hat und munter mitliest:

Die Verschlüsselung von Datenträgern, Partitionen oder Volumes bietet keinen Schutz auf gehackten Systemen. Sie bietet "nur" Schutz gegen unbefugten Zugriff im nicht-entschlüsseltem und/oder nicht-gemountetem Zustand der Volumes also z.B. im heruntergefahrenen Zustand des Systems.

Volume-Verschlüsselung ist also nur eine - wenn auch eine wichtige Maßnahme - zur Ausschaltung bestimmter Risiken. Auch das sollte aus meiner Sicht in einem Vertrag mit einem Auftraggeber festgehalten werden. Natürlich muss man sich u.a. auch um die Integrität der Virtualisierungshosts selbst kümmern - wir reden da aber über Systeme mit einer sehr begrenzten Anzahl an OS-Komponenten, die selbst keine direkte Verbindung zum Internet aufnehmen müssen.

Man erkennt, dass ein vernünftiger DSGVO-bezogener Vertrag zum Schutz personenbezogener und anderer geheim zu haltender Daten im Endeffekt wesentlich mehr beinhalten muss als nur Hinweise auf die Mailbehandlung und zugehörige Krypto-Verfahren für Transport und Lagerung. U.a. wird man eine Begrenzung ein- und aus-gehender Kommunikation von (virtualisierten) Servern und Clients, die bei der Auftragsbearbeitung eingesetzt werden, auf nur sehr wenige erlaubte Adressen im Internet umsetzen müssen. Z.B. gilt: Völlig offene HTTP(S)- / SMTP(S) - / IMAP(S)- oder gar UDP-basierte Kanäle nach außen zu beliebigen Zieladressen sind im Zeitalter von strafbewehrten DSGVO-Verträgen überhaupt keine gute Idee! Zumindest nicht auf denjenigen Server- und Client-Systemen, auf denen man mit geheim zu haltenden Informationen operiert.

Virtuelle KVM/QEMU-Systeme auf verschlüsselten Volumes

Will man aus anderen grundlegenden Risikoerwägungen heraus nicht gleich alle "Volumes" auf allen Systemen im Haus-/Firmen-Netz verschlüsseln, bleibt nur der Weg über virtuelle Maschinen. Das betrifft dann Server- wie Client-Systeme gleichermaßen.

Im Besonderen Linux-E-Mail-Server sind dabei recht komplexe Systeme; eine Neuinstallation der vielen Einzel-Komponenten auf verschlüsselten Platten/Partitionen mag man sich daher wirklich ersparen. Es geht somit um System-Migration. Nachfolgend betrachte ich deshalb den Umzug eines (virtuellen) (E-Mail-) Servers auf einem KVM/QEMU-Host von unverschlüsselten Partitionen/Volumes auf verschlüsselte Volumes.

Ich gebe einige wichtige Befehle am Beispiel eines KVM/QEMU-Hosts unter Opensuse an. Das ist insofern nützlich, weil man hierfür mit YaST allein nicht auskommt und auf die Kommandozeile runter muss. Für einen Umzug voll ausgestatteter virtueller Clients (KVM/QEMU-Linux-Gastsysteme) zur Mail- und Auftragsbearbeitung gelten die Ausführungen dann analog.

Übrigens: Durch voll-virtualisierte KVM/QEMU-Systeme (für Mailserver und Clients),

  • die netzwerktechnisch weitgehend abgeschottet sind,
  • über die kein freier Internetzugang mit Browsern erlaubt ist
  • und die auch nur spezielle Mail-Accounts bedienen

kann man auch Hackern das Eindringen ein wenig erschweren!

Umzug eines physikalischen Linux-E-Mail-Servers in eine Virtualisierungsumgebung?

Das erste Problem besteht für manchen Leidensgenossen ggf. darin, einen schon vorhandenen physikalischen Server in eine Virtualisierungsumgebung zu bringen. Ehrlich gesagt, habe ich das noch nie selbst gemacht - und leider auch keine Zeit, das mal testweise auszuprobieren. Server für spezielle Aufgaben sind in meinem begrenzten Netz schon seit langem aus guten Gründen virtualisiert 🙂 .

Ich verweise für diese Aufgabe unter Linux deshalb auf sog. "P2V-Tools" (physical to virtual) und entsprechende Literatur. Die ganz unten aufgeführten Links geben hierzu Hinweise und Anleitungen. Für die nachfolgenden Schritte setze ich voraus, dass es bereits einen unter KVM/QEMU virtualisierten Server gibt - allerdings auf unverschlüsselten Partitionen/Volumes.

Vorüberlegung A: Wie sieht es mit der Performance und der Flexibilität auf verschlüsselten Plattformen aus?

Kann man sich auf seinen Systemen eigentlich eine Verschlüsselungsschicht zusätzlich zur Virtualisierung leisten? Das ist eine gute Frage, die man pauschal schlecht beantworten kann. Unter Linux kommt meist eine Kombination aus dm-crypt und LUKS zum Einsatz. Für Systeme mit Prozessoren der letzten 5 Jahre sieht es dabei hinsichtlich der reinen Krypto-Performance recht gut aus. Bei Virtualisierungshosts im Heim-Bereich (also eher mit begrenzten Ressourcen) sind aber ein paar zusätzliche Punkte zu beachten:

Schichtung
Hat man als Plattenunterbau Raid-Systeme im Einsatz, so stellt sich etwa die Frage der Schichtung der verschiedenen Zugriffsverfahren. Aus meiner Sicht ist folgende Reihenfolge für virtualisierte Serversysteme sinnvoll:

  • Plattenpartitionen für Raid   >>  
  • Raid 10   >>  
  • LVM   >>  
  • Volumes für KVM-Host-OS   >>  
  • dm-crypt/Luks für ein LVM-Raw-Volume   >>  
  • KVM/QEMU- und Gastsystem mit Zugriff auf das Raw-Volume als virtuelle Platte   >>  
  • LVM /Volumes (oder Partitionen) im Gastsystem   >>  
  • ext4-Filesysteme im Gastsystem

Verschlüsselung vor Raid scheint mir aus naheliegenden Gründen wenig performance-optimierend zu sein. Bzgl. der Reihenfolge "LVM <> dm-crypt/Luks" kann man streiten. Für die eine oder andere Wahl ist aus meiner Sicht dabei nicht die Performance sondern die Flexibilität ausschlaggebend. Bei der von mir gewählten Vorgehensweise verschlüsseln wir LVM-Raw-Volumes und nicht die sie tragenden Platten-Partitionen. Das erlaubt den Einsatz unterschiedlicher Krypto-Algorithmen und individueller Passphrases für die zu verschlüsselnden Volumes. Ein Nachteil ist, dass Größenänderungen der Volumes und Filesysteme danach nicht im Online-Betrieb möglich sind. Das stört im semi-professionellen Umfeld aber weniger (s.u.).
Siehe auch:
https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks

Einsatz von virtio-Treiber
Für optimale Performance setze ich auf dem KVM-Host für die Vermittlung des Zugriffs des KVM-Gast-Systems auf die als virtuelle HDs bereitgestellten Volumes den QEMU-eigenen "VirtIO"-Treiber ein. Das sieht im "virt-manager" dann etwa so aus:

Übernahme der Verschlüsselung durch den Virtualisierungs-Host!
Man erkennt an der oben angegebenen Schichtung, dass ich die Verschlüsselung vollkommen dem Virtualisierungs-Host überlasse. Das erscheint mir sinnvoll, da ihm normalerweise mehr CPU-Cores als dem Gastsystem zur Verfügung stehen.

Ich kann jedenfalls mit diesem Setup auf einem schon sehr betagten Host mit einem KVM-Gast-Mail-Server, der nur um die 10 Mails pro Minute verarbeiten muss, sehr gut leben. (Der Host beherbergt dabei noch mehr aktive virtualisierte Systeme!) Der Unterschied zur Situation ohne Verschlüsselung ist gefühlt klein. Soviel zum Mail-Server und Performance.

Vorüberlegung B: Verschlüsselung eines (LVM-) "Raw"-Devices? Verzicht auf "qcow2"?

Gem. der oben propagierten Schichtung möchte ich das Gastsystem für meinen E-Mail-Server offenbar auf einem "Raw-Volume" der LVM-Schicht betreiben - also direkt auf einem LVM-Volume, das vom Gast-System aus formatiert wurde, und nicht auf einem "qcow2"-Loopback-File eines übergeordneten Filesystems des Hosts. Was spricht gegen ein Vorgehen mit "qcow2"-Dateien auf einem KVM-Host für einen virtualisierten Server?

"qcow2"-Dateien - mit internem Filesystem für den Gast - sind zwar hochflexibel einsetzbar - der Zugriff des Gastes auf seine virtuelle Platte erfolgt dabei aber immer über die Filesystem-Schicht des KVM/QEMU-Hosts UND über die Filesystem-Schicht des KVM-Gastes; das kostet Performance!

Der entsprechende Overhead ist nicht unerheblich - vor allem dann nicht, wenn der Server ggf. von mehreren Clients gleichzeitig genutzt werden soll. Die QEMU-Leute haben deshalb schon immer vorgesorgt und erlauben den direkten Zugriff eines Gastes auch auf nicht gemountete Volumes oder Partitionen des Hosts.

Der zweite Grund entspringt ein wenig Sicherheitsüberlegungen.

Auf eine "qcow2"-Datei muss vom Gast-System über ein Mount-Verzeichnis des Host-Dateisystems aus zugegriffen werden. Die Datei liegt dann also bereits in einem unverschlüsselten Dateisystem, das auf einem Verzeichnis des Hosts gemountet ist, vor. Damit besteht aber auch - je nach Rechtesetzungen - die potentielle Gefahr, dass ihr Inhalt im laufenden Betrieb auch anderweitig ausgelesen werden kann (z.B. mit qemu-mount).

Die Situation ist im Fall von Raw-Devices komplexer. Das LVM-Volume wird nach einer Entsperrung des Verschlüsselungsverfahrens (s.u.) zwar wie eine Platte als Device unter "/dev/mapper" bereitgestellt. Aber dieses Device ist auch bei laufendem Gastsystem nicht direkt im Verzeichnisbaum des laufenden Host-Systems verankert. Ein evtl. durchgeführter Mountvorgang auf dem Host ist aber gar nicht so einfach zu verschleiern. Er wäre unnötig und würde bei entsprechender Protokollierung Alarmglocken auslösen.

Dennoch gilt:

Verschlüsselung von LVM-Volumes und Einsatz von qcow2 müssen bei hinreichenden Performance-Reserven kein Widerspruch sein.

Eine Schichtung

Raid 10   >>   LVM   >>   dm-crypt/Luks-Volume mit ext4   >>   Gemountetes LUKS/ext4-Volume mit qcow2-Datei auf dem KVM/QEMU-Host   >>   KVM/QEMU-Gast mit Zugriff auf qcow2-Loopback-Device   >>   LVM-Volumes des Gastsystems auf qcow2-Device   >>   ext4-Gast-Filesystem auf LVM-Volumes des Loop-Devices

funktioniert auf schnellen Hosts auch gut und bietet Verschlüsselung samt qcow2-Flexibilität. Ich nutze diese Variante u.a. auf Linux-Workstations für virtualisierte Clients.

Ich verfolge nachfolgend für unseren geplanten (Server-) Umzug aber die Variante ohne qcow2-Loopback-Device. Auch unser bisheriger virtualisierter (Mail-) Server mag bereits direkt auf einem unverschlüsselten Volume des Hosts verankert sein.

Vorüberlegung C: Größe des neuen kryptierten Raw-Volumes für den Umzug?

Wir können nun z.B. über den LVM-Volume-Manager von YaST oder über LVM-CLI-Kommandos (vgcreate, lvcreate) ein Raw-Volume kreieren, das nach seiner Verschlüsselung eine Kopie des alten Systems aufnehmen soll. Wie groß muss dieses logische Volume sein?

Naiverweise könnte man davon ausgehen, dass genau die Größe des alten Volumes (oder der alten Partition) in GiB hinreichend ist. Das wäre falsch. LUKS hinterlegt Informationen zum verschlüsselten Plattenplatz und zu 8 möglichen Passphrase-Keys in einem sog. "Verschlüsselungsheader". Dieser Header benötigt zusätzlichen Platz jenseits der verschlüsselten Nutzlast. Der Platzbedarf ist zwar nicht groß (ca. 2 MB) - aber er ist eben zu berücksichtigen. Man muss dem neuen Volume etwas mehr Platz als dem alten spendieren. Ich vergebe meist gleich 1 GB extra.

Verschlüsselung des Raw-Volumes

In unserem Beispiel heiße das neue logische LVM-Volume für das virtuelle Plattendevice des KVM-Gastes "lvimap_hd0" und sei Teil einer LVM-Volume-Group "volgrp4". Als Device erscheint dieses Volume dann unter "/dev/mapper" als "volgrp4-lvimap_hd0".

myserv:~ # la /dev/mapper 
...
lrwxrwxrwx  1 root root       8 Jun 10 09:40 volgrp4-lvimap_hd0 -> ../dm-14
...

Der zugehörige Link verweist im Beispiel dann ebenso wie "/dev/volgrp4/lvimap_hd0" auf "/dev/dm-14".

Wir setzen zur Kryptierung "dm-crypt" ein. "dm-crypt" nutzt LUKS über gut integrierte Module.

Die Aufgabe, ein (LVM-basiertes) "Raw-"-Device mit dmcrypt/LUKS zu verschlüsseln, lässt sich unter Opensuse Leap (42.2/42.3) entgegen jeder Erwartung mit YaST leider nicht erfolgreich durchführen. YaST wickelt die Anlage eines verschlüsselten Volumes nur dann korrekt ab, wenn das Filesystem bereits vorgegeben wird - also NICHT bei der Verschlüsselung für Raw-Devices innerhalb der Reihenfolge :

Partition   >>   LVM-Group   >>   Raw LVM-Volume   >>   dm-crypt/LUKS   >>   KVM-guest   >>   LVM im Gast   >>   Filesystem

Das ist bereits von anderen beklagt worden; siehe etwa:
https://forums.opensuse.org/showthread.php/528938-installation-with-LUKS-cryptsetup-installer-gives-error-code-3034

Man muss also auf der Kommandozeile arbeiten und das Kommando "cryptsetup" bemühen. Für unser Beispiel-Volume "lvimap_hd0" (erste virt. Platte des künftigen E-Mail-Servers) lautet ein mögliches Kommando zur Verschlüsselung dann:

myserv:~ # cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/volgrp4/lvimap_hd0

Für Details zu den verfügbaren Verschlüsselungs- und Hash-Verfahren werfe man einen Blick in die man-Seiten zum Kommando. Man muss die künftige Passphrase zweimal eingeben. Damit ist die Verschlüsselung aktiv. Ein anschließender Blick auf das Volume mit dem YaST-Partitioner zeigt entsprechend ein Verschlüsselungssymbol an.

Altes KVM-Gast-System mit "dd" kopieren oder mit "virt-manager" klonen?

Bzgl. des geplanten Umzugs unseres unter KVM/QEMU virtualisierten (Mail-) Servers auf das neue Krypto-Device stellt sich nun die Frage, wie wir das am besten bewerkstelligen:

Sollen wir "dd" einsetzen? Das ist zwar möglich, erfordert anschließend aber wegen kopierter UUIDs, MAC-Adressen etc. etliche manuelle Nacharbeiten im geklonten System und auf dem Host.

Besser ist deshalb aus meiner Sicht ein Cloning mit Hilfe von virt-manager! Dabei ist folgende Schrittfolge einzuhalten:

  • Schritt 1 : Öffnen des neuen dm-crypt-Devices unter einem verständlichen Namen
     
    myserv:~ # cryptsetup open /dev/mapper/volgrp4-lv_imap_hd0  cr_imap_encr

    Dabei muss natürlich die bereits gesetzte Passphrase für das Crypto-Device eingegeben werden. "cr_imap_encr" steht dann als ansprechbares Device unter "/dev/mapper/" bereit

  • Schritt 2 : virt-manager öffnen und in der Liste der Gäste mit der rechten Maustaste auf den zu klonenden Gast klicken. Dann die Option "Clone ..." wählen. Das führt uns dann zu einer Maske, die in etwa so aussieht und die zu klonende virtuelle Platte (vm2_hd1) des vorhandenen Gastes anbietet:
     

    Bzgl. der zu klonenden Disk öffnet man die Drop-Down Box und wählt "Details" :

  • Schritt 3 : In der sich neu öffnenden Maske trägt man den Pfad zum geöffneten "dm-crypt"-Decvice ein:
     

    Dann in der aktuellen Maske den "OK"-Button und anschließend in der Ausgangsmaske den Button "Clone" drücken.

Je nach Größe unseres virtuellen Servers und der Schnelligkeit der Plattensysteme wie des Prozessors dauert das etwas. Anschließend erhalten wir allerdings einen Clone, den man sofort booten kann. (Vorher den ursprünglichen Mail-Server natürlich runterfahren, um IP-Konflikte zu vermeiden. Das geklonte System hat immer noch die gleiche IP-Adresse wie das alte! )

Das war es im Wesentlichen schon. Wir haben erfolgreich ein virtualisiertes Server-System auf einen verschlüsselten LVM-Volume-Unterbau umgezogen!

Wie schließt man das verschlüsselte System manuell?

Unsere manuelle Vorgehensweise hat dazu geführt, dass das verschlüsselte Volume nicht in Systemdateien eingetragen wurde. Es steht daher nach einem Boot-Vorgang des Hosts nicht automatisch zu Verfügung. Auch das Passwort für die Entschlüsselung wird im Bootvorgang nicht automatsich abgefragt.

Ein aktivierter "libvirtd"-Service kann daher nach seinem Start im Zuge eines Bootens des Hosts auch nicht auf das Volume für den umgezogenen Gast zugreifen. Ein automatisches Hochfahren des Gastes über libvirt-Einstellungen ist somit ebenfalls nicht möglich. Das sind Probleme, um die wir uns in nachfolgenden Artikeln kümmern müssen.

An dieser Stelle möchte ich aber wenigstens den notwendigen manuellen Befehl für das Schließen des Crypto-Devices im Zuge eines Herunterfahrens angeben:

  • Schritt 1 - Herunterfahren des Gastsystems: Dies geschieht entweder über Standard-Befehle im Gast selbst oder z.B über virt-manager.
  • Schritt 2 - Schließen des Crypto-Devices :
     
    myserv:~ # cryptsetup close cr_imap_encr

Ausblick

In folgenden Artikeln möchte ich im Nachgang zu unserem "Umzug" ein wenig auf das Thema eingehen, wie man das Hochfahren des KVM-Hosts mit Gastsystemen auf verschlüsselten Volumes gestalten kann. Zudem wollen wir den "Verschlüsselungsheader" sichern und uns mit den Themen Backup und "fstrim" für SSDs als Basis der beschriebenen Schichtung befassen. Sinnvoll ist auch ein Blick auf (Mail-) Client-Systeme: Von irgendwo aus muss ja auch mal grafisch auf die virtualisierten Systeme zugegriffen werden. Dann werden z.B. Spice oder X2GO-Clients samt zugehörigen Protokollen zu einem Sicherheitsthema auf dem System, von dem aus wir auf virtualisierte Clients für die Auftragsbearbeitung zugreifen. Verschieben wir mit der Virtualisierung im Client-Umfeld also nur die Sicherheitsebene?

Links

P2V-Tools
http://manuel.kiessling.net/2013/03/19/converting-a-running-physical-machine-to-a-kvm-virtual-machine/
http://libguestfs.org/virt-p2v.1.html
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/v2v_guide/chap-v2v_guide-p2v_migration_converting_physical_machines_to_virtual_machines
http://events17.linuxfoundation.org/sites/events/files/slides/virt-v2v-rjones-backup-slides.pdf
http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Speichermedien/_Physical-to-Virtualp2v_migration_converting_physical_machines_to_virtual_machines
https://access.redhat.com/articles/1351473

dm-crypt/Luks und die Reihenfolge von Zugriffsschichten
https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks
https://blog.raptor2101.de/2009/09/23/verschlusselung-von-raids/
http://www.andreas-janssen.de/cryptodisk.html
http://linux-club.de/wiki/opensuse/Verschluesselung:_dm-crypt/luks_unter_openSUSE
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties