Active Directory - beschränken der RPC-Ports - ein Lastenproblem?

[wznutzer 35]

Hallo und guten Tag,

 

weil ich meine DCs per Firewall vom Rest trennen will, würde ich gerne die dynamischen Ports beschränken. Mircosoft hat es gut beschrieben und es funktioniert auch. Hat jemand Erfahrung damit, ob es evtl. ein Lastenproblem geben könnte oder kommen die DCs gut damit klar, wenn alles über ein Port läuft?

 

Microsoft: https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-directory/restrict-ad-rpc-traffic-to-specific-port

 

Grüße und einen schönen Tag.

[NilsK 2.971]

Moin, 

 

Warum sollte die Anzahl der Ports einen Unterschied machen? 

 

Gruß, Nils

[cj_berlin 1.356]

Moin,

 

in den meisten Fällen ist es OK. Der Verweis auf den Performance Impact stammt aus der Zeit, wo ein typischer Domain Controller physisch war und 512 MB RAM hatte und man die ganzen Network Offload-Features in Windows abschalten musste, weil der 3Com-Treiber damit nicht klarkam.

 

Was ich allerdings bereits in der "Neuzeit" gesehen habe, waren RPC-aware Firewalls, die sich verschluckt haben, wenn zu viele nicht miteinander verwandte Sessions auf demselben Port beobachtet werden mussten. Ich werde jetzt keine Namen nennen, aber es war ein namhafter Hersteller, der normalerweise das RPC-Business eigentlich ganz gut beherrscht. Vermutlich mal wieder mit 'nem Long Integer für einen Index gegeizt und nur 65534 Sessions per Port vorgesehen, oder sowas in der Art.

 

Es kann also knallen, aber vermutlich nicht an den Stellen, wo man es erwartet.

 

Aber: Was versuchst Du mit der Maßnahme zu erreichen? Um welche Protokolle geht es Dir hier, die DCs untereinander praktizieren sollen, nicht jedoch von anderen Maschinen aus? Denn die Einschränkung von RPC und SMB auf einzelne Ports hat ja aus Security-Sicht den Nachteil, dass der Angreifer immer weiß, auf welchem Port 'ne Session zu suchen ist, ohne mit dem Endpoint Mapper sprechen zu müssen  

[wznutzer 35]

vor 3 Stunden schrieb NilsK:

Warum sollte die Anzahl der Ports einen Unterschied machen?

Das mit der Performance hat mir der Github-Copilot gesagt .

 

vor 2 Stunden schrieb cj_berlin:

Aber: Was versuchst Du mit der Maßnahme zu erreichen? Um welche Protokolle geht es Dir hier, die DCs untereinander praktizieren sollen, nicht jedoch von anderen Maschinen aus? Denn die Einschränkung von RPC und SMB auf einzelne Ports hat ja aus Security-Sicht den Nachteil, dass der Angreifer immer weiß, auf welchem Port 'ne Session zu suchen ist, ohne mit dem Endpoint Mapper sprechen zu müssen  

In dem Konstrukt gibt es ein Segment Management (AD, MS SQL-Server usw, praktisch Tier0 und Tier1). Da kann fast alles miteinander sprechen. Naja fast, ich habe mich ein wenig mit Microsegmentierung per Windows-Firewall ausgetobt. Dann gibt es das Segment Anwender (Tier2) mit Domänenmitglieder. Standardmäßig muss RPC für LSA, SAM, NetLogon 49152-65535/TCP offen sein. Ich dachte großer Portbereich = böse, lieber weniger Ports. An die Sache, dass dann auch immer klar ist, wo eine Session zu suchen ist, bin ich nicht gekommen.

 

Kann man dann sagen, dass aus Sicht der Sicherheit die Portbeschränkung (man würde den Bereich ja nur für die DCs freigeben), außer einem wohligen Bauchgefühl, nicht so sehr was bringt?

 

Danke und Grüße

[Dukel 457]

vor 28 Minuten schrieb wznutzer:

Standardmäßig muss RPC für LSA, SAM, NetLogon 49152-65535/TCP offen sein. Ich dachte großer Portbereich = böse, lieber weniger Ports.

 

Eine große Anzahl von Ports sind normalerweiße irrelevant für Sicherheitslücken. Angreifer brauchen nur einen Port und es wird nicht unsicherer wenn mehr Ports (solange der gleiche Dienst auf der Port Rage lauscht!) "offen" sind.

[NilsK 2.971]

Moin,

 

die ganze Port-Klamotte kommt ihrerseits ja auch aus der Zeit, wo jedes Protokoll einen eigenen Port hatte. Dieser mysteriöse Port ist ja nichts weiter als ein Label, mit dem man dem Netzwerkstack mitteilt, wohin die Pakete innerhalb des Systems denn gehen sollen. Da konnte man am Port die Applikation identifizieren und hatte gute Chancen, dort eine angreifbare Version zu finden. Um das einzudämmen, hat man dann vorsichtshalber auf den Firewalls eben die Ports blockiert.

 

Da die Bedeutung der Ports aber dramatisch abgenommen hat, seit alles über http(s) läuft, gehen Angreifer heute anders vor. Es kommt also noch mehr darauf an, dass man sein Zeug ordentlich pflegt, dafür sind Ports als direkte Einfallstore weniger relevant. Wie Dukel schon sagt, wenn die Applikation selbst nicht lückenhaft ist, ist es egal, ob sie auf einem Port nicht angreifbar ist oder auf hundert. Und umgekehrt - kann ich eine Applikation angreifen, weil sie eine Lücke hat, dann ist der Port genauso egal.

 

Gruß, Nils

 

[daabm 1.375]

Am 7.1.2025 um 12:44 schrieb wznutzer:

 

weil ich meine DCs per Firewall vom Rest trennen will, würde ich gerne die dynamischen Ports beschränken. Mircosoft hat es gut beschrieben und es funktioniert auch. Hat jemand Erfahrung damit, ob es evtl. ein Lastenproblem geben könnte oder kommen die DCs gut damit klar, wenn alles über ein Port läuft?

 

Warum sollte man das tun, wo ist der Mehrwert? Ein offener Port, hinter dem es keinen Listener gibt, ist kein Sicherheitsrisiko. Und auf DCs sollte da nichts "zufällig" dazukommen. Man fährt auch bei RPC gut damit, einen unternehmensweiten Standard zu haben - wir haben "aus Gründen" 3 unterschiedliche RPC-Ranges, das treibt einen in die Verzweiflung

 

Und wenn Du die RPC-Ports von AD statisch festlegst, dann änderst Du ja nichts an der Architektur. Du verhinderst nur, daß der EPM eine "zufällige" Portnummer in seinem Range vergibt. Mit Last hat das nichts zu tun.

[wznutzer 35]

Am 17.1.2025 um 19:11 schrieb daabm:

Warum sollte man das tun, wo ist der Mehrwert?

Der "Mehrwert" war ein Irrtum meinerseits.