Windows Fileserver vor Ransomware schützen (Update 2)

von

Hier habe ich ja schon einige Ansätze veröffentlicht um die Ransomware Pest in den Griff zu bekommen:

Mich erreichen allerdings auch täglich viele Mails mit Nachfragen, was noch alles möglich ist. Dazu muss ich sagen: Kommt drauf an…

Die Scripte in den Artikeln funktionieren nicht in jeder Umgebung, sondern müssen wahrscheinlich etwas angepasst werden. Auch die Liste der Dateiendungen ist mittlerweile veraltet und muss angepasst werden. Hier muss immer mal wieder etwas Hand angelegt werden.

Ich habe daher mal das Script aus diesem Artikel etwas angepasst um weitere Möglichkeiten aufzuzeigen:

$logfile = "c:\Scripts\logfile.csv"
$events = Get-EventLog -LogName application -Source SRMSVC -After (get-date).AddMinutes(-10) | select ReplacementStrings -Unique
if ($events.count -gt 50)
	{
		stop-computer -force
	}
else
	{
		foreach ($event in $events)
			{
				$sourceuser = $event.ReplacementStrings[0]
				$smbsharepath = $event.ReplacementStrings[1]
				
				#Versuchen den Rechner zu finden
				
				$openfiles = Get-SmbOpenFile | where {$_.clientusername -like "$sourceuser"}
				$PCIP = $openfiles.clientcomputername | select -first 1
				$PCFQDN = (Resolve-DnsName $pcip | where {$_.section -match "answer"}).Namehost
				$PCUNC = $PCFQDN.split(".")[0]
				
				#Infos ausgeben
				
				write-host "Benutzer:" $sourceuser
				write-host "Freigabe:" $smbsharepath
				write-host "IP des PCs:" $pcip
				write-host "FQDN des PCs" $PCFQDN
				write-host "PC UNC Name" $PCUNC
		
				#Freigabe blocken (Freigabe Rechte für Benutzer auf Verweigern stellen)
				
				$blockaccess = Get-SmbShare | where {$_.path -like $smbsharepath} | Block-SmbShareAccess -AccountName $sourceuser -Force
				$log = "$sourceuser" + ";" + "$smbsharepath" + "$pcname"
				$log | add-content $logfile
				
				#PC des BEnutzers runterfahren
				
				Stop-Computer -ComputerName $PCUNC -force
				
				#Benutzerkonto sperren (AD Modul für PowerShell benötigt)
				
				Get-ADUser $sourceuser | Disable-ADAccount				
				
			}
	}

Das Script liefert die erkannten Werte zurück, in etwa so:

Ransomware

Ob man nun das Benutzerkonto im Active Directory sperrt, den PC des Benutzers runterfährt, den FileServer runterfährt oder die Zugriffsrechte auf der Freigabe verweigert, muss jeder selbst entscheiden. Natürlich können diese Methoden auch nach hinten losgehen: Benutzer speichert aus Versehen oder mit Absicht eine Datei mit entsprechender Änderung auf einer Freigabe und fährt damit den oder die FileServer runter…

Es gibt also viele Dinge die beachtet werden müssen, man könnte sich ja auch nur eine Mail schicken lassen, wenn eine entsprechende Datei gefunden wird, blöd nur, wenn die Mail in der Nacht nicht gelesen wird. Man könnte aber das Script an die Geschäftszeiten anpassen: Innerhalb der Geschäftszeiten: Mail an den Admin, Außerhalb der Geschäftszeiten: Fahre PC des Benutzers runter.

Alles denkbar, alles machbar, mit ein bisschen PowerShell…

Ach ja, was auch ziemlich hilfreich ist: Ein gutes und AKTUELLES Backup! Wann wurde denn das letzte Mal der Restore getestet? J

Und da wären wir auch schon beim nächsten Punkt: Wenn sich das Verschlüsseln nicht mit Sicherheit verhindern lässt, dann muss ich halt dafür sorgen, dass der Datenverlust im Fall der Fälle möglichst gering ist. Hier könnte man auch über Windows VSS Snapshots nachdenken. Zum Beispiel ein kleines Script, welches alle 30 Minuten einen VSS Snapshot auslöst und beispielsweise 4 Versionen stehen lässt.

Generell muss sich jeder Admin von FileServern Gedanken machen, wie man sich am Besten vor Ransomware schützt. „Geld gegen Daten“ könnte die neue „Penisverlängerung“ werden. Nur fällt auf Mails mit „Penisverlängerung“ _kaum_ jemand mehr rein…

Erste Tests der Malware Bytes Beta sehen ebenfalls sehr vielversprechend aus:

https://forums.malwarebytes.org/index.php?/topic/177751-introducing-malwarebytes-anti-ransomware/

Es bleibt also spannend…

3 Gedanken zu „Windows Fileserver vor Ransomware schützen (Update 2)“

  1. Leider funktioniert das so nicht, mit dem Sperren des Users.
    Die Variable $sourceuser wirft DOMÄNE\BENUTZER als Ergebnis aus. Zu sehen oben im Bild von Franky.

    Der Befehl Get-ADUser mit oder ohne „-Identity“ kann nur den samAccountName auslesen. Es darf keine Domäne mit drin stehen! Alternativ GUID auch möglich.

    Schade

    Antworten

  3. Eine zusätzliche Sicherheit bringt auch Applocker, allerdings nur sofern diese Funktionalität genutzt werden kann (Stichwort Enterprise / Ultimate). Applocker kann bequem über die Gruppenrichtlinien verwaltet werden.

    Antworten

Schreibe einen Kommentar