|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
mefmanlr2Вообще файлы БД ведь не мало весят обычно, как их получилось зашифровать? Да и просто так в винде они не меняются на лету, это служба была остановлена чтоле? резонно... хотя скорее всего база копеечная. может шифровальщики умные вопрос интересный.... ну, не умнее же постгрес сервиса ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 14:49 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Ролг Хупинmefmanпропущено... резонно... хотя скорее всего база копеечная. может шифровальщики умные вопрос интересный.... ну, не умнее же постгрес сервиса предположение: процесс шифрования начинается при ребуте до запуска сервисов ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:02 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
или зашифровано то что получилось зашифровать, а часть осталась как было. Емнип по коду базы были примечания, что winapi не разрешает одновременно открытые дескрипторы чтения и записи на один файл, но чтобы поставить базу в неудобное положение не обязательно шифровать все файлы в PGDATA. База не держит открытые дескрипторы на все файлы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:11 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
MelkijБаза не держит открытые дескрипторы на все файлы. Серьезно? Т.е. при старте PostgreSQL не проверяет и не открывает на запись все файлы в БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:25 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
mefmanЕсть два типа людей. Те кто делает бекап, и те кто пока не делает. теперь ты один из нас Есть третий вид людей - которые хранят бекап не на сервере. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:35 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
982183mefmanпропущено... теперь ты один из нас Есть третий вид людей - которые хранят бекап не на сервере. и четвертый, те что делают тестовые восстановления регулярно ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:36 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 15:36 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Melkijwitte, ОС в общем случае и не даст одновременно открыть все файлы. См. max_files_per_process То что ОС накладывает/может накладывать ограничения на количество одновременно открытых файлов на процесс - это понятно. Меня интересует поведение PostgreSQL по-умолчанию. Если лимиты в ОС выставлены правильно (можно открыть все файлы), что будет во время старта? PostgreSQL попытается открыть все файлы на запись? И что будет если лимиты не позволяют открыть все файлы? При старте PostgreSQL ругнется и не даст работать с БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 16:44 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
witteMelkijwitte, ОС в общем случае и не даст одновременно открыть все файлы. См. max_files_per_process То что ОС накладывает/может накладывать ограничения на количество одновременно открытых файлов на процесс - это понятно. Меня интересует поведение PostgreSQL по-умолчанию. Если лимиты в ОС выставлены правильно (можно открыть все файлы), что будет во время старта? PostgreSQL попытается открыть все файлы на запись? И что будет если лимиты не позволяют открыть все файлы? При старте PostgreSQL ругнется и не даст работать с БД? Не будет он открывать все файлы... зачем ему это? Файлов миллион может быть в тяжелых случаях. Файлы открываются только по мере обращения к ним PER PROCESS (Т.е. у каждого коннекта к базе свой набор открытых файлов). Что значит postgresql попытается? - Postgresql это большой вагон процессов... и у каждого свои файлы открыты. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2019, 17:35 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Ребят спасибо за отзывчивость. Давай те уточню по проблеме. Значит так, шифровальщик ел файл все файлы подряд, не смотря на расширение, что странно, обычно есть определенные , ворд , ексел, какие то dt и прочее. После получения дешифратора, даже винда поднялась, весь софт заработал, на первый взгляд все нормально. Но слон стартовать отказался. Каталог data на первый взгляд живой, но некоторые файлы шифровальщик не взял. Судя по набору файлов, это как раз те которые сидели в памяти на момент заражения, некоторые ехе, dll и _fsm. Глянул в них дизасемблером - нарушен заголовок и каша в структуре, но особая каша, отличается от каши , допустим, у другого зараженного файла который был расшифрован (после того как меня попросили посмотреть, сделал копию в зараженном состоянии ). Прочитал про восстановление из дампа, и еще пару статей, попробовал софтину Recovert for PostgereSQL. Подсовывал data вместо работающей у слона. Результат - служба была остановлена, т.к. никто к ней не обращается. Чувствую что базу поднять можно, просто не знаю как к ней подступится, не так уж крашнута, что бы не подняться. Знаний по слону сильно не хватает. Выручайте братцы, кто чем сможет ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 00:32 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
lr2, каталог Data почти 50 гб ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 00:38 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Уточню вопросы. Кстати, слон 9.4, изначально не сказал важную информацию. Итак , развернул кластер с нуля, и начал подсовывать в data\base каталоги по одному. Первый положил каталог 1, служба стартанула, при , pgAdmin вывалил эрор, с прямым указанием на следующий каталог, допустим 12135. Подсунул ему каталог который он просит, ребут службы, завелась, несмотря на присутствие в этих каталогах зараженных файлов. Видим служебную базу postgre c OID 12135. Поехали, подсовываю каталоги по очереди, после каждого ребут службы, ситуация не меняется, все так же видит только свою служебную базу. Начал подсовывать каталог global, когда заменил все скопом , служба стартовать отказалась , меняю по одному файлу, стартует, но по прежнему видит только свою служебную базу, однако, слон запросил пароль, и съел не тот который я указывал при инсталляции, а тот который был установлен горе-админом. В общем вопрос, где хранится схема БД которые вертятся под слоном, по любому где то то должно быть прописано равенство OID = basename? попробую покопать в этом направлении ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 10:17 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
andre_yktУточню вопросы. Кстати, слон 9.4, изначально не сказал важную информацию. Итак , развернул кластер с нуля, и начал подсовывать в data\base каталоги по одному. Первый положил каталог 1, служба стартанула, при , pgAdmin вывалил эрор, с прямым указанием на следующий каталог, допустим 12135. Подсунул ему каталог который он просит, ребут службы, завелась, несмотря на присутствие в этих каталогах зараженных файлов. Видим служебную базу postgre c OID 12135. Поехали, подсовываю каталоги по очереди, после каждого ребут службы, ситуация не меняется, все так же видит только свою служебную базу. Начал подсовывать каталог global, когда заменил все скопом , служба стартовать отказалась , меняю по одному файлу, стартует, но по прежнему видит только свою служебную базу, однако, слон запросил пароль, и съел не тот который я указывал при инсталляции, а тот который был установлен горе-админом. В общем вопрос, где хранится схема БД которые вертятся под слоном, по любому где то то должно быть прописано равенство OID = basename? попробую покопать в этом направлении global/1262 скорее всего OID pg_database я не помню чтобы менялся когда либо PS: вы так скорее всего нормально не оживите... там очень много чего кроме директории base еще надо иметь живым. Но направление по сути у вас конечно верное хотя и закопаетесь вы с этим надолго. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 11:54 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Maxim Boguk global/1262 скорее всего OID pg_database я не помню чтобы менялся когда либо PS: вы так скорее всего нормально не оживите... там очень много чего кроме директории base еще надо иметь живым. Но направление по сути у вас конечно верное хотя и закопаетесь вы с этим надолго. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru Блин, что то не такой директории, и файла такого нет. Хотя по идее он должен быть, тут вертелось 4 базы, из них две нужные ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 12:03 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Maxim Boguk, pg_filenode.map - это не оно ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 12:05 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
andre_yktMaxim Bogukglobal/1262 скорее всего OID pg_database я не помню чтобы менялся когда либо PS: вы так скорее всего нормально не оживите... там очень много чего кроме директории base еще надо иметь живым. Но направление по сути у вас конечно верное хотя и закопаетесь вы с этим надолго. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru Блин, что то не такой директории, и файла такого нет. Хотя по идее он должен быть, тут вертелось 4 базы, из них две нужные Попробуйте global/12142 (файл 12142 в директории global). Там все не просто с global (shared каталогом) -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 12:11 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
andre_yktMaxim Boguk, pg_filenode.map - это не оно ? + Вам 100% пригодится https://pgeoghegan.blogspot.com/2018/03/decoding-pgfilenodemapdata.html вот эта ссылка. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 12:14 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
Maxim Boguk, благодарю за линк. в общем обычным блокнотом открыл 12134 обнаружил там, значит баз было больше. @sweet @ut11 @mdut @hideoninja @Sweethome2 @sweethome2 @hrm @buh @sweetretail2 @reservedice @postgres @template1 @template0 12142 нет такого файла ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 12:17 |
|
Здравствуйте уважаемые, есть проблема , вирус-шифровальщик
|
|||
---|---|---|---|
#18+
andre_yktИтак , развернул кластер с нуля, и начал подсовывать в data\base каталоги по одному Вам необходимо запустить на копии целиком всего data и смотреть в лог базы: на чём именно отказывается стартовать. И прыгать оттуда. Собирать франкенштейна из кусков несвязанных между собой pgdata - идея нерабочая. Так вы в каком-то пригодном виде данные не получите даже если убедите грязным скальпелем базу запустится и решить что эти файлы её. Потому что нет корректных сведений о транзакционной видимости и вы можете увидеть то что давно удалено, то что должно было rollback одновременно и не увидеть то что должно быть с точки зрения приложения живо. Если детально знаете что где должно лежать и какое состояние является консистентным - то pg_filedump. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2019, 15:58 |
|
|
start [/forum/search_topic.php?author=kir2206&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 420ms |
total: | 582ms |
0 / 0 |