IT-Service Walter  ·  Version 2.3  ·  1. September 2026
NEU

Windows Firewall Manager Pro 2.3

Alles sehen. Ohne sich anzumelden.

Windows Firewall Manager Pro verwaltet die Windows-Firewall von einem Arbeitsplatz aus – über einen Server oder über vierhundert. Regeln anlegen und ändern, das Regelwerk gegen Best Practices prüfen, Abweichungen zwischen Servern finden und alles davon belegbar dokumentieren.

Der Unterschied liegt im Weg dorthin: Das Werkzeug spricht mit einem schlanken Dienst auf dem Server, nicht mit dessen Betriebssystem. Kein PowerShell-Remoting, keine Domänen-Anmeldedaten auf dem Arbeitsplatz, keine Sitzung auf einem Domänencontroller. Tier 0, 1 und 2 bleiben getrennt – auch während der Arbeit daran.

Entwickelt für Administratoren, die Server betreiben, für Sicherheitsverantwortliche, die Nachweise brauchen, und für alle, die beides in einer Person sind.

Das Werkzeug ist Teil der Angriffsfläche

Wer Firewall-Regeln auf vielen Windows-Servern zentral verwalten will, steht vor einer unangenehmen Entscheidung. Der übliche Weg führt über PowerShell-Remoting: WinRM auf 5985 oder 5986 öffnen, Anmeldedaten mit ausreichenden Rechten hinterlegen, fertig. Funktioniert – und hebelt genau das Tier-Modell aus, das man gerade mühsam eingeführt hat.

Denn ein Arbeitsplatz, der sich mit administrativen Anmeldedaten auf einem Domänencontroller anmeldet, ist damit selbst ein Tier-0-System. Wird er kompromittiert, ist die gesamte Domäne kompromittiert. Das Verwaltungswerkzeug wird zum kürzesten Weg ins Herz der Umgebung.

Ein Agent statt einer Anmeldung

Auf dem Server läuft ein schlanker Dienst: eine einzelne signierte EXE, self-contained, ohne installierte .NET-Laufzeit und ohne PowerShell-Remoting. Er nimmt HTTPS auf genau einem Port entgegen, prüft das mitgeschickte Zugriffstoken und setzt die Befehle lokal mit den bordeigenen Windows-Cmdlets um.

Was das in der Praxis bedeutet:

• Die Remoting-Ports 5985, 5986 und 22 bleiben geschlossen. Nach außen ist ein einziger HTTPS-Port offen.
• Keine Domänen-Anmeldedaten auf dem Arbeitsplatz. Das Werkzeug weist sich mit einem Zugriffstoken aus, von dem der Agent ausschließlich den SHA-256-Hash speichert.
• TLS übernimmt Windows selbst über http.sys – der private Schlüssel verlässt den Zertifikatspeicher nie. Bei selbstsigniertem Zertifikat wird der Fingerabdruck angeheftet.
• Der Agent läuft auf gehärteten Servern im PowerShell-Modus ConstrainedLanguage, erzwungen über WDAC oder AppLocker. Genau daran scheitern Werkzeuge, die auf Remoting setzen.
• Tier 0, 1 und 2 bleiben getrennt. Der Arbeitsplatz redet mit einem Dienst, nicht mit dem Betriebssystem des Servers.

Rollout auf vierhundert Server, ohne vierhundert Einträge

Nach der Installation trägt sich der Agent selbst im Active Directory unter seinem eigenen Computerkonto ein und schreibt zusätzlich eine Meldedatei in einen gemeinsamen Ordner – für Server außerhalb der Domäne. Im Werkzeug findet „Agenten suchen“ alle gemeldeten Rechner und übernimmt sie in einem Schritt. Keine Adresse, kein Port, kein Fingerabdruck von Hand.

Das Zugriffstoken holt sich das Werkzeug selbst. Dafür genügt ein einziger Enrollment-Schlüssel je Umgebung, den der Agent beim Rollout mitbekommt. Über die Leitung geht er nie: Die Anmeldung läuft über einen HMAC-SHA-256-Nachweis mit Einmalwert und Fünf-Minuten-Fenster, gebunden an den Rechnernamen, mit Sperre nach fünf Fehlversuchen. Statt zweihundert Token einzusammeln kennen Sie einen Wert – und jeder Agent stellt dem Werkzeug daraufhin sein eigenes aus.

Neue Agent-Fassungen verteilt das Werkzeug später über dieselbe HTTPS-Verbindung, über die es auch die Firewall verwaltet. Keine Softwareverteilung, keine Freigabe, kein zusätzlicher Port. Der Agent nimmt ein Paket nur an, wenn Token, Prüfsumme, Fassung und die Signatur des Herausgebers stimmen.

Was das Werkzeug zeigt

Die Verbindung ist die Voraussetzung, nicht der Zweck. Der Zweck ist, dass jemand am Ende sagen kann, was auf welchem Server erlaubt ist – und belegen kann, warum.

Neu in Version 2.3

Blockierter Verkehr – warum kommt die Verbindung nicht durch?

Die Frage kostet im Alltag die meiste Zeit. Das Werkzeug liest dafür das Firewall-Protokoll des Servers und fasst es nach dem zusammen, wonach man tatsächlich handeln würde: Richtung, Protokoll und Ziel-Port. Dieselbe blockierte Verbindung steht dutzendfach im Protokoll, weil der Absender es wieder versucht – erst die Zusammenfassung zeigt, was nicht durchkommt. Aus dem Befund heraus lässt sich eine passgenaue Freigabe anlegen, beschränkt auf die beobachteten Quelladressen. Fehlt die Protokollierung, schaltet ein Knopfdruck sie auf allen betroffenen Servern ein.

Server-Änderungen – auch das, was nicht über das Werkzeug lief

Ein Audit-Protokoll im Werkzeug zeigt, was Sie geändert haben. Interessanter ist oft, was jemand anderes direkt am Server getan hat. Das Werkzeug liest die Regeländerungen aus dem Windows-Ereignisprotokoll aus – mit dem Benutzer, der sie ausgelöst hat. Damit schließt sich die Lücke, die jedes reine Verwaltungsprotokoll offenlässt.

Weitere Neuerungen

• Firewall-Profile schalten: Zustand der Profile Domäne, Privat und Öffentlich je Server im Blick – ein abgeschaltetes Profil lässt sich direkt wieder einschalten.
• Anhangsformat des geplanten Berichts: HTML, PDF oder beides.
• Build-Zeitstempel: belegt nach einer Aktualisierung, dass wirklich der neue Stand läuft. Die Fassungsnummer allein kann das nicht – zwei Builds derselben Fassung tragen dieselbe Nummer.
• Fähigkeiten statt Fassungsnummer: Jeder Agent meldet, welche Funktionen er beherrscht. Das Werkzeug blendet aus, was ein älterer Agent nicht kennt, statt einen Fehler zu zeigen.
• Ladezeiten je Server: Dauer des letzten Laufs und der Anteil jedes Servers daran. Ein langsamer Server fällt sofort auf, statt in einer Gesamtzeit unterzugehen.

Transparenz ist kein Nebenprodukt

Ein Werkzeug, das in die Firewall von Domänencontrollern schreibt, muss über sich selbst Auskunft geben können. Jede Änderung steht im Audit-Protokoll – mit Benutzer, Zeitpunkt, Server sowie altem und neuem Wert – und lässt sich von dort einzeln wieder zurücknehmen. Anmeldeinformationen, Zugriffstoken und Schlüssel liegen AES-256-verschlüsselt.

Technische Basis

Firewall-Regeln zentral zu verwalten und dabei das Tier-Modell zu wahren galt lange als Widerspruch. Er lässt sich auflösen – man muss das Verwaltungswerkzeug nur so bauen, dass es nicht selbst zum Einfallstor wird.