Postgres - identifikace šifrování ransomwarem?

[jhonzatko]

Ahoj,

snazim se vyresit, zda jde v pripade teoretickeho pruniku do site poznat v db, ze se pripadny ransomware snazi sifrovat datove soubory primo na fs?

Co jsem zatim zkousel, tak editace samotneho souboru Postgresu nijak nevadi. Kdyz do nej neco pripojim, nevadi mu to vubec a vse funguje bez problemu dal a pokud ho komplet zevnitr smazu nebo prepisu, tak jen vraci prazdne vysledky a dokonce nehaze chybu ani pri insertu, ackoliv nasledny select insertovany radek neobsahuje.

V logu se rovnez zadna chyba neobjevi.

Narazil jsem na to, ze od verze 14 je k dispozici pg_checksums a predpokladal jsem, ze po jeho zapnuti tohle nejak osetri. V zakladu se tak ale nestale, vse puvodne popsane funguje stejnym zpusobem dal.

Rad bych se tedy zeptal zkusenejsich, prosim. Jakym zpusobem vyvolavat kontrolu (nejlepe prubezne), zda jsou datove soubory konzistentni a idealne to zaznamenavat do logu?

Diky moc za pripadne rady ci nakopnuti spravnym smerem!

[Reklama]

[Medo77]

Z mojej skusenosti ransomware pozmeni priponu suboru (resp. prida), aby vedel, ze subor uz kryptovany je.
Ak je databaza locknuta samotnym Db enginom, nemal by sa k databaze vediet dostat.
(pokial to neodstreli, a tym subor neodomkne).
Neviem ako Linuxe, ale na Win sa exe snazia nechat na pokoji, aby mali cas na kryptovanie a neukazovali zbytocne na seba. (zazil som, ze bol zakryptovany file aj DB server, ale Exe (sluzby) vzdy bezali, takze v pripade databaz, tieto ostali nedotknute, hehehe). (aj ked nie je vylucene, ze sa tvorcovia casom poucia a zacnu vypinat aj konkretne beziace procesy, aby zabezpecili vecsiu uspesnost).

Dalsia moznost je, porovnavat hlavicku suboru ... (ak je to vzdy identicke).
Napr. ak ma zip ci rar PK ci Rar!, tak ti to ransomware na 100% zmeni .. Ak vies z tohoto vychadzat pri postgre (nemam po ruke), tak mas dalsiu paku ako kontrolovat ...

S konkretnymi subormi vies robit konkretne veci:
txt - find "konkretny retazec" = nenasiel ? spusti poplach .. (msg na obrazovku, email, event do monitorovacie softu, ..)
archiv - otestuj = errorlevel iny ako 0 pri rozbaleni ? spusti poplach ..
databaza  =select nieco unikatne pre tento pripad= nenasiel sa vysledok ? - spusti poplach ...
Ten select mozes rozviest dalej, napr. vysledok select count z nejakej tabulky by ti nikdy  nemal vratit menej riadkov ako v predchadzajucej kontrole (predpokladajme, ze tabulka sa nafukuje, nie premazava - toto treba prisposobit konkretnemu pripadu).

Na nekonzistenciu databazy by mal davat samotny db engine, ale postgre nie je moja kava ...
(nieco ako dbcc checkdb na mssql)

Teoreticky by malo na problemy s databazou prist zalohovanie prostriedkami od vyrobcu.
Pri dumpe zakryptovanej db by mal zahucat chybu, kedze kvazi nema co odzalohovat ...

No a kedze popisujes kryptovanie vramci FS, tak zacat tu.
Silne heslo (kluc)/dvojfaktorove overovanie,  opatchovany OS, na firewalle zakazane vsetko co nemusi bbyt povolene, pristup na jednotlive sluzby z povolenych IP/polov (aj v ramci LAN ak je to rozsiahla infrastruktura).
Taky SSH s klucom, a len otvoreny 5432 port bude na hodne dlhu dobu celkom bezpecny ...
(nebavime sa o defaultnom (dobre znamom) userovi so zufalym heslom, kde je to otazka BForcu na par minut).

Ten defaultny port je vlastne tiez vec, ktora sa da zmenit. Nie ze by to bol problem oskenovat, ale minimalne stazis utocnikovi na chvilu zivot, ze co to tam na druhej strane vlastne je.

[alex6bbc]

to je zajimava myslenka jak hlidat stroj, ze na nem nejede ransomware.
napadlo me, ze jak servery maji ruzne ilo, idrac, tak ze by pocitac mohl mit v sobe nezavisly maly komp a ten by to hlidal.

[Death Walker]

Co jsem zatim zkousel, tak editace samotneho souboru Postgresu nijak nevadi. Kdyz do nej neco pripojim, nevadi mu to vubec a vse funguje bez problemu dal a pokud ho komplet zevnitr smazu nebo prepisu, tak jen vraci prazdne vysledky a dokonce nehaze chybu ani pri insertu, ackoliv nasledny select insertovany radek neobsahuje.

V logu se rovnez zadna chyba neobjevi.

Narazil jsem na to, ze od verze 14 je k dispozici pg_checksums a predpokladal jsem, ze po jeho zapnuti tohle nejak osetri. V zakladu se tak ale nestale, vse puvodne popsane funguje stejnym zpusobem dal.

Postgres sa snazi co najviac dat drzat v pamati, do suborov nezapisuje zmany okamzite, s vynimkou write ahead logu. WAL potom prechadza wal writer a ked ma cas alebo prekroci nastavene limity tak tie zmeny zapise fyzicky na disk. Ak medzi tym vypadne napajanie a ne je k dispozicii napajanie, tak zmeny vo WAL co nie su na disku sa pri starte zapisu. Cize ak mu chcete menit subory, s cielom testu ci to rozdycha, tak najskor tu db stopnite, skuste nieco prepisat a znova nastartujte.

Ten pg_checksums je tam od dvanastky...

[jhonzatko]

Diky za info i opravu. Cilem neni ani tak snaha overit, zda to Postgres rozdycha, jako spise proverit, zda existuje moznost detekovat takovou podezrelou aktivitu uz nejak z databaze.
Pripadne potvrdit, ze to z db urovne smysluplne nejde a musi se jit na uroven operacniho systemu.

[Reklama]

[Death Walker]

Z mojho pohladu je to na urovni db zbytocne, vdaka wal dokaze postgres rozdychat natvrdo vypnuty server. Ak tam vznikne nejaka chyba tak to bude na urovni filesystemu a na tej urovni by sa to malo riesit.

[Death Walker]

Ale inak pg_checksums by malo robit to co hladate. Navod ako to nastavit a otestovat tu: https://postgreshelp.com/postgresql-checksum

[aaa158]

Tripwire - sice to je nastroj na sledovanie celeho systemu ale mozno ho uplatnit aj na jednotlive subory.
Na subory ktore sa casto menia (db, ...) to nie je vhodne ale ak niekto sifruje cely server tak sa to dozvies.

https://forums.freebsd.org/threads/tutorial-intrusion-detection-using-tripwire.56813/

pripadne (neviem ci toto je pokracovatelom orig tripwire):
https://github.com/Tripwire/tripwire-open-source