12
In Active Directory Ports 139 und 445 sperren Clients und Server?
Hallo,
ich habe in diversen Artikeln, wo es um die Härtung von Active Directories geht unter anderem immer mal wieder gelesen, dass empfohlen wird, Port 139/445 eingehend zwischen den Clients in einem Subnetz via Windows Firewall zu sperren.
Ein Beispiel wäre z:B dieser Artikel:
https://blog.palantir.com/restricting-smb-based-lateral-movement-in-a-wi ...
Bei diversen Angriffen ( LAteral Movement innerhalb des Nezwerkes), werden nämlich immer wieder verschiedene Angriffe durchgeführt, die unter anderem auf Lokale Admin-Zugänge auf Clients ( meist via Port 445) abzielen.
Jetzt meine Fragen an euch, weil ich die Sicherheit auch im Falle eines infizierten Clients noch erhöhen möchte:
1.) Gibt es in einer Domäne irgendwelche Einschränkunen wenn ich via GPO auf ALLEN CLients Port 139/445 eingehend sperre? Werden diese in irgendeiner Form benötigt, auch wenn keine Dateifreigabe an den jeweiligen CLients eingesetzt wird?
2.)Kann ich gefahrlos Server, auf denen z.b KEIN Fileserver läuft, z.B nur SQL-Dienste etc., Port 139/445 eingehend ebenfalls sperren?
3.) Kann ich dies auch an einem Domain-Controller gefahrlos tun ( auf dem natürlich keine Filesharing-Dienste aktiv sind) oder gibt es dann Probleme, weil die Clients, auf Laufwerke wie SysVOl etc. nciht mehr zugreifen können? Ich denke ja von der Logik her, dass ich diese Ports nicht schliessen darf.
Was meint ihr?
Danke und Grüße
DC
ich habe in diversen Artikeln, wo es um die Härtung von Active Directories geht unter anderem immer mal wieder gelesen, dass empfohlen wird, Port 139/445 eingehend zwischen den Clients in einem Subnetz via Windows Firewall zu sperren.
Ein Beispiel wäre z:B dieser Artikel:
https://blog.palantir.com/restricting-smb-based-lateral-movement-in-a-wi ...
Bei diversen Angriffen ( LAteral Movement innerhalb des Nezwerkes), werden nämlich immer wieder verschiedene Angriffe durchgeführt, die unter anderem auf Lokale Admin-Zugänge auf Clients ( meist via Port 445) abzielen.
Jetzt meine Fragen an euch, weil ich die Sicherheit auch im Falle eines infizierten Clients noch erhöhen möchte:
1.) Gibt es in einer Domäne irgendwelche Einschränkunen wenn ich via GPO auf ALLEN CLients Port 139/445 eingehend sperre? Werden diese in irgendeiner Form benötigt, auch wenn keine Dateifreigabe an den jeweiligen CLients eingesetzt wird?
2.)Kann ich gefahrlos Server, auf denen z.b KEIN Fileserver läuft, z.B nur SQL-Dienste etc., Port 139/445 eingehend ebenfalls sperren?
3.) Kann ich dies auch an einem Domain-Controller gefahrlos tun ( auf dem natürlich keine Filesharing-Dienste aktiv sind) oder gibt es dann Probleme, weil die Clients, auf Laufwerke wie SysVOl etc. nciht mehr zugreifen können? Ich denke ja von der Logik her, dass ich diese Ports nicht schliessen darf.
Was meint ihr?
Danke und Grüße
DC
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81730996406
Url: https://administrator.de/forum/in-active-directory-ports-139-und-445-sperren-clients-und-server-81730996406.html
Ausgedruckt am: 30.12.2024 um 17:12 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Probier es doch einfach aus. Mehr als Chaos kannst du nicht anstellen.
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Gruss,
Peter
Probier es doch einfach aus. Mehr als Chaos kannst du nicht anstellen.
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Gruss,
Peter
Moin
zu 1): Das musst du am besten wissen, ob du Clients hast, auf die man per SMB drauf muss. Manche Softwareverteilung funktioniert z.B. darüber.
zu 2) Gleiches wie oben
zu 3): Nein, deine DCs sind auch automatisch Fileserver, die das SYSVOL bereitstellen, wo GPOs gehostet werden.
Generell ist zu empfehlen, zumindest eine kleine Testumgebung aufzubauen, wo man solche Dinge mal gefahrlos testen kann...
Gruß
zu 1): Das musst du am besten wissen, ob du Clients hast, auf die man per SMB drauf muss. Manche Softwareverteilung funktioniert z.B. darüber.
zu 2) Gleiches wie oben
zu 3): Nein, deine DCs sind auch automatisch Fileserver, die das SYSVOL bereitstellen, wo GPOs gehostet werden.
Generell ist zu empfehlen, zumindest eine kleine Testumgebung aufzubauen, wo man solche Dinge mal gefahrlos testen kann...
Gruß
Moin.
All deine Fragen und noch viele weitere ließen sich mit einer Segmentierung beantworten, da zwischen den Segmenten i.d.R. ein Traffic Log erstellt wird.
1) Vielleicht, z.B. Softwareverteilung.
2) siehe 1)
3) Gefahrlos nicht, aber durch eine Segmentierung sollte die Schere zwischen Ist- und Soll-Zustand zugehen.
siehe NET.1.1
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standar ...
All deine Fragen und noch viele weitere ließen sich mit einer Segmentierung beantworten, da zwischen den Segmenten i.d.R. ein Traffic Log erstellt wird.
1) Vielleicht, z.B. Softwareverteilung.
2) siehe 1)
3) Gefahrlos nicht, aber durch eine Segmentierung sollte die Schere zwischen Ist- und Soll-Zustand zugehen.
siehe NET.1.1
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standar ...
Moin,
139/445 an einem DC nicht generell blockieren!
Wie schon geschrieben, wird das für SYSVOL (und damit auch für NETLOGON und GPO) benötigt.
Wenn, dann muss man das selektiv reglementieren. Clients, Memberserver und andere DC müssen immer potentiell an die SYSVOL der DC's rankommen. Wenn man über AD Sites das AD "segmentiert" hat, dann kann man diese selektiven Regeln auch auf Clients und Membeserver nur des betreffenden Standorts eingrenzen (aber immer für alle DC der beteiligten Replikationsstandorte erlauben).
E.
139/445 an einem DC nicht generell blockieren!
Wie schon geschrieben, wird das für SYSVOL (und damit auch für NETLOGON und GPO) benötigt.
Wenn, dann muss man das selektiv reglementieren. Clients, Memberserver und andere DC müssen immer potentiell an die SYSVOL der DC's rankommen. Wenn man über AD Sites das AD "segmentiert" hat, dann kann man diese selektiven Regeln auch auf Clients und Membeserver nur des betreffenden Standorts eingrenzen (aber immer für alle DC der beteiligten Replikationsstandorte erlauben).
E.
Würde eher auf verstärkte Securitykontrollen dazwischen setzen wie ein Netzwerk Monitoring Tool was den Traffic auf schadhaftes Verhalten untersucht also den ganzen Netzwerktraffic bekommt und aufgrund dieser Tatsache dann Aktionen wie Client blocken etc ausführt zusätzlich vielleicht ein Intrusion Prevention System.
Der Vorschlag die Ports zu sperren ist ziemlich dämlich kann nur von Security Fuzzies kommen die keine Ahnung von Praxis haben, vorredner haben ja schon dargelegt wo das Problem ist.
Wenn du dein AD abhärten oder Kontrollieren willst solltest folgende Dinge mal durch den kopf gehen lassen:
- Missbrauch AD Admin Rechte:
-> Kontrolle über erstellung und modifikation von AD Objekten >> LOGS
-> Kontrolle, wer verbindet sich per RDP auf den AD Controller >> LOGS
Und ggf. noch mehr, aber wenn man hier die Protokolle entsprechend automatisiert auswertet
und als Admin täglich checkt, merkt man schnell ob hier was stattfindet wie Letheral Movement.
Ansonsten Honeypot System aufstellen um potentielle Gegener im LAN welche Netzwerk scanns machen zu identifizieren...
Gibts systeme gegen Cash $$ die sowas beerrschen, oder man ist fachlich so tief drin in der forensik, scripting das man sich selbst sowas bauen kann.
Kurz man muss seine Landschaft so konfigurieren das entsprechend forensische Daten produziert werden, und dann aber auch mechanismen haben welche die daten auswerten können, und jemand der die Ergebnisse auch kontrolliert.
Wenn du dein AD abhärten oder Kontrollieren willst solltest folgende Dinge mal durch den kopf gehen lassen:
- Missbrauch AD Admin Rechte:
-> Kontrolle über erstellung und modifikation von AD Objekten >> LOGS
-> Kontrolle, wer verbindet sich per RDP auf den AD Controller >> LOGS
Und ggf. noch mehr, aber wenn man hier die Protokolle entsprechend automatisiert auswertet
und als Admin täglich checkt, merkt man schnell ob hier was stattfindet wie Letheral Movement.
Ansonsten Honeypot System aufstellen um potentielle Gegener im LAN welche Netzwerk scanns machen zu identifizieren...
Gibts systeme gegen Cash $$ die sowas beerrschen, oder man ist fachlich so tief drin in der forensik, scripting das man sich selbst sowas bauen kann.
Kurz man muss seine Landschaft so konfigurieren das entsprechend forensische Daten produziert werden, und dann aber auch mechanismen haben welche die daten auswerten können, und jemand der die Ergebnisse auch kontrolliert.
In Kürze: die an einem DC offen zu lassenden Ports für den Betrieb von AD liefert Microsoft hier: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ... - vielleicht übersichtlicher hier: https://www.der-windows-papst.de/wp-content/uploads/2018/10/AD-Ports-Ser ...
Die Clients brauchen keine offenen Ports und haben auch keine offen, wenn man (default!) die Firewall an lässt und keine Admins durch Programminstallationen oder Ähnliches da Ausnahmen erstellen.
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
Die Clients brauchen keine offenen Ports und haben auch keine offen, wenn man (default!) die Firewall an lässt und keine Admins durch Programminstallationen oder Ähnliches da Ausnahmen erstellen.
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
Zitat von @DerWoWusste:
In Kürze: die an einem DC offen zu lassenden Ports für den Betrieb von AD liefert Microsoft hier: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ... - vielleicht übersichtlicher hier: https://www.der-windows-papst.de/wp-content/uploads/2018/10/AD-Ports-Ser ...
Die Clients brauchen keine offenen Ports und haben auch keine offen, wenn man (default!) die Firewall an lässt und keine Admins durch Programminstallationen oder Ähnliches da Ausnahmen erstellen.
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
In Kürze: die an einem DC offen zu lassenden Ports für den Betrieb von AD liefert Microsoft hier: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ... - vielleicht übersichtlicher hier: https://www.der-windows-papst.de/wp-content/uploads/2018/10/AD-Ports-Ser ...
Die Clients brauchen keine offenen Ports und haben auch keine offen, wenn man (default!) die Firewall an lässt und keine Admins durch Programminstallationen oder Ähnliches da Ausnahmen erstellen.
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
Ich würde da eine Firewall mit Single Sign On nehmen dann braucht man sich nicht mit IP Ranges herumschlagen. Da kann man dann aufgrund LDAP/AD User die Regeln machen.
Keine Ahnung, wo jetzt in meinem Kommentar was mit Ranges aufkam.
Ja, der DC nutzt Portranges, aber die sind doch eh offen per default. Dem fragesteller ging's darum, kann ich 445 und 139 auf dem Server bzw. auf dem Client getrost dichtmachen - und da lautet die Antwort: auf dem Client ja, auf dem Server wird 445 benötigt. Zu 139 mal in die Doku schauen.
Ja, der DC nutzt Portranges, aber die sind doch eh offen per default. Dem fragesteller ging's darum, kann ich 445 und 139 auf dem Server bzw. auf dem Client getrost dichtmachen - und da lautet die Antwort: auf dem Client ja, auf dem Server wird 445 benötigt. Zu 139 mal in die Doku schauen.
Zitat von @DerWoWusste:
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
Das Rumgemache auf Clients per c$ (Port 445) oder RDP (3389) kann man natürlich machen, aber dann nur von administrativen Workstations aus erlauben.
Das Thema sind administrative Workstations. Wie machst du das?
Erstellst ein eigenes Subnetz nur für Admins? Das meinte ich mit Ranges weil 1 Subnet im Endeffekt eine IP Range ist.
Daher mein kommentar, dass man eine SSO Lösung dafür nehmen soll weil dann sobald sich der Admin am PC anmeldet hat er automatisch die benötigten freigaben auf der Firewall.
SSO...Die windowsinterne Firewall beherrscht selbst schon sogenannte "secure firewall rules", die mit Kerberos-Autorisierung arbeiten. Du kannst sagen: nur Adminsuser1 von Adminworkstation1 darf Port xy eingehend benutzen.
1Zitat von @DerWoWusste:
SSO...Die windowsinterne Firewall beherrscht selbst schon sogenannte "secure firewall rules", die mit Kerberos-Autorisierung arbeiten. Du kannst sagen: nur Adminsuser1 von Adminworkstation1 darf Port xy eingehend benutzen.
SSO...Die windowsinterne Firewall beherrscht selbst schon sogenannte "secure firewall rules", die mit Kerberos-Autorisierung arbeiten. Du kannst sagen: nur Adminsuser1 von Adminworkstation1 darf Port xy eingehend benutzen.
Sorry da kann ich dann nicht mehr mitreden. Wir nutzen die Win Firewall im Corp Netz nicht sondern haben Mikrosegmentierung und SSO.
