TrueNAS SMB-Sicherheit: AES-128/256, SMB3-Signing und was Admins im Mittelstand jetzt umstellen sollten

SMB ist seit Jahren das Arbeitstier für Dateifreigaben in Windows-Netzen — und genau deshalb lohnt sich der ehrliche Blick darauf, wie sicher es bei uns tatsächlich läuft. In vielen Umgebungen, die wir übernehmen, finden wir noch SMB1 aktiv, kein Signing, keine Verschlüsselung und ein Audit-Log, in das noch nie jemand reingeschaut hat. Dieser Artikel zeigt, wie wir TrueNAS SMB-Sicherheit aufsetzen, wenn wir einen Fileserver im Mittelstand übernehmen oder neu aufbauen — mit Fokus auf SMB3-Signing, AES-128/256-GCM, saubere Client-Kompatibilität zu Windows 11 und Server 2025 und einem Audit-Trail, der im Ernstfall auch wirklich etwas aussagt.

Warum SMB-Sicherheit auf TrueNAS 2026 kein Nice-to-have mehr ist

Dateifreigaben sind in der Regel das wertvollste Ziel in einem Firmennetz. Wer dort entschlüsseln, lesen oder stillschweigend manipulieren kann, hat Zugriff auf Verträge, Buchhaltung, Konstruktionsdaten und Mandantenakten. Gleichzeitig sprechen Ransomware-Berichte, aktuelle Angriffe über Protokoll-Downgrades und die Diskussion um NIS2 und CER eine klare Sprache: Protokoll-Hygiene gehört genauso zur Grundsicherung wie Backup und Patch-Management.

Konkret heißt das für uns:

• SMB1 muss raus. Nicht “irgendwann”, sondern vor der nächsten Audit-Diskussion.
• SMB3-Signing wird erzwungen, nicht nur empfohlen.
• SMB3-Verschlüsselung mit AES-128-GCM oder AES-256-GCM ist der Standard für sensible Shares.
• Audit-Logging läuft dauerhaft mit und wandert mindestens 90 Tage in ein zentrales Log-Ziel.

Die gute Nachricht: TrueNAS 25.10 Goldeye bringt diese Bausteine out of the box mit. Wir müssen sie nur konsequent einschalten und sauber zu den Clients passen lassen.

SMB1 abschalten — ja, immer noch

Auch 2026 finden wir SMB1 noch in erschreckend vielen Umgebungen. Meist liegt es an einem Scanner-MFP, einer alten Dokumentenerfassung, einer Maschinensteuerung oder einem Backup-Script aus Zeiten, in denen Windows XP noch produktiv war. SMB1 ist kaputt, bekannt kaputt und seit Jahren in Microsofts Defaults deaktiviert. Trotzdem reaktiviert jemand den Dienst, weil “der Scanner sonst nicht mehr geht”.

Unser Vorgehen auf TrueNAS:

Shares > SMB > Advanced
  Server Minimum Protocol: SMB3_02
  Server Maximum Protocol: SMB3_11
  Enable SMB1 Support: aus

Was bedeutet das in der Praxis? Alles, was nicht mindestens SMB2 kann, verliert den Zugriff. Deshalb kommt vor dem Umstellen immer eine kurze Bestandsaufnahme:

• Welche Geräte sprechen heute auf welchem Share? Ein Blick ins SMB-Session-Log auf TrueNAS zeigt uns die Clients mit Protokoll-Version.
• Welche MFPs und Scanner sind aktiv? Die bekommen entweder ein Firmware-Update, einen SMB2-fähigen Fileshare-Workflow, einen separaten Scan-to-Mail-Prozess oder landen in einem eng abgeschotteten, nicht routbaren VLAN mit eigenem Scan-Share — getrennt vom produktiven Fileserver.
• Gibt es Legacy-Anwendungen, die zwingend SMB1 brauchen? In 95 Prozent der Fälle lautet die Antwort “nein, der Hersteller hat vor zwei Jahren eine SMB2-Version veröffentlicht, die wurde nur nie eingespielt.”

Wichtig: Wir schalten SMB1 nicht lautlos ab, sondern kommunizieren das vorher mit den Fachabteilungen. Ein stillgelegter Scanner am Montagmorgen ist genau die Art Ereignis, die aus einem sauberen Security-Projekt eine Ticket-Lawine macht.

SMB3-Signing erzwingen

Signing stellt sicher, dass SMB-Pakete auf dem Transportweg nicht verändert wurden. Ohne Signing ist ein klassisches NTLM-Relay-Angriffsmuster deutlich einfacher, weil der Angreifer die authentifizierte Session umlenken und Dateioperationen in fremdem Namen auslösen kann. Mit erzwungenem Signing wird das Paket beim Umbiegen ungültig.

Auf TrueNAS setzen wir dafür in den SMB-Advanced-Settings:

Server Signing: required
Client Signing: required (sofern TrueNAS auch als SMB-Client läuft)

Zusätzlich prüfen wir die Domain-Policy auf dem Windows-Server:

• “Microsoft network server: Digitally sign communications (always)” = Enabled
• “Microsoft network client: Digitally sign communications (always)” = Enabled

Signing kostet Rechenleistung, aber auf aktuellen CPUs mit SHA-Hardware-Beschleunigung ist der Overhead in gemischten Office-Workloads nicht mehr spürbar. Wo wir Vorsicht walten lassen: hochfrequente, viele kleine Files auf alten Clients mit schwachen CPUs. Hier testen wir vorher.

AES-128-GCM und AES-256-GCM aktivieren

Signing schützt die Integrität, Verschlüsselung schützt die Vertraulichkeit. SMB3 kann mit AES-128-CCM, AES-128-GCM, AES-256-CCM und AES-256-GCM arbeiten. GCM ist deutlich performanter als CCM und wird von Windows 11, Windows Server 2022 und Server 2025 bevorzugt gewählt.

Unsere Empfehlung für Produktivumgebungen:

• AES-128-GCM als Minimum. Das ist der Default auf TrueNAS 25.10 und ausreichend für den Großteil der KMU-Workloads.
• AES-256-GCM erzwingen auf Shares mit Mandantendaten, Lohn-/Gehaltsdaten, Konstruktionsdaten und auf allen Shares in regulierten Umgebungen (CER-Pflichtbereich, Steuerberater, Anwaltskanzleien).

Konfiguration auf TrueNAS pro Share:

Shares > SMB > <Share> > Edit > Advanced
  SMB Encryption: required

Zusätzlich auf Server-Ebene:

Shares > SMB > Advanced
  Encrypt all SMB traffic: optional oder required

“Optional” lässt Clients die Entscheidung — wenn der Client Verschlüsselung anbietet, wird sie genutzt. “Required” erzwingt sie global. Für reine Windows-11- und Windows-Server-2025-Umgebungen setzen wir “required”. Für gemischte Umgebungen mit älteren Linux-Clients, bestimmten Thin Clients oder Druckserver-Workflows wählen wir “required” nur pro Share.

Wichtig: Verschlüsselung ersetzt kein Signing. Beides zusammen ist das Ziel.

Kompatibilität mit Windows 11 und Server 2025

Microsoft hat mit Windows 11 24H2 und Server 2025 die Defaults deutlich gestrafft. SMB1 ist dort nicht nur deaktiviert, sondern bei Neuinstallationen nicht mehr nachinstallierbar. SMB-Signing ist bei beiden standardmäßig erzwungen. Guest-Logins auf SMB-Shares sind blockiert. Das ist aus Security-Sicht hervorragend — führt aber in Mischumgebungen regelmäßig zu Problemen, wenn:

• ein alter NAS-Share noch mit Gast-Zugang arbeitet,
• ein Scanner-MFP seine Scans in ein Share schreibt und dafür einen Service-User ohne Passwort nutzt,
• ein Linux-Client mit alter cifs-utils-Version keine aktuellen SMB3-Dialekte spricht.

Unser Vorgehen: Vor dem Rollout prüfen wir die Clients mit Get-SmbConnection (Windows) und schauen auf die ausgehandelte Dialect-Version und die Signing-/Encryption-Flags. Was unter 3.1.1 fährt, wird dokumentiert und entweder geupgradet oder in ein separates VLAN mit eigenem Legacy-Share verschoben. Mehr Hintergrund dazu steht in unserem Artikel zur TrueNAS SMB Active Directory Einrichtung.

Alt-Geräte und Scanner — der ehrliche Umgang

Wir werben hier bewusst nicht mit “alles einfach durchschalten”. Realistisch sind drei Pfade:

1. Firmware-Update: Viele MFPs — Konica Minolta, Kyocera, Xerox, Canon imageRUNNER-Reihe — haben seit 2023 Firmwares mit SMB2/SMB3-Support bekommen. Die Updates sind oft kostenlos, aber nicht automatisch installiert.
2. Scan-to-Mail oder Scan-to-Cloud: Für kleine Office-Umgebungen oft die saubere Alternative, wenn der Scanner nicht mehr an einen klassischen Fileshare schreiben kann.
3. Separater Legacy-Scan-Share in einem isolierten VLAN: Nur dann, wenn Pfade 1 und 2 nicht funktionieren. Dann aber: eigener Benutzer mit Passwort, kein Zugriff auf andere Shares, dauerhafte Audit-Protokollierung, kein Routing in Richtung Produktion.

Wichtig: Alt-Geräte sind kein Grund, SMB1 global zu reaktivieren. Sie sind ein Grund für ein klar umrissenes Legacy-Segment mit Verfallsdatum.

Audit-Logging — ohne das sieht niemand den Angriff

Die beste SMB-Konfiguration bringt wenig, wenn im Ernstfall nicht nachvollziehbar ist, welcher User welche Datei wann angefasst hat. TrueNAS kann über die SMB-Audit-Konfiguration pro Share oder global protokollieren. Wir aktivieren:

• Logon-/Logoff-Ereignisse,
• erfolgreiche und fehlgeschlagene Zugriffe auf sensible Shares,
• Löschvorgänge,
• Umbenennungen (gerade bei Ransomware spannend — die typische Signatur ist “viele Renames in kurzer Zeit mit neuer Extension”).

Die Logs schicken wir per Syslog an unser zentrales SIEM — bei kleineren Kunden an eine schlanke Open-Source-Lösung wie Graylog oder Wazuh, bei größeren an ein bestehendes System. Mindestens 90 Tage Aufbewahrung, besser 180. Wer Richtung CER unterwegs ist, braucht ohnehin eine lückenlose Nachweiskette.

Konkrete Umstellreihenfolge für ein Produktivsystem

Weil das Thema in der Reihenfolge entscheidend ist, hier unser übliches Rollout bei Kunden:

1. Inventur: SMB-Dialekte und Clients erfassen, Alt-Geräte identifizieren.
2. Kommunikation mit Fachabteilungen, Fenster für Umstellung festlegen.
3. Audit-Logging aktivieren — bewusst zuerst, damit wir Vorher-Nachher sauber vergleichen können.
4. SMB-Signing auf “required” setzen, mit Clients kurz testen.
5. SMB-Encryption pro Share aktivieren, mit sensiblen Shares beginnen.
6. SMB1 serverseitig deaktivieren.
7. Legacy-Geräte in getrenntes VLAN mit Legacy-Share verschieben, Verfallsdatum notieren.
8. Nach zwei Wochen: Audit-Logs prüfen, offene Fehler mit Clients abarbeiten.

Für die Hardware-Seite im Fileserver-Umfeld lohnt der Blick in unseren TrueNAS Konfigurator — für Beratung und Umsetzung durch unser Team gibt es den TrueNAS Support. Wer SMB auch performant will, findet im Artikel zu SMB Multichannel über 10 GbE die passende Netzwerkkonfiguration dazu.

FAQ

Reicht SMB-Signing nicht auch ohne Verschlüsselung?

Signing schützt die Integrität der Pakete, aber nicht die Vertraulichkeit. Ohne Verschlüsselung kann ein Angreifer mit Netzzugriff den Inhalt mitlesen. In regulierten Umgebungen und bei Mandantendaten setzen wir deshalb beides.

Was bringt AES-256-GCM gegenüber AES-128-GCM in der Praxis?

Beide Verfahren gelten als sicher. AES-256-GCM hat einen höheren Sicherheitsmargen gegen zukünftige Angriffe und wird in regulierten Branchen oft explizit gefordert. Für reine Office-Workloads auf aktuellen CPUs ist der Performance-Unterschied im Alltag nicht spürbar.

Muss ich SMB1 wirklich global abschalten, auch wenn nur ein einziger Scanner es braucht?

Ja. Ein aktiver SMB1-Dienst steht jedem Angreifer im Netz zur Verfügung, nicht nur dem Scanner. Für den Einzelfall gibt es Firmware-Updates, Scan-to-Mail oder einen isolierten Legacy-Share. SMB1 global aktiv zu lassen, nur weil ein Gerät alt ist, ist aus Risiko-Sicht nicht vertretbar.

Welche Audit-Daten sollten wir mindestens aufheben?

Wir empfehlen Logon-/Logoff, Datei-Zugriffe auf sensible Shares, Löschungen und Umbenennungen — mindestens 90 Tage, in regulierten Branchen 180 Tage oder länger. Zentral gespeichert, nicht nur auf dem NAS, damit ein Angreifer die Spuren nicht gleich mitverschlüsselt.

Was kostet die Umstellung in einem typischen KMU-Projekt?

Das hängt stark von der Zahl der Clients, dem Zustand der Alt-Geräte und dem bestehenden Monitoring ab. Als Rahmen: ein kleineres Projekt mit 20 bis 50 Clients, einem TrueNAS und einem bestehenden AD planen wir meist in ein bis zwei Umsetzungstagen plus Vor- und Nachbereitung. Konkrete Zahlen gern auf Anfrage.

Wie passt das Thema zu einem späteren Upgrade auf TrueNAS 27?

Die hier beschriebenen SMB-Einstellungen bleiben mit dem Upgrade auf TrueNAS 27, das Anfang Dezember 2026 als GA erwartet wird, kompatibel. Alle Protokoll-Hygiene-Schritte, die Sie jetzt auf 25.10 Goldeye umsetzen, bleiben erhalten. Mehr dazu in unserem Artikel zur TrueNAS 27 Umbenennung.