Plötzlich 100% auf allen Kernen, aber kein Thread über 0.7% ?

Zitat von Loxley

Hi Kris, dieser Server gehört nicht mehr dir, sondern jemanden anderen, der ohne dein Wissen ein Programm installieren und starten konnte. Vermutlich hat dieser jemand auch Systerndateien wie den ps-Befehl ausgetauscht. Diesen Zustand kann man in Normalfall nicht mehr retten. Bitte fahre den Server herunter, führe eine Revision deiner Security Policy durch und installiere den Rechner mir einem aktualisierten Sicherheitskonzept neu.

Dem schließe ich mich prinzipiell an.

Löschen dieser einen Datei macht den Server mit großer Wahrscheinlichkeit noch nicht wieder sauber. (Außer du hast großes Glück)

Man kann unmöglich wissen, an welchen Stellen noch Läuse versteckt sind und wo die Lücke letztlich ist. ("Ist". Nicht "war")

Ich kann mich noch gut an einen Bekannten erinnern, der mal zu mir meinte:

"Meine HP wurde jetzt schon mehrmals gehackt. Zum Glück habe ich ein Backup, das ich immer wieder einspielen kann"

Zitat von aRaphael

"Meine HP wurde jetzt schon mehrmals gehackt. Zum Glück habe ich ein Backup, das ich immer wieder einspielen kann"

Ein Äquivalent zu: "das Boot läuft voll Wasser und sinkt, weil ein Loch darin ist. Ich habe jetzt das Wasser mal wieder rausgeschöpft. Fährt wieder".

Hay,

Zitat von KrisAusEU

Letztere habe ich erstmal gelöscht - falls das ein "externer Angriff" war, kann er ja nur darüber passiert sein

oder da:

subsonic.JPG

gibt auch ein paar CVEs für Subsonic... https://www.cvedetails.com/vul…or_id-16575/Subsonic.html

Viel Spaß weiterhin...

CU, Peter

Gefühlt jede zweite Maschine bei tryhackme beinhaltet ausbrechen aus einem Docker Container. Also als sicher würd ich die nicht bezeichnen…

Und gute rootkits machen zwar eventuell Prozessorlast, sorgen aber dafür dass diese eben nicht angezeigt wird.

Fürs Protokoll: Im obigen Fall ggf. nicht zutreffend, aber mit neuerem 5.1x-Kernel, Root-ZFS und LXD mit Btrfs-Storage-Pools (für Docker) kann man beispielsweise seit Kurzem mit I/O-Waits zu kämpfen haben. Da dies bislang wohl leider (noch?) kein weitverbreitetes Szenario ist, finden sich hierzu keinerlei leicht zuzuordnende Fehlerberichte. Es gibt also durchaus Fehlerquellen, welche man nicht durch [h]top (allein) identifizieren kann. Hier hilft letztlich nur das sukzessive/wechselseitige Abschalten oder Austauschen von Applikations-/Betriebssystemkomponenten oder der Neuaufbau einer Vergleichskonfiguration.

Zitat von KrisAusEU

- Neuinstallation bzw. Runterfahren des Servers wäre für mich die letzte Option - dafür steckt zu viel Arbeit drin..

docker compose up - ist doch schon die halbe Neuinstallation.

Updatest du deine Container nie?

Zitat von KrisAusEU

Neuinstallation bzw. Runterfahren des Servers wäre für mich die letzte Option - dafür steckt zu viel Arbeit drin..

Dieser Kommentar wird dir irgendwann als Beweis von grober Fahrlässigkeit auf die Füße fallen.

KrisAusEU Die gefundene Datei lag in einem Ordner, den es normalerweise gar nicht gibt. Diesen Ordner kann (bei korrekten Berechtigungen) aber nur der root-User erstellen. Weiters ist das Verstecken eines Prozesses ebenfalls nichts, was ein anderer User bewerkstelligen könnte. Du kannst somit gar nicht wissen, was noch alles verändert wurde und nun still und heimlich schlummert. Dass die hohe CPU-Last innerhalb Deines Systems überhaupt sichtbar war, war pures Glück bzw. Faulheit des Angreifers. Du kannst spätestens nach dieser Erkenntnis keiner Ausgabe dieses Systems mehr trauen.

BITTE MACH DIE KISTE PLATT! DAS BRINGT NICHTS. PUNKT.

Die Aussage von NaN trifft es nämlich leider sehr gut: Das ist grobe Fahrlässigkeit und die kostet Dir am Ende wahrscheinlich weit mehr Ressourcen (vor allem Zeit und Geld), als ein Neuaufsetzen des Servers.

Zitat von H6G

docker compose up - ist doch schon die halbe Neuinstallation.

Updatest du deine Container nie?

Herausgelegte Daten runter ziehen, Volumes sichern. Kiste platt, zurückspielen der Daten, "docker compose up". Wenn es damit nicht getan ist, hast Du unsauber gearbeitet.

Und ja, Containerupdates sind PFLICHT!

Zitat von KrisAusEU

um mal hier zum (hoffentlich versöhnlichen) Abschluss zu kommen:

Guten Morgen KrisAusEU

ich will mich den harten Aussagen der Pros hier anschließen und vielleicht noch etwas anekdotisch oder erklärend beitragen, um das auch zu begründen. Wenn man solche Sicherheitszwischenfälle öfters hat und mit denen auch routiniert und professionell umgeht, dann sind die hier vorgeschlagenen Schritte die korrekte und saubere Lösung.

Die saubere Aufarbeitung also das Post Mortem nach so einem Zwischenfall hast Du abgekürzt bzw. gar nicht durchgeführt indem Du die problematische Datei einfach entsorgt hast und nicht weiter den Angriffsvektor und die sonstigen Aktivitäten auf dem System nachvollzogen hast. Dabei wird versucht alle Aktivitäten des Angreifers vom Einbruch bis zum Neuaufsetzen des Systems nachzuvollziehen, um evtl. dieses vorgeschlagene Worst-Case Szenario zu vermeiden. Dadurch ist es wie die anderen schon anmerken fast unmöglich das genaue Szenario zu ermitteln und man muss von einer vollständigen Kompromittierung ausgehen und das System ist praktisch nach Backup der Daten komplett neu aufzusetzen. Bildvergleich ... Du räumst alle Wertsachen aus dem Haus wie nach einer Termitenplage und brennst danach alles nieder und baust neu auf und räumst dann wieder ein.

Wenn z.B. in dem Post Mortem festgestellt würde, dass nur ein lokaler Benutzer wie z.B. www ohne Privilegien durch den automatischen Einfall über eine XMLRPC Lücke per Einfall über den Webserver kompromittiert wurde, braucht man vermutlich nicht das ganze System plätten. Voraussetzung ist auch hier, dass man sämtliche Manipulationen herausfindet, rückgängig machen kann und das Einfallstor stopfen kann. Aber wie schon mehrfach von den anderen Profis hier geschrieben war auf Deinem System jemand mit root Rechten unterwegs und konnte und vermutlich kann nach wie vor sämtliche Ausgaben des Systems manipulieren und hat die komplette Kontrolle übernommen.

Wie aufwendig so ein Post Mortem ist und was ebenfalls viel Zeit und Wissen in Anspruch nimmt, kann man in vielen Berichten im Netz lesen. Hier mal ein wahllos herausgegriffenes Beispiel - da gibt es sicher bessere: Matrix.org zieht Lehren aus dem Hack (linux-magazin.de)

Jetzt noch ein paar Vermutungen und Anekdoten:

Einen möglichen Angriffsvektor hat Dir sofort CmdrXay nach vermutlich nur kurzer Durchsicht Deiner eingesetzten Software geliefert ... dafür solltest aber Du auf den ganzen Security Mailinglisten aller dieser eingesetzten Dienste stehen und dies VORHER oder zumindest während solcher Angriffswellen schon davon wissen. Die Angst nicht rebooten zu wollen oder auch die Sicherheit von Diensten in Containern als absolut zu akzeptieren und diese nicht zu aktualisieren hilft nur einem und zwar dem (nächsten) Angreifer.
In Deinem Fall war es vermutlich Glück und vielleicht auch etwas Nachlässigkeit des Einbrechers (ich personifiziere den mal weil ich annehme dass hier nicht mehr nur ein Script oder Wurm am Werk war bei so einem großen Server), dass das Symptom der hohen CPU Last überhaupt so schnell bereinigt werden konnte. Das kann z.B. auch einfach daran gelegen haben dass der Angreifer in dem Server wenig Wert gesehen hat und nur für etwas Mining vorgesehen hat. Das bedeutet aber evtl. nicht dass er wie schon gesagt nicht noch weitere Hintertüren hinterlassen hat oder den kompromittierten Host für den nächste Verwertungsstufe freigibt. Diese mag dann bei weitem nicht mehr so auffällig zu erkennen sein. Ich war interessanterweise schon auf beiden Seiten irgendwie mal mit dabei und kann nur bestätigen dass Du mit Deinem Kenntnisstand vermutlich den Krieg so nicht gewinnen kannst.

Nachdem manche hier schon etwas sehr hartnäckig sind, aber nicht unbedingt zielführend in der Kommunikation, mal meine Erfahrung dazu:

Mit meiner ersten Kiste bei Netcup 2012 habe ich auch definitiv 2 Neuinstallationen gemacht. Eine davon war nachdem mir eine Abuse-Meldung im CCP effektiv mitteilte dass mein System nicht mehr sauber war. Aller Anfang ist schwer und so.

Wenn der Angreifer dich nicht mag, dann ersetzt er übrigens einfach deine Tools zum auflisten von Prozessen und Dateien, schon findest du da nichts mehr.

Lass doch auf dem Server vorher auch nochmal clamav über alle Dateien laufen, die du übernehmen willst.

Zitat von KrisAusEU

Ich will aber meine Foto/Video/Musik-Ordner von Netcup Alt nach Netcup Neu verschieben (ohne Viren, ca. 100 GB), weil hochladen vom PC wären bei meinem bescheidenen Internetzugang wieder 10 Tage und Nächte Dauerupload..

Aber hoffentlich vom Rettungssystem aus...

Und wenn Du die Dateien eh noch woanders hast, wo sie garantiert sauber sind, vergleiche sicherheitshalber die Prüfsummen. Aber nicht MD5, sondern was ordentliches wie SHA256/SHA512.

Viel Erfolg!

Vom neuen Server aus:

scp -r alteruser@alterserver.de:/meine/dateien .

sollte den kompletten ordner in den aktuellen ordner kopieren. Befehl ausm Kopf, müsste schon so passen…

-p preserved auch noch die rechte, falls gewünscht.

Zitat von KrisAusEU

Neuinstallation bzw. Runterfahren des Servers wäre für mich die letzte Option - dafür steckt zu viel Arbeit drin..

Klingt ein bisschen wie „Ja gut, hab die Pizza zwar 12 Stunden im Ofen vergessen und sie hat die halbe Küche abgefackelt und vergiftet, aber - das Feuer löschen und ne neue Pizza backen wäre für mich die letzte Option - dafür steckt zu viel Arbeit drin..“

Na dann guten Appetit!

Zitat von KrisAusEU

Jetzt gibts ja SCP, rsync, SFTP usw. - ich kann googeln wie ich will, ich kapiere es nicht. Also falls da noch jemand einen idiotensicheren Tip hat

Ich verwende für solche Server zu Servertransfers und auch für andere Fileoperationen als jemand der alt genug ist um Norton Commander auf DOS noch zu kennen gerne Midnight Commander mit dem Befehl für Debian / Ubuntu:

apt install mc
mc

Da kann man einen entfernten Server in einem Panel via SSH (! nicht FTP) verbinden und Dateien pseudografisch auswählen und kopieren.

Zitat von TBT

...als jemand der alt genug ist um Norton Commander auf DOS noch zu kennen...

Ja, der hat mich auch geprägt.

Ich nutze auch heute noch beständig MC auf Linux und TC in Windows.