4
Windows Clients zu AD-Server - Firewallregeln
Moin zusammen!
Wie sind eure Erfahrungen, wenn Windows Clients in anderen Netzen stehen, als "seine" AD-Server im Zusammenhang mit Firewalls.
Es gibt im Internet ja diverse Portlisten, die aber in Teilen von einander abweichen.
Wie macht ihr das so wenn ihr externe Standorte habt, die bspw. per IPSEC an die Zentrale, wo der/die Server stehen, angebunden sind?
Benutzt ihr die böse Any-Any-Regel? Filtert ihr tatsächlich die Ports? Wenn ja, nach welcher Quelle geht ihr?
53, 88,445, 389 würden ja schon das meiste erschlagen. Wenn man dann aber noch 1024-65535 hinzufügt wird das Filtern ja schon fast albern.
Einige Quellen meinen aber auch 49152-65535 würden auch reichen.
Wie geht ihr vor? Mich interessiert wirklich, wie ihr es in der Praxis handhabt und nicht, wie das Optimum aussieht.
Grüße
Christoph
Wie sind eure Erfahrungen, wenn Windows Clients in anderen Netzen stehen, als "seine" AD-Server im Zusammenhang mit Firewalls.
Es gibt im Internet ja diverse Portlisten, die aber in Teilen von einander abweichen.
Wie macht ihr das so wenn ihr externe Standorte habt, die bspw. per IPSEC an die Zentrale, wo der/die Server stehen, angebunden sind?
Benutzt ihr die böse Any-Any-Regel? Filtert ihr tatsächlich die Ports? Wenn ja, nach welcher Quelle geht ihr?
53, 88,445, 389 würden ja schon das meiste erschlagen. Wenn man dann aber noch 1024-65535 hinzufügt wird das Filtern ja schon fast albern.
Einige Quellen meinen aber auch 49152-65535 würden auch reichen.
Wie geht ihr vor? Mich interessiert wirklich, wie ihr es in der Praxis handhabt und nicht, wie das Optimum aussieht.
Grüße
Christoph
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: 564787
Url: https://administrator.de/contentid/564787
Printed on: April 24, 2024 at 03:04 o'clock
4 Comments
Latest comment
Ich hätte jetzt auch die üblichen genannten verdächtigen eingehenden Ports gemacht. Die oberen Port sind ja nur für ausgehende Anfragen z.B. an den DC.
Also reicht es, wenn du diese nur für die IPs der Domain Controller öffnest und für alle anderen Ziele gesperrt lässt.
Also reicht es, wenn du diese nur für die IPs der Domain Controller öffnest und für alle anderen Ziele gesperrt lässt.
Moin,
Einige Quellen meinen aber auch 49152-65535 würden auch reichen.
Wir haben irgendwanns ab 32xxx bis 65535 konfiguriert.
Gruß,
Dani
Benutzt ihr die böse Any-Any-Regel?
Ja, als Deny Regel. Filtert ihr tatsächlich die Ports?
Ja, wir gehen sogar noch weiter. Source IP, Destination IP, Port (TCP und/oder UDP) sowie Richtung.Wenn ja, nach welcher Quelle geht ihr?
Microsoft Docs und das Logfile der Firewall. Wenn man dann aber noch 1024-65535 hinzufügt wird das Filtern ja schon fast albern.
Ne, warum? Wenn man es auf die Antwort zu deiner zweiten Frage bezieht. Die Ports kommen eben durch die Anwendung von RPC (Port 135) zu Stande. Zudem braucht das nicht jeder Windows Server. Das hängt von den Rollen und installieren Anwendungen ab.Einige Quellen meinen aber auch 49152-65535 würden auch reichen.
Wir haben irgendwanns ab 32xxx bis 65535 konfiguriert.
Wie geht ihr vor? Mich interessiert wirklich, wie ihr es in der Praxis handhabt und nicht, wie das Optimum aussieht.
Das obenbeschrieben ist das Optimum und sieht auch so in der Praxi aus.Gruß,
Dani
Ja, als Deny Regel.
Ja, wir gehen sogar noch weiter. Source IP, Destination IP, Port (TCP und/oder UDP) sowie Richtung.
Ja, wir gehen sogar noch weiter. Source IP, Destination IP, Port (TCP und/oder UDP) sowie Richtung.
Das habe ich einfach mal als gegeben vorausgesetzt.
Ich bin weiterhin unschlüssig, ob das begrenzen der Ports wirklich hilft. Sinnvoll ist es, da gibt es keine Diskussion. So wenig wie möglich ist die Devise.
Was ist aber die tatsächliche Bedrohung? Wir reden hier über die Netze in denen die Clients unterwegs sind. Grundsätzlich sind die erstmal vertrauenswürdig, bergen nur die Gefahr sich etwas einzutreten oder sonst als Einfallstor zu dienen.
Was passiert dann aber tatsächlich? Nehmen wir an ein Client fängt sich Schadsoftware ein, die nun gegen den Server tritt, der AD, Fileserver, DNS, CA, DHCP macht. Das ist ja in kleinen Umgebungen nicht ungewöhnlich.
Nun werden doch ohnehin die Services angegangen, die auf dem Server laufen und auf deren Ports der Server lauscht.
Nehmen wir einfach mal an die Schadsoftware nutzt eine Schwachstelle im DNS aus (egal wie wahrscheinlich das nun ist). In dem Fall würde es nicht helfen firewallseitig "4711 TCP" zu blockieren. 53 UDP muss für den Betrieb ohnehin offen sein.
Ist es nicht viel sinnvoller am Ende sauber zu arbeiten und auf dem Server oder den Servern wirklich nur die Dienste laufen zu haben, die benötigt werden?
Bitte nicht falsch verstehen!! Ich argumentiere nicht dafür einfach alles auf zu machen, nach dem Motto: Was soll schon passieren. Ich halte es für den einzig richtigen Weg so wenig zu erlauben wie möglich und so viel wie nötig.
Ich stelle mir nur die Frage ob es die "Mühe" wert ist das an Firewalls zu tun, oder ob eine saubere Konfiguration der Server nicht effizienter ist.
Tatsächlich aber nur im Bereich der Ports. Wie gesagt, das Quell- und Zielnetze gefiltert werden, versteht sich von selbst.
Grüße
Christoph
Es ist so: Der Server hat mehr Dienste als der Client benötigt. Nicht jeder Client benötigt auch jeden Dienst des Servers. Ziel der Firewall ist es den Clients die nicht benötigten Ports zu sperren. Eigentlich ist der Port auf dem Server schon dicht, wenn kein unnötiger Dienst läuft, aber wenn der Dienst für einen anderen Rechner laufen muss, dann ist es die Aufgabe der Firewall diesen anderen Rechnern den Port durch zu lassen und den anderen Clients eben zu sperren.
Dann gibt es noch böse Leute (oder Trojaner), die Dienste einfach dazu installieren oder aktivieren. Wenn sie keine Berechtigung zur Firewall haben, nutzt ihnen diese Tat dann auch nichts.
Dann gibt es noch böse Leute (oder Trojaner), die Dienste einfach dazu installieren oder aktivieren. Wenn sie keine Berechtigung zur Firewall haben, nutzt ihnen diese Tat dann auch nichts.
