Netzwerksegmentierung - Abteilung per VLAN trennen

[wznutzer 35]

Hallo,

 

wenn ich mein Netzwerk segmentiere, also z. B. eine Abteilung vom Rest per VLAN trenne, müssen ja trotzdem Zugriffe untereinander notwendig sein. Ich meine jetzt nicht ein Gastnetz oder Testnetz das komplett abgeschottet ist, sondern das produktive Netz soll untergliedert werden. Die Broadcasts werden verringert, aber das ist bei ~100 Clients nicht so sehr das Problem. Mir geht es eher um die Sicherheit.

 

Wenn ich jetzt für eine Abteilung ein separates Segment erstelle, müssen sich diese ja immer noch am AD authentifizieren und auch Fileserver / Drucker im Netzwerk müssen erreichbar sein. Also benötige ich jede Menge Freigaben. Teilweise sollen auch die Clients untereinander Daten per Freigabe austauschen.

 

Überlegungen

• Es bringt nix, einfach mal so VLANs zu erstellen und dann alles freizugeben, damit wieder alles möglich ist.
• Datenaustausch muss über zentrale Ablagen stattfinden. Also die Berührungspunkte der Segmente müssen reduziert werden.
• Das Routing nicht über die Switche machen, sondern granular über eine Firewall.
• Es ist kein Allheilmittel z. B. gegen "lateral movement", nur halt eine weitere Hürde.
• Am AD selbst ändert es nichts, das muss sowieso nach Best Practive gehärtet werden.
• Wenn jemand den Domänencontroller kompromittiert, hilft auch keine Segmentierung.
• Kann man machen, ist aber in kleineren Netzen eher dann an der Reihe wenn schon alles andere gemacht wurde (Mitarbeiterschulung, AD gehärtet, reduzierte Rechte usw.)

 

Wie seht Ihr das. Macht Ihr das schon von Anfang an, auch in kleinen Netzen?

 

Vielen Dank

[MurdocX 953]

Hallo wznutzer,

 

ein Netzwerk zu trennen, damit bei ca. 100 Clients die Broadcast-Domäne eine Andere ist, halte ich für nicht sinnvoll. Damit erreichst du nur mehr verwaltungsaufwand. Eine Trennung ist erst sinnvoll, wenn der Grund und die dazugehörigen Überlegungen ein Bild ergeben. Das Thema Sicherheit ist gut. Wie du die Netze trennst hängt davon ab was du erreichen willst, oder vor was du dich schützen willst. Eine allgemeine Antwort kann ich Dir hier nicht geben.

 

vor 1 Stunde schrieb wznutzer:

Es bringt nix, einfach mal so VLANs zu erstellen und dann alles freizugeben, damit wieder alles möglich ist.

vor 1 Stunde schrieb wznutzer:

Datenaustausch muss über zentrale Ablagen stattfinden. Also die Berührungspunkte der Segmente müssen reduziert werden.

vor 1 Stunde schrieb wznutzer:

Das Routing nicht über die Switche machen, sondern granular über eine Firewall.

vor 1 Stunde schrieb wznutzer:

Am AD selbst ändert es nichts, das muss sowieso nach Best Practive gehärtet werden.

Ja.

 

vor 1 Stunde schrieb wznutzer:

Wenn jemand den Domänencontroller kompromittiert, hilft auch keine Segmentierung.

Da hilft nur ein valides Backup.

 

vor 1 Stunde schrieb wznutzer:

Kann man machen, ist aber in kleineren Netzen eher dann an der Reihe wenn schon alles andere gemacht wurde (Mitarbeiterschulung, AD gehärtet, reduzierte Rechte usw.)

vor 1 Stunde schrieb wznutzer:

Es ist kein Allheilmittel z. B. gegen "lateral movement", nur halt eine weitere Hürde.

Es kommt immer darauf an. Das kann nicht pauschal beantwortet werden.

[cj_berlin 1.329]

vor 1 Stunde schrieb wznutzer:

 

• Es ist kein Allheilmittel z. B. gegen "lateral movement", nur halt eine weitere Hürde.

Gegen lateral movement hilft auf Netzwerkebene praktisch nur MIKROsegmentierung. Und diese wird nicht durch VLANs erreicht, sondern entweder durch Netzwerk-Virtualisierung und Distributed Firewall (siehe NSX-T oder das Pendant von Microsoft) oder durch lokale Firewalls auf den Maschinen.

[wznutzer 35]

Vielen Dank euch für die Antworten.

 

Der Gedanke war tatsächlich sicherheitsgetrieben. Eine Abteilung die besonders schützenswert ist wollte ich abtrennen. Aber je länger ich nachdenke, je mehr zweifle ich an meinem Vorhaben.

 

Was ich bisher gemacht habe

• Domänenadmins dürfen sich nicht über das Netzwerk an den Workstations anmelden. Ebenso User aus Abteilungen mit denen sie nichts zu tun haben.
• Emails / Internet über einen TSE. Von diesem aus, dürfen sie sich auch nicht an Ihrem PC anmelden. Sollte jemand auf dem TSE, trotz aller Vorkehrungen, Malware starten, würde diese ja mit den Benutzerrechten der Kollegen laufen, die auf Ihren Workstations Adminrechte haben und somit hätte die Malware auch Zugriff mit Adminrechten. Die Verbindung TSE -> Workstation ist aber verboten. Die Kollegen benötigen Adminrechte (Debugger).
• RDP geht nur vom userspezifischen VPN (Home-Office) aus.
• Die lokalen User dürfen sich nicht über das Netzwerk anmelden.
• In der Firewall (Windows) ist alles abgedreht was ich für möglich gehalten habe.
• Regelmäßige Scans mit Thor-Lite.

Genaugenommen habe ich MIKRO-Segmentierung betrieben, ich hatte nur kein Wort dafür .

 

Danke nochmals. VLANs wären wohl das falsche Werkzeug aus dem Werkzeugkasten.

[NorbertFe 2.061]

vor 3 Stunden schrieb wznutzer:

Domänenadmins dürfen sich nicht über das Netzwerk an den Workstations anmelden.

Warum dürfen die sich überhaupt an workstations anmelden?

[MurdocX 953]

vor 35 Minuten schrieb NorbertFe:

Warum dürfen die sich überhaupt an workstations anmelden?

Weil das die Standardeinstellung ist 

[NorbertFe 2.061]

Nein ich meine im konkreten Fall. Wenn man da schon ansetzt, dann doch komplett!

[wznutzer 35]

Als Teilzeitadmin kann ich mich natürlich immer irren .

 

Es gibt ja die Richtlinie "Lokal anmelden zulassen". Da sind Administratoren und Benutzer drin. In den Benutzer (lokal) sind die Domänen-Benutzer drin und in den Administratoren (lokal) sind die Domänen-Admins drin. Ich habe in den Administratoren (lokal) die Domänen-Admins entfernt per GPO. Ich denke Ihr nehmt die Domänen-Admins in die Richtlinie "Lokal anmelden verweigern" auf? Kommt auf das Gleiche raus, oder?

 

Organisatorisch ist es sowieso verboten sich mit dem Domänen-Admin (und einigen anderen) auf Workstations anzumelden bzw. zu arbeiten, die nicht zu den Admin-Workstations gehören.

 

Etwas unbehagen bereitet mir immer, dass sich ein Kollege, der das Adminpasswort kennt, es trotzdem versuchen könnte sich auf einer Workstation mit dem Domänenadmin anzumelden, weil es halt so einfach ist, gehen tut es nicht, weil ja technisch unterbunden, aber eingetippt ist es dann ja schon. Ein Keylogger könnte das loggen. Ist das realistisch? Man sollte sich ja immer klar machen gegen was man sich schützen will, um es nicht zu übertreiben.

 

[MurdocX 953]

vor 13 Stunden schrieb NorbertFe:

Nein ich meine im konkreten Fall. Wenn man da schon ansetzt, dann doch komplett!

Ich bin auch ein Freund davon. Die Erfahrung spricht, dass ich zu wenige mit dem Thema Sicherheit beschäftigen und deshalb Ehrfurcht vor Veränderungen haben. Die Gründe gehen bekanntlich weit auseinander.

 

vor 9 Minuten schrieb wznutzer:

Ich denke Ihr nehmt die Domänen-Admins in die Richtlinie "Lokal anmelden verweigern" auf? Kommt auf das Gleiche raus, oder?

Ja. Wobei ich lieber die Admin-Gruppe durch die GPOs wieder bereinigen lasse.

 

vor 10 Minuten schrieb wznutzer:

Organisatorisch ist es sowieso verboten sich mit dem Domänen-Admin (und einigen anderen) auf Workstations anzumelden bzw. zu arbeiten, die nicht zu den Admin-Workstations gehören.

Zwischen Organisation / Absprache und was dann wirklich mal passiert, wenn ein Kollege nicht weiter weiß und denkt es würde an den Berechtigungen liegen, sind Welten  Vertrauen ist gut, Restriktion ist besser.

 

vor 12 Minuten schrieb wznutzer:

Man sollte sich ja immer klar machen gegen was man sich schützen will, um es nicht zu übertreiben.

Das ist manchmal gar nicht so einfach das zu beurteilen   MITRE ATT&CK® - Signierung und Verschlüsselung im internen Netz sind der Einstieg zur Sicherheit. Beispielsweise mindestens einen DC 2019 hilft auch schon.

[wznutzer 35]

Danke für den Link .

[speer 19]

Hi,

wir haben bei uns in der Firma ebenfalls einen "speziellen" Arbeitsbereich der abgeschottet sein soll.

Wir haben lange hin- und her überlegt welchen Schutzbedarf die Geräte/Benutzer haben, was für techniken uns helfen könnten, etc. pp.

Letzen Endes sind wir beim Switch und ACLs hängen geblieben. Eine Inbound rule für den DC/DNS/DHCP und eine weitere für den Fileserver und SCCM. Outbound wurde keine Filterung vorgenommen. Die Windows Firewall ist über GPO gesteuert...

 

Vielleicht eine Möglichkeit, der Konstrukt ist schnell eingerichtet und funktioniert sehr gut.

 

[NorbertFe 2.061]

Ist halt immer die Frage, wie flexibel und skalierbar sowas sein soll. Wenn’s den Zweck erfüllt, kann das eine Lösung sein.

 

Konstrukt ist übrigens ein Neutrum. ;)

 

bye

norbert

 

[speer 19]

Konstrukt (m/w/d)

 

Besser?

[Weingeist 159]

Am 2.3.2022 um 16:41 schrieb wznutzer:

Teilweise sollen auch die Clients untereinander Daten per Freigabe austauschen.

Zumindest das würde ich ohnen zwingenden Grund unterbinden... Clients sollen untereinander nicht quatschen müssen, sondern eben über zentrale Stellen wie Du selbst geschrieben hast. Je nach Grössenordnung reicht hier sogar die Windows-Firewall aus (Kommunikation nur zu Adress-range der Server). Wo das Share dann liegt, kannst mit DFS definieren. ;)

 

Gewisse Segmentierung kannst auch erreichen indem Du die Clients in verschiedene Tears unterteilst, so wie man das auch für die Server macht/machen sollte. Sprich sehr wichtige Gruppen bekommen eine eigene Admin-Gruppe und nur diese dürfen sich an den Clients anmelden. Alle anderen bekommen ein Deny. Gleiches gilt für deren User. Die bekommen dann einen zweiten Usernamen wenn sie sich in einem anderen Bereich anmelden müssen. Insbesondere für User die Admin-Rechte benötigen, käme eigentlich nur sowas in Frage und grundsätzlich dürften die auch nur über eine zweite VM surfen. ;)

--> einfacher logischer Aufbau ist halt wichtig, damit die Pflege nicht ausartet. Evtl. auch Automatisationsfreundlichen, gibt da so Ansätze von einem User hier, habe leider grad den Thread nicht gefunden.

[NorbertFe 2.061]

vor 4 Minuten schrieb Weingeist:

Kommunikation nur zu Adress-range der Server

Ausgehend is ja eher egal, also Kommunikation von Adress-Range wäre interessanter.