Sagen wir so.. es haut mich nicht gerade vom Hocker.
Beiträge von friend_of_root
-
-
Alles anzeigen
Kannst ja mal testen:
fio installieren. Dann
Schreibtest:
fio --name=write --filename=~/fiotest --size=4G --bs=1m --rw=write --direct=1 --ioengine=io_uring
Cache leeren:
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
Lesetest:
fio --name=read --filename=~/fiotest --size=4G --bs=1m --rw=read --direct=1 --ioengine=io_uring
Wenn Du 4k IOPS vergleichen willst:
fio --name=randread --filename=~/fiotest --size=4G --bs=4k --rw=randread --direct=1 --ioengine=io_uring --iodepth=32 --numjobs=4
rm ~/fiotest (falls die Datei noch über bleibt)
Poste die Werte. Wenn Du mehrere Server hast, kannste gleich selbst vergleichen, ansonsten mit read: Laying out IO file (1 file / 4096MiB) hier.
read: Laying out IO file (1 file / 4096MiB) braucht 30 Minuten.
CPU-Auslastung 1.073,00 % ( 85,84 45,06 21,05 ) -
Weiß der Support denn jetzt davon oder nicht? Morgen ist Freitag und Montag ist Pfingsten, mein ja nur. Ob da ein Hardwareproblem vorliegt, sollte hoffentlich für den Support auf einen Blick erkennbar sein. Wenn ein ernsthafter Verdacht auf einen Defekt besteht, würde ich nicht die "Festplatte optimieren".
Ok, ich melde es mal. Danke.
Ich dachte ein bisschen quantitativ belegen würde die Anfrage beschleunigen. -
Wäre zumindest ein erster Schritt, wenn der nix bringt, kann man immer noch weiter machen. Ansonsten wurde nicht mitgeteilt, ob die SSD noch ne alte SATA/SAS oder NVMe ist, noch wie groß sie ist.
Sowohl der Server als auch der Vergleichsserver sind RS mit 8 Kernen, 24 GB Ram, 960GB SSD erstellt Ende April 2022.
Läuft aber wie eine äußerst altersbetagte Ente.
Auch bei 10% CPU Auslastung und 6GB Ram Auslastung kann man schon die Seiten nicht unter 8 Sekunden aufrufen, weil der Speicher langsam ist. -
Schon mal "Speicher optimieren" bei Medien im SCP gemacht?
Ui, du meinst das könnte wirklich was bringen?
Ich dachte immer es bringt gar nichts und sorgt nur dafür, dass man seine Snapshots immer entfernen muss.
Werde ich sofort probieren. -
Eh Support -> Voll Kacke geht nicht mach mal Fix - Bezahle immer pünktlich.
Nein, ich meine welche Befehle im Rettungssystem, damit sie es wirklich bearbeiten.
Glaube auch, dass der Support momentan komplett ausgelastet ist wegen gehackten Copy Fail Servern. -
Bei einem Server ist die Pladde (SSD) so langsam, dass ein apt dist-upgrade 14 Minuten statt 20 Sekunden dauert.
Was würdet ihr Netcup schicken, damit die da reinschauen? -
Dagegen würde ich in meiner Umgebung nicht auf die Idee kommen, PHP-Skripte wie Roundcube oder PHPMyAdmin über Debian zu installieren. Zumal das in ein eigenes Verzeichnis installiert, was nicht wirklich mit Hostingpanel etc. zusammenläuft. Also höchstens um die Dependencies aufs System zu ziehen und dann wieder deinstallieren.
Das sehe ich auch so, aber war trotzdem davon überrascht wieso solche Komponenten nicht mehr wie moderne Paketmanagern gehandhabt werden, sondern von nicht motivierten Maintainern abhängig sind.
-
Sind die offiziellen Repositories von Debian im aktuellen Umfeld schnell genug?
Ich denke zB daran, dass lange Zeit super alte phpmyadmin Versionen ausgespielt wurden. -
Ich hab das aber eher aus Eigeninteresse gemacht und mir das ganze mal anzuschauen. Wollte mir auch mal die Shell und den Double-SHA256 in Hashcat hauen.
Wäre interessant, ob maldetect geholfen hätte. Ich hab das mal auf 2 Servern installiert und konfiguriert. Not sure ob man es beim Webhosting zum Laufen kriegt.
-
Da hackuni aber aktuell nicht antwortet und somit der PHP Prozess weiter läuft hab ich es ein wenig anders gemacht und nun sind alle 11 Domains + Subdomains wieder sauber und im Grundzustand mit kleiner abgeänderter index.html (PS: Nur 4 Seiten waren betroffen)
Viel Spaß und Gute Nacht und diesmal ohne KI, ich hoffe das ist euch nun lieber
Hat sich hackuni jemals wieder gemeldet?
-
Alles anzeigen
Da hackuni aber aktuell nicht antwortet und somit der PHP Prozess weiter läuft hab ich es ein wenig anders gemacht und nun sind alle 11 Domains + Subdomains wieder sauber und im Grundzustand mit kleiner abgeänderter index.html (PS: Nur 4 Seiten waren betroffen)
image.pngIch bin folgendermaßen Vorgegangen:
Aufbau bei hackuni: /domain1.de/httpdocs | /domain2.de/httpdocs usw...
1. Zugriff auf Hauptordner domain1.de nehmen (chmod 500 domain1.de/)
Dadurch ist die Seite von außen nicht mehr erreichbar und zeigt den bekannten 403 - Forbidden an:
image.png2. Jetzt wäre Zeit den PHP Prozess zu killen, da aber keiner da -> Warten wir eben das Timeout von dem PHP Prozess ab, da das eval() ja nicht von außen erneut aufgerufen werden kann.
In dem aktuellen Fall habe ich die Rechte vom Ordner am Mittag genommen und jetzt gerade aufgeräumt. Da der Prozess mit der Shell und das Reinfizieren durch Timeout nicht mehr lief und ein erneuter Aufruf von außen nicht erfolgen kann, ging das relativ Problemlos.
3. Reste kontrollieren und HTML Seite replacen
Der letzte Schritt war eigentlich nur alles zu kontrollieren ob doch irgendwo noch was rumliegt, dann überall die index.html von Netcup mit leicht abgeänderten Text reinkopiert und dann die Rechte wieder ordentlich gesetzt. Nun kann der Kollege hackuni sich wieder ausbreiten in der Hoffung ohne weitere Infektionen aus alten Backups.
Wichtig: Hier war ALLES leer, außer eben die Infektion. Deswegen auch relativ einfach zu bereinigen. Wenn man Daten retten muss, sollte vorab ein komplettes Backup gezogen werden. Was ich hier schade finde, dass der Wunsch einfach alles zu löschen des Kunden nicht nachgekommen wird - Natürlich nach Absicherung seitens Netcup sehe ich da eigentlich keine Probleme. Ohne die Hilfe denke ich wäre die Malware bis zur Kündigung auf dem Webspace liegen geblieben.
Final: So und für die Spielkinder unter euch, natürlich hab ich ein Backup für euch zum Spielen
Hier die Dateien zum spielen und gerne analysieren. Denn hier kann das eh jeder besser:
Zip: Ohne Passwort damit man es hier anhängen kann
7z: Passwort: "iknowwhatido"
Viel Spaß und Gute Nacht und diesmal ohne KI, ich hoffe das ist euch nun lieberDu hast das eh sehr gut gemacht! Nun auch mit deinen Schritten der Bereinigung um einiges wertvoller für den nächsten Hack.
-
Wo hatten die Webmaster nun Probleme in den letzten 140 Posts:
- konnten die Dateien nicht löschen (weil wiedergeneriert)
- konnten Hack nicht ausfindig machen (weil mehrere Dateien, im RAM und unlesbar gemacht)Denke das könnte man mit den dargelegten Schritten erledigen.
Bitte soll doch mal jemand gehackter probieren und wieder Feedback geben. -
auch hier im WCP/Plesk kannst du PHP einfach per haken deaktivieren.
Ja, denke das ist korrekt und damit kriegt man auch das RAM frei.
-
mein Reden - deshalb ist das erste was ich als zertifizierter Anfänger abschalte in einem webhosting, PHP.
Das ist auch ein guter Ansatz und dann eventuell dann auch in 2 Schritten möglich.
1) PHP ausschalten
2) Alle Dateien verschieben in einen anderen Ordner. Es ist davon auszugehen, dass alle Webseiten infiziert sind. -
Denke es klappt so in 60 Sekunden:
1) httpdocs umbenennen auf httpdocs_
Nun kann der Hack nicht mehr zugreifen oder etwas neu schreiben2) Alle Dateien verschieben in einen anderen Ordner. Es ist davon auszugehen, dass alle Webseiten infiziert sind.
3) Dann PHP Version wechseln, dies startet PHP FPM neu und ist die einzige Möglichkeit die uns netcup gibt.
Nun kann er nicht mehr aus dem Ram einen neuen Hack schreiben
4) Nun wieder httpdocs_umbenennen auf httpdocs
5) Nun neu installieren -
Debian hat gerade das Paket linux-image-6.12.86+deb13-amd6 freigegeben. Laut Changelog repariert das ausser "Dirty Frag" noch etliche andere Fehler, auch welche mit CVE.
Na dann wieder ran und alles updaten.
-
Great work! Es wäre gut ein Erkennungs und ein Entfernungsskript erstellen zu lassen.
Der Hack ist auf einer Stufe, die für Anfänger unschaffbar ist.
-
Hat hier schon mal jemand mit Apache HertzBeat gearbeitet/gespielt?
Das schaut richtig schnucke aus.
-
Das Duplikator Plugin ist das Problem:
https://www.invicti.com/web-application-vulnerabilities/wordpress-duplicator-plugin-unauthenticated-arbitrary-file-download
https://github.com/advisories/GHSA-2xxp-777x-hr57
https://de.tenable.com/blog/duplicator-wordpress-plugin-vulnerability-exploited-in-the-wildNeu anfangen.
