История одного шифровальщика: как локальные бэкапы подвели бизнес

К нам обратился клиент уже после случившегося инцидента.
Обычный рабочий день, сотрудники включили компьютеры — и почти сразу стало понятно, что что-то идет не так:
документы не открываются, базы недоступны, файлы получили странные расширения.

Диагноз подтвердился быстро — локальную сеть и сервера поразил шифровальщик.

У клиента есть свой системный администратор, но он не справился с задачей и со стороны клиента было принято решение — привлечь специалистов со стороны для аудита инцидента и настройки системы, позволяющей в дальнейшем избежать повторения подобных ситуаций.

Что произошло на самом деле

Расследование показало классический, но очень опасный сценарий:

• • Заражение произошло через один из рабочих ПК.
    Пользователь открыл ссылку в письме для скачивания, как было написано в письме, доп. соглашения по контракту с сервера контрагента. Ссылка была похожа на сайт контрагента (но только похожа!), файл был сценарием для выполнения вторжения. Злоумышленники получили доступ к ПК пользователя и стали собирать сведения о локальной сети и системе резервных копий, попросту стали сканировать локальные сетевые ресурсы, которые доступны данному пользователю.
  • С ПК пользователя был доступ к серверу, где хранились данные, почти ко всем доступным сетевым ресурсам с возможностью изменения данных. В 1С с доступом к конфигуратору. 
  • Для резервного копирования был настроен отдельный сервер, данные на него передавались по локальной сети, но с зараженного ПК доступа до этого сервера не было.
  • Злоумышленники использовали доступ к конфигуратору 1С для выполнения программ на сервере с уровнем доступа Администратор. Запуск программ через специальную конфигурацию 1С.
  • Таким образом злоумышленники получили доступ к серверу резервных копий, находящемуся в локальной сети и всем данным, размещенным на сервере.

В итоге при помощи программы шифрования были:

* Зашифрованы все рабочие файлы на компьютере пользователя и сервере;
* Стерты резервные копии на сервере бэкап;

Фактически — были уничтожены все данных и их копии!

Давайте рассмотрим вопрос, почему локальные бэкапы не спасли ситуацию

Локальный бэкап — не позволяет защитить данные, если:

• К нему есть доступ из той же сети, где хранятся данные;
• Нет раздельных прав на доступ к серверу резервного копирования и основным серверам;
• Нет дублирования резервных копий в защищенное хранилище с глубоким сроком хранения;
• Защищенное хранилище находится внутри локального контура сетевой инфраструктуры клиента.

Надо понимать, что шифровальщики бывают автоматические, когда шифровальщик «не знает», где данные, а где бэкапы — для него это просто файлы. А бывают, как в нашем случае, управляемые людьми (самый критичный для инфраструктуры случай).

С чем клиент пришёл к нам

• Данные утеряны, но повезло, что за неделю до событий приезжал программист и перед внесением изменений в конфигурацию 1С сделал копию баз на локальный компьютер одного из бухгалтеров, с которого работал.
• Полная остановка рабочих процессов. Договора, таблицы, данные юристов — все утеряно!
• Есть понимание, что риски повторной атаки очень велики.
• Отсутствие понимания, как выстроить защиту правильно и что вообще нужно сделать.

Задачу клиент сформировал так: «Сделайте так, чтобы это больше никогда не повторилось!»

---

Как мы помогли и что сделали

Мы не стали «латать» старую схему — мы полностью пересобрали инфраструктуру.

1. Убрали критичные данные из локальной сети

Рабочие данные и сервисы перенесли на удалённый сервер в дата-центр
Сервер полностью изолирован от сети с рабочими ПК
Доступ — только по защищённым каналам связи с шифрованием и обязательной авторизацией

Теперь заражённый компьютер физически не может добраться до серверных данных, но остается возможность перехвата пароля входа сервер или запуска заражения непосредственно на сервере.

От шифровальщиков почти не спасает антивирус, злоумышленники используют абсолютно легальные программы для шифрования, а сам процесс заражения происходит посредством социальной инженерии — пользователь сам запускает процесс заражения.

2. Организовали многоуровневое резервное копирование

Мы внедрили систему облачных резервных копий из нескольких уровней:

• Резервное копирование в облако непосредственно образа дисков сервера. С самого сервера доступа к этим копиям нет. Копии снимаются через отдельный физический сетевой интерфейс, который недоступен в пользовательском пространстве.
• Хранение версий резервных копий (версионирование). Можно откатиться «на вчера», «на прошлую неделю» и т.д. Глубина бэкапа задается индивидуально, но обычно не меньше двух недель.
• Файловые копии в защищенное хранилище.
  На сервер клиента ставится специализированное ПО, которое делает резервные копии на уровне файлов, кидает копию на промежуточный NAS (сетевое хранилище), а с этого хранилища копия забирается на другое хранилище, недоступное из сети серверов клиента и с доступом к хранящимся копиям»только для чтения». Удаление копий делается от пользователя отличного от пользователя создающего резервные копии по расписанию.
• Все эти действия бесполезны без постоянного контроля успешности резервного копирования через специализированный сервер Zabbix.

Даже если опять случится напасть вида:

— шифровальщик,
— ошибка сотрудника,
— сбой оборудования, приведший к потери данных

— данные можно восстановить из двух разных источников!

3. Разделили доступы и минимизировали риски

• Сотрудники работают «только со своими данными»;
• Нет избыточных прав (раньше главный бухгалтер имела доступ «везде», хотя он ей был операционно не нужен!;
• Убрали сервер с критичными данными из локальной сети;
• Полный контроль подключения к серверу извне. Создана возможность для сотрудников безопасно работать из дома и командировок без переноса данных на ноутбуки;

4. Навели порядок и объяснили клиенту, как это работает

Мы не просто «сделали и ушли», а:

• Показали, где теперь хранятся данные, как они защищаются, каким образом организован контроль доступа к серверу;
• Объяснили, как устроена система резервного копирования;
• Описали сценарии восстановления данных в случае проблем;
• Дали рекомендации, как не повторять ошибок и на что обратить внимание;
• Создали директору отдельного пользователя с доступом «везде» для контроля, но объяснили, что работать нужно под пользователем без «лишних» прав доступа;
• Научили технического специалиста клиента пользоваться системой резервного копирования и мониторинга.

---

Подведем итоги

✔ Работа клиента восстановлена
✔ Теперь данные защищены
✔ Проведены работы, позволяющие работать с данными локально и удаленно — безопасно
✔ Настроена система резервного копирования с двумя видами копий, позволяющая свести вероятность потери данных к нулю в пределах времени хранения копий
✔ Риски повторного шифрования данных или иных злонамеренных действий, приводящих к потери данных, сведены к минимуму. Возможна потеря данных за текущий день, но не более в пределах времени хранения резервных копий.
✔ Клиенту предложен вариант резервного копирования, который можно выполнять каждые 15 минут и таким образом свести потери данных к максимальному временному промежутку в  15 минут. Вариант требует дополнительных вложений и рассматривается клиентом как вероятный в будущем.

Этот кейс — наглядный пример того, что:

Локальные бэкапы ≠ безопасность
Удалённая инфраструктура + облачные копии + двухуровневое резервирование = реальная защита бизнеса

Если Вам нужен системный администратор, который не болеет, всегда на связи, имеет большой опыт работы — обращайтесь в A1-Support, вменяемые цены, есть возможность работы от компании на ОСНО (с НДС).

Полезные статьи: 

Как и где хранить пароли и почему нужна двухфакторная авторизация для доступа к серверу

Цифровой след компании. Чем грозит совпадение цифрового следа у нескольких компаний.