Проблема вирусов-шифровальщиков затрагивает уже не только отдельно взятые персональные компьютеры, но доходит до уровня дата-центров. Для атак на инфраструктуру компаний применяются, например, Locky, TeslaCrypt и CryptoLocker. Зачастую вирусы используют уязвимости веб-браузеров или их плагинов, а также непредусмотрительно открытые вложения сообщений электронной почты. Проникнув в инфраструктуру, программа-вымогатель начинает быстрое распространение и шифрование данных.
Важной составляющей стратегии защиты данных всегда было наличие резервных копий, из которых можно выполнить восстановление. Рассмотрим же несколько рекомендаций от моего коллеги Rick Vanover относительно того, как как уберечь СХД резервных копий от шифровальщиков (вне зависимости от того, используете вы решения Veeam или других производителей). Итак, добро пожаловать под кат.
1. Используйте отдельную учетную запись для доступа к хранилищу резервных копий
Эта общечеловеческая рекомендация особенно актуальна в эпоху троянов-шифровальщиков.
- Резонно использовать для доступа к хранилищу бэкапов специально выделенные для этого учетные записи.
- Следует избегать назначения прав доступа к хранилищу всевозможным пользователям, за исключением тех, кому они необходимы для выполнения резервного копирования.
- И, конечно, не стоит повсеместно использовать учетку доменного админа.
Встречаются варианты, когда инфраструктура Veeam не включена в домен (как правило, в небольших организациях) или входит в домен, организованный специально для работы инструментов резервного копирования и защиты данных (в более крупных средах). В любом случае важно уделить внимание аутентификации и тщательному разграничению рабочей среды и инфраструктуры резервного копирования.
2. Имейте резервные копии, хранящиеся offline (без подключения к инфраструктуре)
Весьма действенный способ обезопасить себя от проникновения трояна-шифровальщика – сохранять резервные копии offline (то есть вне работающей инфраструктуры). Например, если вы используете решение Veeam, то можно рассмотреть следующие опции:
| Где хранить данные | Пояснение |
|---|---|
| Магнитная лента | Всегда offline (если только не в процессе чтения-записи). |
| Реплика ВМ | Обычно выключена; в большинстве случаев будет задействована в среде с аутентификацией, отдельной от продакшена (например, хосты vSphere и Hyper-V в разных доменах). |
| Аппаратные снимки производственных СХД | Можно использовать для восстановления; обычно задействуются в среде с аутентификацией, отдельной от продакшена. |
| Бэкапы в Cloud Connect | Не подключаются непосредственно к инфраструктуре резервного копирования; задействуют иной механизм аутентификации. |
| Сменные носители (например, внешний жесткий диск) | Всегда offline (если только не в процессе чтения-записи). |
Если вы используете выделенную СХД только для хранения резервных копий, то обычно такое хранилище используется только во время окна резервного копирования (скажем, только ночью). В этом случае отдельным простым способом перевода резервной копии в оффлайн будет настройка расписания автоматического выключения/включения СХД на период времени, когда оно не требуется.
3. Используйте для хранения бэкапов СХД с разными файловыми системами
Предупредить распространение шифровальщиков можно, используя разные файловые протоколы. Например, если держать репозиторий на Linux, то в этом случае при резервном копировании и восстановлении с помощью Veeam будет использоваться аутентификация Linux, а файловая система может быть как ext3, так и ext4 (или другая). Таким образом можно дополнительно защитить свои резервные копии. Вот несколько примеров систем хранения резервных копий с таким подходом:
- СХД Data Domain со встроенной дедупликацией и использованием DDBoost (рекомендованный метод) или с монтированием NFS в случае, если DDBoost не используется
- СХД Hewlett Packard Enterprise (HPE) StoreOnce со встроенной дедупликацией и использованием Catalyst
- ExaGrid со встроенной дедупликацией и использованием Veeam agent
При указанных вариантах доступ к СХД со стороны процессов Veeam будет происходить в рамках специфического контекста безопасности (security context).
4. По возможности создавайте аппаратные снимки СХД резервных копий
Аппаратные снимки являются, так сказать, «полу-оффлайновым» способом сохранения данных в случае работы с основной СХД. Если же есть возможность создания аппаратных снимков и для СХД резервного копирования, то вполне резонно задействовать ее для предотвращения атак шифровальщиков.
5. Применяйте правило «3-2-1-1»
Как вы помните, есть правило «3-2-1», которое предписывает хранить 3 резервных копии как минимум на носителях двух типов, и одну из этих копий держать на резервной площадке (а не в месте расположения производственной инфраструктуры).
Это простое правило поможет вам практически в любой аварийной ситуации, при которой потребуется восстановить данные, и при этом оно не требует применения какой-либо специфической технологии. В эпоху шифровальщиков будет разумным добавить еще одну единичку к этому правилу, подразумевая, что один из носителей должен храниться offline. Приведенные выше опции (см. пункт 2) помогут вам с выбором носителя и способа хранения, что, в свою очередь, укрепит вашу инфраструктуру в противостоянии шифровальщикам.
6. Контролируйте работу оборудования и ПО
Одна из угроз, которые несут с собой шифровальщики — это потенциальная возможность распространения на другие системы. Поэтому важно контролировать работу оборудования, процессов и приложений с целью выявления подозрительной активности. Так, Veeam ONE 9.5 предлагает вашему вниманию новое встроенное оповещение Possible ransomware activity (вероятная активность шифровальщика). Оно срабатывает, если замечена повышенная активность в использовании ЦПУ и рост количества операций записи на диск.
7. Задействуйте задания переноса резервных копий Backup Copy Job
Для того, чтобы получить точку восстановления, хранящуюся на удаленной СХД и имеющую свою политику хранения (отличную от той, что задана в настройках бэкапа), удобно использовать задание переноса резервных копий Backup Copy Job. Это задание берет данные из репозитория резервных копий и на их основе создает точки восстановления на удаленной СХД. Так, например, если вы добавили еще одну СХД к инфраструктуре резервного копирования (допустим, Linux), то можно создать соответствующий репозиторий и затем настроить задание переноса для работы с ним.
В заключение можно сказать, что существует немало методов борьбы с троянами-«шифровальщиками», позволяющих сохранить ваши бэкапы в целости, и в этом посте была перечислена лишь их часть. Если же у вас есть личный опыт или конструктивные идеи на этот счет, милости простим в комментарии.
Что еще почитать и посмотреть
Статья на Хабре о правиле 3-2-1 для резервного копирования:
> Часть 1
> Часть 2
> Вебинар об интеграции Veeam и HPE StoreOnce (на русском языке)
> Статья базы знаний Veeam об интеграции с EMC Data Domain (на англ. языке)
Комментарии (47)
navion
16.01.2017 17:02Veeam Enterprise Manager ведь не будет работать без ввода сервера в домен?
Tomas_Torquemada
16.01.2017 17:23А что ему помешает?
navion
16.01.2017 17:28Доменную аутентификацию так просто не прикрутить.
Tomas_Torquemada
16.01.2017 17:29Вопрос был будет он работать без домена или нет.
Ответ — будет.
Что там у вас за сложности с доменной аутентификацией — непонятно.navion
17.01.2017 13:33Сложность в желании закрыть доступ к серверу администраторам домена, но оставив портал самообслуживания.
Tomas_Torquemada
17.01.2017 17:03Доменные администраторы в администраторы Veeam Enterprise Manager попадают через группу локальных администраторов сервера, если у вас как-то ещё им права не выдаются на администрирование всех серверов подряд.
Включить кого надо с необходимыми ролями в настройках Veeam Enterprise Manager.
Не забыть кого-то Portal Administrator'ом сделать.
а BUILTIN\Administrators в настройках Veeam Enterprise Manager выкинуть совсем.
Тогда у членов группы BUILTIN\Administrators на сам сервер доступ останется — RDP и прочее — но именно в Veeam административные права отсохнут.navion
17.01.2017 20:57Администратору домена не составит труда повысить права на доменной машине.
Tomas_Torquemada
17.01.2017 21:08Читайте внимательнее.
на сам сервер доступ останется но именно в Veeam административные права отсохнут.
Ничего повышать на машине ему и не нужно.
Но если уж у вас так всё плохо в разделении полномочий с доменными админами или просто паранойя запредельная — то проблема не техническая.
mikkisse
16.01.2017 17:29Для доменной аутентификации нужно включать в домен, да. Но ведь работать то без нее будет.
datacompboy
16.01.2017 20:29Бакапы должны быть append-only. Тогда их нельзя будет уничтожить шифрованием.
maniacscientist
16.01.2017 21:40Это не поможет против вируса на той машине, к которой подключены носители с бекапом. Ну, если только не написать специальную файловую систему с водкой и охранницами
datacompboy
17.01.2017 00:25Носители типа CD-R. Туда мультисессией можно заменять, при желании, но все предыдущие сессии тоже доступны, вместе с их данными.
poznawatel
17.01.2017 13:00Это был бы идеал. Но в данный момент, при текущем уровне беспечности абсолютного большинства пользователей — недостижимый.
Как пример — год назад я искал флешки с аппаратным выключателем записи. В Томске не оказалось, пришлось через Интернет заказывать и ждать!datacompboy
17.01.2017 13:05хм. а можно пример флешки где аппапратный свич — аппаратный, а не програмный на уровне дров? (именно такие я видел исключительно, блин)
poznawatel
17.01.2017 15:02Я долго искал — выбрал Qumo ИНЬ и ЯНь.
Кстати, на Яндекс Маркете среди россыпей ма это единственная марка с аппаратным микриком.
electronus
17.01.2017 19:06Он везде аппаратный. Работает на уровне контроллера.
Иногда этот свич программный, но тоже работает на уровне контроллера
Пластиковый свич на SD карте — тоже работает на уровне контроллера, и обойти его программно с хоста невозможноdatacompboy
17.01.2017 19:14Да, но есть и программный: http://www.bertold.org/sdtool/
во-2х, поскольку это как с флопиками, надо «закрыть» датчик, то где гарантия что когда ты втыкаешь в чей-то ридер там уже не закорочено/заклеено, чтобы игнорировать шторку защиты?
Я бы предпочел, чтоб он отключал write enable ножку внутри самого чипа карты памяти…electronus
17.01.2017 20:25Мое уточнение заключается в том, что программно снять аппаратную блокировку невозмножно
Просто — носить карту со своим ридером
WE на флеш-чипе отключать нельзя. Контроллер делает housekeeping, даже если хост ничего не пишет. Проверял лично — usb флешки при играх с WE самого чипа моментально окукливаются до подъема их утилитами.
WE силами контроллера — достаточно надежная вещь.
electronus
17.01.2017 19:08Аппаратный свич поможет при путешествиях по чужим хостам, но не поможет если сам заразился…
pansa
17.01.2017 01:50— Бэкап сервер должен сам вытягивать файлы с резервируемых машин.
— Бэкап сервер не доступен по сети со стороны резервируемых машин.
— вылизанный годами rsync позволяет создавать снимки бэкапируемых каталогов, место будут занимать только изменившиеся файлы.
— даже виндовые машины можно бэкапить, на винде можно запустить ssh, а rsync умеет работать через него.
— скрипт — в крон/systemd.timer
Всё.malbaron
17.01.2017 01:55-1Вот как раз такой широкоизвестный и не особо защищенный инструмент как rsync — запросто может быть шифровальщиками «накрыт»
pansa
17.01.2017 02:51Во-первых, не настолько широко, чтобы шифровальщики его использовали.
Во-вторых, каким образом они его используют? Доступа с резервируемых машин к бэкап серверу не должно быть ни на уровне сети (фильтрация портов, dmz), ни на уровне «приложения» (ключи аутентификации, закладки, и тп).
Поэтому, или уже расшифруйте ваше «запросто накрыт», может мы чего не знаем, или не говорите впустую.
kvazimoda24
17.01.2017 15:36А можно с этого места поподробнее? Просто, не могу понять, как можно запороть бэкап порчей rsync'а на стороне системы, которую бэкапят. У меня получаются варианты, что процесс бэкапа рушится и выдаётся предупреждение админу, либо идёт замена всех файлов, но в этом случае всегда можно взять предыдущую купию файлов.
Единственный вариант, как порушить бэкап, так это заразить систему, которая хранит бэкапы, но предыдущий комментатор это учёл и указал, что "Бэкап сервер не доступен по сети со стороны резервируемых машин."
vviz
17.01.2017 15:36Согласен на все 100%. Немного дополню из продакшена:
Бсервер на Linux.
На источниках данных шаринг правами RO.
bash скрипт, монтирует шаринги, забирает данные rsync на основе различия размера и времени модификации.
12 (4+4+3+1) внешних USB 3.0 дисков с luks.
Доступ к Бсервер только у админов по ssh-sftp/ключи.
После создания суточного бэкапа сервер выключается, будится биосом в нужный момент бэкапа.
Админ по потребности будит сервер через wol
teecat
17.01.2017 11:03+1Как я понимаю вариантов воздействия шифровальщика на систему резервного копирования два:
— автоматически заменяются рабочие копии файлов на зашифрованные
— используя дыру в системе бекапа шифровальщик внедряется в систему резервного копирования и портит там все напрямую.
Второй вариант возможен (один пример известен), но честно говоря маловероятен. Для его парирования нужно использовать две разных системы резервирования, а также периодически контролировать состояние бекапов.
Гораздо более вероятен первый вариант. Пройдемся по предлагаемым мерам защиты
— Имейте резервные копии, хранящиеся offline (без подключения к инфраструктуре). Если состояние резервных копий не контролируется, то хоть на луне хранить — испорченные копии попадут и в оффлайн
— Используйте для хранения бэкапов СХД с разными файловыми системами. Если система резервного копирования работает автоматически, то какая разница шифровальщику на какую ФС попадут испорченные данные?
— По возможности создавайте аппаратные снимки СХД резервных копий. Не понимаю, как это может помочь в предотвращении атак шифровальщиков
WERR0NI
17.01.2017 13:00Пришла в голову такая мысль, а ведь большинство из этих вирусов шифруют файлы определенного типа, кто-то ориентировал вирус на фото, тобиш на рядового пользователя больше, кто-то на файлы бухгалтерии, бэкапы и так далее…
Довольно не плохо защищать файлы простым удалением расширения в имени файла, что бы вирус пропускал файл при поиске…AlexBin
17.01.2017 17:03Этот метод будет годен ровно до тех пор, пока не станет популярным. То бишь он уже не годен.
navion
17.01.2017 19:43Вроде бы на Ignite была занятная сессия от Полы Янушкевич по уменьшению вреда от малвари. Одним из советов было создание зацикленного симлинка в профиле, чтобы шифровальщик застрял на нём.
AlexBin
17.01.2017 21:18И этот метод будет годен ровно до тех пор, пока не станет популярным. То бишь он уже не годен.
navion
18.01.2017 10:52Это догадка или есть анализ зловреда с обходом подобных трюков?
AlexBin
18.01.2017 12:30Ну вот сами подумайте. Способ годный, и начинает набирать популярность. Будучи автором зловреда в такой ситуации, вы бы сами не сделали обход этого метода? Технически то это возможно.
navion
18.01.2017 14:04Он может иметь популярность у айтишников (которые не являются ЦА шифровальшиков), а обычные люди такой ерундой не занимаются. Плюс низкая культура разработки у авторов зловредов не позволяет отвлекаться на малополезные рюшечки.
AlexBin
20.01.2017 08:28Вы говорите о вирусе, основная ЦА которого — обычные пользователи, а решение предлагаете, нацеленное на айтишников. Определитесь.
Мы можем надеяться на низкую культуру авторов разработки конкретно этих зловредов. Но есть зловреды с весьма впечатляющей культурой. Этим авторам технически ничто не мешает писать шифровальщики.
Рюшечки остаются рюшечками, пока они не влияют на доход. Если зацикленную симлинку начнут по умолчанию создавать во всяких пиратских сборках винды (как один из твиков, например, в свое время это было отключение автозапуска на флешках), то оно перестанет быть рюшечкой, и даже автор с низкой культурой разработки позаботиться о фиксе.
elanc
Вот бреда ради: а если ввести понятие допустимого объема изменения при автоматическом обновлении, а в случае превышения данного порога требовать подтверждение? Перед «заливкой» новой версии файла сравнивать N сегментов в старой и новой версиях, если количество схожих сегментов превысило Y, то заменяем старую версию новой, в противном случае требовать подтверждения. Защита от дураков простая, как камень на палке.
elanc
Прочитал свой комментарий и почему-то про Adinf вспомнил… Аж прослезился… Как же давно это было…
YaakovTooth
… единственный антивирус, который я использовал. И то, не для защиты, а потому что нравился безумно крутой способ работы и потрясающая скорость. Эх, досовские времена.
quverty
Помню, сам не только вспомнил прослезился но даже пришлось написать простенький аналог adinf, так как нужной функциональности в других не нашёл, а надо было срочно что-то делать с непонятно почему гибнущими файлами и дисками.
Areso
Заголовок утренних газет от 17 января: «Новый криптовымогатель, авторы которого вдохновились комментарием российского хакера elanc с известного сообщества криптоанархистов и анархоразработчиков Habrahabr, шифрует несколько случайных кусков файла, общим объемом до 5%, дабы обойти поведенческие защиты известных антивирусов».
Demon_i
Я вот одного не понимаю — почему это не использует ни один антивирус? Почему так сложно отследить вызов стандартных библиотек шифрования и выдавать предупреждения? Касперыч просит дофига денег, но НИЧЕГО абсолютно не гарантирует. Бизнес по-русски.
pansa
Очень легко сфолсить, например. Вы просто не представляете количество фидбека, которое можно огрести за блок казалось бы абсолютно неадекватного поведения ПО.
Как их ловить — все постоянно думают, уверен, и в каспере тоже. Кто найдет серебряную пулю, тот получит очень много бонусов во всех смыслах.
Только не бывать этому, боюсь. :(