daabm

Warnwetter heute: "Warnung vor HITZE"... Aktuell 33°

Hab mir das mal angeschaut... (Erzeugt mit https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 ) Die bieten eine extrem eingeschränkte Auswahl von Cipher Suites an - https://www.ssllabs.com/ssltest/analyze.html?d=nvd.nist.gov Möglicherweise hat Powershell/Invoke-WebRequest damit ein Problem. Für nähere Diagnose fehlt mir grad die Konzentration.

Da wären wir dann wieder bei dem Zertifikatsproblem mit dem Truststore. Der Angreifer muß ein Zertifikat präsentieren, das den "eigentlichen" Namen enthält.

Und die enthalten was genau? Du hast vielleicht eine Ahnung, wie viele verschiedene Event-IDs es aus unterschiedlichsten Quellen in den diversen Eventlogs gibt - meine Glaskugel kennt die alle nicht

Nene, nicht auf Share-Ebene. Die Heimnetzfreigabe macht auch auf Dateisystemebene "komische" Sachen.

@NilsK Du hast schon lange nichts mehr mit der Heimnetzfreigabe gemacht... "Everyone"

Jaja, weiß ich doch... $ValidationCallback = [Net.Security.RemoteCertificateValidationCallback] { return $True } $Socket = [Net.Sockets.Socket]::new( [Net.Sockets.SocketType]::Stream, [Net.Sockets.ProtocolType]::Tcp ) $Socket.Connect( $TargetComputer, $Port ) $NetStream = [Net.Sockets.NetworkStream]::new( $Socket, $true ) $SslStream = [Net.Security.SslStream]::new( $NetStream, $true, $ValidationCallback )

Entweder hat Dein DC kein Serverzertifikat, dann gibt es keinen Listener auf Port 636. Oder Du hast irgendwo anders Firewalls, die 636 nicht durchlassen. Portqry/Test-NetConnection könnte hier Klarheit schaffen. Das hier kann das alles für Dich prüfen inkl. der verwendeten Zertifkate: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Wichtig bei LDAPS, wenn die Basis mal funktioniert: Der Client (also Dein Webserver) muß der kompletten CA-Kette vorher schon vertrauen - LDAPS liefert im Handshake die CA-Chain nicht mit aus (wie das https macht).

Ja, ich hab oft mit "unbekannten" Speicherorten für Konfigs zu tun, die zentral deployt werden sollen - da fehlt mir die Zeit, jedesmal individuell zu suchen. Set-NetAdapterAdvancedProperty macht ja laut (kurz überflogener) Beschreibung im Prinzip das gleiche, nur daß es ein paar Dinge "convenient" auflöst

Typischerweise sollte das ein Regwert sein - wenn Du nix findest, probier's mal mit Regshot, das erstellt und vergleicht vorher/nachher Snapshots der Registry. Da muß man zwar dann ziemlich viel Müll rausfiltern, aber oft ist es hilfreich. Alternativ ProcMon mit Filter auf RegWrite.

Sysinternals "handle.exe" oder ProcMon sagen Dir, wer (welcher Prozess) genau welche Dateien offen hat.

Hast hoffentlich ein Windkraftwerk auf dem Dach

Ne, wäre es nicht. Den gleichen Quatsch hatten sie schon mal mit tsadmin.dll, die plötzlich gefehlt hat. Wäre eher "if you can't, we can"

Hier heute schon 24° - perfekt für ne Woche Kurzurlaub Das wäre mein Idealwetter: Tagsüber 24 bis 26 Grad, dann Regen von 1 Uhr bis 4 Uhr in der Nacht...

LOL - three in a second 😂😂

Das Profil ändert sich dadurch nicht, das hängt an der SID, wenn es schon existiert. Also mach einfach.

UNC-Hardening aktiv und Kerberos kaputt? "net share netlogon" - und die Netlogon-Freigabe ist NICHT das gleiche wie die Sysvol-Freigabe, auch wenn erstere ein Unterordner von zweiterer ist. Um Nils noch zu ergänzen: Die Eventlogs werden in dem Fall nur was Sinnvolles hergeben, wenn das Auditing entsprechend aktiviert wurde. "By default" kommt da nix bei raus.

Sorry, ja hab ich übersehen... Aber schadet ja nicht, das noch mal explizit als Statement zu haben - ohne "den vielen Text" drum herum

Ich ergänze mal: "Inbound" und "Outbound" bezieht sich ausschließlich auf den Initiator des IP- und TCP/UDP-Handshake beim Session-Aufbau. Ein Outbound-Allow erlaubt dem lokalen System, zum definierten Ziel eine Session aufzubauen. Ein Inbound-Allow erlaubt das einem Remote-System. Danach haben wir eine offene Verbindung, über die selbstverständlich Daten in beide Richtungen fließen können. Siehe netstat - "established".

Bissele Salzkammergut, ja. Wetter soll angenehm werden Danke Dir!

Hey, ich hab weder von Tomaten noch von Mangos geredet - ich bin eher reif wie ein gutes Ribeye 😂

Ich hätte ja dann einfach ne CMD gemacht gleichen Namens mit - sinngemäß - diesem Inhalt: %systemroot%\WindowsPowershell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "%~dpn0.ps1" Die startet mit Doppelklick problemlos, weil die Verknüpfung von .CMD zu cmd.exe in nahezu keiner Umgebung aufgehoben wird. Ob man in 32 oder 64 Bit läuft, läßt sich dann über $env:Processor_Architecture herausfinden, und notfalls spawnt man sich selbst dann noch mal aus Syswow64. Hab ich alles schon hinter mir Warum muß man immer alles compilen und rückwärts durch den Kamelhintern durch das Nadelöhr fädeln? SCNR 😂

Lokaler Admin reicht. Aber ist ja egal - "Admin für alle", und nie wieder Probleme mit Zugrifsseinschränkungen. SCNR...

DNS-Blocking - aber bring das mal dem Heimanwender bei, der seinen Firmenlaptop nach dem Homeoffice noch ein wenig zum Surfen verwendet... Der Webmailer funktioniert ja, klicken kann man auch. Und "per GPO" ist da nichts zu retten. Da hilft - "on the long term" - nur Brain 2.0...

Bergfest, durchhalten bis Freitag - und dann 10 Tage Urlaub. Boah, bin ich reif dafür...