glass4217
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Всем добрый день, тут довольно часто появляются вопросы по поводу того как защитить свои бэкапы от возможного заражения вирусами шифровальщиками.
Я опишу тот механизм который мы используем для резервного копирования баз данных 1с.
Собственно сам механизм резервного копирования мы подробно разбирать не будем не та тема форума))), будем смотреть на механизм работы самого зловреда.
В большинстве своем шифровальщики действуют достаточно прямолинейно, но в тот же момент это дает максимальный урон.
Некоторые форумчане высказывали свою мысль что шифрование начинается с системного диска, включая рабочий стол и другие каталоги профиля жертвы а затем переходит к следующему по списку диску по схеме "A:"-"Z:", назовем их группой A
Другие считают что зловред начинает с обратного конца, то есть с последнего тома до первого по схеме "Z:"-"A:", назовем их группой Z
Вы все правы, есть и те и другие зловреды обитают но у каждого своя цель.
Вирусы шифровальщики из группы A действуют по принципу максимально скоростного блокирования документации расположенной на рабочем столе или иных папках профиля пользователя(тем самым выдавая себя), попутно возможен вариант с блокировкой ОС с красивой заставкой и требованием выкупа (чаще всего встречается в домашнем сегменте).
Вирусы из группы Z действуют немного по другому, в первую очередь создается несколько способов запуска самого себя и укоренение в системе будь то планировщик задач, автозагрузка, подмена ярлыков или просто подмена Shell. Затем начинает поиск доступных дисков начиная с конца алфавита, найдя такой диск и получив к нему доступ начинает свое черное дело, при этом контролируя нагрузку на процессор и оперативную память, дабы не вызвать "лагов" и "тормозов", тем самым скрывая свое присутствие.
В дальнейшем закончим с одним Диском, будь то сетевой или локальный зловред переходит к следующему и продолжает до тех пор пока не доберется до системного диска (причем некоторые не гнушаются проверить A: и B: диски), там уже закончив со своей задачей, только в этот момент привлекает внимание пользователя зашифрованными файлами.
Теперь собственно к защите бэкапов.
Не столь важно, какая у вас версия и тип 1С(старая новая, локальна или на MsSQL), тут в принципе суть одна везде, нужно сформировать файл бэкапа и сунуть его в такое место куда зловред не доберется.
Собственно как мы сделали у себя, у нас 1С на MsSQL...
Не будем вдаваться в подробности резервного копирования на MsSQL, но MsSQL умеет работать с внешними приложениями в данном случае мы использовали CMD, собственно в задачу резервного копирования первым пунктом мы добавляем команду подключить сетевой диск - (Z: ), после выполнения бэкапа, и проведения проверки на целостность, отключаем сетевой диск.
Один нюанс конечно есть, чтобы MsSQL начал работать с CMD ему надо "рассказать" что он умеет так. В планах обслуживания создаем новую задачу, а в ней добавляем инструкцию T-SQL
в который записываем:
Код: EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
|
сохраняем и исполняем... все мускул прокачался
затем в плане бэкапа собственно опять же добавляем инструкцию T-SQL и выставляем ее как выполняемую прямо перед самим бэкапом
Код: GO
EXEC xp_cmdshell 'net use z: \\192.168.1.6\data2 password /user:Domen\BackUpUser';
|
Доступ из сети к каталогу data2 должен быть тооолько у пользователя BackUpUser для пущей паранойи.
после выполнения бэкапа
Код: EXEC xp_cmdshell 'net use z: /delete';
|
Собственно те кто пользуются локальной версией 1С также вполне могут использовать подобный способ, есть конечно свои нюансы но вовремя исполненный бат-файл или бат-файл с примерно таким
содержимым перед началом резервного копирования:
Код: net use z: \\192.168.1.6\data2 password /user:Domen\BackUpUser
|
и Бат-файл с примерно таким содержимым после завершения копирования
Код:
Опять же все описанное здесь является только моим мнением и не претендует на звание авторитарной, я опирался на свой опыт по борьбе с вирусами шифровальщиками и опыт попыток обезопасить резервные копии от посягательств.
|
Всего записей: 29 | Зарегистр. 10-04-2010 | Отправлено: 02:51 22-02-2017 | Исправлено: glass4217, 04:37 22-02-2017 |
|
