Extop zeigt keine Nutzung von C6. Die Prozessoren wechseln lediglich zwischen C0 und C1:

• C0: Der Prozessorkern arbeitet aktiv.
• C1: Der Kern befindet sich in einem leichten Ruhezustand.
• C6: Wird auf diesem System unter VMware nicht genutzt.

Die tiefen Schlafzustände bleiben damit abgeschaltet. VMware setzt die Einstellung des Servers auf meinem System also ohne weitere Anpassungen um. Zusätzliche Startparameter, wie zuvor bei Proxmox, waren nicht notwendig.

Das Ergebnis hat allerdings seinen Preis: Bereits im Leerlauf benötigt der Server rund 150 Watt.

Ob das sinnvoll ist, hängt wieder vom Einsatzzweck ab. Für ein Homelab ist ein dauerhaft hoher Verbrauch meistens unnötig. Bei Arbeitslasten, die kurze Reaktionszeiten und eine möglichst gleichbleibende Leistung benötigen, kann dieses Verhalten dagegen gewünscht sein.

Der Vergleich zeigt vor allem eines: Die gleiche BIOS-Einstellung kann sich je nach Hypervisor unterschiedlich auswirken. Während Proxmox auf meinem Server trotz „Static High Performance“ weiterhin C6 nutzte, beschränkt sich VMware auf C0 und C1.

Damit macht VMware in diesem Fall genau das, was im BIOS bestellt wurde. Es liefert volle Leistung und schickt anschließend die passende Stromrechnung.

Kurz gesagt:

• C-States bestimmen, wie tief die CPU im Leerlauf schläft.
• P-States bestimmen Takt und Spannung, während die CPU arbeitet.
  
  Lenovopress p-states-with-linux-on-intel-based-servers

apt update && apt install -y powertop linux-cpupower
cpupower frequency-info

Aktuelles Performance Profil anzeigen lassen:

So weit, so gut, aber ich werde das Gefühl nicht los, dass ich wieder veräppelt werde… beginnende Paranoia?

steuerung aller CPU´s anzeigen lassen:
grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Das passt auch. Warum bin ich so misstrauisch? Energischer nachfragen!

for f in /sys/devices/system/cpu/cpu*/power/energy_perf_bias; do echo -n "$(basename $(dirname $(dirname $f))): "; cat $f; done

Was bedeutet „6“, mal recherchieren „CPU_frequency_scaling“,… ha… erwischt

Dauerhafte Umstellung (nach Neustarts)

Da Proxmox (Debian) diese Werte beim Booten neu einliest, sollten Sie die Einstellung automatisieren. Am saubersten gelingt dies über eine udev-Regel. Dadurch wird der Wert automatisch auf 0 gesetzt, sobald das System die CPU-Kerne beim Booten initialisiert.

1. Erstellen Sie eine neue Regeldatei:bashnano /etc/udev/rules.d/99-cpu-performance.rules
2. Fügen Sie die folgende Zeile ein:textACTION=="add", SUBSYSTEM=="cpu", ATTR{power/energy_perf_bias}="0"
3. Speichern Sie die Datei

Hat es sich gelohnt?

Ob die Änderung wirklich etwas gebracht hat, muss am Ende jeder für sich selbst entscheiden. Mein Server verbraucht im Leerlauf jetzt rund 40 Watt mehr. Auf ein Jahr gerechnet sind das immerhin etwa 350 Kilowattstunden zusätzlich.

Ist es das wert?

In einem Homelab vermutlich eher nicht. Bei Arbeitslasten, die kurze Reaktionszeiten und eine gleichbleibend hohe Leistung benötigen, kann es dagegen sinnvoll sein. Entscheidend ist, ob sich die Verbesserung auch wirklich messen lässt. Nur weil C6 nicht mehr genutzt wird, läuft eine Anwendung nicht automatisch schneller.

Spannend finde ich trotzdem, an welchen Stellen man etwas hinters Licht geführt wird. Im BIOS steht „Static High Performance“, die C-States sind abgeschaltet und trotzdem entscheidet das Betriebssystem am Ende anders.

Kaum macht man es richtig, funktioniert es. Die Stromrechnung erinnert einen dann aber daran, dass volle Leistung auch ihren Preis hat.

Der Tanker läuft mit voller Kraft voraus. Keine unnötigen Pausen, keine Tiefschlafphase und möglichst geringe Verzögerungen.

Oder?

Nö. Das interessiert meinen Lieblings-Hypervisor Proxmox auf Debian-Basis offenbar einen feuchten ***.

Warum wird C6 trotzdem genutzt?

Obwohl im BIOS alles korrekt eingestellt war, zeigte PowerTOP weiterhin, dass die Prozessoren fleißig den tiefen C6-Zustand nutzten.

Also begann die übliche Fehlersuche:

• BIOS-Einstellungen prüfen
• Einstellungen zurücksetzen und neu setzen
• BIOS aktualisieren
• Server neu starten
• Erneut messen
• Langsam an sich selbst zweifeln

Nach mehreren Durchläufen und einigen energischen Rückfragen lieferte die Google-KI schließlich einen entscheidenden Hinweis: Der Linux-Kernel verwendet auf Intel-Systemen den Treiber intel_idle. Dieser verwaltet die verfügbaren Ruhemodi der CPU und kann dabei tiefere C-States anbieten, obwohl diese im BIOS vermeintlich eingeschränkt wurden.

Ganz aus der Luft gegriffen war diese Aussage nicht. IBM beschreibt genau dieses Verhalten für bestimmte Serversysteme. Auch die Dokumentation des Linux-Kernels bestätigt, dass intel_idle und acpi_idle unterschiedliche Wege zur Verwaltung der C-States nutzen.

Wichtig ist jedoch: Das ist kein reines HPE- oder Proxmox-Problem. Es betrifft das Zusammenspiel aus Firmware, Prozessor und Linux-Kernel. Außerdem sind „High Performance“ und das Abschalten tiefer C-States nicht automatisch dasselbe. Das eine betrifft vor allem die Leistung und Taktsteuerung, das andere die Ruhephasen der CPU.

Die Lösung

EFI: In meinem Fall half der folgende Kernel-Parameter:

intel_idle.max_cstate=1

Damit darf intel_idle weiterhin genutzt werden, wird aber auf einen flachen C-State begrenzt.

Bei einem Proxmox-System sollte zuerst geprüft werden, welcher Bootloader tatsächlich verwendet wird:

proxmox-boot-tool status

Wenn das Ergebniss wie bei mir EFI ist müssen wir folgendes machen:

nano /etc/kernel/cmdline

und folgendes in der Zeile hinzufügen:

intel_idle.max_cstate=1

Danach wird die Boot-Konfiguration aktualisiert:

proxmox-boot-tool refresh

BIOS: Bei einer klassischen GRUB-Konfiguration wird der Parameter dagegen in /etc/default/grub innerhalb von GRUB_CMDLINE_LINUX_DEFAULT eingetragen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"

Anschließend:

update-grub
reboot

Nach dem Neustart kann geprüft werden, welcher Treiber aktiv ist:

cat /sys/devices/system/cpu/cpuidle/current_driver

Zusätzlich sollte kontrolliert werden, ob der Parameter wirklich übernommen wurde:

cat /proc/cmdline

Und siehe da: C6 war verschwunden und der Server verhielt sich endlich so, wie es die BIOS-Einstellung bereits versprochen hatte.

Kaum macht man es richtig, funktioniert es.

Kleiner Hinweis

Das Einschränken tiefer C-States kann den Stromverbrauch und die Wärmeentwicklung erhöhen. Es sollte daher nicht vorsorglich auf jedem Server umgesetzt werden. Sinnvoll ist es vor allem dann, wenn messbare Verzögerungen auftreten und ein Vorher-Nachher-Test zeigt, dass die Änderung wirklich hilft. Das Performance Workload Profil ändert nichts an den C-States Einstellungen.

Quellen:

• Linux Kernel: CPU Idle Time Management
• Linux Kernel: Parameter intel_idle.max_cstate
• IBM: Linux ignores C-State settings in UEFI
• Proxmox: Host Bootloader
• Prozessor P-States und C-States
• https://www.spec.org/cpu2017/flags/HPE-Platform-Flags-Intel-V1.1-HSW-revB.html

Doch es bleibt noch >> „Die Frage nach den P-States“ >>

Beim Restore ist mir etwas aufgefallen, was mich erstmal etwas stutzig gemacht hat.

Proxmox zeigte mir beim Restore Geschwindigkeiten von 695 MB/s und teilweise sogar über 2.500 MB/s an. Das wäre schön, passt aber nicht so ganz zu meiner Umgebung. Der Proxmox Backup Server ist nämlich nur mit 1 Gbit/s angebunden. Mehr als rund 125 MB/s können also gar nicht über die Leitung kommen.

...
progress 95% (read 122406567936 bytes, zeroes = 65% (80488693760 bytes), duration 203 sec)
progress 96% (read 123698413568 bytes, zeroes = 66% (81780539392 bytes), duration 203 sec)
progress 97% (read 124986064896 bytes, zeroes = 66% (83068190720 bytes), duration 203 sec)
progress 98% (read 126273716224 bytes, zeroes = 66% (84355842048 bytes), duration 203 sec)
progress 99% (read 127561367552 bytes, zeroes = 67% (85643493376 bytes), duration 203 sec)
progress 100% (read 128849018880 bytes, zeroes = 66% (86205530112 bytes), duration 209 sec)
restore image complete (bytes=128849018880, duration=209.95s, speed=585.29MB/s)
restore proxmox backup image: /usr/bin/pbs-restore --repository pizza-pan@pbs!pizza-pan-pbs02@pbs02.xyz.de:Backup --ns ABC vm/101/2026-08-13T00:21:19Z drive-scsi1.img.fidx /dev/zvol/rpool/data/vm-600-disk-2 --verbose --format raw --keyfile /etc/pve/priv/storage/PBS02.enc --skip-zero
connecting to repository 'pizza-pan@pbs!pizza-pan-pbs02@pbs02.xyz.de:Backup'
using up to 4 threads
open block backend for target '/dev/zvol/rpool/data/vm-600-disk-2'
starting to restore snapshot 'vm/101/2026-08-13T00:21:19Z'
download and verify backup index
fetching up to 16 chunks in parallel
progress 1% (read 10737418240 bytes, zeroes = 0% (37748736 bytes), duration 27 sec)
progress 2% (read 21474836480 bytes, zeroes = 0% (37748736 bytes), duration 58 sec)
progress 3% (read 32212254720 bytes, zeroes = 0% (37748736 bytes), duration 91 sec)
progress 4% (read 42949672960 bytes, zeroes = 0% (37748736 bytes), duration 126 sec)
progress 5% (read 53687091200 bytes, zeroes = 0% (37748736 bytes), duration 173 sec)
progress 6% (read 64424509440 bytes, zeroes = 0% (37748736 bytes), duration 206 sec)
....
progress 97% (read 1041529569280 bytes, zeroes = 38% (397942980608 bytes), duration 1472 sec)
progress 98% (read 1052266987520 bytes, zeroes = 38% (408680398848 bytes), duration 1472 sec)
progress 99% (read 1063004405760 bytes, zeroes = 39% (419417817088 bytes), duration 1472 sec)
progress 100% (read 1073741824000 bytes, zeroes = 40% (430146846720 bytes), duration 1472 sec)
restore image complete (bytes=1073741824000, duration=1472.39s, speed=695.47MB/s)

open block backend for target '/dev/zvol/rpool/data/vm-600-disk-3'
starting to restore snapshot 'vm/101/2026-08-13T00:21:19Z'
download and verify backup index
fetching up to 16 chunks in parallel
progress 1% (read 3758096384 bytes, zeroes = 22% (864026624 bytes), duration 1 sec)
progress 2% (read 7516192768 bytes, zeroes = 11% (864026624 bytes), duration 7 sec)
progress 3% (read 11274289152 bytes, zeroes = 7% (864026624 bytes), duration 15 sec)
progress 4% (read 15032385536 bytes, zeroes = 5% (864026624 bytes), duration 22 sec)
progress 5% (read 18790481920 bytes, zeroes = 4% (864026624 bytes), duration 25 sec)
progress 6% (read 22548578304 bytes, zeroes = 3% (864026624 bytes), duration 27 sec)
...
progress 98% (read 368293445632 bytes, zeroes = 25% (94493474816 bytes), duration 142 sec)
progress 99% (read 372051542016 bytes, zeroes = 26% (98251571200 bytes), duration 142 sec)
progress 100% (read 375809638400 bytes, zeroes = 27% (102001278976 bytes), duration 142 sec)
restore image complete (bytes=375809638400, duration=142.56s, speed=2514.02MB/s)

Die Erklärung findet sich im Restore selbst.

Proxmox rechnet die Geschwindigkeit anhand der logischen Größe der virtuellen Festplatte. Leere Bereiche werden dabei dank --skip-zero einfach übersprungen. Bei meiner 1 TB großen Disk waren das immerhin rund 430 GB. Diese Daten müssen weder übertragen noch auf das ZFS geschrieben werden.

Dazu kommt die Komprimierung des Proxmox Backup Servers. Über die 1 Gbit Leitung werden die komprimierten Chunks übertragen und auf dem Proxmox Server wieder entpackt. Aus beispielsweise 100 MB übertragenen Daten können so mehrere hundert MB wiederhergestellte Daten werden.

Die angezeigten 695 MB/s sind also nicht der Netzwerkdurchsatz, sondern die Geschwindigkeit bezogen auf die wiederhergestellte Datenmenge.

Damit war auch geklärt, warum mein 1 Gbit Backup Server plötzlich Geschwindigkeiten erreicht, für die er eigentlich eine deutlich schnellere Netzwerkkarte bräuchte.

Referenz:

https://proxmox.com
https://pbs.proxmox.com/docs/introduction.html

Ich habe mittlerweile die ein oder andere Proxmox Umgebung produktiv im Einsatz. Im Rahmen eines aktuellen Kundenprojekts wollen wir einen Schritt weitergehen und nicht nur über theoretische Werte sprechen.

Wir wollen mit echten Datenmengen testen, wie sich ein Restore einer kompletten Umgebung verhält. Gleichzeitig wollen wir prüfen, welchen Vorteil eine schnelle 10 Gbit Verbindung zwischen zwei Standorten in der Praxis bringt.

Aufbau der Proxmox Testumgebung

Für den Test bauen wir bei Hetzner eine eigene Umgebung auf:

• Zwei Server mit jeweils 10 Gbit Anbindung anmieten
• Proxmox auf beiden Servern über die Hetzner Rescue Console installieren
  • Installation Hetzner
  • Server sicher machen
• Beide Standorte über einen VPN Tunnel miteinander verbinden
• Die Server mit unserem bestehenden Proxmox Backup Server verbinden

Damit haben wir eine Umgebung, die wir für die Restore Tests nutzen können, ohne bestehende produktive Systeme zu beeinflussen.

Restore der Umgebung

Anschließend wollen wir eine bestehende Umgebung auf die beiden Proxmox Server verteilen.

Die Systeme werden dabei auf zwei Standorte aufgeteilt:

Standort A

• Domain Controller
• Datenbankserver

Standort B

• Terminalserver

Beide Standorte verfügen über eine 10 Gbit Anbindung. Die Backups werden direkt aus dem bestehenden Proxmox Backup Server wiederhergestellt.

Uns interessiert dabei vor allem, wie lange die Wiederherstellung mit echten Datenmengen dauert und wo mögliche Flaschenhälse entstehen.

Anwendung über eine 10 Gbit WAN Strecke

Nach dem Restore kommt für uns der eigentlich interessante Teil.

Die Anwendung soll anschließend über die Verbindung zwischen beiden Standorten getestet werden. Dabei wollen wir nicht nur einfache Netzwerk Tests durchführen, sondern die Anwendung so nutzen, wie sie später auch im normalen Betrieb verwendet wird.

Damit wollen wir herausfinden, ob eine 10 Gbit Anbindung zwischen den Standorten im Echtbetrieb einen spürbaren Vorteil bringt.

Am Ende soll der Test zwei einfache Fragen beantworten:

Wie schnell können wir eine komplette Proxmox Umgebung aus unserem Backup wiederherstellen und welchen Vorteil bringt uns eine 10 Gbit Verbindung zwischen zwei Standorten wirklich?

Die Ergebnisse und Erfahrungen aus dem Test werde ich hier im Blog festhalten.

Donnerstag, 11:00 Uhr. Ein Anruf, den man als IT-Dienstleister nicht bekommen möchte.

„Herr Breiter, wir haben gerade das LKA, die Steuerfahndung und die Staatsanwaltschaft im Haus.“

Ich kenne die Räumlichkeiten. Meine Antwort rutscht raus:

„Das ist aber bestimmt kuschelig.“

Ein kurzer Lacher am anderen Ende.

Dann wird es ernst.

„Entweder wir liefern jetzt die Daten – oder der Server wird beschlagnahmt.“

Und plötzlich geht es nicht mehr um irgendein theoretisches IT-Notfallszenario.

Es geht um laufende Systeme, sensible Daten, rechtliche Vorgaben – und darum, innerhalb kürzester Zeit die richtigen Entscheidungen zu treffen.

Die entscheidende Frage lautet:

Wie verhält man sich als Unternehmen und IT-Dienstleister in einer solchen Situation?

Das Wichtigste zuerst: Ruhe bewahren

Eine Durchsuchung durch Ermittlungsbehörden gehört für die meisten Unternehmen glücklicherweise nicht zum Alltag.

Genau deshalb trifft sie die Beteiligten meist völlig unvorbereitet.

Mitarbeiter werden nervös. Telefone klingeln. Fragen kommen gleichzeitig. Und plötzlich möchte jeder wissen, was jetzt zu tun ist.

Das Schlechteste, was man in diesem Moment tun kann, ist improvisieren.

Keine vorschnellen Zusagen. Keine eigenmächtige Herausgabe von Daten. Keine Spekulationen.

Stattdessen gilt:

Ruhe bewahren, Zuständigkeiten klären und strukturiert vorgehen.

Was dürfen die Behörden überhaupt?

Eine der ersten Fragen sollte sein, auf welcher rechtlichen Grundlage die Maßnahme erfolgt.

Liegt beispielsweise ein richterlicher Durchsuchungs- oder Beschlagnahmebeschluss vor?

Ein solcher Beschluss sollte vorgelegt und – soweit in der konkreten Situation möglich – durch die zuständigen Verantwortlichen beziehungsweise einen Rechtsbeistand geprüft werden.

Dabei geht es unter anderem darum:

• Welche Räumlichkeiten und Systeme sind betroffen?
• Welche Daten oder Unterlagen werden gesucht?
• Gegen wen beziehungsweise welches Unternehmen richtet sich die Maßnahme?
• Welchen Umfang hat der Beschluss?

Denn auch bei einer behördlichen Maßnahme bedeutet ein IT-System voller Daten nicht automatisch, dass sämtliche darauf gespeicherten Informationen gleichermaßen relevant sind.

Welche Rechte und Pflichten konkret bestehen, sollte jedoch nicht spontan vom IT-Dienstleister beurteilt werden. Im Zweifel gehört diese Frage sofort in die Hände eines Rechtsanwalts.

Die besondere Rolle des IT-Dienstleisters

Für uns als IT-Dienstleister entsteht in diesem Moment eine ungewöhnliche Situation.

Wir kennen die Infrastruktur.

Wir wissen, wo Daten liegen.

Wir kennen Zugänge, Backups, Server und Systeme.

Damit können wir technisch sehr schnell helfen.

Aber genau darin liegt auch das Risiko.

Technisch etwas tun zu können bedeutet nicht automatisch, dass man es auch tun sollte oder darf.

Deshalb sollte ein IT-Dienstleister nicht eigenständig entscheiden, welche Daten herausgegeben werden.

Stattdessen müssen Zuständigkeiten geklärt, rechtliche Vorgaben berücksichtigt und Maßnahmen sauber dokumentiert werden.

Das gilt besonders dann, wenn sensible Unternehmens-, Kunden- oder personenbezogene Daten betroffen sind.

Darf man Fragen beantworten?

Grundsätzlich sollte man bei Fragen der Ermittlungsbehörden vor allem eines vermeiden: Spekulationen.

Wenn technische Auskünfte erforderlich und rechtlich abgestimmt sind, gilt:

Nur gesicherte Fakten nennen.

Nicht vermuten. Nicht interpretieren. Nicht versuchen, Zusammenhänge zu erklären, die man selbst nicht sicher beurteilen kann.

Und vor allem die eigene Rolle klar benennen:

„Ich bin der IT-Dienstleister und kann Ihnen die technische Struktur erklären.“

Das ist etwas anderes, als Aussagen über geschäftliche Vorgänge oder Verantwortlichkeiten innerhalb des Unternehmens zu treffen.

Der kritische Moment: Zugriff auf die Daten

In unserem Fall wurde schnell deutlich, worum es ging.

Bestimmte Daten sollten sichergestellt werden.

Technisch gab es grundsätzlich zwei Szenarien:

Entweder die benötigten Daten konnten – im rechtlich abgestimmten Rahmen – gezielt bereitgestellt werden.

Oder die Ermittlungsbehörden hätten möglicherweise die entsprechende Hardware zur weiteren Auswertung mitgenommen.

Für ein Unternehmen kann Letzteres erhebliche Folgen haben.

Wenn ein produktiver Server plötzlich nicht mehr verfügbar ist, geht es nicht nur um IT.

Dann geht es um Arbeitsplätze, Aufträge, Kommunikation, Produktion und möglicherweise den gesamten Geschäftsbetrieb.

Genau deshalb darf eine solche Situation nicht erst dann durchdacht werden, wenn die Behörden bereits im Serverraum stehen.

Was in unserem Fall den Betrieb gerettet hat

Nach ungefähr zwei Stunden war die Situation technisch unter Kontrolle.

Die erforderlichen Daten konnten gezielt bereitgestellt werden.

Die Systeme blieben verfügbar.

Der Geschäftsbetrieb konnte weiterlaufen.

Keine hektische Wiederherstellung. Kein stunden- oder tagelanger Systemausfall.

Der Grund dafür war erstaunlich unspektakulär:

Vorbereitung.

Nicht irgendein besonders cleverer Trick.

Keine spontane Heldentat.

Sondern Dinge, die lange vorher erledigt worden waren.

Drei Dinge, die im Ernstfall den Unterschied machen

1. Saubere Dokumentation

Wer erst während eines Notfalls herausfinden muss, auf welchem System welche Daten liegen, hat bereits wertvolle Zeit verloren.

Eine aktuelle Dokumentation der Infrastruktur hilft dabei, schnell zu erkennen, welche Systeme betroffen sind und welche Abhängigkeiten bestehen.

2. Ein einfaches Notfallhandbuch

Ein Notfallhandbuch muss kein 150-seitiger Ordner sein, den im entscheidenden Moment niemand liest.

Es muss vor allem klare Antworten liefern:

Wer wird angerufen? Wer darf entscheiden? Wer spricht mit Behörden? Wer kontaktiert den Rechtsbeistand? Wer dokumentiert technische Maßnahmen?

Diese Fragen sollten beantwortet sein, bevor der Ernstfall eintritt.

3. Funktionierende Backups

Ein Backup ist erst dann ein gutes Backup, wenn bekannt ist, dass es sich tatsächlich wiederherstellen lässt.

Gerade wenn Hardware ausfällt, beschädigt wird oder nicht mehr zur Verfügung steht, kann eine funktionierende Backup- und Wiederherstellungsstrategie darüber entscheiden, wie lange ein Unternehmen stillsteht.

Der eigentliche IT-Notfall beginnt lange vor dem Notfall

Der Vorfall hat mir noch einmal deutlich gezeigt, was gute IT ausmacht.

Nicht nur schnelle Server.

Nicht nur Firewalls.

Nicht nur Backups.

Sondern die Fähigkeit, auch in einer außergewöhnlichen Situation handlungsfähig zu bleiben.

Dazu gehören Technik, Dokumentation und klare Prozesse genauso wie die Erkenntnis, wann eine Entscheidung nicht mehr in den Aufgabenbereich der IT gehört.

Ein IT-Dienstleister sollte in einer solchen Situation nicht versuchen, Jurist zu spielen.

Aber er sollte seine Infrastruktur so gut kennen und vorbereitet haben, dass technische Entscheidungen schnell, kontrolliert und nachvollziehbar umgesetzt werden können.

Fazit: Vorbereitung schlägt Improvisation

An diesem Donnerstag hätte die Geschichte anders ausgehen können.

Server weg.

Systeme nicht verfügbar.

Mitarbeiter können nicht arbeiten.

Der wirtschaftliche Schaden wächst mit jeder Stunde.

Stattdessen lief der Betrieb nach kurzer Zeit weiter.

Nicht, weil jemand im entscheidenden Moment besonders heldenhaft reagiert hat.

Sondern weil die Grundlagen vorher geschaffen worden waren:

Dokumentation. Notfallplan. Backups. Klare Zuständigkeiten.

Der beste IT-Notfall ist natürlich der, der niemals eintritt.

Aber auf manche Situationen hat man keinen Einfluss.

Darauf vorbereitet zu sein, sehr wohl.

Hinweis: Dieser Beitrag beschreibt Erfahrungen aus der Praxis und stellt keine Rechtsberatung dar. Welche Rechte und Pflichten bei einer Durchsuchung, Beschlagnahme oder Datenherausgabe bestehen, hängt vom konkreten Einzelfall ab und sollte mit einem entsprechend spezialisierten Rechtsbeistand geklärt werden.

Um das Problem zu lösen, habe ich einen Server bei Hetzner gemietet.

Mein Setup besteht aus einer handelsüblichen Maschine mit 32 GB RAM und 1 TB SSD. Darauf läuft Proxmox, mit dem ich mehrere virtuelle Umgebungen betreiben kann.

Proxmox wurde über die Konsole auf einem dedizierten Server bei Hetzner installiert. Innerhalb des Servers habe ich mehrere Netzwerksegmente eingerichtet, die durch die integrierte Proxmox‑Firewall voneinander getrennt und geschützt sind.

Der Datenverkehr zwischen den virtuellen Umgebungen und dem Internet wird zuverlässig überwacht und geschützt. Dafür verwende ich eine OPNsense‑Firewall, die als sichere Datenschleuse dient.

Als privaten Cloud‑Speicher nutze ich Nextcloud in einem fertigen Container (in meinem Fall NextcloudPi). Dieser Container wird durch Proxmox direkt bereitgestellt. Nach der Installation ist Nextcloud sofort einsatzbereit und erfordert nur minimalen Konfigurationsaufwand. Man kann sogar direkt SSL‑Zertifikate über Let’s Encrypt installieren.

(https://community-scripts.github.io/ProxmoxVE/scripts?id=nextcloudpi)

Der Proxmox‑Server ist von außen über Port 8006 per SSL erreichbar. Der Zugriff ist jedoch auf 2–3 feste IP‑Adressen beschränkt, um die Sicherheit weiter zu erhöhen.

Die Test‑Umgebung

Für das Management und die tägliche Arbeit mit der Umgebung nutze ich eine virtuelle Ubuntu‑Maschine. Diese VM befindet sich ebenfalls in einem separaten Netzwerksegment.

Die Datenschleuse ist fest eingebunden, sodass hochgeladene Nextcloud‑Daten sofort in der VM‑Umgebung genutzt und analysiert werden können.

Zur Überprüfung der Daten kommt ein Windows‑System (Windows 11) zum Einsatz. Dieses läuft mit dem Flare VM Framework. (https://github.com/mandiant/flare-vm)

Die virtuelle Maschine wird jede Nacht automatisch um 03:00 Uhr per Cronjob zurückgesetzt, um stets einen sauberen Ausgangszustand zu gewährleisten.

0 3 * * * /root/reset_vm.sh

#!/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# VM-ID und Snapshot-Name anpassen
VM_ID=105
SNAPSHOT_NAME="Clean"

# VM stoppen, falls sie läuft
qm stop $VM_ID

# Snapshot wiederherstellen
qm rollback $VM_ID $SNAPSHOT_NAME

# VM wieder starten
qm start $VM_ID

echo "VM $VM_ID wurde erfolgreich auf Snapshot '$SNAPSHOT_NAME' zurückgesetzt."

Im nächsten Schritt plane ich, den Zugang zum Proxmox‑Server so weit einzuschränken, dass er von außen nicht mehr erreichbar ist. Die Verwaltung soll dann ausschließlich über die interne Management‑VM erfolgen. Diese kann sicher über ein Fernwartungstool wie z. B. RustDesk betrieben werden.

Kosten und Aufwand des Projekts

• Server bei Hetzner: ca. 60 € pro Monat
• Arbeitszeit für Setup und Grundkonfiguration: ca. 2 Tage
• Zeitaufwand für individuelle Anpassungen: geschätzt weitere 2–3 Tage, je nach Bedarf

Alternativ kann das ganze Setup auch auf einem kleinen mini PC laufen

Wichtiger Hinweis

Bitte überprüfe unbedingt die AGB des Hosters genau – insbesondere im Hinblick auf die geplante Nutzung. Das Ziel ist nicht die Entwicklung oder das absichtliche Testen von Schadsoftware, sondern ausschließlich die Analyse und Prüfung verdächtiger E‑Mails. Gefundene Bedrohungen sollen selbstverständlich umgehend gelöscht werden.

Achte außerdem darauf, dass die Testumgebung durch eine Firewall abgesichert ist – idealerweise mit Intrusion Detection und Prevention. So stellst du sicher, dass im Falle eines Schadcodes (z. B. in einem Anhang) kein Risiko für andere Systeme im Rechenzentrum oder im Netzwerk bei Hetzner entsteht.

Proxmox absichern leicht gemacht

Proxmox ist eine leistungsstarke Open-Source-Virtualisierungslösung, die in vielen HomeLabs, KMUs und IT-Infrastrukturen zum Einsatz kommt. Doch wie bei jedem öffentlich erreichbaren System besteht ein Risiko: ungesicherte SSH- oder WebGUI-Zugriffe bieten ein leichtes Ziel für automatisierte Brute-Force-Angriffe.

Genau hier setzt Fail2Ban an – ein effektives Tool zur Abwehr solcher Angriffe. In diesem Beitrag zeigen wir dir, warum die Absicherung deines Proxmox-Servers so wichtig ist und wie du SSH und optional die WebGUI mit Fail2Ban schützt – Schritt für Schritt.

Warum SSH- und WebGUI-Zugriffe schützen?

Jeder öffentlich zugängliche Server ist täglich Ziel tausender automatisierter Login-Versuche. Besonders SSH-Zugänge auf Port 22 und die WebGUI von Proxmox (Port 8006) sind beliebte Angriffsziele. Ohne Schutz können Angreifer durch sogenannte Brute-Force-Attacken Passwörter erraten und sich unautorisierten Zugang verschaffen.

Fail2Ban analysiert Logdateien, erkennt solche Attacken und blockiert verdächtige IP-Adressen automatisch – bevor Schaden entsteht.

Schritt-für-Schritt: Fail2Ban für Proxmox einrichten

1. Fail2Ban installieren

Als erstes machen wir ein apt update und danach ein apt install

apt update && apt install fail2ban -y

Nach der Installation kannst du die Version prüfen:

fail2ban-client -V

2. Web-Zugriff absichern

Erstelle eine lokale Konfiguration:
Hierzu kopieren wir erst zu Sicherheit die aktuelle jail.conf nach jail.local

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Bearbeite die Datei:

nano /etc/fail2ban/jail.local

Am Ende der Datei jail.local einfach folgendes hinzufügen:

[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h

Filter anlegen:

nano /etc/fail2ban/filter.d/proxmox.conf

Füge hinzu:

[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service

3. SSH-Zugriff absichern

Suchen Sie wieder in der Datei jail.local nach dem Eintrag [sshd] und falls vorhanden ersetzen oder erstellen Sie den Block:

[sshd]

enabled	= true
port    = ssh
filter	= sshd
logpath	= /var/log/auth.log
maxretry = 4

4. Fail2Ban aktivieren und starten

systemctl enable fail2ban
systemctl start fail2ban

Status prüfen:

systemctl status fail2ban

#Sollte folgendes ausgeben:
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-04-01 21:24:24 CEST; 3s ago
       Docs: man:fail2ban(1)
   Main PID: 136991 (fail2ban-server)
      Tasks: 7 (limit: 38169)
     Memory: 29.7M
        CPU: 251ms
     CGroup: /system.slice/fail2ban.service
             └─136991 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Sollte aber ein Fehler ausgegeben werden:

× fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2025-04-01 21:22:18 CEST; 6s ago
   Duration: 74ms
       Docs: man:fail2ban(1)
    Process: 135997 ExecStart=/usr/bin/fail2ban-server -xf start (code=exited, status=255/EXCEPTION)
   Main PID: 135997 (code=exited, status=255/EXCEPTION)
        CPU: 73ms

Apr 01 21:22:18 pve-SandBox systemd[1]: Started fail2ban.service - Fail2Ban Service.
Apr 01 21:22:18 pve-SandBox fail2ban-server[135997]: 2025-04-01 21:22:18,631 fail2ban.configreader   [135997]: WARNING 'allowipv6' not defined in 'Definitio>
Apr 01 21:22:18 pve-SandBox fail2ban-server[135997]: 2025-04-01 21:22:18,638 fail2ban                [135997]: ERROR   Failed during configuration: Have not>
Apr 01 21:22:18 pve-SandBox fail2ban-server[135997]: 2025-04-01 21:22:18,638 fail2ban                [135997]: ERROR   Async configuration of server failed
Apr 01 21:22:18 pve-SandBox systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION
Apr 01 21:22:18 pve-SandBox systemd[1]: fail2ban.service: Failed with result 'exit-code'.

Muss rsyslog nachinstalliert werden:

apt install rsyslog

Kontrolle & Monitoring

Zeige gebannte IPs an:

fail2ban-client status
iptables -L -n

Manuelle Entsperrung:

fail2ban-client set sshd unbanip 192.168.0.1

Fazit

Mit wenigen Befehlen hast du deinen Proxmox-Server deutlich sicherer gemacht. Fail2Ban schützt dich zuverlässig vor Brute-Force-Angriffen auf SSH und optional auch die WebGUI. Du solltest es aber dennoch vermeiden deinen Proxmox Server nach außen zu veröffentlichen.

FAQ: Häufige Fragen zu Fail2Ban in Proxmox

Was passiert, wenn ich mich selbst aussperre?
→ Du kannst dich über ein anderes Gerät oder Netz verbinden und dich manuell mit unbanip entsperren.

Kann ich auch andere Dienste mit Fail2Ban absichern?
→ Ja, Fail2Ban unterstützt viele Dienste wie Apache, nginx, Postfix, FTP und mehr.

Wie lange bleibt eine IP gebannt?
→ Standardmäßig 1 Stunde (bantime = 1h), individuell anpassbar.

Funktioniert Fail2Ban auch mit UFW oder iptables?
→ Ja. Fail2Ban nutzt intern iptables-Regeln, ist aber mit UFW kompatibel.

Hier zeig ich dir kurz, was das Skript alles macht – vielleicht hilft’s dir ja auch.

Erkennt automatisch, ob es eine VM ist

Bevor’s losgeht, prüft das Skript, ob es in einer virtuellen Maschine läuft. Wenn nicht, gibt’s eine Warnung und du kannst entscheiden, ob du weitermachen willst. Praktisch, damit du versehentlich nicht auf einem Host rumpfuscht.

Visuelle Effekte abschalten

Alle Animationen und Eye-Candy-Effekte werden deaktiviert. Das spart RAM und CPU, was gerade bei RDP/Terminalservern oder kleinen VMs nützlich ist. Du kannst das sogar global für alle Benutzerprofile umsetzen.

Energieschema auf „Höchstleistung“

Windows neigt dazu, die Leistung automatisch zu drosseln. Das Skript stellt die Energieeinstellungen direkt auf volle Leistung – genau das, was du für produktive Server willst.

Netzwerk-Tuning für VMs

Wenn du VirtIO-Treiber nutzt, wird das Netzwerk optimiert:

• TCP-Offloading wird deaktiviert
• Receive Side Scaling wird aktiviert

Das sorgt für stabilere und schnellere Netzwerklastverteilung.

Unnötige Dienste und Apps deaktivieren

Dienste wie Telemetrie, Kartendienst und die Windows-Suche (wenn nicht nötig) werden gestoppt und deaktiviert. Auch vorinstallierte Apps wie Xbox & Co. werden entfernt – perfekt für schlanke Server-Setups.

Keine automatischen Neustarts nach Updates

Damit dich Windows nicht mitten im Betrieb einfach neu startet, wird diese Funktion deaktiviert – solange ein Benutzer angemeldet ist.

NTP-Zeitserver konfigurieren

Der Server kann sich auf Wunsch mit pool.ntp.org synchronisieren. Das sorgt für eine saubere Uhrzeit, besonders bei Proxmox-Setups, wo die Host-Zeit nicht immer zuverlässig durchgereicht wird.

Windows Defender „entschärfen“

Windows Defender wird nicht deaktiviert, aber der maximale CPU-Verbrauch beim Scannen wird begrenzt. Das bringt etwas Luft, ohne auf Schutz zu verzichten.

Core Parking deaktivieren

Standardmäßig „parkt“ Windows ungenutzte CPU-Kerne. Das Skript sorgt dafür, dass alle Kerne ständig verfügbar sind – besonders hilfreich bei schwach ausgelasteten VMs.

TRIM für SSD/Thin Storage

TRIM gibt freien Speicher an den Host zurück. Du kannst einstellen, ob TRIM aktiviert oder deaktiviert werden soll – je nachdem, ob du Proxmox mit discard=on oder z. B. VMware mit Thin-VMDK nutzt.

Visuelle Effekte global abschalten (optional)

Für Terminalserver oder besonders minimalistische Umgebungen kannst du die visuellen Effekte auch global für alle Benutzer deaktivieren. Das spart nochmal Ressourcen.

Fazit

Das Skript ist kein Hexenwerk, aber es nimmt dir ordentlich Arbeit ab – vor allem bei wiederholten VM-Installationen.

Schnell, pragmatisch, anpassbar.
Ein Neustart nach dem Durchlauf wird empfohlen.

Fragen, Tipps oder eigene Erfahrungen? Lass gern einen Kommentar da!

# Optimierungsskript für Windows Server 2022 auf Proxmox

# -----------------------------
# 0. Systemprüfung: Läuft dieses System in einer VM?
# -----------------------------
Write-Output "Systemprüfung: Virtuelle Umgebung erkennen..."
$computerSystem = Get-WmiObject -Class Win32_ComputerSystem
$manufacturer  = $computerSystem.Manufacturer
$model         = $computerSystem.Model

$biosInfo = Get-WmiObject -Class Win32_BIOS
$biosVendor = $biosInfo.Manufacturer

# Erkennungsmuster für VMs (viele Hypervisoren melden sich als Hersteller)
$vmPatterns = @("QEMU", "KVM", "Microsoft Corporation", "VMware", "VirtualBox", "Xen", "Parallels", "Red Hat")

$isVM = $false
foreach ($pattern in $vmPatterns) {
    if ($manufacturer -like "*$pattern*" -or $model -like "*$pattern*" -or $biosVendor -like "*$pattern*") {
        $isVM = $true
        break
    }
}

if (-not $isVM) {
    Write-Warning "⚠ Dieses System scheint keine virtuelle Maschine zu sein."
    $proceed = Read-Host "Möchtest du das Skript trotzdem fortsetzen? (J/N)"
    if ($proceed -notmatch "^[Jj]") {
        Write-Output "Skript wird beendet."
        exit
    }
} else {
    Write-Output "✅ Virtuelle Maschine erkannt: $manufacturer / $model"
}




Write-Output "Starte Optimierung des Windows Server 2022..."

# 1. Deaktiviere unnötige visuelle Effekte
Write-Output "Setze visuelle Effekte auf beste Leistung..."
$PerformanceKey = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects'
Set-ItemProperty -Path $PerformanceKey -Name VisualFXSetting -Value 2

# 2. Deaktiviere Windows-Tipps
Write-Output "Deaktiviere Windows Tipps..."
New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" -Name "SoftLandingEnabled" -Value 0 -PropertyType DWord -Force
New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" -Name "SubscribedContent-310093Enabled" -Value 0 -PropertyType DWord -Force

# 3. Energieoptionen: Höchstleistung aktivieren
Write-Output "Aktiviere Energieschema Höchstleistung..."
powercfg -setactive SCHEME_MIN

# 4. Netzwerk-Optimierungen (nur wenn VM-Treiber wie VirtIO korrekt installiert sind)
Write-Output "Aktiviere TCP Offloading Optimierungen..."
Get-NetAdapter | ForEach-Object {
    Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName "Large Send Offload v2 (IPv4)" -DisplayValue "Disabled" -ErrorAction SilentlyContinue
    Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName "Large Send Offload v2 (IPv6)" -DisplayValue "Disabled" -ErrorAction SilentlyContinue
    Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName "Receive Side Scaling" -DisplayValue "Enabled" -ErrorAction SilentlyContinue
}

# 5. Dienste deaktivieren (vorsichtig verwenden – abhängig vom Einsatzzweck!)
Write-Output "Deaktiviere nicht benötigte Dienste..."
$ServicesToDisable = @(
    "DiagTrack",            # Connected User Experiences and Telemetry
    "WerSvc",               # Windows Error Reporting
    "WSearch",              # Windows Search (nicht nötig für Server mit wenigen Dateien)
    "MapsBroker"            # Karten Dienst
)

foreach ($svc in $ServicesToDisable) {
    if (Get-Service -Name $svc -ErrorAction SilentlyContinue) {
        Stop-Service -Name $svc -Force -ErrorAction SilentlyContinue
        Set-Service -Name $svc -StartupType Disabled
    }
}

# 6. Deaktiviere automatische Neustarts nach Updates
Write-Output "Verhindere automatische Neustarts nach Updates..."
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "NoAutoRebootWithLoggedOnUsers" -Value 1 -Type DWord

# 7. Aktivieren von NTP-Zeitservern (optional)
Write-Output "Konfiguriere NTP-Zeitserver..."
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync

# 8. Entferne unnötige vorinstallierte Apps (optional/minimal auf Server)
Write-Output "Entferne vorinstallierte Apps (minimal)..."
Get-AppxPackage -AllUsers | Where-Object {$_.Name -like "*Xbox*" -or $_.Name -like "*Zune*"} | Remove-AppxPackage -ErrorAction SilentlyContinue

# 9. Windows Defender – Performance-Tuning (nicht deaktivieren, aber optimieren)
Write-Output "Setze Defender Performance Einstellungen..."
Set-MpPreference -ScanAvgCPULoadFactor 30

# -----------------------------
# 10. Core Parking deaktivieren
# -----------------------------
Write-Output "Deaktiviere Core Parking (für bessere CPU-Auslastung)..."
$parkingKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00\0cc5b647-c1df-4637-891a-dec35c318583"
Set-ItemProperty -Path $parkingKey -Name "ValueMax" -Value 0 -ErrorAction SilentlyContinue
Set-ItemProperty -Path $parkingKey -Name "ValueMin" -Value 0 -ErrorAction SilentlyContinue

# Hinweis: Nach dieser Änderung muss das Energieprofil ggf. neu aktiviert werden
powercfg -setactive SCHEME_MIN

# -----------------------------
# 11. TRIM-Konfiguration per Eingabe
# -----------------------------
Write-Output ""
Write-Output "TRIM (DisableDeleteNotify) Konfiguration"
Write-Output "----------------------------------------"
Write-Output "TRIM aktiviert Speicherfreigabe bei SSD/Thin-Storage (z.B. unter Proxmox mit discard=on)."
Write-Output "0 = TRIM aktivieren (empfohlen für Proxmox)"
Write-Output "1 = TRIM deaktivieren (z.B. bei VMware mit Thin-VMDK)"
$trimChoice = Read-Host "Bitte gewünschten Wert für DisableDeleteNotify eingeben (0 oder 1)"

if ($trimChoice -eq "0" -or $trimChoice -eq "1") {
    Write-Output "Setze DisableDeleteNotify auf $trimChoice..."
    fsutil behavior set DisableDeleteNotify $trimChoice
} else {
    Write-Output "Ungültige Eingabe – TRIM-Einstellung wird übersprungen."
}

# -----------------------------
# 12. Visuelle Effekte und Animationen deaktivieren - aktuelle Nutzer (optional)
# -----------------------------
Write-Output ""
Write-Output "Windows-Optimierung: Visuelle Effekte deaktivieren"
Write-Output "----------------------------------------------------"
Write-Output "Diese Option deaktiviert Fensteranimationen, Schatten, Transparenz und weitere visuelle Elemente."
Write-Output "Vorteil: Geringere CPU- und RAM-Auslastung, ideal für RDP/Terminalserver oder ressourcenschonende Server-VMs."

$visualChoice = Read-Host "Möchtest du alle visuellen Effekte deaktivieren? (J/N)"

if ($visualChoice -match "^[Jj]") {
    Write-Output "Deaktiviere visuelle Effekte..."

    # Setzt System auf beste Leistung (alle visuellen Effekte aus)
    $visualEffectsReg = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects"
    Set-ItemProperty -Path $visualEffectsReg -Name "VisualFXSetting" -Value 2 -ErrorAction SilentlyContinue

    # Deaktiviert einzelne visuelle Features
    $visualTweaks = @{
        "UserPreferencesMask" = ([byte[]](0x90,0x12,0x03,0x80,0x10,0x00,0x00,0x00)) # Beste Leistung
    }

    foreach ($key in $visualTweaks.Keys) {
        New-Item -Path "HKCU:\Control Panel\Desktop" -Force | Out-Null
        Set-ItemProperty -Path "HKCU:\Control Panel\Desktop" -Name $key -Value $visualTweaks[$key]
    }

    # Weitere Animationen ausschalten
    Set-ItemProperty -Path "HKCU:\Control Panel\Desktop" -Name "MenuShowDelay" -Value "0"
    Set-ItemProperty -Path "HKCU:\Control Panel\Desktop" -Name "MouseHoverTime" -Value "0"
    Set-ItemProperty -Path "HKCU:\Control Panel\Desktop" -Name "ForegroundFlashCount" -Value "0"
    Set-ItemProperty -Path "HKCU:\Control Panel\Desktop" -Name "AutoEndTasks" -Value "1"

    # Abschalten von AeroPeek und Taskbar-Animationen
    New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\DWM" -Name "EnableAeroPeek" -Value 0 -PropertyType DWord -Force
    Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "TaskbarAnimations" -Value 0

    Write-Output "Visuelle Effekte wurden abgeschaltet. Abmelden oder Neustart erforderlich, um alle Änderungen zu aktivieren."
} else {
    Write-Output "Visuelle Effekte bleiben unverändert."
}

# -----------------------------
# 13. Visuelle Effekte und Animationen deaktivieren (global, optional)
# -----------------------------
Write-Output ""
Write-Output "Windows-Optimierung: Visuelle Effekte global deaktivieren"
Write-Output "-------------------------------------------------------------"
Write-Output "Diese Option deaktiviert visuelle Effekte (Animationen, Schatten, Transparenz) für alle Benutzer."
Write-Output "Empfohlen für RDP-/Terminalserver oder minimalistische VM-Setups."

$visualChoice = Read-Host "Möchtest du visuelle Effekte für alle Benutzer deaktivieren? (J/N)"

if ($visualChoice -match "^[Jj]") {
    Write-Output "Deaktiviere visuelle Effekte für alle Benutzerprofile..."

    $userPrefsMask = ([byte[]](0x90,0x12,0x03,0x80,0x10,0x00,0x00,0x00))

    $userHives = Get-ChildItem Registry::HKEY_USERS | Where-Object {
        $_.Name -notlike "*_Classes"
    }

    foreach ($hive in $userHives) {
        $sid = $hive.PSChildName
        $regBase = "Registry::HKEY_USERS\$sid"

        # Alle relevanten Unterschlüssel erstellen, wenn nötig
        $pathsToEnsure = @(
            "$regBase\Control Panel\Desktop",
            "$regBase\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects",
            "$regBase\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced",
            "$regBase\Software\Microsoft\Windows\DWM"
        )

        foreach ($path in $pathsToEnsure) {
            if (-not (Test-Path $path)) {
                New-Item -Path $path -Force | Out-Null
            }
        }

        # Einstellungen setzen
        Set-ItemProperty -Path "$regBase\Control Panel\Desktop" -Name "MenuShowDelay" -Value "0" -Force
        Set-ItemProperty -Path "$regBase\Control Panel\Desktop" -Name "MouseHoverTime" -Value "0" -Force
        Set-ItemProperty -Path "$regBase\Control Panel\Desktop" -Name "ForegroundFlashCount" -Value "0" -Force
        Set-ItemProperty -Path "$regBase\Control Panel\Desktop" -Name "AutoEndTasks" -Value "1" -Force
        Set-ItemProperty -Path "$regBase\Control Panel\Desktop" -Name "UserPreferencesMask" -Value $userPrefsMask -Force

        Set-ItemProperty -Path "$regBase\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects" -Name "VisualFXSetting" -Value 2 -Force
        Set-ItemProperty -Path "$regBase\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "TaskbarAnimations" -Value 0 -Force
        Set-ItemProperty -Path "$regBase\Software\Microsoft\Windows\DWM" -Name "EnableAeroPeek" -Value 0 -Force
    }

    Write-Output "Visuelle Effekte wurden für alle Benutzerprofile (inkl. .DEFAULT) deaktiviert."
    Write-Output "Ein Abmelden oder Neustart ist erforderlich, um die Änderungen wirksam zu machen."
} else {
    Write-Output "Visuelle Effekte bleiben unverändert."
}

# Fertig
Write-Output "Optimierung abgeschlossen. Neustart empfohlen."

Die größten Cyberbedrohungen 2025

1. Ransomware 2.0
   Ransomware-Angriffe sind weiterhin eine der größten Bedrohungen. Doch anstelle von einfachen Datenverschlüsselungen gehen Angreifer nun raffinierter vor. Sie drohen mit der Veröffentlichung sensibler Daten (Double Extortion) oder nehmen kritische Infrastrukturen ins Visier.
2. KI-gestützte Angriffe
   Cyberkriminelle setzen Künstliche Intelligenz ein, um Schwachstellen automatisch zu scannen, Phishing-Mails überzeugender zu gestalten oder Sicherheitsmechanismen gezielt zu umgehen.
3. Angriffe auf IoT-Geräte
   Mit der wachsenden Zahl vernetzter Geräte im Unternehmen entstehen neue Einfallstore. Besonders schlecht gesicherte IoT-Geräte (wie Kameras, Drucker oder Sensoren) bieten Hackern leichte Beute.
4. Social Engineering
   Technische Schutzmaßnahmen sind wichtig, doch der Mensch bleibt oft das schwächste Glied in der Sicherheitskette. Social Engineering zielt darauf ab, Mitarbeiter zu manipulieren, um Zugangsdaten oder vertrauliche Informationen preiszugeben.

Wie Unternehmen sich gegen Cyberrisiken wappnen können

1. Next-Generation Firewalls und Netzwerksegmentierung
   Eine starke Firewall und die Segmentierung des Netzwerks verhindern, dass Angreifer sich im System ausbreiten können. Kritische Systeme sollten stets isoliert und nur über sichere VPN-Verbindungen erreichbar sein.
2. Mitarbeiterschulungen und Awareness-Programme
   Regelmäßige Schulungen helfen, das Bewusstsein für Phishing, Social Engineering und sichere Passworthygiene zu stärken.
3. Zero-Trust-Ansatz
   Der Zero-Trust-Ansatz geht davon aus, dass kein Benutzer und keine Anwendung automatisch vertraut werden kann. Stattdessen werden alle Zugriffe kontinuierlich überprüft.
4. Regelmäßige Backups und Notfallpläne
   Tägliche Backups und getestete Notfallpläne sorgen dafür, dass Unternehmen auch nach einem Angriff schnell wieder handlungsfähig sind.
5. Einsatz von Sicherheitssoftware und KI
   Moderne Sicherheitslösungen nutzen selbst KI, um Bedrohungen frühzeitig zu erkennen und automatisch Gegenmaßnahmen einzuleiten.

Fazit: Proaktiv statt reaktiv handeln

Cyberrisiken werden 2025 nicht weniger, doch Unternehmen können sich mit einem ganzheitlichen Sicherheitskonzept effektiv schützen. Wer proaktiv handelt, regelmäßig schult und moderne Sicherheitslösungen einsetzt, reduziert das Risiko erheblich. Gerne unterstützen wir Sie bei der Auswahl und Implementierung der passenden Sicherheitsmaßnahmen, um Ihr Unternehmen bestmöglich zu schützen.