6
Windows Firewall Limitierungen
Hallo,
ich suche nach Limits für die Windows Firewall von Windows Server 2008 R2, 2012 R2 und 2016:
1. Anzahl der Regeln
2. Anzahl der RemoteIPs innerhalb einer Regel.
Sollte beides unbegrenzt sein, würden mich Erfahrungen interessieren, wo denn sinnvolle Grenzen sind.
Danke für Hinweise.
Jörg
P.S. Ein frohes neues Jahr 2019
ich suche nach Limits für die Windows Firewall von Windows Server 2008 R2, 2012 R2 und 2016:
1. Anzahl der Regeln
2. Anzahl der RemoteIPs innerhalb einer Regel.
Sollte beides unbegrenzt sein, würden mich Erfahrungen interessieren, wo denn sinnvolle Grenzen sind.
Danke für Hinweise.
Jörg
P.S. Ein frohes neues Jahr 2019
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 397088
Url: https://administrator.de/contentid/397088
Printed on: April 26, 2024 at 09:04 o'clock
6 Comments
Latest comment
Moin.
Du hast ein paar Ports offen und wirst für jeden Port eine Regel brauchen, sofern Du den nicht eh für die Allgemeinheit offen lassen magst.
Ob man überhaupt mit IPs arbeiten sollte, würde ich mich statt dessen fragen. Nimm lieber zertifikatsbasierte Regeln, die kann man nämlich nicht so einfach austricksen.
wo denn sinnvolle Grenzen sind
Wie sollen wir als Außenstehende das beurteilen? Du hast ein paar Ports offen und wirst für jeden Port eine Regel brauchen, sofern Du den nicht eh für die Allgemeinheit offen lassen magst.
Ob man überhaupt mit IPs arbeiten sollte, würde ich mich statt dessen fragen. Nimm lieber zertifikatsbasierte Regeln, die kann man nämlich nicht so einfach austricksen.
ach ich weiß nicht... ich finde Firewalls sowieso überbewertet, solange der Dienst dahinter nicht "gehärtet" ist und die IDS zu doof ist. Bei einem Kumpel ist z.B. der RDP Dienst vom Windows 2016 mit aktuellem Patchstand gehackt worden, incl Erlangung lokaler Adminrechte und Deaktivierung des eingebauten Adminkontos. Vermutlch mit einem Zeroday Exploit, den die IDS noch nicht auf der Liste hatte.
Am besten mit den Füßen auf dem Boden bleiben... nichts von "außen" reinlassen, innen soviel abschotten wie geht. Der MS Artikel besagt dcoh auch relativ deutlich daß das Durcharbeiten von Adreß/portbasierten Regeln Performance kostet, Zertifikatsprüfung um so mehr...
Am besten mit den Füßen auf dem Boden bleiben... nichts von "außen" reinlassen, innen soviel abschotten wie geht. Der MS Artikel besagt dcoh auch relativ deutlich daß das Durcharbeiten von Adreß/portbasierten Regeln Performance kostet, Zertifikatsprüfung um so mehr...
Zitat von @GrueneSosseMitSpeck:
Bei einem Kumpel ist z.B. der RDP Dienst vom Windows 2016 mit aktuellem Patchstand gehackt worden, incl Erlangung lokaler Adminrechte und Deaktivierung des eingebauten Adminkontos. Vermutlch mit einem Zeroday Exploit, den die IDS noch nicht auf der Liste hatte.
Bei einem Kumpel ist z.B. der RDP Dienst vom Windows 2016 mit aktuellem Patchstand gehackt worden, incl Erlangung lokaler Adminrechte und Deaktivierung des eingebauten Adminkontos. Vermutlch mit einem Zeroday Exploit, den die IDS noch nicht auf der Liste hatte.
Den RDP-Dienst hängt man doch nicht mit nacktem Arsch ins Internet. Da gehört immer ein VPN davor.
lks
Oh,
gemeint waren eigentlich sinnvolle Grenzen in der Anzahl der Regeln, Erfahrungswerte wie sich die Windowsfirewall bei mhreren tausend Regeln verhält, etc., ...
Ein Bekannter hat z.B. einen Exchange Server am Netz. Dem hat er zwar einen Mail-Proxy vorgehängt, der aber auch unter Windows läuft. Von ihm stammte die Anfrage an mich, ob man da nicht mit der Windows Firewall automatisiert etwas tun könnte.
Die Idee war "unfreundliche SMTP-Anfragen" am Proxy zu erkennen und die IPs in der Windows Firewall zu blocken. Dazu sollte ein Powershell-Script benutzt werden.
Das ist technisch machbar, aber um die Sinnhaftigkeit abschätzen zu können, wäre eine Information von Nöten über die "Limits der Windows Firewall" nötig. Und dabei sind sowohl technische Limits (z.B. maximal 1000 IP Adressen pro Regel) als auch die Anzahl der Regeln in der Firewall (ist unlimitiert, aber ab X-tausend Rregeln wird's halt langsam) interessant zu wissen.
Zertifikatsbasierte Regeln sind im professionellen Bereich im Mittelstand leider nicht immer möglich. Da bleibt dann oftmals nur Port und IP.
Und: Ja, es besteht ein Restrisiko, dass erfolgreiche illegitime Zugriffe mit der beschriebenen Idee nicht entdeckt werden...
gemeint waren eigentlich sinnvolle Grenzen in der Anzahl der Regeln, Erfahrungswerte wie sich die Windowsfirewall bei mhreren tausend Regeln verhält, etc., ...
Ein Bekannter hat z.B. einen Exchange Server am Netz. Dem hat er zwar einen Mail-Proxy vorgehängt, der aber auch unter Windows läuft. Von ihm stammte die Anfrage an mich, ob man da nicht mit der Windows Firewall automatisiert etwas tun könnte.
Die Idee war "unfreundliche SMTP-Anfragen" am Proxy zu erkennen und die IPs in der Windows Firewall zu blocken. Dazu sollte ein Powershell-Script benutzt werden.
Das ist technisch machbar, aber um die Sinnhaftigkeit abschätzen zu können, wäre eine Information von Nöten über die "Limits der Windows Firewall" nötig. Und dabei sind sowohl technische Limits (z.B. maximal 1000 IP Adressen pro Regel) als auch die Anzahl der Regeln in der Firewall (ist unlimitiert, aber ab X-tausend Rregeln wird's halt langsam) interessant zu wissen.
Zertifikatsbasierte Regeln sind im professionellen Bereich im Mittelstand leider nicht immer möglich. Da bleibt dann oftmals nur Port und IP.
Und: Ja, es besteht ein Restrisiko, dass erfolgreiche illegitime Zugriffe mit der beschriebenen Idee nicht entdeckt werden...
Salut,
ich mag Firewalls schon ganz gerne. Dreck, der nicht in mein Netz kommt, kann dort keinen Unsinn verursachen.
Wenn ich an der Firewall schon Netzwerkscans abblocken kann, müssen die Server sich nicht mehr um Reaktionen auf Unsinn kümmern. Gut, wenn sie es durch Härtung der Dienste trotzdem können.
ich mag Firewalls schon ganz gerne. Dreck, der nicht in mein Netz kommt, kann dort keinen Unsinn verursachen.
Wenn ich an der Firewall schon Netzwerkscans abblocken kann, müssen die Server sich nicht mehr um Reaktionen auf Unsinn kümmern. Gut, wenn sie es durch Härtung der Dienste trotzdem können.