AD-Portscanner mit "Matrix-Multithreading"

[daabm 1.366]

Hallo miteinander.

 

Heute mal keine Frage, keine Antwort, sondern ein Angebot: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1

 

Wir haben beruflich immer wieder mit Multi-Domain-Umgebungen zu tun, in denen User, Computer und Target Accounts (aka "zu verwaltende Konten") in verschiedenen Domänen sind. Das bedeutet, daß wir relativl viel AD-Kommunikation brauchen. Und naturgemäß liegen dazwischen Firewalls. Daraus entstand das Bedürfnis, Ports schneller und einfacher zu prüfen also "pro Host, pro Ziel-DC und pro Port per Test-NetConnection oder portqry.exe". Test-NetConnection ist eh ganz furchtbar langsam...

 

Was dabei herauskam: Ein Skript, dem Du eine Liste von Zielcomputern (oder einen Domänennamen - DNS-Auflösung ist mit drin) übergeben kannst. Dann prüft es vom lokalen Computer aus alle AD-relevanten (default) oder eine benutzerdefinierte Liste von Ports gegen diese Computer. Wenn Powershell Remoting in Deiner Umgebung funktioniert, kannst Du zusätzlich eine Liste von Quellcomputern angeben, von denen aus diese Ports geprüft werden sollen.

 

Beides läuft multithreaded. Auf dem ausführenden Rechner wird über Runspaces und PSSessions das Skript auf den Quellcomputern gestartet. Dort jeweils macht es wieder über Runspaces parallel die Port-Prüfungen.

 

Soweit klar? Du kannst also parallel von 4 Quellcomputern Zielports auf 4 Zielcomputern prüfen. Damit ist auch der Thread-Titel erklärt - Matrix-Multithreading

 

Dazu kommt noch: Das Skript kann auch die RPC-HighPorts prüfen (holt diese dynamisch vom RPC-Portmapper des Zielcomputers, Credits an Ryan Ries), es kann SSL/TLS-Ports prüfen inkl. deren Protokollversion und Zertifikat. Eignet sich also auch für Webserver-Farmen o.ä.

 

Wenn man's "einfach so" aufruft, prüft es "nur" alle DCs der aktuellen Umgebung auf alle (naja, die meisten) AD-relevanten Ports. Dabei kommt dann z.B .so was raus:

 

 

Natürlich kannst Du das Ergebnis auch ("-PassThru") in Powershell weiterverarbeiten statt es nur in ein Out-Gridview zu pipen Und mit "-IncludeEPM" bekommst Du auch die RPC Highports. Oder Du willst alle DCs von allen Trusting Domains prüfen - IncludeAllTrustingDomains (und vielleicht noch IncludeAllTrustedDomains?)

 

Interessant wird's mit diesem Aufruf:

.\Test-TcpPorts.ps1 -Computer <ZielDom1>, <ZielDom2> -SourceComputer ( Get-ADDomain ).ReplicaDirectoryServers -IncludeEPM

Das Ergebnis (und vor allem die Ausführungszeit) mag sich jeder Interessierte gern selber mal anschauen. Die ändert sich nämlich kaum, ob es nun 5 oder 50 Server sind. Du weißt in wenigen Sekunden, welche Kommunikationswege gefiltert werden.

 

PS: Modulabhängigkeiten gibt es keine - intern ist alles mit AD über [DirectoryServices] gelöst. Nur das DNS-Modul brauche ich, aber das ist immer vorhanden. Und wenn Du die Zertifkate beim SSL-Check speichern willst - die Objekte dazu haben eine .Save( TargetDirectory ) Methode.

 

bearbeitet 16. Dezember 2022 von daabm

[cj_berlin 1.329]

Nice

 

[daabm 1.366]

Dankeschön

 

Ich weiß, daß der Code (obwohl eigentlich nicht "gewachsen", sondern erst knapp 4 Monate alt) schon direkt ein paar Verbesserungspotentiale hat - ich hätte z.B. Klassen nehmen sollen statt verdammt vieler [PSCustomObject]. Aber wir sind in der Firma echt zufrieden damit, weil's halt sackschnell sauviele Ports "kreuz und quer" prüfen kann. Und ParameterFromPipelineByPropertyName war auch keine freiwillige Erfindung - ich mußte tatsächlich mal von 9 Sytemen aus Verbindungen zu 12 verschiedenen DB2-Datenbankservern prüfen, die jeweils auf anderen Ports laufen