MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Highportrange-Risiko

Webserver nutzen Port 443/TCP, Mailserver Port 25/TCP aber RPC, DCOM, WMI u.a. wählen  dynamische Ports zwischen 1024-65535. Das führt zu sehr freizügigen Firewall-Regeln, die man mit etwas Konfiguration vielleicht gar nicht braucht.

Erreichbarkeit von Servern

Ein Client nutzt einen High-Port um eine Verbindung zum Zielserver aufzubauen. Ihr Windows Client verbindet sich z.B. mit einem Quellport zwischen 1024-65535 zum Domain Controller per LDAP auf 389, 6363, den GC auf 3268 3269 oder SMB auf 445. Die UDP/TCP-Ports werden gerne in drei Klassen einsortiert.

Well Known Ports: 0 through 1023.
Registered Ports: 1024 through 49151.
Dynamic/Private : 49152 through 65535.

Da es aber mehr als 1024 Dienste gibt, müssen sich viele andere Dienste auf andere Port verlegen. Schon das AD nutzt für den GC ja Port 3268 und auch Microsoft SQL ist auf 1433/TCP ausgewichen. Nur schon früh im Internet definierten Dienste haben wirklich einen statischen Port unterhalb der 1024-er Grenze.

Firewall-Regeln für Verbindungen von Client:High auf Server:StatischePorts werden natürlich eingerichtet aber wenn das Ziel dynamische Ports nutzt, dann brauchen Sie genaugenommen ein "Client:High -> Server:High". Damit machen wir aber auch Dienste auf dem Server

 

Wir könnten hier also eine Firewall zwischen Client und Server stellen und alle Highports des DCs blockieren. Auf dem DC laufen ja vielleicht noch weitere Dienste, die auch auf Ports lauschen aber von Clients (und Angreifern) nicht erreichbar sein müssen. Wenn Sie aber nun die Liste der Netzwerkkommunikationen ansehen, dann fordert Microsoft hier weitere statische Ports aber insbesondere auch eine sehr große dynamische Range


Quelle: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements  

Das ist zwar nun nicht 1024-65535 aber immer noch eine große Portrange die auch in Firewalls entsprechend freigegeben wird. Es gibt Firewalls, die die Protokolle besser verstehen (RPC-Firewall). Eine RPC-Anfrage an solche High-Ports geht eine Verbindung auf Port 135 voraus, über die der Client erst den Highport erfragt. Einfache Layer-4 Switches mit Access Listen können das aber nicht.

Das Risiko

In den meisten Firmen gibt es intern nur wenige Firewalls oder wenn, dann mit sehr offenen Ports. Der Angreifer wird bevorzugt im Internet vermutet und weniger im LAN. Das ist natürlich ein Irrglaube und bei einem Penetrationtest fallen daher immer wieder Lücken auf, die eigentlich gar nicht sein müssten.

Wenn Sie in der mittleren Firewall einfach "High Ports" zulassen, kann kann ein böser Clients eben auch den Monitoring-Agents (Hier am Beispiel NSCLient++) zugreifen. Dann muss er nur noch auf eine Lücke warten, um Server zu übernehmen. Dieses Risiko kann natürlich auf mehrere Wege verhindert werden.

  • DENY auf bestimmte Ports
    Da kein Client eine direkte Verbindung zum NSClient auf den Servern benötigt, könnten Sie auf der mittleren Firewall einfach eine "DENY-Regel konfiguriere, die Zugriffe aus dem Client-Netzwerk auf den Port blockiert, wenn die Source-IP nicht ihr Monitoring-Service ist.
  • Firewall auf dem Server
    Jedes Betriebssystem hat heute eine Firewall-Funktion, die man auch aktiv nutzen kann. Bei der Installation eines Diensts, der auf einem Port hören will, muss dieser auch eine eingehende Regel in der Firewall einrichten. Hier sollte natürlich kein "Source:Any/Destination:Local:Port" sondern z.B. die Quell-IP auf das Monitoring-System bechränken. Übrigens empfehlen dies auch Anleitungen zur Installation von NSClient (https://nsclient.org/docs/installing/).
  • Applikations-Konfiguration
    Wenn die Software es hergibt, dann können Sie natürlich auch in der Software eine Liste der erlaubten Kommunikationspartner pflegen, sei es anhand der Source-IP, DNS-Namen oder durch eine sichere Authentifizierung. Allerdings hilft das nicht, wenn eine Lücke in der eigentlichen Software diesen Schutz aushebelt.

Dennoch ist es ein effektiver Schutz, wenn Sie die Kommunikationswege in ihrem Netzwerk kennen und explizit mit "Allow" arbeiten. Allerdings hilft es nur bedingt bei Diensten, die von vielen Gegenstellen angesprochen werden. Dass ein Exchange Server über Port 443 angesprochen wird ist aus Sicht der Firewall einfach und schnell konfiguriert. Das schützt aber nicht gegen Angriffe, die über 443 möglich sind. Siehe auch Exchange extern absichern.

Auslöser für die Seite war der Bericht eines Penetration-Tests, bei dem das Red-Team quasi alle Incinga-Instanzen über 5665 erreichen konnten und diese Systeme 4 Monate zu alt waren und daher für "CVE-2025-48057 - Icinga 2 certificate renewal might incorrectly renew an invalid certificate" (https://app.opencve.io/cve/CVE-2025-48057) verletzbar war

Die Umgebung hatte damit zwei  Probleme aufgezeigt:

  • Update-Management
    Wer heute Dienste betreibt, die als "LocalSystem" auf einem Server laufen und per IP erreichbar sind, muss sich um seine Updates kümmern und diese zeitnah einspielen. Hier geht es um Stunden oder Tage. Eine bekannte Lücke über lange Zeit ungepatcht zu lassen, kann man sich nicht erlauben
  • Host-Firewall
    Das Problem wäre weniger schwerwiegend gewesen, wenn die Firewall auf den Hosts nur eingehende Verbindungen von legitimen Gegenstellen erlaubt hätte.
  • Netzwerk-Firewall
    Bei dem Penetrationtest war der Angreifer im "Client Netzwerk" und eine Verbindung auf 5665 wäre nie erforderlich gewesen. Man hätte solche Versuche schon auf der Netzwerkfirewall blocken können.

Besser als Blocken wäre es aber gewesen, dies Verbindung gar nicht zu erlauben. Aber hier kam dann wieder die Thematik der "dynamischen HighPorts". Natürlich müssen die Client auch andere Server im Server-VLAN erreichen und wenn dort auch High-Ports genutzt werden, dann ist es oft der einfachere Weg, diese einfach freizugeben.

High-Ports beschränken

Es würde einiges einfacher sein, wenn der Einsatz von dynamischen Ports reduziert werden könnte. Es wird natürlich immer wieder berechtigte Anwendungsfälle geben. Ein Client, der eine Verbindung aufbaut, wird immer einen "High Port" als Quelle nutzen aber jede Firewall kann gut unterscheiden, wer die Verbindung initiiert. Ein "Von Any:High -> Ziel:Static" ist aber viel sicherer als ein "Any:High->Ziel:High". Auch bei P2P-Traffic, z.B. VoIP werden zwei Clients versuchen sich direkt zu erreichen. (Siehe auch ICE, Kandidaten, STUN und TURN). Hier fällt aber auf, dass sowohl Quellport als auch Zielport in der Regel in der "HighRange" liegen oder vorgegeben werden können. Bei TCP wird eine "Session" aufgebaut und gehalten, die eine "Stateful Inspection Firewall" problemlos nachhalten kann. Bei UDP sieht das etwas anders aus. Für das erste Paket eines Verbindungsaufbau erstellen wir eine Tabelle.

Quelle Ziel Bewertung Beschreibung

High

Statisch

OK

Wenn der Zielports bekannt und festgelegt ist, kann eine Firewall sehr gut diese Verbindungen explizit erlauben oder unterbinden. Das ist eigentlich die Wunschvorstellung, dass jeder Dienst eigentlich einen definierten Port nutzt. So lassen sich dann auch sehr gut Netzwerkflüsse ermitteln und Missbrauch erkennen. Mit einem festen Port, der von anderen Systemen nicht genutzt wird, können Sie auch deutliche Firewall-Regeln einrichten. Dann ist es auch ziemlich egal, ob der Port nun zwischen 1-1024 oder einem höheren Port liegt.

1-1024 

Any

Kaum genutzt

Es gibt nur ganz wenige Dienste, die mit einem niedrigen Source-Port eine Verbindung starten. Da mag ECHO, DNS, FINGER, NTP o.ä. mal auftauchen, aber ich habe schon lange keinen Client mehr gesehen, der 1-1024 als Quelle nutzt. Microsoft hat sogar die

High

High

Eingeschränkt

VoIP nutzt gerne die Option, bei der beide Endpunkte mit High-Ports kommunizieren. Diese Kommunikation ist in der Regel auf das interne Netzwerk beschränkt und da sie ihr eingesetztes Produkt kennen, können Sie hier oft die Portrange einschränken. Bei Microsoft Teams nutzt man gerne folgende Port.

50000-500019 für Audio
50020-500039 für Video
50040-500059 für Desktop Sharing

Dann ist es natürlich einfach, eine "Intern:50000-50059 <-> intern:50000-50050"-Regel einzurichten, um Sprache und Video im LAN zu lassen. Ansonsten würden die Clients nämlich die TURN-Kommunikation nutzen und meinst eine Verbindung zu 3478/UDP-3781/UDP zum TURN-Server aufbauen. Andere VoIP-Lösungen nutzen ggfls. andere Bereiche.

High

Dynamisch

Problematisch

Diese Verbindungen sind unschön, da Sie eine N:M-Allow-Regel zwischen den beiden Endpunkten erforderlich machen und damit indirekt auch andere Dienste auf den Servern von Client erreichbar sein werden, wenn dies speziellen Ports dann nicht per DENY geblockt werden. 

Während die ersten drei Fälle noch über Regeln behandelt werden können, müssen wie bei der letzten Relation schauen, dass wir die dynamischen Ports der Server besser geregelt bekommen. Auch wenn Firewalls oft behaupten, dass Sie die Protokolle erkennen und intelligent erlauben, würde ich mich darauf nicht allein verlassen. Vor allem ist es oftmals sogar möglich, die Dynamik einzuschränken oder komplett abzuschalten.

Als Exchange noch das Protokoll MAPI/RPC genutzt hat, haben Outlook Clients zuerst eine Verbindung per RPC (135/TCP) zum Exchange Server gestartet und nach dem Port für "MSExchangeIS" und "MSExchangeDS" gefragt. Der Exchange Server hat also bei jedem Neustart der Dienste einen freien dynamischen Ports genutzt und per 135/RPC bereitgestellt. Diese Einstellung konnte ein Exchange Administrator aber auch fixieren, so dass die beiden Exchange-Dienste immer den gleichen statischen Ports genutzt haben. Das war auch ratsam.

# Obsolet Aktuelle Outlook/Exchange-Systeme nutzen kein MAPI/RPC mehr
HKLM:\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\TCP/IP Port:60000
HKLM:\System\CurrentControlSet\Services\MSExchangeAB\Parameters\RpcTcpPort:60001

Heute haben diese Einstellungen keine echte Funktion mehr, da es keine Zugriffe von Clients per RPC auf Exchange gibt. Exchange Server müssen von Clients eigentlich nur noch per MAPI/HTTP (443/HTTPS) und in Einzelfällen noch per IMAP/SMTP/POP  (993/996/587) erreichbar sein.

Für andere WindowsProtokolle müssen wir schon noch einmal genauer hinschauen. Wenn Sie die Portbereiche auf "Service overview and network port requirements for Windows" (https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements) analysieren, dann gibt es da überall ein "Sternchen" an den High-Ports. Hier nur ein Auszug

 

 
Auszüge aus https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements

Es gibt aber noch sehr viele weitere Dienste und die Seite geht primäre auf den Windows Server ein. Aber auch viele Remote-Zugriffe auf Server, z.B. Eventlog, WMI, Regedit, etc. nutzen im Hintergrund RPC. Auch 3rd-Party-Tools können sich auf einem Windows Server als RPC-Dienste registrieren. Wir kommen also nicht umhin, für jeden Dienst zu prüfen, wie eine statische Portkonfiguration erfolgen kann. Der RPC-Portmapper auf Port 135 ist nämlich nur dazu da, die Ports der bei ihm registrierten Dienste an Clients zu übermitteln aber kontrolliert nicht, welche Ports ein Dienst beim Start öffnet. Microsoft schreibt das auch auf

Many RPC servers in Windows let you specify the server port in custom configuration items such as registry entries. When you can specify a dedicated server port, you know what traffic flows between the hosts across the firewall. And you can define what traffic is allowed in a more directed manner.  
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-rpc-dynamic-port-allocation-with-firewalls

Wenn wir uns auf "Active Directory Domain Controller" beschränken, die als Tier-0-System besonders geschützt sein sollten, dann ist der folgende Artikel der Startpunkt:

Für die AD-Replikation zwischen DCs können die Ports vorgegeben werden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port:REG_DWORD = <portnummer>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DCTcpipPort:REG_DWORD = <portnummer>

Wichtig ist natürlich, dass der Port "verfügbar" ist und kein anderer Dienst sich diesen Port vorher reserviert.

Vielleicht sollten Sie sich eine Dokumentation anlegen, welche Ports sie auf welchen Servern nutzen. 

Ein Domain Controller hat natürlich noch mehr Ports. Bis Windows 2008 wurde noch der alte FRS-Dienst zur Replikation von NETLOGON und SYSVOL genutzt.

# Obsolet FRS wird nicht mehr genutzt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\RPC TCP/IP Port Assignment:DWORD = <portnummer> 

Neuere Domaincontroller nutzen natürlich DFRS, so dass dieser Wert nicht mehr erforderlich sein sollte.

Die Referenzen gehen auf weitere Seiten wie:

Datenverkehr erfassen

Sicher können Sie bei bekannten Servern schon vorab anfangen, die Ports entsprechend ihrer Vorgaben festzulegen. Aber um sicher zu sein, dass auch wirklich niemand mehr dynamische Ports nutzt, und sie die Regeln der Firewall auf "streng" umbauen können, sollten Sie die aktuellen Verbindungen erfassen. Dazu gibt es mehrere Optionen:

  • Netzwerk-Firewall
    Dort wollten Sie zukünftig ja strenger reglementieren. Prüfen Sie hier ihr Logging, ob sie den Aufbau von Verbindungen zu HighPorts gesondert protokollieren können. Sie sehen so schnell die Server, die immer noch Highports anbieten und auch die Clients, welche diese Nutzen.
  • NetFlow/sFlow/IPFix/cFlow
    Prüfen Sie, ob ihre Netzwerkkomponenten ebenfalls die Datenverkehre erfassen können. Suchen Sie nach NetFlow/sFlow/IPFix/cFlow. Es ist nicht unwahrscheinlich, dass Sie so ebenfalls die aktuelle Nutzung von Highports als Ziel neuer Verbindungen ermitteln können.
  • Server-Firewall
    Auf ihren Servern gibt es auch Firewalls und sie können die Windows Firewall problemlos dafür nutzen, ein Protokoll über die Verbindungen zu erstellen. Das ist schnell konfiguriert, auch per Gruppenrichtlinie, und die Logfiles sind klassische CSV-Dateien, die einfach verfolgt werden können-
  • "Paketsniffer"
    Neben der Firewall gibt es auch System wie Packetbeat u.a., die Pakete mitschneiden und "Flows" berichten. Auch hier müssen Sie aber einen Sammelpunkt betreiben und auf allen Servern solche Dienste integrieren. Vielleicht haben Sie solche Systeme aber schon als Teil einer Endpoint-Schutzlösung im Einsatz.
  • Inventory mit NETSTAT etc.
    Sowohl Windows als auch Linux liefern Tools mit, auf denen Sie sowohl aktuelle Verbindungen als auch "lauschende Ports" ermitteln können. Wenn Sie alle Server kennen, können Sie so auch eine erste Landkarte der Server mit Ports und angebotenen Diensten aufstellen.

Damit bekommen Sie eigentlich alle Daten, die für eine Härtung erforderlich sind 

Vorgehen

Wenn wir später auf dem Netzwerklevel mit Firewalls die Regeln strenger fassen wollen, dann ist der erste Ansatz auch die Firewall, die heute die Pakete schon durchlässt. Aktivieren Sie hier ein Logging und stellen Sie dann nach und nach die Server auf feste IP-Ports um. Der zweite Ansatz sind NetFlow/sFlow/IPFix/cFlow auf den aktiven Netzwerkkomponenten, da diese ohne Änderungen auf den Endpunkten ebenfalls die Verkehrsflüsse ermitteln können. Sie sehen sogar Verbindungen im gleichen Subnetz, die noch nicht durch eine Firewall müssen und könnten Ansatzpunkt für eine weitere Segmentierung ihres Netzwerks geben.

Wenn beides nicht geht oder von einem anderen Team abhängt, dann können Sie immer noch auf ihrem Server selbst die Verbindungen erfassen und davon Konfigurationsänderungen ableiten.

Sobald ich ein Skript zur Auswertung der FirewallLogs habe, werde ich es hier addieren. 

Einschätzung

Dynamische Ports als Zugang zu Diensten wurden eingeführt, als die ersten 1024 Ports vergeben waren und man weitere Ports braucht. Systembedingt gibt es aber nie mehr als 65535 Ports auf einem IP-Stack und es wird immer zu Überlappungen kommen. Das von SUN im Jahr 1988 als RFC1080 RPC: Remote Procedure Call Protocol Specification (https://www.rfc-editor.org/rfc/rfc1050) erstmals veröffentliche RPC-Protokoll ist ein Weg, Dienste mit dynamischen Ports zu betreiben. Andere nutzen alternative Discovery-Dienste. Letztlich sollte ein Server aber immer genug Ports haben, wenn er für einen gewisse Aufgabe eingesetzt wird. Wenn Administratoren ihre Dienste mit statischen Ports konfigurieren, dann erleichtert dies immens die Absicherung durch Firewall-Regeln auf dem Transportweg aber auch auf dem Server selbst. Wenn dann noch die Kommunikationspartner bekannt sind, können sogar IP-Adressen oder zumindest Netzwerkzonen in die Regeln mit eingebunden werden.

Mit deutlich enger gefassten Firewall-Regeln können Sie dann auch im internen Netzwerk den Schutz gegen Angreifer erhöhen. Das bedeutet natürlich nicht, dass Sie dann beim Patchmanagement und einer sicheren Grundkonfiguration nachlässig sein dürfen.

Weitere Links