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
• Physische Sicherheit
• Netzwerk und Netzwerksicherheit
• Systemsicherheit
  • Bitlocker Network Unlock
  • Group Policies
• Anwendungssicherheit

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)?

-

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. Tatsächlich ist mir die Vertraulichkeit wesentlich wichtiger als die Verfügbarkeit, das wird dann auch bei der Alarmanlage und Bitlocker-Network-Unlock klar erkennbar.

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.

Natürlich gibt es einen Rauchwarnmelder – sind ja in Wohngebäuden vorgeschrieben. Und ich habe eine Alarmanlage basierend auf Smart-Home-Komponenten im Testbetrieb, die unerwartete Besucher erkennt und Komponenten herunterfahren kann und – geplant – den Strom der IT-Systeme abstellen könnte. Einen virtuellen Notaus-Knopf gibt es auch, aber die Intention ist eher nicht identisch mit der von INF.2.A4 des Grundschutz-Kompendiums. Dazu mehr unter Restrisiko Bitlocker Network Unlock.

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.

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).

Jedes lokale Netzwerk hat mit dem Router einen DHCP-Server für IPv4 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).

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, wobei für alle meine Systeme TPM + PIN und Bitlocker Network Unlock verwendet wird. Alle Schlüssel sind im Active Directory gesichert. 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.

(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) 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 nach Schwachstellen-Management.

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 (WDS) wird unter der Kontrolle der Alarmanlage heruntergefahren, wenn diese etwas verdächtiges erkennt. Dabei laufen Alarmanlage und WDS 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. Wird das Abschalten durch die Alarmanlage initiiert, bedarf es den 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. Ich habe mich daher von VLANs wieder verabschiedet, zumal die in meinen Augen keinen ernsthaften Beitrag zur Sicherheit leisten.

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 kurzes Zeitfenster in dem das System ausreichend gekühlt wird. Der Angriff kann teilweise mit dem BIOS weiter erschwert aber nicht vollständig ausgeschlossen werden. Wenn meine Alarmanlage produktiv geht, wird das Restrisiko weiter reduziert, denn im ausgeschalteten Zustand ohne Kühlung vergessen die Systeme ganz schnell die Verschlüsselungsschlüssel und neue bekommen sie nicht.

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.

• Versuche auf den Wordpress-Admin-Bereich von externen Webseiten zuzugreifen – nur dass da gar kein Wordpress verwendet wird.
• Versuche auf Port 22 zuzugreifen – aber SSH läuft nach außen nicht auf Port 22.
• Versuche sich auf dem Email-Server mit Standard-Usern/Passwörtern anzumelden. Mailcow macht dann einen fail2ban (im Standard erst im Docker-Netzwerk) auf die entsprechenden IP-Adressen. Die IP-Adressen aus dem fail2ban werden via API und How to make iptables rules expire? auf die VPS gespiegelt und bremsen dort die Versuche aus. Überlegt hatte ich auch, für imap und submission nur deutsche Netze in eine Whitelist aufzunehmen, aber die Liste ist so groß, dass die Firewall konfigurieren sehr langsam wird.
• 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 auch hier 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.
• 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. Weil das aber auch protokolliert wurde findet inzwischen eine Filterung auf Basis der Netzwerkadressen statt.

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