Kürzlich ließ einer unserer Kunden ein IT-Netzwerk-Audit von einem anderen (externen) IT-Audit-Unternehmen durchführen. Die Ergebnisse waren im Allgemeinen gut, obwohl sie darauf hinwiesen, dass wir einen iSCSI-Client auf Windows Server verwendet hatten, um eine Verbindung zum NAS herzustellen, anstatt eine SMB-Freigabe auf dem NAS zu erstellen. Sie meinten, das sei keine gute Idee:
„Es besteht [auch] ein Sicherheitsrisiko bei iSCSI- und Ransomware-Angriffen, bei denen eine unerlaubte Verschlüsselung der iSCSI-Festplatte vorgenommen werden kann, wodurch Daten unlesbar werden. Aus Sicherheitsgründen wird empfohlen, diese Methode der Datenfreigabe aufzugeben und einen gemeinsamen Ansatz zu verfolgen.“
Was meinen sie damit? Bezieht es sich auf die Tatsache, dass iSCSI auf einer niedrigeren OSI-Schicht (Sitzung) arbeitet als SMB (Anwendung) und dass sich eine iSCSI-Festplatte der Anwendungsschicht auf dieselbe Weise präsentiert wie eine lokal angeschlossene Festplatte und daher leichter kompromittiert werden kann?
Wenn ja, ist das richtig?
Ich bin kein Experte für Sicherheitsforensik, obwohl unsere Arbeit oft forensischer Natur ist. Meines Wissens ist es genauso wahrscheinlich, dass Ransomware Daten auf einer SMB-Freigabe angreift, auf die ein bestimmter Win-Computer zugreifen kann, wie dass sie eine iSCSI-Festplatte angreift.
Habe ich das richtig verstanden oder habe ich etwas übersehen?
Zusätzlicher Kontext zur Frage
Das CHAP-Passwort ist auf dem iSCSI-Server festgelegt, daher würde ich annehmen, dass ihr Argument mit einer Gefährdung des Windows-Servers zusammenhängt, auf dem der iSCSI-Client installiert ist.
Es ist immer nur ein iSCSI-Client verbunden und es wird eine sehr strenge „Cyber-Hygiene“ angewendet, um sicherzustellen, dass dieses Kennwort zu keinem Zeitpunkt in einen anderen Server oder Computer innerhalb oder außerhalb des Netzwerks eingegeben wird.
Im Allgemeinen bevorzugen wir iSCSI, um NAS-Festplatten für den Windows-Server verfügbar zu machen. Wir haben festgestellt, dass wir keine Probleme mit erweiterten Zugriffssteuerungseinträgen (ACEs) innerhalb der DACL haben, wenn Windows sich um das Dateisystem kümmert. Beispielsweise war die Implementierung von QNAP in der Vergangenheit in Bezug auf die ACE-Reihenfolge fehlerhaft, was problematisch sein kann. Wir haben auch einen Fehler beim Festlegen von CONTAINER_INHERIT_ACE für untergeordnete Objekte gefunden (QNAP mitgeteilt, aber bis heute nicht behoben). Dieser Punkt ist für diese Frage nicht unbedingt relevant, liefert aber einen Kontext dafür, warum wir iSCSI bevorzugen.
Im Gegensatz zu meinem obigen Punkt ist im Fall dieses speziellen Kunden die betreffende, per iSCSI angeschlossene Festplatte mit ReFS formatiert, da sie als Veeam-Backup-Speicher verwendet wird. Obwohl es technisch nicht erforderlich ist, empfiehlt Veeam aus Leistungsgründen die Verwendung von ReFS gegenüber NTFS, sodass wir diese Option tendenziell bevorzugen. (Hier ist ein guter ArtikelErläuterung des Vergleichs zwischen ReFS und NTFS für die Sicherung.) Diese Vorteile sind nur möglich, wenn wir iSCSI verwenden, nicht, wenn wir das NAS auf SMB verschieben.
Ich habe mich bereits ein wenig in dieses Thema eingelesen und konnte keine Belege dafür finden, dass iSCSI anfälliger für Ransomware ist als die Verbindung über eine Netzwerkfreigabe, bin jedoch weiterhin unvoreingenommen.
Antwort1
Jede online beschreibbare Festplatte kann durch Schadsoftware oder einen Benutzer beschädigt werden. Es ist ein Fehler, sie zu unterschätzen, indem man annimmt, sie könnten keine Dateifreigabe finden.
Die letzte Verteidigungslinie für wichtige Daten ist immergeprüft, kalte Offline-Backups. Und in diesem Fall können die wichtigen Daten auch Backups selbst enthalten! Denken Sie über die Möglichkeiten nach, Backup-Archive unveränderlich zu machen. Wechselmedien (Bänder), unveränderlicher Cloud-Speicher mit Anmeldeinformationen, die nur für Backups verwendet werden, das NAS ausschließlich für Backups verwenden und nichts anderes anschließen, alles außer den Ports der Backup-Software mit einer Firewall schützen, Dateifreigabe deaktivieren.
Eine weitere Kontrollmöglichkeit besteht darin, Software auf Zulassungslisten zu setzen, wodurch die Ausführung unbekannter Dinge deutlich eingeschränkt wird.
Der von Ihnen angegebene Kontext zeigt, dass Sie darüber nachgedacht haben. Es ist gut, dass Sie Ihre Verwendung des Protokolls erklärt haben. Denken Sie etwas höher als diese Frage und geben Sie in der Antwort an, welche Schutzmaßnahmen im Geschäftskontinuitätsplan enthalten sind.
- Wann fand der letzte Backup-Wiederherstellungstest statt? Wurden die Ziele für Wiederherstellungspunkt und Wiederherstellungszeit erreicht?
- Hat jemand nachgewiesen, dass die Cold Backups nicht online und anfällig sind, beispielsweise durch eine Red-Team-Übung?
- Wann hatten Sie zuletzt Probleme mit Ransomware und was wurde unternommen, um die technischen oder prozessbezogenen Kontrollen zu verbessern?
Antwort2
Wenn man die Frage der iSCSI-Sicherheitslücke bei der Verwendung ohne Cluster-Dateisystem, aber mit mehreren Initiatoren einmal beiseite lässt, kann ich kaum einen klaren Grund dafür finden, warum das File-Sharing-Protokoll im Hinblick auf Ransomware sicherer sein sollte als iSCSI. Sie erhalten CHAP zur Stärkung der Authentifizierung und IPSec zur Sicherung der Datenübertragung über das Netzwerk. Hier ist eine gute Übersicht über die Gründe für iSCSI:https://www.starwindsoftware.com/blog/ein-Infrastrukturprojekt-fur-Ihre-Organisation-mit-iscsi-san-abschließen
Ansonsten ist es eher eine Frage der allgemeinen Sicherheit des Backup-Servers, z. B. dass er von Ihrer Hauptproduktionsumgebung getrennt ist, außerhalb der Domäne liegt und über ein separates Konto (kein Domänenadministrator) verfügt usw. Wenn Sie es jedoch schaffen, Ransomware auf den Backup-Server zu bringen, spielt dies keine große Rolle, wenn Sie beispielsweise eine SMB-Freigabe als Backup-Repository verwenden (https://helpcenter.veeam.com/docs/backup/vsphere/smb_share.html?ver=100) oder ein iSCSI-Speicher.
Antwort3
Ja, jedes Netzwerkdatenzugriffsprotokoll auf Dateiebene ist SICHERER als das Blockprotokoll (iSCSI, FC, FCoE usw.), da das Volume nicht mit einem „Netzwerk-Redirector“ beschädigt werden kann, was bei einem falsch konfigurierten Cluster oder einem lokalen Dateisystem (EXT3/4, ReFS, XFS usw.) sehr leicht passieren kann. Die ganze Geschichte wird hier gut erklärt:
https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392