Защитили клиента от ransomware: 12 слоёв — кейс ITfresh
Луковица из 12 слоёв защиты от ransomware Защита луковицей: 12 слоёв до данных Данные 1. Обучение пользователей Phishing simulation 4× год 2. NGFW + IDS на периметре UserGate D200, Suricata 3. Email security gateway Kaspersky Secure Mail Gateway 4. EDR на каждой РМ Kaspersky Endpoint Detection 5. Application whitelisting AppLocker через GPO 6. Сегментация сети VLAN 5 зон, MikroTik CCR2004 7. MFA на всех аккаунтах Microsoft Authenticator 8. Принцип наим. привилегий JEA, LAPS, tier-модель 9. Patch management WSUS + Wazuh, SLA 7 дней 10. SIEM с алертами Wazuh + Elastic, 24/7 11. Immutable бэкапы 3-2-1 Veeam HSM + LTO-8 в сейф 12. Incident response план Runbook + квартальные учения Кейс ITfresh: производство 47 РМ. Атака детектирована на слое 4, не дошла до бэкапов
Луковица из 12 слоёв: каждый снимает часть рисков. На клиенте-производстве реальная атака была остановлена на четвёртом слое
Безопасность · 19 мин чтения · Семёнов Е.С., руководитель ITfresh

Защитили клиента от ransomware: 12 слоёв защиты на 47 РМ

Защитили клиента от ransomware: 12 слоёв защиты на 47 РМ

В марте 2026 года у нашего клиента — производства на 47 рабочих мест в Балашихе — случилась реальная атака шифровальщика. Бухгалтер открыл фишинговое письмо. Внутри сидел LokiBot, который тянул за собой основную нагрузку — ransomware Lynx. Атака остановилась на четвёртом слое защиты: EDR Kaspersky перехватил её раньше, чем та успела добраться до файлового сервера. Почему так вышло? Потому что за полгода до инцидента мы выстроили 12-слойную архитектуру защиты — шесть недель плотной работы. В этой статье — пошаговый разбор каждого слоя с реальными командами, скриптами и цифрами по стоимости.

Почему именно 12 слоёв и почему "луковица"

«Defense in depth», она же оборона в глубину — концепция совсем не новая. Римляне строили крепости именно так: каждая стена прикрывала следующую. В кибербезопасности 2026 года логика та же. Каждый слой берёт на себя часть атак, и чтобы пробить все 12 — атакующим не хватает либо времени, либо компетенций. Большинство ransomware-атак на МСБ — это автоматизированный массовый трафик, который ищет лёгкую добычу. По нашим наблюдениям: если у клиента настроено хотя бы 5 слоёв, с вероятностью 95% атакующий просто уходит к следующей, менее защищённой цели.

Люблю сравнивать это с медициной. Один антибиотик сепсис не вылечит — нужен и дренаж, и иммуноподдержка, и постоянный мониторинг всех систем сразу. Здесь ровно то же самое. Никакого «волшебного» инструмента, который закрывает всё разом, не существует. Нужна архитектура. Продуманная, слой за слоем.

Слой 1. Обучение пользователей

Этот пункт стоит первым — не случайно. По нашей внутренней статистике, 78% инцидентов начинаются одинаково: человек кликнул по фишингу, открыл подозрительное вложение или скачал заражённый файл. И никакой EDR тут не спасёт, если пользователь сам отключил защиту, потому что «служба безопасности банка» попросила. Техника без людей не работает.

Что мы делаем у клиента-производства:

Мы поставили себе конкретную метрику: доля пользователей, которые вводят пароль на фишинговой странице в ходе тренировочной кампании, должна быть ниже 5%. На старте у клиента-производства этот показатель был 31%. За 4 квартала мы опустили его до 6%. Это реальный прогресс — и он измерим.

Слой 2. NGFW и IDS на периметре

Старый Cisco ASA 5505 у клиента мы заменили на UserGate D200. UserGate — российский NGFW со встроенным IDS/IPS, deep packet inspection, антивирусом на периметре и URL-фильтрацией. Само устройство — 240 000 ₽, годовая лицензия — ещё 90 000 ₽. Параллельно поставили open-source Suricata на отдельном железе: она даёт «второе мнение» и пишет pcap-трафик для детального постфактум-анализа. Две независимые точки контроля — это лучше, чем одна.

# Базовая настройка Suricata на Ubuntu Server 24.04 LTS
sudo apt update && sudo apt install -y suricata

# Включаем правила Emerging Threats Open
sudo suricata-update list-sources
sudo suricata-update enable-source et/open
sudo suricata-update

# Настройка интерфейса (мониторинг через SPAN-порт MikroTik)
# В /etc/suricata/suricata.yaml:
af-packet:
  - interface: ens18
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes
    use-mmap: yes
    tpacket-v3: yes

# Включаем eve.json для пересылки в Wazuh
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - http
        - dns
        - tls
        - flow

sudo systemctl enable --now suricata

UserGate по умолчанию отбрасывает все входящие подключения. Открыты только три: 443 на reverse proxy для веб-сервиса, 25 на mail relay с проверкой SPF/DKIM/DMARC и VPN на pre-shared key плюс сертификат. Исходящий трафик — категориальная фильтрация по URL. Анонимайзеры, торрент-трекеры и известные C2-домены ransomware-семейств заблокированы. База IOC обновляется ежедневно из ФинЦЕРТа и open-source-фидов.

Слой 3. Email security gateway

Статистика простая: 80% ransomware-атак приходит через почту. Именно поэтому внутренний Exchange Server 2019 у клиента мы спрятали за Kaspersky Secure Mail Gateway 1.1 — отдельная виртуалка-релей, которая стоит перед основным почтовым сервером и пропускает через себя весь входящий поток. Что она делает с этим потоком?

Только за март 2026 года этот слой заблокировал 1247 фишинговых писем и 38 заражённых вложений. Клиент ничего из этого не видит — всё происходит в фоне, тихо. Именно так и должно работать.

Слой 4. EDR на каждом рабочем месте

EDR — это следующая ступень после классического антивируса. Обычный антивирус ловит известные сигнатуры. EDR смотрит на поведение: процесс вдруг начал массово шифровать файлы, запустился из временной папки или маскируется под svchost.exe — всё это триггеры. Мы работаем с Kaspersky EDR Optimum в связке с Kaspersky Endpoint Security 12.6.

Именно на этом слое в марте и остановилась та самая атака. Бухгалтер открыл письмо с фейковым актом сверки. Макрос в .doc-файле скачал LokiBot, а тот попытался мимикрировать под lsass.exe — стандартный приём для кражи учётных данных. Kaspersky EDR распознал паттерн «process injection into lsass» и автоматически среагировал:

  1. Принудительно завершили процесс word.exe — вместе со всеми дочерними процессами, которые он успел породить.
  2. Само вложение и временные файлы из кэша отправили в карантин — чтобы ничего не осталось доступным на диске.
  3. Рабочую станцию отрезали от сети. Разрешили только два направления трафика: серверы Kaspersky и подключение наших инженеров.
  4. Сразу ушёл алерт в SOC и в Telegram дежурному инженеру — задержки между обнаружением и реакцией не было.

От момента клика бухгалтера до полной изоляции станции прошло 3,7 секунды. Я приехал к клиенту через 25 минут после алерта. Провёл forensic-анализ, пересадил пользователя на чистую рабочую станцию из резерва, заблокировал его учётку и запустил смену паролей по всем критичным системам: банк-клиент, 1С, AD, почта. Весь сценарий потом разобрали на тренинге со всеми сотрудниками — живой кейс работает лучше любой теории.

Слой 5. Application whitelisting

На рабочих станциях офисных сотрудников через GPO с AppLocker мы запретили запуск исполняемых файлов из всех директорий, куда обычный пользователь может что-то записать: Downloads, Temp, AppData\Local\Temp, %USERPROFILE%. Запуск разрешён только из C:\Program Files, C:\Program Files (x86), C:\Windows\System32 и для файлов, подписанных доверенным сертификатом. Поверхность атаки сужается радикально.

# Создание GPO с AppLocker правилами через PowerShell
# На контроллере домена

# Готовим политику с дефолтными правилами для Windows + EXE/MSI/Script
$gpo = New-GPO -Name "AppLocker-Workstation-Strict" -Comment "ITfresh ransomware lockdown"

# Импорт XML-политики
$xml = @'
<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePathRule Id="..." Name="Programs Files" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions><FilePathCondition Path="%PROGRAMFILES%\*"/></Conditions>
    </FilePathRule>
    <FilePathRule Id="..." Name="Windows" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions><FilePathCondition Path="%WINDIR%\*"/></Conditions>
    </FilePathRule>
    <FilePathRule Id="..." Name="Block Temp" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions><FilePathCondition Path="%OSDRIVE%\Users\*\AppData\Local\Temp\*"/></Conditions>
    </FilePathRule>
  </RuleCollection>
</AppLockerPolicy>
'@
$xml | Out-File -FilePath C:\applocker-policy.xml -Encoding UTF8
Set-AppLockerPolicy -XmlPolicy C:\applocker-policy.xml

# Включаем сервис на машинах через тот же GPO
# Computer Configuration → Policies → Windows Settings → System Services → Application Identity → Automatic

New-GPLink -Name "AppLocker-Workstation-Strict" -Target "OU=Workstations,DC=corp,DC=client,DC=local"

Логика простая: даже если ransomware попал на рабочую станцию, запустить свой исполняемый файл ему негде — все «писаемые» директории в чёрном списке. Без запуска — нет шифрования.

Слой 6. Сегментация сети по VLAN

На MikroTik CCR2004 у клиента сеть разбита на 5 изолированных зон с межсетевым экраном между каждой из них:

Между зонами у нас прописаны очень конкретные правила — никакой «широкой» доступности. Рабочая станция разговаривает с сервером 1С только через порты 1540, 1541, 80 и 443. С файловым сервером — исключительно 445-й порт, и ни байтом больше. С контроллером домена — только LDAP и Kerberos. Принтеры живут в своём отдельном VLAN, куда пускаем лишь необходимые службы. Зачем такая детализация? Всё просто: если ransomware зашифрует одну рабочую станцию, у него не будет пути «доползти» до серверов — сеть его не пустит.

Слой 7. MFA на всех аккаунтах

Двухфакторная аутентификация через Microsoft Authenticator включена у всех 47 пользователей. Доменные учётки, корпоративная почта, RDP-доступы, VPN — второй фактор требуется везде без исключений. А вот для административных учёток — администраторов домена, Backup Operators, всех, кто имеет доступ к серверам резервного копирования, — мы пошли дальше. Там работает только FIDO2-токен YubiKey 5C. Никаких SMS, никаких обычных Authenticator-кодов. Аппаратный токен, и точка.

Развернуть MFA для всех 47 пользователей мы успели за 5 рабочих дней. День первый — закупка 8 ключей YubiKey для администраторов. Второй день ушёл на разворачивание Microsoft Entra ID Connect и настройку синхронизации с локальным AD. Следующие два дня мы посвятили групповой регистрации пользователей: организовали короткие утренние тренинги прямо перед началом рабочего дня, чтобы не выбивать людей из рабочего ритма. Пятый день — финальное тестирование и отладка.

Слой 8. Принцип наименьших привилегий

Никто из нас не сидит под учёткой Domain Admin постоянно. У меня и каждого инженера — по две учётные записи: обычная рабочая, без прав на серверах, и привилегированная с DA-префиксом, которую используют строго под конкретную задачу и сразу отзывают после. На стороне клиента это реализовано через Privileged Access Workstation — отдельный физический ноутбук, который стоит в офисе и используется исключительно для административных задач. Интернет напрямую к нему не подключён. Почта, веб-сёрфинг — на этой машине этого просто нет.

# Just Enough Administration (JEA) — даём админу только нужные команды
# На сервере, к которому нужно делегировать управление

# Создаём роль JEA для управления службами
$rolePath = "C:\Program Files\WindowsPowerShell\Modules\ServiceMgmt\RoleCapabilities"
New-Item -Path $rolePath -ItemType Directory -Force

$roleCapability = @{
    Path = "$rolePath\ServiceManagement.psrc"
    VisibleCmdlets = "Get-Service", @{
        Name = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = 'spooler','wuauserv' }
    }
}
New-PSRoleCapabilityFile @roleCapability

# Конфигурация сессии
New-PSSessionConfigurationFile -Path "C:\jea\service-mgmt.pssc" `
  -SessionType RestrictedRemoteServer `
  -RoleDefinitions @{ 'CORP\helpdesk' = @{ RoleCapabilities = 'ServiceManagement' } } `
  -RunAsVirtualAccount

Register-PSSessionConfiguration -Name ServiceMgmt `
  -Path "C:\jea\service-mgmt.pssc" -Force

# Теперь пользователь helpdesk может с обычной учётки рестартовать только spooler и wuauserv
# Через: Enter-PSSession -ComputerName SRV01 -ConfigurationName ServiceMgmt

Слой 9. Patch management

Патч-менеджмент построен на WSUS-сервере SRV-WSUS01, а Wazuh с лицензией отслеживает все пропущенные обновления. По SLA: критические патчи Microsoft — в течение 7 дней с момента выхода, остальные — раз в месяц, во второй вторник после Patch Tuesday. Каждый месяц клиент получает отчёт: какие хосты обновлены, какие ещё ждут своей очереди, есть ли несовместимости.

Сторонние приложения — отдельная история. Chrome, Adobe, Java, Zoom, 1C — всё это обновляется через PDQ Deploy, который еженедельно раскатывает апдейты по AD-группам компьютеров. Особо пристально мы следим за прошивками MikroTik, UserGate и HPE iLO. Про них многие забывают, а зря — «дыры» в прошивках находят регулярно, и через них злоумышленники заходят не хуже, чем через Windows.

Слой 10. SIEM и мониторинг 24/7

У клиента развёрнут полноценный SIEM-стек: Wazuh 4.10, Elasticsearch 8, Kibana. Всё вместе работает как единая система мониторинга безопасности (Security Information and Event Management). Что именно туда попадает?

Все алерты летят напрямую в наш дежурный Telegram-канал. Допустим, в 3:00 ночи кто-то пробует залогиниться в DA-учётку — я вижу это через 30 секунд после попытки. Запустился неподписанный процесс на сервере — та же история, сразу алерт. По критичным событиям инженеры дежурят круглосуточно в ротации, так что реакция не зависит от времени суток.

Слой 11. Immutable бэкапы по правилу 3-2-1

Если все предыдущие слои по какой-то причине не сработали — нас держит вот этот. У каждой критичной базы данных клиента три независимые копии. Первая — на основном Veeam-сервере прямо в офисе. Вторая — на физическом сервере ITfreshFTP в дата-центре МТС на Авиамоторной, там ReFS с дедупликацией. Третья — на ленте LTO-8 в банковском сейфе клиента. Ключевая деталь: immutable storage. Даже учётка Domain Admin не сможет удалить или изменить бэкап в течение 30 дней периода ретенции. Вот это и есть настоящая подушка безопасности.

# Veeam Hardened Repository — immutable бэкапы на Linux с XFS
# На отдельной железке Ubuntu Server 24.04, без AD, с уникальным root-паролем

# Создание пула с ретеншеном через chattr
sudo apt install -y veeam-iam xfsprogs
sudo mkfs.xfs -f -L vbr_repo /dev/sdb
sudo mkdir -p /mnt/vbr_repo
echo "LABEL=vbr_repo /mnt/vbr_repo xfs defaults,noatime 0 0" | sudo tee -a /etc/fstab
sudo mount -a

# Создание пользователя veeam_repo с нестандартным uid и без sudo-прав
sudo useradd -m -s /bin/bash -u 11001 veeam_repo
sudo chown veeam_repo:veeam_repo /mnt/vbr_repo

# Veeam B&R 12.1 на стороне сервера, добавляем repository:
# Backup Infrastructure → Backup Repositories → Add Repository → Direct attached storage → Linux
# Хост: 192.168.20.50, креды veeam_repo
# В мастере включаем "Make recent backups immutable for: 30 days"

# Veeam использует chattr +i на блобах после записи — даже root не может стереть в течение 30 дней
# Чтобы стереть — надо физический доступ к серверу + загрузка с liveCD

Раз в квартал — тестовое восстановление. Я беру случайный бэкап случайной виртуальной машины и разворачиваю в изолированную среду. Если что-то не поднялось — это сразу критичный инцидент, не «мелочь». За период с 2025 по 2026 год у нашего клиента-производства из 12 квартальных тестов прошли все 12. Вот эта цифра и позволяет мне нормально спать.

Слой 12. Incident response план и квартальные учения

В IT-кабинете клиента на столе лежит распечатанный Incident Response Runbook — 17 страниц, физическая бумага. Внутри: телефоны всех ответственных лиц, чёткая последовательность действий для каждого сценария — ransomware, утечка данных, кража ноутбука, пожар в серверной. Прописано, кто и что говорит партнёрам и сотрудникам. Описан процесс принятия решения: платить выкуп, не платить, обращаться в правоохранительные органы. Никаких импровизаций в момент паники.

Каждый квартал мы проводим тренировочные учения. Я объявляю условный «инцидент», и команда клиента — директор, юрист, бухгалтер, штатный админ — проходит сценарий по runbook от начала до конца. Засекаем время на каждом шаге, разбираем, где притормозили. После реальной атаки в марте 2026-го провели «горячий» ретроспективный разбор и добавили в runbook два пункта — выяснилось, что не было готового шаблона уведомления партнёрам о возможной утечке данных. Теперь есть.

Сколько это всё стоило клиенту

Сводные цифры за 6 недель внедрения и первый год эксплуатации:

Первый год: 1,87 млн ₽ за внедрение плюс 660 000 ₽ за ежемесячную поддержку — итого 2,53 млн ₽. Много? Сравните со средним выкупом у российских ransomware-групп в 2026 году: для МСБ это от 2 до 8 миллионов рублей только за расшифровку. И это без учёта простоя производства, репутационных потерь и штрафов по 152-ФЗ и 187-ФЗ. На нашей практике совокупные издержки от реальной атаки превышают сумму выкупа в 3–5 раз.

FAQ: что чаще всего спрашивают клиенты

Сколько стоит построить полную защиту от ransomware для офиса 30-50 РМ?

Для нашего клиента-производства с 47 рабочими местами полное внедрение всех 12 слоёв защиты заняло 6 недель. Стоимость работ — 720 000 ₽, лицензии и оборудование (Kaspersky EDR, Wazuh, immutable storage) — ещё 380 000 ₽. Ежемесячная поддержка по аутсорс-контракту — 55 000 ₽. Для сравнения: средний выкуп за расшифровку для МСБ в России в 2026 году стартует от 2 млн ₽. Разница ощутима.

Платить ли вымогателям, если уже зашифровали?

Никогда. И вот почему. Статистика жёсткая: только 65% компаний, заплативших выкуп, реально получают рабочий ключ дешифровки. Остальные остаются ни с чем — и без денег, и без данных. Но даже если ключ придёт — сам факт оплаты мгновенно переводит вас в категорию «платящих», а значит, вы становитесь приоритетной целью для следующей атаки. Плюс в России перевод денег криминальной группировке может быть квалифицирован как финансирование преступной деятельности — это уже другой уровень проблем. Восстановление из бэкапов — единственный путь, на котором я настаиваю всегда и без исключений.

Что важнее — антивирус или бэкап?

Если расставлять приоритеты — бэкап на первом месте. Антивирус и EDR работают как барьеры: снижают вероятность проникновения, но не дают стопроцентной гарантии. Атака всё равно может прорваться. А вот immutable бэкап с ежедневной проверкой — это уже не профилактика, это страховка. Даже при успешном взломе бизнес поднимается за 4–8 часов, а не за недели. Если бы выбор стоял жёстко: антивирус или бэкап — я бы взял бэкап, не раздумывая. На практике, конечно, нужны оба слоя: они не заменяют, а дополняют друг друга.

Как часто реально атакуют МСБ в России?

По данным Лаборатории Касперского за 2025 год, в России ежемесячно фиксируется около 4500 успешных атак шифровальщиков на компании сегмента МСБ. В 3,4 раза больше, чем в 2022-м. Цифра пугающая, но в новостях эти случаи почти не всплывают — большинство компаний просто платят выкуп и молчат, чтобы не светить репутацию. У нас в ITfresh за 2025 год было два таких инцидента, где мы оказались буквально последним рубежом между ransomware и данными клиента. Оба раза удержали.

Что делать прямо сейчас, если денег на полный комплекс нет?

Три шага — и сделайте их прямо сейчас, по приоритету. Первый: immutable бэкап на отдельный физический сервер вне домена, retention 30 дней. Один инженер настраивает за день. Второй: MFA для всех учёток с правами администратора — бесплатно через Microsoft Authenticator, никаких отговорок. Третий: запрет выполнения макросов в Office из интернета через GPO. Звучит скучно, но именно эти три вещи закрывают 70% типовых сценариев атаки шифровальщиков.

Итог

Ransomware — не абстрактная угроза из учебника. Каждая четвёртая компания МСБ в России сталкивается с ней в течение года. Один из четырёх — это уже статистика, а не страшилка. Наша 12-слойная защита для офиса на 47 рабочих мест обходится в 2–3 миллиона рублей в год. Много? Сравните с потерями в десятки миллионов при успешной атаке. Важный момент: каждый из 12 слоёв отсекает только часть угроз. Они работают только вместе, как единый механизм — вытащи один элемент, и вся конструкция слабеет. Если хотите выстроить такую же защиту у себя — приходите, у нас есть готовый плейбук внедрения на 6 недель.

Похожая задача в вашей компании?

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

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh

Похожие статьи

Подпишитесь на рассылку ITfresh

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

Письмо придёт в течение минутыНе нашли его во «Входящих» — загляните в папку «Спам» или «Промоакции» и нажмите «Не спам». Так все следующие выпуски будут приходить прямо в основную почту.
Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.