Jump to content

Dukel

Members
  • Gesamte Inhalte

    11.569
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Dukel

  1. vor 38 Minuten schrieb mwiederkehr:

    Mit Pre-Auth: einverstanden. Wenn ein Proxy aber alles 1:1 weiter gibt, bringt er nicht viel. Bei der ProxyLogon-Lücke hätte so ein Proxy nichts geholfen. (Aber man hätte mit ihm schnell und zentral den Zugriff auf die anfällige Datei blockieren können, als raus kam, welche es ist.)

    Man kann mit einem Reverse Proxy einzelne Adressen (powershell, ecp, oab,...) erlauben oder verbieten.

  2. https://www.loadbalancer.org/blog/nginx-vs-haproxy/

     

    https://thehftguy.com/2016/10/03/haproxy-vs-nginx-why-you-should-never-use-nginx-for-load-balancing/

     

    Außerdem ist es einfacher tcp Verbindungen (außer http(s)) zu loadbalancen / redirecten.

     

    EDIT:

    Frage 2:

    https://nginx.org/en/docs/http/server_names.html

     

    Das ist der externe Hostname bzw. auf den Nginx / Der Reverse Proxy hört.

     

    EDIT2:

    Eine Funktion, die mir bei Nginx fehlt ist, dass man einzelne Realen Server temporär deaktivieren kann (z.B. beim patchen).

  3. vor 1 Stunde schrieb fmsmuc:

    11.) Passwörter ändern

     

    Welche Passwörter? Auch der des KRBTGT (https://www.msxfaq.de/windows/kerberos/krbtgt_keyrollover.htm) ?

    https://www.msxfaq.de/exchange/update/hafnium-exploit.htm#was_tun_bei_erkanntem_einbruch_

     

    Zitat

    Stellen Sie sich vor, sie haben eine PowerShell auf einem Server mit "LocalSystem" und "ExchangeTrustedSubsystem" in einem fremden Netzwerk und sie haben kriminelle Energie. Was könnten sie alles anstellen? Ziemlich viel und auf ziemlich vielen Servern.

     

    Eigentlich hat das Gesamtsystem als kompromittiert zu gelten. Es kann keine allgemein gültige Empfehlung geben, den Sie wissen ja nicht, wie tief der Angriff war und welche "Hinterlassenschaften" in ihrem System zu finden sind.

     

    • Like 1
  4. vor 1 Minute schrieb magicpeter:

    Sehr komisch, auf dem Server war und ist keine Malware drauf.

    Laut .\Test-ProxyLogon.ps1 -OutPath $home\desktop\logs und MSERT.exe ist nichts auf den beiden Servern drauf.

    Auf dem Server ist keine erkennbare Malware drauf.

     

    Auf das AD kann nicht nur der AD Controller zugreifen, auch andere Systeme. Es muss ja nichts Lokal sein, sondern kann auch von einem Server oder Client kommen.

  5. Wieso brauchst du am Server Bild und Ton, wenn du das WebEx nur administrieren willst?

    Ich kenne jetzt WebEx nicht. Aber ich gehe davon aus, dass man dies an einem Server Administriert (Startet, Stoppt) und sich alle Clients (z.B. du von deinem Client und andere Personen auf diesen Server verbinden.

     

    Ob dein Bild/Ton über RDP oder über WebEx an den Server geleitet wird sollte ja kein Unterschied machen.

    Btw. hast du RDP auf dem Server direkt im Internet freigegeben? Das ist Sicherheitstechnisch keine gute Idee.

  6. 3 minutes ago, magicpeter said:

    Mal schaun wie es weiter geht.

    Hat jemand noch eine Idee? ;)

    Die willst du ja nicht hören. Aber ich wiederhole mich aus einem anderen Thread:


     

    Quote

     

    Alte Umgebung vom Netz nehmen. Ursachenforschung betreiben.

    Paralell dazu eine neue, saubere Umgebung aufsetzen. Dann die Backups (alles nichts ausführbare) zurückspielen. Diese Umgebung dann mit aktuellen Möglichkeiten absichern.

     

    Daher, wenn man nicht das Gegenteil belegen kann, gilt die ganze Umgebung als korrumpiert und gehört neu aufgesetzt.

     

    Spätestens jetzt hat man Budget für ein Notfallkonzept verfügbar.

     

     

  7. 7 minutes ago, rt1970 said:

    Ja, das nehme ich an. Warum jetzt Paranoia schieben, wenn das Ding seit "Anfang der Aufzeichnung" läuft?

    Je nachdem, was das Ding macht, hätte man von Anfang an "Paranoia" schieben sollen.

    7 minutes ago, rt1970 said:

    Zur Ursachenfindung trägt eine Neuinstallation nicht bei.

    Alte Umgebung vom Netz nehmen. Ursachenforschung betreiben.

    Paralell dazu eine neue, saubere Umgebung aufsetzen. Dann die Backups (alles nichts ausführbare) zurückspielen. Diese Umgebung dann mit aktuellen Möglichkeiten absichern.

    8 minutes ago, rt1970 said:

    Sollte das tatsächlich eine Schadsoftware sein, könnte sich diese genauso im Active Directory eingenistet haben...

    Daher, wenn man nicht das Gegenteil belegen kann, gilt die ganze Umgebung als korrumpiert und gehört neu aufgesetzt.

     

    Spätestens jetzt hat man Budget für ein Notfallkonzept verfügbar.

×
×
  • Neu erstellen...