Луковица из 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 РМ

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

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

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

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

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

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

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

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

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

Я заменил старый Cisco ASA 5505 у клиента на новенький UserGate D200. UserGate — это наш, российский NGFW (Next-Generation Firewall), в котором уже есть всё необходимое: встроенный 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-семейств (база обновляется ежедневно из ФинЦЕРТа и open-source IOC-фидов).

Слой 3. Email security gateway

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

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

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

EDR (Endpoint Detection and Response) — это как бы следующая ступень в эволюции антивирусов. Если обычный антивирус ловит известные сигнатуры, то 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, почта). А полный simулированный сценарий мы потом подробно разобрали на следующем тренинге со всеми сотрудниками.

Слой 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. С контроллером домена (DC) — только LDAP/Kerberos. Принтеры вообще в отдельном VLAN, и к ним мы пускаем только нужные службы. В чём смысл? Даже если ransomware зашифрует одну рабочую станцию, он не сможет дальше "ползти" по сети к серверам.

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

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

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

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

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

# 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. Про эти штуки часто забывают, а ведь в них регулярно находят "дыры", которые могут стать лазейкой для злоумышленников.

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

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

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

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

Если вдруг все 10 предыдущих слоёв почему-то не сработали — нас спасает вот этот, наш последний барьер. У клиента есть три копии каждой критичной базы данных: одна хранится на основном Veeam-сервере прямо в офисе, вторая — на физическом сервере ITfreshFTP в дата-центре МТС на Авиамоторной (там у нас ReFS с deduplication), а третья — на ленте 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 ₽ за сами работы, плюс 380 000 ₽ за лицензии и оборудование (включая Kaspersky EDR, Wazuh, immutable storage). Ежемесячная поддержка обходится в 55 000 ₽ по нашему аутсорс-контракту. Как видите, это куда меньше, чем средний выкуп за расшифровку, который для МСБ в России в 2026 году начинается от 2 млн ₽.

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

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

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

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

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

По данным Лаборатории Касперского за 2025 год, в России ежемесячно фиксируется около 4500 успешных атак шифровальщиков на компании сегмента МСБ. Это, между прочим, в 3.4 раза больше, чем в 2022 году! Большинство таких случаев, к сожалению, не попадает в новости, потому что компании предпочитают платить выкуп и молчать. У нас в ITfresh за 2025 год было два таких инцидента, где мы оказались единственным препятствием на пути ransomware к данным клиента.

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

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

Итог

Ransomware — это не какая-то мифическая угроза, это статистический риск, который, к сожалению, реализуется у 1 из 4 компаний МСБ в России в течение года. И наша 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 подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.