Abusehinweis: Bruteforce-Attacke von eigenem VServer

  • Hallo zusammen,


    ich habe seit über einem Jahr einen VServer bei Netcup und bekam einen Abusehinweis, mit folgendem Inhalt:

    (Ich habe die IP-Adresse meines VServers mit ##### unkenntlich gemacht)


    Auf dem VServer läuft nur ein MySQL-Datenbankserver, ansonsten nichts.

    Betriebssystem ist Windows Server 2016 Standard.


    Ich interpretiere die Nachricht oben so: Von meinem VServer aus wurden bruteforce-Angriffe auf andere Server im Internet getätigt- daher wurde der VServer heruntergefahren.


    Ich habe nun den VServer im Rettungssystem starten lassen- und die Windows Partition eingebunden, um Datensicherung zu betreiben und die Ursache zu finden...


    --> Wisst ihr wie man nun Windows Anmelde-Logs o.ä. noch auswerten kann, um zu sehen wer sich auf meinem VServer z.B. via RDP eingeloggt hat?


    Oder habt ihr andere Vorschläge was man da nachträglich Analyse-mäßig noch tun kann?

  • Ist das (neben RDP) wirklich der einzige öffentlich erreichbare Port?

    Der MySQL-Port 3306 war noch offen, damit eine Kommunikation zur Datenbank möglich war.



    Ich habe mir mal den Ordner "Windows/System32/winevt/Logs/" gezogen und die Logs ausgewertet


    Dort zu sehen sind gestern fast im Sekundentakt folgende Meldungen:

    Ereignis 261:

    "Listener RDP-Tcp hat eine Verbindung empfangen."



    Auch zu sehen sind Ereignis 4625:

    "Fehler beim Anmelden eines Kontos"

    Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort

    Netzwerkinformationen:

    Arbeitsstationsname: -

    Quellnetzwerkadresse: 182.151.########

    --> Diese IP Adresse läuft auf einen chinesischen Server, es sind aber auch litauische IP´s dabei gewesen



    Ich würde gerne nur wissen wie mein Server gekapert wurde - wisst ihr auf welche Windows Log-Einträge ich besonders achten soll?

  • Falls diese nicht entfernt wurden, schaue in den Eventlogs nach Logins nach. Weiterhin sollte man auch den RDP Versuch sehen können.

    https://www.ultimatewindowssec…securitylog/encyclopedia/

    Category: Logon/Logoff

    Ab ID 4624
    System ohne Netzwerk hochfahren und dann 3389 ausgehend sperren. Danach mittels Sysinternals usw. nach Prozessen suchen

    Angriffe auf RDP sind normal. Das ist immer ein Einfalltor. Deswegen nach Möglichkeit garnicht freigeben/VPN nutzen. Wichtig wäre in diesem Fall auch MFA und NLA.

    Was das System auf den aktuellen Stand? Wie ist RDP konfiguriert?

    Muss die DB frei im Netz sein oder kann man das auch über ein VPN nutzen. Brauchst du MySQL unter Windows oder ist vielleicht ein Linux Server (evtl auch eine Managed Lösung) eine Alternative?

  • Falls diese nicht entfernt wurden, schaue in den Eventlogs nach Logins nach. Weiterhin sollte man auch den RDP Versuch sehen können.

    https://www.ultimatewindowssec…securitylog/encyclopedia/

    Category: Logon/Logoff

    Ab ID 4624

    Also in den Eventlogs sind ca. 35.000 Einträge mit der Ereignis-ID 4625 (Unbekannter Benutzername oder ungültiges Passwort). Konnte jetzt auf den ersten Blick keinen Eintrag für einen erfolgreichen Login finden können (4624).


    Das RDP war ziemlich in den default-Einstellungen konfiguriert- relativ kurzes Passwort und keine Blockierung bei Fehlversuchen, das man normal besser einstellt wie ich gelesen habe...


    Überlege nun aber auch beim Neuaufsetzen auf Linux zu gehen und die Mysql-DB via Docker separat laufen zu lassen.


    Das Windows System nochmal starten und via Sysinternals auszulesen würde ich ungern tun- gibt es sonst noch Möglichkeiten nach der Ursache für die Bruteforce-Meldung zu suchen? Außer nach zuletzt geänderten Dateien etc?

  • Tjo, es kann auch sein, das man direkt über die bekannten RDP Bugs eingestiegen ist. Die Frage ist auch, hast du das System abgesichert gehabt? Firewall? ungenutzte Dienste abgeschaltet? Alle Updates usw.

    Warum willst du die Mysql DB als Docker laufen lassen? warum nicht nativ?

    Du kannst das System einmal ohne Netzwerk starten und dann die Firewall dicht machen und dann mal schauen.

    Sonst steht immer noch die Frage im Raum, muss die Datenbank komplett für alle erreichbar sein?

  • Tjo, es kann auch sein, das man direkt über die bekannten RDP Bugs eingestiegen ist. Die Frage ist auch, hast du das System abgesichert gehabt? Firewall? ungenutzte Dienste abgeschaltet? Alle Updates usw.

    Warum willst du die Mysql DB als Docker laufen lassen? warum nicht nativ?

    Du kannst das System einmal ohne Netzwerk starten und dann die Firewall dicht machen und dann mal schauen.

    Sonst steht immer noch die Frage im Raum, muss die Datenbank komplett für alle erreichbar sein?

    Dachte mir wenn das ganze dann als Docker Image läuft, ist es nochmal gekapselt und falls jemand auf die DB kommt, kann er nur dort was anrichten.


    Die DB muss im Endeffekt schon für alle IPs erreichbar sein- greife dort u.a. von daheim aus drauf zu und da ich keine feste IP habe, wäre das schwer einzugrenzen.


    Firewall war aktiv auf dem Windows Server- vieles aber auf den default-Settings gelassen und autom. Win-Updates deaktiviert, also einige Monate alt.

  • Dachte mir wenn das ganze dann als Docker Image läuft, ist es nochmal gekapselt und falls jemand auf die DB kommt, kann er nur dort was anrichten.


    Die DB muss im Endeffekt schon für alle IPs erreichbar sein- greife dort u.a. von daheim aus drauf zu und da ich keine feste IP habe, wäre das schwer einzugrenzen.


    Firewall war aktiv auf dem Windows Server- vieles aber auf den default-Settings gelassen und autom. Win-Updates deaktiviert, also einige Monate alt.

    Tjo, dann hast du schon die Ursache. Einige Monate alt.....

    Du hast dich mit Docker Sicherheit beschäftigt?

    Nutzt du SSL/TLS bei der DB?
    Was spricht gegen einen reinen VPN Zugriff auf die DB?

  • Tjo, dann hast du schon die Ursache. Einige Monate alt.....

    Du hast dich mit Docker Sicherheit beschäftigt?

    Nutzt du SSL/TLS bei der DB?
    Was spricht gegen einen reinen VPN Zugriff auf die DB?

    Nein, habe kein SSL/TLS Verschlüsselung beim DB-Zugriff verwendet- das waren aber auch nur "Testdaten", also nichts kritisches.

    VPN-Zugriff auf die DB? Wie kann man sich das vorstellen? In meinem Fall läuft eine Anwendung auf einer anderen Maschine, welche ihre gemessenen Daten zu der MySQl-DB übermittelt. Dann müsste ja vorher die andere Maschine sich vorher via VPN auf dem Netcup Server verbinden, um anschließend auf die MySql-DB zuzugreifen?

  • In meinem Fall läuft eine Anwendung auf einer anderen Maschine, welche ihre gemessenen Daten zu der MySQl-DB übermittelt

    Ne alternative zum VPN wäre, dass man einen SSH-Tunnel aufbaut (abgesichert mit PubKey) und über diesen den MySQL-Port tunnelt.

    Wenn die andere Maschine ne feste IP hat kann man zur not nur diese im Server auch freigeben, falls die alternativen nicht möglich sind.