Update-Dokumentation

[cosinus]

Hi,

hat sich schonmal jemand mit der Dokumentation der Updates also Patchmanagement beschäftigt?

Es geht darum, dass bei uns im Büro diverse Server in Betrieb sind - sowohl Linux als auch Windows. Angenommen wir haben trotz aller Sicherheitsmaßnahmen nun doch einen Ransomwarebefall und melden diesen Schaden unserer Versicherung, dann will diese ja wissen, ob wir unsere Server rechtzeitig auf dem aktuellen Stand brachten.

Hat da jemand eine Idee wie man sowas machen kann? Handschriftlich einen Plan so eine Art "Update-Einspielkalender" an eine Wand pinnen und dann unterschreiben wenn ein Update eingespielt wurde halte ich für zu bürokratisch. Wenn ich das nur elektronisch mache laufe ich Gefahr, dass wir bei einem angenommenen richtig schlimmen Schaden an die Dokumentation nicht mehr rankommen. Und irgendwie hab ich das blöde Gefühl, dass beide Varianten nicht sicher vor nachträglichen Manipulationen sind...

Ich freu mich auf eure Ideen

[bluestar]

Wir exportieren unser Wiki einmal täglich und übertragen die Daten an einen Notar, dieser hält die letzten 365 Versionen des Uploads vor. Das Vorgehen wurde im Vorfeld mit der Versicherung zusammen abgestimmt.

[cosinus]

Danke, das ist ein interessanter Ansatz.
Wie genau füllt ihr das Wiki mit Leben? Was steht da wie drin?

[bluestar]

Wie genau füllt ihr das Wiki mit Leben?

Die Inhalte stammen aus händischer Arbeit, werden zum Teil regelmäßig durch Agentenprogramme aktualisiert und last but not least schieben wir toolbasiert die Git-Kommentare aus unseren Ansible Repositories in das System.

Was steht da wie drin?

Zuerst einmal die Hardware-Daten, die Verwendung, etwaige Garantie und Serviceverträge. Dann natürlich die komplette Konfiguration und ein Changelog aller Änderungen.

Bei uns gilt der ungeschriebene Grundsatz, dass wir anhand der Doku ein System von null neu aufsetzen können.

[cosinus]

Ok, klingt aber rel. aufwendig was ihr da macht
Was wir schon haben: ein Inventarsystem in dem auch alle Server inventarisiert sind. Die Agents, die auch auf den Servern laufen, melden regelmäßig ihren Status beim Inventarserver. Dort kann man dann über ein Webfrontend alles sehen, zB auch ob für einen bestimmten WindowsServer KB5016690 installiert ist.

Ist jetzt die Frage ob die Versicherung sich mit sowas zufrieden gibt. Wir haben nur die Aussage bekommen, dass sie uns die Art und Weise der Dokumentation überlassen und es nur wichtig sei, dass wir unsere Systeme und Anwendungen kennen sowie einen Überblick über alle Patchstände haben müssen. Die werden im Schadensfall geprüft. Da frag ich mich jetzt aber von welchem Schadensfall wir ausgehen müssen bzw ob bei ransomware auch alle Linux-Server kompromittiert sind (was ich nicht glaube)

[bluestar]

Im Zweifelsfall stell doch mal anhand eurer Systeme eine dokumentation zusammen und bitte die Versicherung um die offizielle Freigabe als Protokoll. Damit bist du auf etwaige Schadensfälle vorbereitet und kannst die passende Doku erstellen und einreichen.

Der Aufwand hält sich bei uns in Grenzen, die Schnittstellen aus den verschiedenen Systemen in das Wiki sind mit der Zeit entstanden und nehmen uns inzwischen das Gro der Arbeit ab. Wenn bei uns Patches installiert werden, dann steht der Eintrag etwa 1-2min nach der Installation im Wiki mit der Anmerkung: Bitte vervollständigen und meist wird das nur mit „installiert wegen XYZ“ (Datum Uhrzeit und Name des Admins hat das System zuvor schon eingetragen)

[MSfree]

ob bei ransomware auch alle Linux-Server kompromittiert sind (was ich nicht glaube)

Sollten die Linuxkisten als Sambaserver laufen, können auch Dateien auf den Linuxrechnern vershlüsselt worden sein, denn die Ransomware macht vor Netzwerklaufwerken keinen Halt. Das Linux selbst ist zwar wahrscheinlich noch intakt, die Daten können trotzdem beschädigt sein.

[cosinus]

Sollten die Linuxkisten als Sambaserver laufen, können auch Dateien auf den Linuxrechnern vershlüsselt worden sein, denn die Ransomware macht vor Netzwerklaufwerken keinen Halt. Das Linux selbst ist zwar wahrscheinlich noch intakt, die Daten können trotzdem beschädigt sein.

Richtig, vor Netzlaufwerken machen die keinen Halt, aber Linux wird hier als Fileserver nicht genutzt. Nur ganz wenige Ausnahmen.

[cosinus]

Im Zweifelsfall stell doch mal anhand eurer Systeme eine dokumentation zusammen und bitte die Versicherung um die offizielle Freigabe als Protokoll. Damit bist du auf etwaige Schadensfälle vorbereitet und kannst die passende Doku erstellen und einreichen.

Also mit dem "install from scratch" nur aus der Dokumentation heraus habe ich noch so meine Probleme v.a. weil hier Software im Einsatz ist, die damals mein Kollege bzw. Systemhaus oder Beraterfirma installiert hat. Und dann haben wir auch nen Linuxserver für Entwickler, die sich fast komplett selbst um den kümmern.

Fangen wir mal klein an, nur mit den Windows-Servern, die stehen ja in der Schußlinie. Ich überleg mir dazu noch was, ein Art Updateprotokoll für jeden Server, das ich dann ausdrucke. Aber das kann man nach dem Schadensfall doch einfach so generieren/fälschen?!

[bluestar]

Also mit dem "install from scratch" nur aus der Dokumentation heraus habe ich noch so meine Probleme v.a. weil hier Software im Einsatz ist, die damals mein Kollege bzw. Systemhaus oder Beraterfirma installiert hat. Und dann haben wir auch nen Linuxserver für Entwickler, die sich fast komplett selbst um den kümmern.

Es ist durchaus legitim eine Beraterfirma und/oder das Entwicklerteam als Quelle für Neuinstallations-Informationen zu nutzen.

Aber das kann man nach dem Schadensfall doch einfach so generieren/fälschen?!

Zur Manipulationssicherung kannst du die Dokumente auch digital signieren und die Signatur mit ausdrucken. Wichtig ist halt, dass sozusagen eine dritte Instanz den Zeitstempel liefert.

[cosinus]

Ich seh schon, ich muss mit der Versicherung nochmal sprechen. Denn im Moment beißen sich die ganzen Anforderungen mit der lapidaren Aussage, die ich vor ein paar Wochen bekommen habe bzw. befürchte ich, dass die Versicherung im Schadensfall so ein Updateprotokoll nicht akzeptiert.
Wobei aber in so einem auch geklärt werden müsste, ob der Schaden wirklich durch eine Sicherheitslücke in Windows verursachte wurde oder weil ein Anwender eine Mail anklickte, die durch sämtliche Filter und Virenscanner ging - und es somit keine Rolle spielte, welches Update auf dem Server drauf war oder nicht.

[MSfree]

...bzw. befürchte ich, dass die Versicherung im Schadensfall so ein Updateprotokoll nicht akzeptiert.

Die Versicherung will im Schadensfall möglichst wenig zahlen. Je mehr Nachlässigkeit man walten läßt, desto mehr Grund haben sie, die Schadenssumme zu minimieren.

[bluestar]

Die Versicherung will im Schadensfall möglichst wenig zahlen. Je mehr Nachlässigkeit man walten läßt, desto mehr Grund haben sie, die Schadenssumme zu minimieren.

Genau um dieses Problem zu entschärfen, haben wir die Erwartungsthematik der Versicherung im Schadensfall geklärt, bevor überhaupt ein Schaden im Raum steht.

Klärst du die Details erst beim akuten Schaden bist du halt in einer echt schlechten Position und kannst dich im worst-case auf wochenlanges Nachliefern von Doku/Zertifikaten/Logs/Protokollen einstellen.

[MSfree]

Genau um dieses Problem zu entschärfen, haben wir die Erwartungsthematik der Versicherung im Schadensfall geklärt, bevor überhaupt ein Schaden im Raum steht.

Das finde ich auch sehr gut.

Dennoch ist es fraglich, ob die Versicherung wirklich alle Kosten übernimmt. Nehmen wir den Fall Bitterfeld als Beispiel. Da waren meines Wissens rund 600 Rechner verschlüsselt worden. Selbst bei sorgfältigsten Backups und vollständiger Installationshistorie dauert es 4 Stunden, um einen Arbeitsplatz wieder lauffähig herzurichten. Natürlich kann man mehrere PCs gleichzeitig wiederherstellen, aber mehr als 8 Rechner pro Tag schafft eine einzelne Person nicht. Man kann mehrere Personen abkommandieren, die parallel mehrere Rechner pro Tag wiederherstellen, aber irgendwann wird die Netzwerkbandbreite zum Backupsystem zum Flaschenhals. Meiner Schätzung nach benötigen 600 Rechner mindestens 20 Arbeitstage zur Wiederherstellung, das ist ein voller Monat Produktionsausfall. Ob die Versicherung so einen Ausfall trägt? Und wenn man zum Zwecke der Forensik die verschlüsselten Platten aufheben will/muß und neue beschaffen muß, dauert es nochmal seine Zeit, denn 600 Platten kauft man nicht mal um die Ecke im Mediamarkt.

In den meisten Fällen ist das Backup aber unvollständig, die Installationshistorie nicht vorhanden und der Patchzustand der Rechner hinkt hinterher. Bei 600 Rechnern ist das auch alles gar nicht so einfach in den Griff zu bekommen. Das schreit geradezu nach Automatisierung.

[cosinus]

Genau um dieses Problem zu entschärfen, haben wir die Erwartungsthematik der Versicherung im Schadensfall geklärt, bevor überhaupt ein Schaden im Raum steht.

Klärst du die Details erst beim akuten Schaden bist du halt in einer echt schlechten Position und kannst dich im worst-case auf wochenlanges Nachliefern von Doku/Zertifikaten/Logs/Protokollen einstellen.

Genau das dachte ich auch eben. Wie gesagt, ich werde da morgen nochmal nachhaken und berichten was als Antwort kam...der Thread scheint ja doch auch für andere interessant zu sein

[hec_tech]

Ich würde mit der Versicherung reden und eine sinnvolle Ransomware Protection nutzen. Wir bieten sowas an und installieren sowas auch. Damit kann man sich auch genug Prämie ersparen. Weiters müsste man genau schauen welche Angriffsmöglichkeiten es gibt.
Wenn Mitarbeiter mit verseuchten USB Sticks kommen hat man meistens ein Problem. Dazu kommt dann meistens Social Engineering gepaart mit einem einem falschen Berechtigungskonzept.

Wichtig sind Snapshots die man auch schnell wieder herstellen kann - also in ein paar Sekunden bis Minuten. Irgendwelche Restores von NL-SAS Platten oder noch schlimmer Tape dauern einfach zu lange. Da kostet dann der Ausfall ein Vermögen weil niemand arbeiten kann.

[bluestar]

Ich würde in dem Zusammenhang direkt mal deine Chefs auf das Thema Business Continuity Plan (BCP) ansprechen, darin wird das Thema Desaster Recovery auch noch mal konkretisiert.

[MSfree]

Wichtig sind Snapshots die man auch schnell wieder herstellen kann - also in ein paar Sekunden bis Minuten.

Wenn dir eine Schadsoftware 800GB Daten verschlüsselt hat, mußt du auch 800GB wiederherstellen. Das geht auch mit Snapshots nicht in Sekunden. Bei optimistischer Einschätzung von Festplattendatenraten von 150MB/s dauert das fast 2 Stunden, realistischer sind aber eher 8 Stunden, Snapshots hin oder her.

[bluestar]

Das geht auch mit Snapshots nicht in Sekunden.

Unser ZFS Setup erlaubt uns binnen Sekunden die Snapshots wiederherzustellen.

Den größten Zeitfaktor sehe ich darin, den „besten“ Snapshot zu finden, der Datenverlust soll ja schließlich minimal/nicht vorhanden sein.

[cosinus]

Snapshots nutzen wir nicht, aber die Schattenkopien vom Windows-Server. Ich frag mich aber immer wieder was der worst-case eigentlich bedeuten soll, im schlimmsten Fall kann ich ja keine Windows-Maschine mehr booten weil alles putt ist. Der schlimmste Fall wäre, dass die Angreifer einbrechen und wir das nicht merken und die tage- oder wochenlang ihren Angriff vorbereiten um zB Passwörter abzugreifen. Wenn die das schaffen, sind natürlich auch unsere Linux-VMs nicht mehr sicher, falls sie die root Passwörter bekommen. Wir haben aber für die Linuxkisten für root unterschiedliche Passwörter und nicht dasselbe Passwort wie der Windows-Domadmin.

Zur Infrastruktur: wir haben keine "echten" Server, sondern zwei dicke Hosts mit VMWare vSphere. Die eigentlichen produktiven Server laufen als VM auf diesen beiden ESX-Hosts. Die VMs bzw ihre virtuellen Disks liegen auf einem SAN. Backups werden täglich mit VEEAM auf einem NAS gesichert. Das hat natürlich auch komplett andere Zugangsdaten. Einmal im Monat machen wir ein Export eines Vollbackups auf eine externe Platte die offsite gelagert wird.

[MSfree]

Unser ZFS Setup erlaubt uns binnen Sekunden die Snapshots wiederherzustellen.

Ohne mich mit ZFS auszukennen, aber wie soll das gehen? Wenn ich 800GB wiederherstellen muß, muß ich 800GB vom Backup lesen und 800GB auf das Dateisystem schreiben. Ob ich das mit rsync mache oder 800000 ein Mbyte kleine Snapshots zurück rolle, ist letztlich egal, die Daten müssen übertragen werden, und das dauert nunmal.

[bluestar]

Unser ZFS Setup erlaubt uns binnen Sekunden die Snapshots wiederherzustellen.

Ohne mich mit ZFS auszukennen, aber wie soll das gehen?

Bei ZFS ist der Snapshot ja ein komplettes Dateisystem zum Stand seiner Erzeugung, nachfolgende Änderungen im Dateisystem erzeugen neue kopierte Daten(Copy-On-Write), die alten Blöcke werden jedoch nicht freigegeben, da sie vom Snapshot referenziert werden. Der Speicherbedarf eines Snapshots zum Erzeugungszeitpunkt ist daher vereinfacht gesagt 0 und der wächst mit dem Alter erst an, je mehr Daten du nach seiner Erzeugung manipulierst.

Beim Rollback wird das Dateisystem einfach auf den Snapshot zurückgesetzt und die verschlüsselten Daten werden asynchron im Hintergrund gelöscht.

In deinem Beispiel hätte der intakte Snapshot 800GB und das „verseuchte“ Dateisystem wäre auch 800GB groß. Das Umbiegen des Datenstartzeigers vom „verseuchten“ Dateisystem auf den Snapshot dauert Sekunden.

Dieses Verhalten ist übrigens nicht ZFS spezifisch, sie gilt für alle Copy-On-Write Dateisysteme, u.a. ZFS, BtRfs, APFS, etc.

[MSfree]

die alten Blöcke werden jedoch nicht freigegeben

Irgendwann ist dein Speicherpool aber voll, und dann? Ich gege auch davon aus, daß die Snapshots zumindest irgendwohin gespiegelt werden müssen. Und spätestens, wenn du Daten vom Spiegel zurückholen mußt, ist es aus mit Sekunden.

Beim Rollback wird das Dateisystem einfach auf den Snapshot zurückgesetzt und die verschlüsselten Daten werden asynchron im Hintergrund gelöscht.

Das kann aber nur solange gut gehen, solange dein Speicherpool genug Platz hat, alle Änderungen zu speichern.

In deinem Beispiel hätte der intakte Snapshot 800GB

Im Realfall wären es vermutlich Hunderte kleinerer Snapshots, aber die Anzahl spielt ja keine Rolle.

Dieses Verhalten ist übrigens nicht ZFS spezifisch, sie gilt für alle Copy-On-Write Dateisysteme

Na dann hatte ich das Prinzip schon halbwegs richtig verstanden. Bleibt nur das Problem, was passiert, wenn kein freier Speicherplatz merhr vorhanden ist, um die ganzen Kopien zu halten. Wenn man bei der ältesten Kopie Anfäng, diese freizugeben und den Platz überschreibt, kann man halt nicht beliebig weit zurück und muß dann doch wieder Daten vom Backup holen.

[bluestar]

die alten Blöcke werden jedoch nicht freigegeben

Irgendwann ist dein Speicherpool aber voll, und dann? Ich gege auch davon aus, daß die Snapshots zumindest irgendwohin gespiegelt werden müssen. Und spätestens, wenn du Daten vom Spiegel zurückholen mußt, ist es aus mit Sekunden.

Snapshots sind kein Langzeitbackup, wir halten ausreichend Speicherplatz für 4 Wochen Snapshots bereit. Ältere Daten müssen wir auch aus anderen Backups wiederherstellen. Der Zeitgewinn durch die Snapshots ist in 99% der Fälle jedoch enorm, typischer Anwendungsfall „Ich hab letzte Woche eine Datei überschrieben“.

[MSfree]

Snapshots sind kein Langzeitbackup

Danke für die Klarstellung. Und gegen Hardwaredefekte helfen die auch nur begrenzt. Der Ausfall einer einzelnen Platte eines Pools wird druch Snapshots auch nicht kompensiert, dazu braucht man dann schon ein RAID.

wir halten ausreichend Speicherplatz für 4 Wochen Snapshots bereit.

Für den normalen Betrieb und die typischen Betriebsunfälle (versehntlich Datei gelöscht) ist das sicher ausreichend.

Wenn bei einer Verschlüsselungsattacke der komplette Datenbestand verschlüsselt wird, brauchst du aber den doppelten Platz für deine Snapshots. Ist der wirklich vorhanden? Wenn nicht, sind wir wieder beim lahmen Backup.