Postgres flutet meinen Speicher mit großen Dateien

Hallo,

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
2021-12-15 10_52_38-Angesagt - PG-Forum.de

Was sind das für Dateien? Kann ich die Dateien löschen? Bitte um Unterstützung!

Schwer zu sagen. Irgend welche anderen komische Dinge? Ist das System aus dem Internet erreichbar? Inhalt der Dateien mal angeschaut (strings etc.)?

Fast sagt den file dazu.
Also bspw. file zi9XN9Go
Ich vermute das sind Zwischenergebnisse bzw. Artifakte von fehlerhaften Scripts oder Scriptversuchen.

Du bist ge-hackt worden. Das sind typische Anzeichen für “bitcoin mining malware”.

Siehe z.B. hier oder hier

Du solltest den Server sofort vom Netz nehmen.

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.

1 „Gefällt mir“

jupp, ich erinnere mich, hab das auch mal bei einem Kunden gesehen. Danke für die Links.

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.

pgsql/zimtD037: Zip archive data, at least v2.0 to extract

Das Bild (Screenshot) entspricht aber ganz genau den Symptomen wenn man von einer Miner-Malware befallen wurde.

Welche Dateien sind in dem Zip Archive enthalten?
zipinfo pgsql/zimtD037

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…

2021-12-15 13_23_16-Clipboard

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.

sudo strings pgsql/zimtD037 | head
Pp@5
pg_wal/000000010000000000000001UT
SZDf
Ou{X
{+WD{S{S L
1{2,
V       :q|t
8>Yo
+8Fp
)5=^

sudo strings pgsql/zimtD037 | less
}hT>_Mv
fIGI
n]wM
4K:J
%eH)
4G:&
r}$7d
:&eNc
S=FS
g[B{
;?52
k45fw
[sNI
tylM5%
qq{y[
2n|K
!iv'
.O:=
X94H
X94H
3h<~
u2~xE
C6O:
=Zo7
PSouYp
n9?]
,)CJ
fH9R?
%eHiR
0mO:MZ
GZ<N
$~.w
mO:MZ
,)CJ
x;mO:MZ
|k6-
p/p%
<C|5
q^=0
q^-0
q^10
%gXr
0 (*(*fL
<o3`
<o#`
<o=`
<o-`
<o5`
<o%`
<o9`
<o)`
|n$`
|n8`
Gd{>
j^Sr]
;NJ>
~k:|w
v8|5
jc;[5
_EyT,=
xnOy
tNzF
xnOy
xn?N
xn?I
xn_Q
vFi<
~u7n?X
~x>Zw
]]0t
-l?Y
{/gB
Lor~
_s?`Z
...

Danke für Eure Unterstützung!

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.

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.