Einleitung
Ransomware stellt aktuell eine der herausragenden Bedrohungen für IT Infrastrukturen dar. Berichte über erfolgreiche Angriffe häufen sich, die Einschläge kommen näher. Über 30% aller Unternehmen, Institute, Universitäten oder Behörden in Deutschland hatten bereits mit derartigen Attacken zu tun. Zum Teil wurde ein Lösegeld bezahlt, um wieder an die eigenen Daten zu gelangen.
Selbst bei Zahlung ist der Erfolg niemals sicher. Schließlich verhandelt man mit Verbrechern. Die Behörden raten daher von der Zahlung ab.
Die wesentliche Schutzmaßnahme gegen die Folgen einer solchen Attacke ist ein aktuelles und konsistentes Backup.
Ransomware vs. Backup
Leider wissen auch die Angreifer um die Wichtigkeit der Backups. Die aktuell kursierenden Schädlinge, wie z.B. Emotet oder Ryuk, enthalten Code der aktiv nach Datensicherungen im Netz fahndet. Mit vorher erlangten Zugangsdaten für Active Directory Konten oder durch Attacken auf z.B. RDP Lücken oder die brandaktuelle Zerologon Lücke wird versucht die Systeme zu übernehmen, welche die Datensicherung im Unternehmen betreiben bzw. die Backupdaten halten.
Oftmals folgen der automatischen Attacke sogar Hacker aus Fleisch und Blut, die sich aktiv im Netz umsehen und versuchen alle Backups zu zerstören. Ein vielfach leiches Unterfangen, da Backups heute vorzugsweise auf Festplattensystemen permanent mit der Infrastruktur verbunden sind.
Der Grund liegt auf der Hand: Sind alle Backups gelöscht oder ebenfalls verschlüsselt, steigt die Compliance des “Kunden” zur Zahlung eines Lösegeldes massiv.
Viele Ansätze wurden daher schon erdacht, die Backupdaten sicher im Netz abzulegen. Eine sehr einfache und sichere Variante ist ein Air-Gap – also eine echte Trennung der Backupmedien vom System. Beispielsweise können LTO Tapes physisch aus der Library entnommen werden.
Ohne eine solche aufwändige manuelle Entnahme – die zudem täglich erfolgen müsste – bleiben die Daten latent verwundbar. Ganz egal, ob sie auf Plattensystemen, Dedup-Appliances, Tapes in einer Library oder sogar in einem S3 Cloud Repository liegen.
S3 Cloud Anbieter haben daher schon vor einiger Zeit eine API Erweiterung mit dem Namen “Object Lock” vorgeschlagen. Hiermit können zumindest die Backups im Cloud Layer eine gewisse Zeit immun gegen Änderungen gemacht werden.
Einige dieser Lösungen werden inzwischen nativ von Veeam unterstützt. Amazon AWS gehört z.B. dazu. Microsoft Azure fehlt z.B. aktuell noch. Außerdem ist S3 Speicher nicht für jeden Anwendungsfall geeignet. Ein Primärbackup mit Veeam auf S3 ist z.B. nicht direkt möglich. Der S3 Layer ist ausschließlich als Erweiterung eines Scale-Out-Backup Repositories verfügbar.
ExaGrid
Die speziell für Veeam Backups geeignete “Tiered-Backup Storage” von ExaGrid weist auch so schon im Hinblick auf die Datensicherheit ein paar Vorteile auf. Durch die initiale Sicherung in eine “Landing-Zone” ohne Deduplizierung kann die Lösung auch schon fürs primäre Backup eingesetzt werden. Schnelle Recoveries und selbst Sure-Backup-Überprüfungen sind mit einer ExaGrid als Repository kein Problem. Auch ist die Appliance als Linux basierte Lösung wesentlich robuster gegenüber Attacken auf den üblichen Angriffswegen. RDP Lücken gibt es bei Linux nicht und erspähte Domänenkonten helfen auch nicht beim direkten Angriff.
Dennoch blieb ein Restrisiko: Hatte ein Eindringling die Kontrolle über den Veeam Backup Server erlangt, konnte er bislang Backups in allen Repositories und damit auch der ExaGrid einfach aktiv löschen.
Mit der gerade erschienenen neuen Betriebssoftware für die ExaGrid Systeme ist damit Schluss!
Time-Lock
Die neue Funktion Time-Lock war schon seit Anfang des Jahres angekündigt und ist am 18.09.2020 offiziell mit der Version 6 der Betriebssoftware erschienen.
Im Folgenden sehen wir uns die Funktion etwas genauer an.
Time-Lock fungiert dabei in der Art eines temporären WORM Schutzes für den gesamten Retention-Tier des Systems. Alle Daten im deduplizierten Bereich der Systeme führen dann jeden Löschauftrag nicht wirklich aus. Selbst wenn die Daten in Veeam gelöscht werden und damit auch in der Landing Zone der ExaGrid verschwinden, lassen sich diese über einen speziellen Recovery Modus wiederherstellen. Die Haltezeit in Tagen für diesen Time-Lock lässt sich einstellen. Die Funktion ist bereits per-default aktiv und zunächst auf 10 Tage eingestellt.
Manipulationssicher
Mein erster Gedanke war: “Ok. Dann stellt der Angreifer auch den Time-Lock wieder ab”. Daran hat ExaGrid gedacht. Der normale Admin der ExaGrid darf hier zunächst gar keine Änderungen durchführen, sondern lediglich anfragen.
Nur ein “Security-Officer”, der als Konto mit gesonderter Rolle im Verwaltungsbereich der ExaGrid angelegt werden muss, kann die angefragte Änderung mit “Approve” bestätigen. Im Beispiel habe ich dafür den User “cso” angelegt und mich mit diesem angemeldet.
Dieses Konto, wie auch das des Admins, kann man auf Wunsch zusätzlich mit einem zweiten Faktor absichern. Die ExaGrid lässt sich dazu schnell und einfach mit einer der gängigen Autheticator-Apps verbinden. Der kostenfreie Microsoft Authenticator funktionierte z.B. in meinem Test zuverlässig.
Beim nächsten Login als “cso” reicht das Passwort alleine nicht mehr aus. Der “Challenge Code” kommt bei mir jetzt aus dem Microsoft Authenticator und verhindert die Anmeldung eines Dritten mit erspähten Credentials.
Aus Veeam ist diese Verwaltungsschicht ohnehin nicht sichtbar. Paranoide Naturen könnten diese sogar ganz vom internen Netzwerk trennen. Die Sicherung aus Veeam auf die ExaGrid läuft trotzdem und über andere Schnittstellen der Appliance.
Und im Falle des Falles?
Kommt es dann tatsächlich zum Datenverlust und sind auch die Backups betroffen, stellt sich die Frage, wie man wieder an seine Daten kommt.
In unserem Beispiel löschen wir einfach mal, ganz wie ein Angreifer, eine komplette Backupkette aus dem Scale-Out Repo unserer ExaGrid.
Unter normalen Umständen wäre jetzt keine Wiederherstellung aus diesem Backup mehr möglich. Ein Rescan des Repositories zeigt folglich keinerlei Spuren eines Backups…
“It’s a kind of magic”
Ist der Angriff entdeckt und soll jetzt recovered werden, setzt der Admin die ExaGrid zunächst in einen besonderen Modus: “Suspend All Shares”.
Damit werden alle weiteren schreibenden Zugriffe aus Veeam heraus verhindert. Der Datenstand der Sicherung ist eingefroren. Der Vorgang muss bestätigt werden.
Im nächsten Schritt hat man über die Verwaltungsschicht die Möglichkeit einen früheren Point-In-Time der Backupdaten in einem der Shares gezielt wieder aktiv zu schalten.
Dazu wählt man ein Datum und eine Uhrzeit zu der noch alles sauber war. Die GUI zeigt dann den nächstgelegenen konsistenten Sicherungspunkt.
Wählt man diesen aus, dauert es einen kurzen Moment und die ExaGrid meldet, dass der Sicherungspunkt zur Verfügung steht. Ein erneuter Rescan auf das Repository unter Veeam meldet plötzliche wieder einen erfolgreichen Import einer Sicherung.
Diese taucht dann, da nicht mehr direkt mit einem Veeam Job verbunden, unter “Disk(Imported)” auf.
Von hier an wird der Recovery-Vorgang zu einem ganz normalen “skip-skip-finish” Veeam Recovery Prozess. Alle Spielarten für ein Recovery stehen wieder zur Verfügung. Aus Veeam heraus ist der Vorgang also völlig transparent.
Alles wieder im Lot
Bleibt noch der Hinweis, dass die Sicherung im Regelbetrieb dann nicht mehr in diesen, jetzt schreibgeschützten Share erfolgen kann. Sind alle Daten wiederhergestellt, sollte man auf der ExaGrid einen neuen Share anlegen und die Sicherung auf diesen umziehen. Der alte Share kann nach erfolgter Wiederherstellung und ggf. einer Wartezeit einfach gelöscht werden. Durch die Deduplizierung in der ExaGrid entsteht im Wesentlichen dadurch kein zusätzlicher Speicherplatzbedarf.
Zusammenfassung
Das Time-Lock Feature löst ein lange bestehendes Problem im Veeam Ökosystem. Es schafft faktisch den geforderten Air-Gap, ohne echte Luft dazwischen. Quasi ein “virtual Air-Gap”. Das Feature kommt ohne Preisaufschlag und steht allen Nutzern der ExaGrid mit der neuen Betriebssoftware direkt zur Verfügung. Einzig ein klein wenig zusätzlicher Platz im Repository ist für die Tage der Unverwundbarkeit einzuplanen. ExaGrid gibt ca. 2% Mehrverbrauch pro “gelockter” Woche an. Aber das sollte einem die Sicherheit wert sein.