aus mir unerklärlichen Gründen flutet seit kurzem Postgres das /var/lib/pgsql Verzeichnis mit
großen Dateien - siehe Screenshots. Da der Speicher dadurch zunehmend wächst, muss ich eine Lösung dafür finden!
Ein Zusammenhang mit OS-Updates oder wachsenden Datenbanken kann ausgeschlossen werden. Datenbank ist lt. pg_admin ~450MB gross.
OS: RHEL 8.4, Postgres 12.3
Was sind das für Dateien? Kann ich die Dateien löschen? Bitte um Unterstützung!
Fast sagt den file dazu.
Also bspw. file zi9XN9Go
Ich vermute das sind Zwischenergebnisse bzw. Artifakte von fehlerhaften Scripts oder Scriptversuchen.
Dann säubern (besser neu aufsetzen) und danach für den postgres Datenbank Benutzer Remote logins abschalten oder zumindest ein sehr starkes Passwort wählen.
Ein Hacking-Angriff kann ich mir schwer vorstellen, da der Server nur aus dem Internen Netz erreichbar ist. Auch die Applikationen die die DB nutzen sind nicht im Internet.
Mining müsste man ja auf der CPU sehen. Hab daher mal den CPU-Trend angesehen und das Datum des ersten Files passt ziemlich zu zum Anstieg der CPU-Last. Könnte wirklich zu zusammenpassen…
Archive: pgsql/zimtD037
[pgsql/zimtD037]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
zipinfo: cannot find zipfile directory in one of pgsql/zimtD037 or
pgsql/zimtD037.zip, and cannot find pgsql/zimtD037.ZIP, period.
Dann scheint es doch kein ZIP zu sein.
Dann lass dir mal wie von @akretschmer vorgeschlagen die Strings ausgeben. Am besten am Anfang pipen mit head oder less.
strings pgsql/zimtD037 | head
strings pgsql/zimtD037 | less
Die erste Aktion ist unbedingt das Passwort des postgres users jetzt zu ändern.
Dann prüfst Du ob irgendwelche Funktionen in Deiner Datenbank existieren. Du kannst ja z.B. via pg_stat_activity ermitteln, welche SQL Befehle diese Malware Prozesse ausführen. Dann auf jeden Fall diese Funktionen löschen.
Sicherheitshalber würde ich noch log_connections auf on stellen und dann kannst Du nachvollziehen wann und von wo die Verbindungen kommen, die diese Malware-Funktionen aufrufen (oder aufrufen wollen).
Da hier auch Zugriff auf’s Dateisystem beteiligt war, musst Du prüfen ob die Malware crontab Einträge gemacht hat die die Prozesse immer wieder starten. Wenn das mit dem Linux user postgres gemacht wurde, dann hilft auch das Ändern des Passwortes nichts.
Wenn das Netz auf PG default Port nach außen dicht ist, muss ja innen auf anderen Systemen ein Befall vorliegen. Noch Möglichkeit den Port ändern (ist ja vielleicht nur ein App Server)
Vielleicht in yum Logs nach verdächtigen Aktivitäten suchen. Also direkte Installation oder von Hilfstools (curl) oder direkt schauen, ob curl installiert ist, obwohl nie selbst durchgeführt.