IT-Sicherheit bei Lindenberg

BSI-Grundschutz @ Lindenberg? Als Ein-Mann-Unternehmen ein vollständiges ISMS? Nicht wirklich. Insbesondere der Grundschutz würde ganz viel Aufwand und Papier, aber nicht unbedingt Sicherheit liefern. Als Sicherheits-Enthusiast habe ich dennoch klare Vorstellungen...

Inhalt

Schutzziele, Sicherheitsanforderungen, Risiken

Fangen wir mit den Schutzzielen an:

  1. Gespeicherte Daten vor unberechtigtem Zugriff schützen
  2. Datenübertragung vor unberechtigtem Zugriff schützen
  3. Daten gegen Verlust schützen
  4. Daten verfügbar halten (Resilience, Business Continuity)
  5. Strom sparen (Klimaschutz 😉)

Etwas feingranularere Informationen liefern meine Sicherheitsanforderungen. Ja, ich benutze die nicht nur bei der Softwareentwicklung sondern auch bei der Beurteilung der Sicherheit anderer IT-Komponenten. Im Vergleich zum Standard-Vorgehen des BSIs spare ich so viel Gehirnschmalz und Text. Die Schutzziele 1 und 2 werden direkt von den Anforderungen Authentifizierung, Berechtigungen, und Verschlüsselung von gespeicherten Daten bzw. von Verbindungen adressiert. Die Verschlüsselung gespeicherter Daten wird auf Systemebene adressiert und in Systemsicherheit beschrieben. Schutzziel 3 wird dadurch adressiert, dass alle physischen Systeme (siehe Systemsicherheit) regelmäßig gesichert werden, teilweise mehrmals am Tag, und auch außer Haus. Authentifizierung, Berechtigungen, Verschlüsselung der Kommunikation und Maßnahmen zur Verfügbarkeit (Schutzziel 4) sind Anwendungs- bzw. dienstspezifisch, die werden in Anwendungssicherheit betrachtet. Bei Schutzziel 4 bin ich selbst nicht zufrieden, weder auf Netzwerkebene noch auf Anwendungsebene, da möchte ich besser werden, aber genaugenommen ist der erreichte Stand gut genug oder zumindest besser als bei vielen anderen. Strom sparen habe ich aufgeführt, weil bessere Verfügbarkeit oft mehr Stromverbrauch durch redundant laufende Systeme bedeutet – da muss man abwägen. Und weil das in der nächsten Tabelle gleich auftaucht: meine Systeme sind über zwei Standorte verteilt, die ca. 5km auseinander liegen.

Wie adressieren diese Sicherheitsanforderungen und Schutzziele die typischen Gefährdungen (elementare Gefährdungen aus dem BSI Kompendium)?

Risiko Eintrittswahrscheinlichkeit (vor Mitigation)SchutzzielKommentare
1234
G 0.1Feuer möglich--MAunwahrscheinlich dass mehrere Standorte gleichzeitig betroffen sind.
G 0.2Ungünstige klimatische Bedingungen unwahrscheinlich--MAnoch im zulässigen Betriebsbereich.
G 0.3Wasser möglich--MAunwahrscheinlich dass mehrere Standorte gleichzeitig betroffen sind.
G 0.4Verschmutzung, Staub, Korrosion möglich--MADer Staubsauger wird tatsächlich benutzt
G 0.5Naturkatastrophen (z.B. Überschwemmung, Erdbeben, Vulkanausbruch) unwahrscheinlich--MAÜberschwemmung: ein Standort 20m, der andere 13m oberall des Rheins – da braucht es sehr viel Wasser. Außer bei Erdbeben unwahrscheinlich, dass mehrere Standorte betroffen sind. Erdbeben: alle wichtigen Daten sind nicht nur gesichert, sondern sowohl auf SSD als auch als Backup auf herkömmlichen Festplatten redundant gespeichert. Ausnahmen sind Fotos, Videos, Musik und DVDs.
G 0.6Katastrophen im Umfeld sehr unwahrscheinlich--AATerrorangriff auf Philippsburg oder Krieg nicht mitigiert – da haben wir dann ganz andere Probleme.
G 0.7Großereignisse im Umfeld unwahrscheinlich--MAKein Standort innenstadtnah.
G 0.8Ausfall oder Störung der Stromversorgung (einschließlich Überspannung z.B. durch Blitzschlag)1/a--MAUnwahrscheinlich dass mehrere Standorte gleichzeitig betroffen sind.
G 0.9Ausfall oder Störung von Kommunikationsnetzen1/a--MAUnwahrscheinlich dass mehrere Standorte gleichzeitig betroffen sind.
G 0.10Ausfall oder Störung von Versorgungsnetzen möglich--MAStrom und Internet siehe G 0,8 und G.09, Rest hat wenig Einfluss auf meine Infrastruktur.
G 0.11Ausfall oder Störung von Dienstleistern möglich--MAUnwahrscheinlich dass mehrere Dienstleister gleichzeitig betroffen sind.
G 0.12Elektromagnetische Störstrahlung möglich--MADie wichtigsten Server haben tatsächlich noch ein Metallgehäuse.
G 0.13Abfangen kompromittierender Strahlung unwahrscheinlich----Sehe mich nicht als Angriffsziel. Bildschirme von außen nicht einsehbar plaziert.
G 0.14Ausspähen von Informationen (Spionage)eher unwahrscheinlichAM--Sehe mich nicht als Angriffsziel, glaube aber auch dass mir nicht so leicht ein Trojaner untergeschoben werden kann.
G 0.15Abhören (einschließlich Netzwerkzugriff) möglich-M--Sehe mich nicht als Angriffsziel
G 0.16Diebstahl von Geräten, Datenträgern oder Dokumenten möglichM-MAVerschlüsselung: keine Offenlegung. Datensicherung: allenfalls geringer Datenverlust. Verfügbarkeit bei Servern kritischer.
G 0.17Verlust von Geräten, Datenträgern oder Dokumenten (einschließlich Hardware oder Softwaredefekt und Benutzerfehlern) wahrscheinlichM-MAAuch ein Admin macht Fehler – Wiederherstellung aus einer Sicherung wird verwendet.
G 0.18Fehlplanung oder fehlende Anpassung möglich--AADas ist ein Sammelbecken unterschiedlichster Probleme.
G 0.19Offenlegung schützenswerter Informationen möglichMM--Auch vertrauliche Korrespondenz auf Papier geht in den Aktenvernichter.
G 0.20Informationen oder Produkte aus unzuverlässiger Quelle möglich----Adblocker und organisatorisch.
G 0.21Manipulation von Hard- oder Softwareunwahrscheinlich--MAAngreifer muss reinkommen und ggfs. Verschlüsselung überwinden.
G 0.22Manipulation von Informationen unwahrscheinlich--MAAngreifer muss reinkommen und ggfs. Verschlüsselung überwinden.
G 0.23Unbefugtes Eindringen in IT-Systeme unwahrscheinlich--MAAngreifer muss reinkommen und ggfs. Verschlüsselung überwinden.
G 0.24Zerstörung von Geräten oder Datenträgernmöglich--MARegelmäßige Datensicherung.
G 0.25Ausfall von Geräten oder Systemen möglich--MATeilweise Monitoring.
G 0.26Fehlfunktion von Geräten oder Systemen möglich--MA
G 0.27Ressourcenmangel wahrscheinlich--MATatsächlich stoßen meine Server an die Belastungsgrenze.
G 0.28Software-Schwachstellen oder -Fehler möglich--MASicherheitsrelevante Patches werden zeitnah eingespielt. Für selbstentwickelte Software gibt es Tests die Funktionen und Sicherheitsanforderungen überprüfen. Für Fremdsoftware gibt es das nicht, da wird stattdessen auf Datensicherung und teilweise redundante Auslegung geachtet.
G 0.29Verstoß gegen Gesetze oder Regelungen unwahrscheinlich----
G 0.30Unberechtigte Nutzung oder Administration von Geräten und Systemen unwahrscheinlichM--A
G 0.31Fehlerhafte Nutzung oder Administration von Geräten und Systemen möglich--MA
G 0.32Missbrauch von Berechtigungen möglich--MAIn einem 1-Mann Unternehmen eher kein Problem.
G 0.33Personalausfall möglich---AIn einem 1-Mann-Unternehmen ein reales Problem.
G 0.34Anschlag unwahrscheinlich--MASehe mich nicht als Angriffsziel.
G 0.35Nötigung, Erpressung oder Korruption unwahrscheinlichA-M-Wer kann schon vorhersagen, was er macht, wenn einem eine Pistole unter die Nase gehalten wird?
G 0.36Identitätsdiebstahl unwahrscheinlich--MA
G 0.37Abstreiten von Handlungen unwahrscheinlich--MA
G 0.38Missbrauch personenbezogener Daten unwahrscheinlich--MA
G 0.39Schadprogramme möglich--MA
G 0.40Verhinderung von Diensten (Denial of Service) möglich---ABisher nur beim Mailserver beobachtet.
G 0.41Sabotage unwahrscheinlich--MA
G 0.42Social Engineering unwahrscheinlich--MA
G 0.43Einspielen von Nachrichten unwahrscheinlichMMMA
G 0.44Unbefugtes Eindringen in Räumlichkeiten (Einbruch, Diebstahl) unwahrscheinlichM-MAKeine Wertgegenstände vorhanden. Computer eher Beifang.
G 0.45Datenverlust möglich--MARegelmäßige Datensicherung.
G 0.46Integritätsverlust schützenswerter Informationen möglich-MMAÜbertragung durch Verschlüsselung geschützt. Server haben ECC-RAM. Sonst Datensicherung.
G 0.47Schädliche Seiteneffekte IT-gestützter Angriffeunwahrscheinlich--MA
In der Tabelle oben bedeutet
-
nicht relevant
M
mitigiert. In Spalte 1+2 bleibt natürlich ein Restrisiko falls Schwachstellen existieren und ausgenutzt werden. In Spalte 3 heißt das mindestens, ein regelmäßiges Backup existiert. Es gehen also maximal die Daten verloren, die seit der letzten Sicherung entstanden oder geändert wurden. Auch hier bleibt immer ein Restrisiko, aber die Datensicherung wird sporadisch überprüft.
A
akzeptiert. In Spalte 4: in Ausnahmefällen besteht Redundanz. Das steht dann unter Anwendungssicherheit.

Physische Sicherheit

Hier glänzen andere Konzepte: Beton, Zaun, Videoüberwachung, biometrische Zugangskontrolle, etc.. – aber hilft das wirklich? Alle Berichte über Team-Reds sagen: Nein. Wer rein will, kommt auch rein. Ggfs. lässt er sich anstellen, direkt oder bei einem Subunternehmer, beim Reinigungspersonal oder Servicediensten. Oder er besticht oder bedroht jemanden, der schon rein darf. Die Hülle kann bremsen, aber den Zugang nicht verhindern. Ich halte daher Verschlüsselung für Pflicht.

Meine Systeme stehen in normalen Wohnungen. Die Haustür öffnet irgendein Nachbar für jeden Boten, die Wohnungstür ist natürlich bei Abwesenheit verschlossen, aber mit dem richtigen Akkubohrer bestimmt überwindbar. Bin ich zuhause und jemand überwältigt mich, dann ist der Angreifer auch drinnen. Nur gibt es nicht wirklich etwas zu holen, weder Wertsachen noch (unverschlüsselte) Daten

Netzwerk und Netzwerksicherheit

Auch hier eine andere Philosophie: anders als der BSI-Grundschutz gehe ich davon aus, dass das Netzwerk unsicher ist und allenfalls Defense-in-Depth unterstützt. Insbesondere sind Clients unabhängig von Netzwerkfirewalls sicher zu konfigurieren (leider keine Anforderung im Grundschutz) – dazu muss ich mal noch einen eigenen Artikel veröffentlichen. Erst die Verschlüsselung mit https oder TLS sorgt für eine Authentifizierung des Servers und sichere Kommunikation. Wenn man mögliche Schwachstellen in der verwendeten Software vernachlässigt, dann sind nur aufgrund des Zugangs zum lokalen Netz keine nicht-öffentlichen Informationen zugreifbar.

Das Netzwerk besteht aus mehreren lokalen Netzwerken an verschiedenen Standorten, je einem virtuellen Systemen bei Netcup und 1fire, sowie einigen mobilen Clients, die alle über ein Wireguard-VPN verbunden sind. Nach außen ist das Netzwerk durch Firewalls getrennt, die für IPv4 NAT verwenden. Einige lokale Router verwenden auch IPv6, das VPN jedoch nicht. Zusätzlich existiert ein SSTP Einwahlpunkt für mobile Nutzer, der gegen das Active Directory authentifiziert.

Alle Einstiegsknoten – die Router der lokalen Netzwerke sowie die beiden virtuellen Systeme – haben natürlich eine aktive Firewall und lassen nur Anfragen auf bestimmten Ports und unter Verwendung von NAT in das VPN, bzw. auf Port 443 laufen Nginx-basierte Proxies die anhand von SNI Verbindungen unter Verwendung des Proxy-Protokolls an andere Dienste weiterreichen. Dienste die nach außen exponiert werden: SMTP (Port 25 und 587 – Submission), IMAP (143), HTTP (80, nur für Letsencrypt, sonst redirect auf HTTPS), HTTPS (443 – diverse Dienste), SSH (insbesondere auf allen VPN-Routern), Lindenberg Backup (https basiert).

Netzwerk

Jedes lokale Netzwerk hat einen DHCP-Server für IPv4 (meist der Router, in der Heubergstraße anders) der leider auch ein SPoF insbesondere für mobile Clients ist. Einige Server haben daher eine feste IP-Adresse (leider muss dann auch die Routingtabelle redundant gepflegt werden). Typisch sind Ausfälle des DHCP-Servers aber eigentlich nur als Folge eines Software-Updates des Routers oder eines Stromausfalls – und dann geht meist auch anderes nicht mehr. Ich hatte eine Zeitlang eine unterbrechungsfreie Stromversorgung im Einsatz – nur hat die leider öfter Fehlalarme ausgelöst als die Stromversorgung sichergestellt.

Es ist ganz klar, dass die lokalen Netzwerke die Achillesferse für alle Dienste sind – fallen lokale Netzwerke aus, egal ob durch Stromausfall, Ausfall der Internetverbindung, oder Ausfall von Hardware (Router oder Switches), dann geht fast nichts mehr. In normalen Wohngebäuden sind redundante Einspeisungen von Strom und Internet aber meist nicht vorhanden, selbst Kabel-Internet und DSL wird vom gleichen Bagger oder Stromausfall abgeschaltet. Die einzige Alternative wäre mobiles Internet – aber das ist bei einem Datenvolumen von ca. 1TB/Monat nicht wirtschaftlich.

Auch liefert das lokale Netzwerk keinen Beitrag zur Verteidigung gegen Denial-of-Service-Attacken durch Überlastung der Netzwerkanbindung. Dazu müsste man Paketfilter auf ISP-Seite beeinflussen können – bisher nicht bekannt dass das einer anbietet, bisher aber auch keine derartige Attacke beobachtet.

Das externe DNS wird von Cloudflare erbracht, einschließlich DNSSEC. Das interne DNS wird je nach Standort oder System entweder vom Router oder (ohne DNSSEC) von drei Linux-Systemen mit jeweils Bind9, Samba-AD-DC, Pi-Hole, und Stubby erbracht, Stubby verwendet dann DoT um alle Anfragen verschlüsselt durchzuführen. Der Emailserver hat seinen eigenen rekursiven DNS-Resolver (Unbound).

FrageAntwort
Warum kein oder nur eingeschränkt IPv6?Das schöne an IPv4 ist, dass NAT Standard ist (sonst wäre IPv4 schon lange tot) – intern werden private Adressen vergeben und die kann man bei Diensten fest vorgeben. Bei IPv6 ist NAT zumindest unüblich und wird von SoHo-Routern nicht unterstützt. Aber auch bei IPv6 ändern sich die Adressen gelegentlich, und dann sind die fest vorgegeben Adressen falsch. Und selbst wenn man dynamische Adressen verwendet und jedes System sich aktiv im Directory registriert – es dauert eine Weile bis die Kommunikation wieder rund läuft. Also kein Gewinn. Theoretisch kann man eigene IPv6-Adressen zukaufen, aber das müsste dann auch der typische Provider und ein typischer Router unterstützen.
Warum kein DNSSEC intern? 1. Mein DNS ist Split-Horizon, d.h. Anfragen für einige Dienste liefern intern andere Adressen als extern – damit interne Kommunikation mit Gigabit-Geschwindigkeit läuft und nicht einen Umweg über einen oder mehrere Router oder gar den ISP nehmen muss. Das schicke an DNS über Cloudflare ist, dass es so einfach ist. Das weniger schicke ist, dass der private Schlüssel zum Signieren der DNS-Einträge nur Cloudflare bekannt ist. Ich müsste die internen Zonen dann richtig delegieren und damit auch einen DNS-Server nach außen exponieren – das ist insgesamt mehr Angriffsfläche als Nutzen. Oder IPv6 verwenden, aber siehe oben.
2. Windows-Client sind zwar "security-aware" (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn593685(v=ws.11)) aber haben keinen eigenen validierenden Client. Man kann dafür IPsec umsetzen (ganz viel Aufwand), einen validierenden Client nachrüsten (z.B. YogaDNS unten) oder DoT/DoH nutzen (nächster Abschnitt), aber gewinnt damit nicht viel. Die richtig harte Nuss hier ist, dass die meisten Clients heute mobil sind, sich also typischerweise eine dynamische IP-Adresse über DHCP zuweisen lassen und dabei auch Informationen über Router und DNS-Server bekommen. Bei IPv6 technisch etwas anders, aber im Ergebnis das selbe. Diese Autokonfiguration ist leider sehr praktisch aber auch unsicher. Wenn ich in einem angegriffenen Netzwerk meinen eigenen DHCP- und DNS-Server einschleußen kann, dann kann ich den "security-aware" Clients auch gefälschte Validierungsergebnisse unterschieben. Will man mehr, dann muss einen eigenen lokalen DNS-Resolver installieren (z.B. YoaDNS unten), der den per DHCP mitgeteilten ersetzt und mindestens validiert oder eine authentifizierte und verschlüsselte Verbindung zu einem validierenden DNS-Server aufbaut. Schwierig wird dann zu wissen, auf welcher Seite des Split-Horizons man gerade ist, oder man muss ggfs. den Performance-Nachteil in Kauf nehmen.
Da nach den Sicherheitsanforderungen alle Verbindungen höherer Schichten mit TLS geschützt sein sollen, und dabei eine Authentifizierung mit Zertifikaten stattfindet, wäre DNSSEC intern auch nur Defense-in-Depth. Wichtig ist DNSSEC für die qualifizierte Transportverschlüsselung (siehe Email-Verschlüsselung).
Warum kein DoT/DoH intern? Leider gibt es dafür noch keine wirklich geeigneten Standards und Produkte.
1. Für mobile Clients gibt es keine Möglichkeit, über DHCP einen DoT/DoH Server zu verteilen (ungeachtet der Tatsache, dass DHCP selbst unsicher ist).
2. DoH kann Windows erst ab Windows 11, und die Konfiguration ist je DoH-Server-IP-Adresse auf jedem Client. Noch nichtmal Group-Policies werden unterstützt.
3. Stubby auf Windows ist offensichtlich noch nicht ausgereift (s. u.a. Known Issues).
4. YogaDNS kann kein DNS-TCP (wird bei mir benötigt).
Da stehen Aufwand und Nutzen noch in keinem gesunden Verhältnis – ein Angreifer (Neugieriger) müsste im lokalen Netz sein. Für mein Mobiltelefon und den "Reise-Laptop" nutze ich daher das Wireguard-VPN und gebe in der Wireguard-Konfiguration meinen eigenen DNS-Server vor – damit habe ich unterwegs DoT ohne dass alle stationären Clients konfiguriert werden müssen.
Warum Wireguard? Siehe https://www.wireguard.com/. Weniger Komplexität und bessere Geschwindigkeit (siehe auch Bruce Schneier über Komplexität in "Secrets and Lies" und "Click Here to Kill Everybody"). Die Tatsache dass Wireguard evtl. nicht Grundschutz NET.3.3 (VPN) erfüllt hat aufgrund der untergeordneten Relevanz für Sicherheit keine Bedeutung. Da das Netzwerk alleine kein Schutzziel realisiert sondern im wesentlichen eine private Adressierung aufgespannt wird, ist das völlig egal.
Warum Softether?Minimaler Installations- und Konfigurationsaufwand unter Windows, und funktioniert in jedem Hotel-, Firmen, oder sonstigen (W)LAN auch mit Captive-Portals oder strikten Firewalls. Nachteil natürlich der mögliche TCP-Meltdown, der garantiert eintritt, wenn der ICE durch einen Tunnel fährt.
NAT fail over?Die VPS sind weitgehend identisch konfiguriert, und alles was über nginx bedient wird ist damit redundant. Leider gilt das für SMTP und IMAP nicht, weil die nicht über zwei TCP-Verbindungen mit Proxy-Protokoll zusammengeschaltet werden sondern direkt auf IP-Ebene mit NAT. Und es ist ein NAT-inherentes Problem, dass es nicht zwei aktive NAT-Router im Netzwerk für die gleiche Routinginformation gleichzeitig geben kann (RFC 3022, Introduction, There are limitations to using the translation method. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT router.). Theoretisch kann man bei postfix und dovecot – den Diensten in Mailcow – auch bei eingehenden Verbindungen das Proxy-Protokoll verwenden, aber leider ist das bei Mailcow nicht vorgesehen (vermutlich trotzdem möglich). Für abgehende SMTP Verbindungen kann in der Wireguard-Konfiguration definiert werden, über welchen VPS abgehender Verkehr geroutet werden soll. Denkbar ist, den abgehenden Verkehr zu monitoren und bei Netzwerkproblemen automatisch umzuschalten (und auch den MX-Record im DNS oder bei SPF beide VPS eintragen). Ein Problem lässt sich aber nicht beheben: die Tatsache, dass Netcup häufiger auf Blacklisten steht als 1fire. Insgesamt: da Mail konzeptionell kein interaktiver Dienst ist, stehen hier Aufwand und Nutzen in einem deutlich schlechteren Verhältnis als bei den Webseiten.

Systemsicherheit

Es gibt im lokalen Netzwerk fünf Klassen von Systemen:

(1)Netzwerk-Geräte
z.B. Vodafone-Station, Fritzboxen, Switches, Accesspoints. Generell werden Netzwerk und Netzwerk-Geräte nicht als vertrauenswürdig angesehen, auch unabhängig von WLAN-Verschlüsselung oder (zur Zeit nicht aktiver) Network-Access-Control (NAC, WPA2 Enterprise, EAP). Alle konfigurierbaren Netzwerkgeräte sind mit starken Passwörtern geschützt. Diese Geräte Speichern keine sensiblen Daten sondern lediglich die notwendige Konfiguration. Ausnahme: Fritzboxen speichern auch eine Anrufliste und ein Telefonbuch. Positiv bei diesen Geräten ist, dass sie meist hoch-integriert sind und keine auswechselbaren Datenträger enthalten. Man kann sie zwar auf den Auslieferungszustand zurücksetzen, aber ohne Kenntnis des Passworts nur schlecht manipulieren. Schlecht: bei manchen Geräten keine vertrauenswürdigen Zertifikate oder kein https.
(2) Virtuelle Private Server
Über eine Verschlüsselung der virtuellen privaten Server bei Netcup und 1fire steht nichts im jeweiligen Auftragsverarbeitungsvertrag. Auf den VPS werden nur Daten für die externen Webseiten sowie Konfigurationsdaten (einschließlich Zertifikaten) und Zugriffsprotokolle für diese gespeichert. Vertrauliche Daten werden nicht dort gespeichert. Webseiten die Zugriffskontrolle erfordern (career.lindenberg.one) verwenden einen Authentifizierungsmechanismus der per Single-Sign-On Daten des Active Directory verwenden kann, das aber selbst nicht auf diesen Systemen läuft.
(3) Physische Windows-Systeme
Alle physischen Windows-Systeme sind mit Bitlocker geschützt. Alle Schlüssel sind im Active Directory gesichert. Dabei werden verschiedene Entsperrkonzepte verwendet:
a) TPM onlyLaptopsDas Startvolume wird mittels TPM entsperrt. Die Benutzerverzeichnisse werden ggfs. zusätzlich mit EFS verschlüsselt.
b) Key-StickServerDas Startvolume wird mittels getrennt aufbewahrtem Stick entsperrt. Alle weiteren Volumes mit gesicherten Keys auf dem Startvolume.
c) TPM + Remote-EntriegelungServerDas Startvolume wird mittels TPM entsperrt. Die Benutzerverzeichnisse werden ggfs. zusätzlich mit EFS verschlüsselt. Für alle anderen Volumes wird der Key von einem AD-basierten-Service geladen. Im Falle eines Diebstahls oder anderen Verlusts wird der Zugriff im AD gesperrt.
d) TPM + PIN bzw. Bitlocker Network UnlockServerDas Startvolume wird mittels TPM + PIN oder Bitlocker Network Unlock entsperrt. Alle weiteren Volumes mit gesicherten Keys auf dem Startvolume. Details unten unter Bitlocker Network Unlock.
Die Varianten a)-c) sind historisch bedingt. Es ist geplant, zumindest alle Server mit d) zu vereinheitlichen.

Alle physischen Systeme werden regelmäßig automatisch gesichert, teilweise mehrfach am Tag und auch außer Haus. Zum Einsatz kommt dabei meine eigene Backup Software. Die Planung der Backups findet meist mit Axonet Lights-Out statt, Monitoring ebenfalls mit Lights-Out sowie Email-Benachrichtigungen meiner Software.
(4)Virtuelle Systeme
Virtuelle Maschinen (Windows und Linux) werden mit Hyper-V auf Systemen nach (3) betrieben. Mit Ausnahme zweier VPN-Router-VM nur auf Systemen mit Entsperrkonzepten b) bis d), die Router-VMs laufen auf a).
(5) Sonstige Geräte
Sonstige Geräte, z.B. Besucher oder Kunden – hier kann naturgemäß keine allgemeingültige Aussage getroffen werden.

Kundendaten oder personenbezogene Daten mit Ausnahme der Zugriffsprotokolle der Webserver (2) bzw. der Telefonliste der Fritzbox (1) werden nur auf Systemen (3) – Entsperrkonzepte b) bis d) – und (4) gespeichert. Durch die Verschlüsselung der Systeme (3) ist sichergestellt, dass physischer Zugriff auf die Systeme keinen Zugriff auf die gespeicherten Daten ermöglicht. Durch die Datensicherung ist sichergestellt, dass nur kleine Deltas verloren gehen können.

Alle Systeme nach (2) bis (4) sowie die Fritzboxen erhalten regelmäßig Updates.

Bitlocker Network Unlock

Die Dokumentation von Microsoft zu Bitlocker Network Unlock ist nicht besonders gut, einige Schritte und vor allem die Problembeseitigung ist an unterschiedlichsten Stellen beschrieben, insofern ist Fleiß und Ausdauer gefragt, Bitlocker Network Unlock an den Start zu bringen. Irgendwann tut es dann – oder auch nicht. Wirklich essentielle Anforderungen sind ein UEFI BIOS ohne Legacy-Unterstützung und mit Netzwerk-Stack für mindestens einen Netzwerkadaper – daran scheitern einige meiner alten PCs und auch jeder neue Laptop mangels eingebauter Ethernetschnittstelle. Auch nicht so ganz klar ist in der Dokumentation, was man tun soll, wenn ein Computer geklaut wird und vielleicht doch noch den Windows Deployment Server erreichen könnte. Der Insider weiß oder ahnt es: das Zertifikat tauschen, und tatsächlich kann der Windows Deployment Server daher auch mehrere Zertifikate, das jeweils für den Client relevante wird im [MS-NKPU]: Network Key Protector Unlock Protocol über den Hash des Zertifikats identifiziert. Normalerweise nur eines oder beim Zertifikatswechsel zwei, aber irgend eine Grenze ist nicht dokumentiert.

Normalerweise wird man ein oder für Redundanz auch zwei Windows Deployment Server installieren, die ein großes Rechnenzentrum versorgen, und dann unterstellen, dass ein Angreifer oder Einbrecher nicht sowohl einen Server mit kritischen Daten als auch einen der Windows Deployment Server unter seine Kontrolle bringt oder mitnimmt. Dann reichen diese getrennten Systeme, die nur gemeinsam die Schlüssel bereitstellen können, völlig aus. Da bei mir aber die gesamte Infrastruktur auf wenigen Quadratmetern steht und außerdem remote erreichbar ist, reicht mir das nicht aus. Und im Unterschied zu typischen Rechenzentren hab ich auch keine Notstromversorgung sondern allenfalls ein paar Akkus, und ich betrachte es nicht als ausgeschlossen, dass ein wirklich versierter Angreifer von außen auf das LAN zugreift.

Ich habe daher zwei zusätzliche Mechanismen realisiert:

  • Der Windows Deployment Server wird heruntergefahren, wenn der Host länger als fünf Minuten keinen Strom oder kein (lokales) Netzwerk hat. Richtig, der Windows Deployment Server läuft auf einem alten Laptop, damit er auch einen kurzzeitigen Stromausfall überlebt (die allermeisten Stromausfälle sind sehr kurz), und dann den anderen Systemen beim Wiederanlauf Schlüssel liefern kann. Zum Wiederanlauf nach einem Stromausfall von mehr als fünf Minuten braucht es dann einen Eingriff eines Administrators.
  • Der Windows Deployment Server authentifiziert den Client normalerweise nicht, man kann allenfalls auf Basis von Netzwerkadressen einschränken. Ich wollte aber Clients einzeln berechtigen oder auch sperren können. Die einzige Information die Clients dem Server über das Protokolll bekanntgeben ist der Hash des Zertifikats. Also generiere ich für jeden Client (bisher eine einstellige Anzahl) ein eigenes Netzwerk-Entsperr-Zertifikat (und damit auch eindeutige Hashes) und da der Windows Deployment Server mit mehreren Zertifikaten umgehen kann, bekommt jeder Client die richtigen Schlüssel geliefert. Löscht man aber das entsprechende Client-Zertifikat auf dem Windows Deployment Server, dann wird der Client effektiv ausgesperrt und man muss auf dem Client die PIN eingeben.

Und noch zwei Probleme, die haben aber auch manche Rechenzentren:

  • da meine Server an verschiedenen Standorten stehen, braucht es entweder an jedem Standort einen Windows Deployment Server (und auch einen vertrauenswürdigen Server mit Akku), oder es braucht einen Bootp-Relay-Dienst, der Bootp-Anfragen an den zentralen Windows Deployment Server weiterschickt. Zum Einsatz kommt zur Zeit der dhcp-helper von Simon Kelley. Dummerweise bei mir via VPN, d.h. es macht ganz bestimmt keinen Sinn, auch DHCP zu relayen (und geht aufgrund der Ziel-IP-Adresse auch ins Leere), und leider kann keine der mir bekannten Standarddienste das auf DHCP einschränken. Da muss ich evtl. noch einen Filter realisieren. Dieses Problem kann man aber sogar zum Sicherheitskonzept befördern, denn man kann erreichen, dass Windows Deployment Server und die dadurch bedienten Server an verschiedenen Standorten stehen.
  • UEFI BIOS kann in der Regel nicht ein konkretes VLAN konfigurieren. Da ich bisher VLANs bei Hyper-V verwende, muss ich teilweise nach einer anderen Lösung dafür suchen. Auf manchen Systemen braucht es das nicht, andere benötigen dafür einen 2. Netzwerkadapter.

Sicherheitsanforderungen?

Klar, Authentifizierung des Clients findet nicht mit seinem X.509 Zertifikat oder Kerberos statt, und die Kommunikation ist auch nicht mit TLS verschlüsselt sondern nutzt ein anderes Verfahren, dokumentiert in [MS-NKPU]: Network Key Protector Unlock Protocol. Strenggenommen wird der Client im Protokoll gar nicht authentifiziert sondern – in meiner Variante – nur identfiziert, aber die Übertragung findet verschlüsselt statt, und nur wenn Informationen im TPM des Client vom privaten Schlüssel des WDS entschlüsselt werden können klappt der Zugriff auf die verschlüsselte Festplatte – und an der Stelle kann man dann auch sagen der Client wurde authentifiziert.

Restrisiko?

Ein Windows Computer ohne Bitlocker oder andere Verschlüsselung ist ungeschützt gegenüber einem Angreifer der physischen Zugang zum Computer oder der Festplatte hat. Es gibt genügend Anleitungen im Internet wie man sich auf so einem Computer Administratorrechte verschaffen kann. Dieser triviale Zugang ist mit Bitlocker versperrt. Mit Bitlocker und "TPM only" bleiben die Angriffsvektoren "Auslesen des TPMs" und "Cold boot attack", wobei ein Angreifer der den Computer mitnimmt dafür beliebig viel Zeit hat. Mit allen Varianten von Pre-Boot-Authentication, darunter fallen auch TPM+PIN und Network Unlock, bleibt nur noch "Cold boot attack" und auch nur für ein Zeitfenster in dem das System ausreichend gekühlt wird. Der Angriff kann teilweise mit dem BIOS weiter erschwert aber nicht vollständig ausgeschlossen werden. Auch erschwert Secure Boot und Measured Boot das Einbringen von Malware in den Bootprozess, aber natürlich bleibt jedes System gegen Trojaner anfällig die ein Administrator oder ein Angreifer mit physischem Zugang installiert. Nur dass die Schwierigkeit eines Angriffs von trivial auf schwierig erhöht wurde.

Group Policies

Alle Windows Systeme werden soweit möglich und sinnvoll mit Group Policies konfiguriert, u.a. Firewall, Screensaver, Verschlüsselung von Shares, Bitlocker, Updates, Remote Desktop mit Network Level Authentication, etc..

Anwendungssicherheit

Die folgende Tablle listet ggfs. Abweichungen von den Sicherheitsanforderungen (ohne auf alle Details einzugehen) bzw. wesentliche Informationen zur Umsetzung der Schutzziele 1 und 2 sowie ggfs. Schutzziel 4. Schutzziel 3 muss nicht betrachtet werden denn das wird durch die Datensicherung einheitlich adressiert.

AnwendungSchutzziele 1 und 2Schutzziel 4
Bitlocker Network Unlocksiehe oben Zur Zeit ein Server, aber es könnte auch redundante geben.
Active Directory und internes DNSActive Directory authentifziert und verschlüsselt mit Kerberos (s. What Is the Active Directory Replication Model?). Internes DNS wird ohne DoT/DoH und ohne DNSSEC erbracht (siehe dazu auch die Bemerkungen im Abschnitt Netzwerk und Netzwerksicherheit). Active Directory und internes DNS ist natürlich kritisch für ganz viele Dienste. Active Directory läuft daher auf drei virtuellen Linux-Systemen mit Samba sowie Bind, Pi-hole und Stubby auf drei unterschiedlichen physischen Servern verteilt auf zwei Standorte. Upgrades werden nicht gleichzeitig sondern nacheinander durchgeführt.
Externes DNS (Cloudflare)Die Konfiguration erfolgt über https. Meine DNS Anfragen werden mit DoT verschlüsselt. Was andere Clienten machen weiß ich nicht. Cloudflare beobachtet gelegentlich DNS-Attacken, und der coole Umgang (Lesenswert : What is a DNS amplification attack? und Deep Inside a DNS Amplification DDoS Attack) damit war Auswahlkriterium für Cloudflare.
Systeme, SSH, Remote Desktop, GuacamoleAlle Windows-Systeme sind Domain-Member und authentifzieren gegen Active Directory, ganz überwiegend via Kerberos, in Ausnahmefällen NTLM2. Linux-Systeme authentifzieren lokal (es existiert sowieso nur ein realer Benutzer). Alle Windows-Systeme und die Domain-Controlller haben ein X.509 Zertifikat passend zum Hostnamen, alle Systeme ggfs. zusätzliche Zertifikate für Dienste die erbracht werden. Alle Linux-Systeme und manche Windows-Systeme sind zur Administration über SSH erreichbar. Die Verschlüsselung von SSH gilt als sicher, die Authentifizierung ist leider weniger praktisch wie Kerberos – aber mit der Kombination SSH+Kerberos experimentiere ich noch. Alle Windows-Systeme sind über Remote Desktop Protokoll erreichbar, dabei wird Network-Level-Authentication (NLA) und Transport-Layer-Security erzwungen. Da vertrauenswürdige Zertifikate vorhanden sind, erscheinen keine Sicherheitswarnungen, wie ich das bei anderen Organisationen immer wieder beobachte. Virtuelle Systeme (Windows + Linux) sind auch über Apache Guacamole erreichbar (s. Guacamole Integration). Physische und virtuelle Systeme können aus den Backups leicht extrahiert werden und ggfs. auf anderer Hardware zur Verfügung gestellt werden. Engpass ist dabei der verfügbare Speicher auf den vorhandenen Virtualisierungshosts. Theoretisch könnte auch die Hyper-V-Replikation verwendet werden, aber für die Replikation zwischen den Standorten reicht dafür die Bandbreite nicht.
DateizugriffAlle Dateisysteme verwenden Standard-Windows-ACLs, Access-Based-Enumeration, und erzwingen Authentifizierung (Kerberos) und Verschlüsselung beim Remote-Zugriff. Dateisysteme oder einzelne Dateien können aus den Backups leicht restauriert werden und zur Verfügung gestellt werden.
WebDAV Verschlüsselung mit https. Leider unterstützt der Internet-Information-Service Access-Based-Enumeration oder Impersonierung nicht konsequent, daher können Benutzer auch Verzeichnisse sehen, auf die sie dann keinen Zugriff haben.
SSTP (Softether)Die Authentifzierung findet via Radius gegen das Active Directory statt. Freeradius läuft wegen der schwachen Radius-Verschlüsselung lokal auf dem Einwahlserver. Zur Zeit keine Redundanz (es gab mal zwei Server). Mit Wireguard und Guacamole bestehen Alternativen und damit Redundanz.
Externe WebseitenVerschlüsselung mit https. Zugriffsprotokolle werden lokal gespeichert. Die externen Webseiten laufen redundant bei Netcup und 1fire.
Formulardienst Verschlüsselung mit https und Proxyprotokoll bis auf den Formularserver. Zur Zeit nicht redundant, für einzelne Formulare wäre es möglich, die meisten hängen aber vom Email-Server ab.
Lindenberg Software BackupDie Übertragung findet per https statt. Dateisystemzugriffe werden auf Windows abgebildet indem der Benutzer wo immer möglich impersoniert wird. Weitere Details unter Security Aspects. Es wird die Resilience-Konfiguration verwendet, die drei Server sind auf zwei Standorte verteilt.
Email-Server (Mailcow)Bei Email reichen die Sicherheitsanforderungen nicht aus bzw. werden an zwei Stellen verletzt: weder DNS noch SMTP bieten eine ausreichende Authentifzierung der Kommunikationspartner. Siehe dazu meine anderen Veröffentlichungen zur Email-Sicherheit, u.a. Email-Verschlüsselung. Zumindest meine eigenen Hausaufgaben habe ich gemacht bzw. bringt die verwendete Software Mailcow und Postfix mit: der Emailserver hat seinen eigenen DNSSEC-validierenden reskurisven DNS-Resolver (Unbound). Es sind keine Netzwerke konfiguriert, die ohne Authentifzierung Emails an nicht-lokale Emails versenden dürfen.
Die Grundeinstellung des Servers ist so, dass er Verschlüsselung erzwingt und auch Zertifikate validiert – aber da gültige Zertifikate leider nicht selbstverständlich sind, findet automatisch ein Fallback statt. Und natürlich erfüllt er RFC 7672 (s.a. RFC 7672 mit Mailcow / Postfix).
Für Mailcow ist leider kein dokumentiertes Hochverfügbarkeits-Szenario verfügbar und die TINC GmbH hat im Zusammenhang mit meiner Anfrage auch keinen Auftragsverarbeitungsvertrag angeboten, und natürlich will ich ohne solchen Vertrag niemanden auf mein System lassen. Als Technikfreak habe ich selbst recherchiert und nach dem letzten Internetausfall Redundanz realisiert – gerade im Pilotbetrieb. Auch existiert ein Inbound-Relay das notfalls Emails von außen entgegennehmen und zwischenspeichern kann.
TelefonieVerschlüsselung ist ein Sorgenkind weil sie noch nicht von allen VOIP-Anbietern unterstützt wird, s. z.B. Ist eine SRTP/TLS Sprachverschlüsselung möglich? von Sipgate. Leider muss ich feststellen, dass die Bundesnetzagentur da keine klaren Forderungen aufstellt – suchen Sie doch mal im Katalog von Sicherheitsmaßnahmen den die Bundesnetzagentur auf meine Anfrage geliefert hat nach "Verschlüssel(ung)" – maximal ein "soll", kein "muss", oder Verweis auf den Stand der Technik. Wer definiert den? Manche sagen das Bundesamt für Sicherheit in der Informationstechnik (BSI), und das verlangt ja auch wenig, siehe Ist Verschlüsselung Pflicht?. Es sind je nach Telefonnummer teilweise mehrere Endgeräte und auch Anrufbeantworter registriert, so dass der Mensch und ggfs. Mobilfunkabdeckung der Engpass bleibt.
Es existiert keine zentrale Erfassung von sicherheitsrelevanten Ereignissen. Bisher beobachtet in den jeweiligen Logs:
  • Versuche auf den Wordpress-Admin-Bereich von externen Webseiten zuzugreifen – nur dass da gar kein Wordpress verwendet wird.
  • Versuche sich auf dem Email-Server mit Standard-Usern/Passwörtern anzumelden. Mailcow macht dann einen fail2ban (leider erst im Docker-Netzwerk) auf die entsprechenden IP-Adressen.
  • Versuche auf Port 22 zuzugreifen – aber SSH läuft nach außen nicht auf Port 22
  • Versuche auf den Port von Lindenberg Software Backup zuzugreifen – aber weil das offensichtlich Skript-Kiddies aufgrund von Port-Scans machen stimmt schon der Hostname nicht.
  • Versuche auf den Email-Test-Service (siehe Emailsicherheit – der Test) zuzugreifen – da dieser Dienst vergleichsweise viel mitschreibt waren die Versuche ihn als offenes Relay zu missbrauchen sehr ärgerlich. Daraufhin habe ich die Firewall wie in How to make iptables rules expire? instrumentiert. Der klassische Fail2Ban-Weg passte nicht, weil der Dienst und die Firewall auf verschiedenen Systemen angesiedelt sind. Ich beobachte auch Versuche, http(s) oder ftp mit dem Service (Port 25) zu kommunizieren, diese Versuche sind aber so niederfrequent, dass mir Maßnahmen über die Eingabevalidierung hinaus (siehe Sicherheitsanforderungen) bisher unnötig erschienen.

Keine anderen Unregelmäßigkeiten. Daraus schließe ich dass ich kein Angriffsziel von professionellen Hackern bin.


Zuletzt geändert am 24.07.2022.

© 2022 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.