Луковица из 12 слоёв: каждый снимает часть рисков. На клиенте-производстве реальная атака была остановлена на четвёртом слое

Безопасность 3 мая 2026 · 19 мин чтения · Семёнов Е.С., руководитель ITfresh

Защитили клиента от 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 не спасёт, если пользователь сам отключил защиту по просьбе «службы безопасности банка».

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

Раз в квартал — фишинговая кампания тренировочного характера. Я отправляю 47 пользователям имитацию письма «от Налоговой» или «от 1С» с подозрительным вложением. Через систему Phishing Simulator считаем, кто кликнул, кто ввёл логин в фейковую форму, кто запустил приложение. Результаты — обезличенные, с разбором на собрании.
Раз в полгода — очный тренинг 1.5 часа с разбором свежих кейсов и сценариев социальной инженерии. Я лично провожу для тех клиентов, у кого аутсорс-контракт.
Каждому новому сотруднику — обязательная вводная «Безопасность для не-айтишника» в первый день работы.
Памятки на стенах в коридорах: «Что делать, если открылось подозрительное окно» и «Как проверить отправителя письма».

Метрика успеха: процент пользователей, которые вводят пароль на фишинговой странице, должен быть менее 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 — отдельная виртуалка-релей перед почтовым сервером. Что она делает:

Антивирусная проверка вложений включая архивы до 5 уровней вложенности (ransomware часто прячут в .zip внутри .iso внутри .zip).
Sandbox-анализ всех исполняемых файлов и подозрительных макросов в Office-документах. Подозрительный файл уходит в детонационный бокс на 60 секунд, и решение принимается по поведенческим индикаторам.
SPF, DKIM, DMARC-проверка на каждое входящее письмо. Письмо без правильной аутентификации помечается флагом «possibly forged» в теме.
URL-перезапись (URL rewriting): все ссылки в письмах проксируются через Kaspersky CloudCheck, который проверяет страницу на момент клика, а не на момент получения письма (важно для time-bomb атак).
Блокировка вложений типа .exe, .bat, .ps1, .vbs, .iso, .lnk — даже в архивах.

За март 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» и автоматически:

Терминировал процесс word.exe и все его дочерние процессы.
Поместил вложение и его кэшированные временные файлы в карантин.
Изолировал рабочее место от сети (ограничение коммуникации только до серверов Kaspersky и наших инженеров).
Отправил алерт в наш 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 зон с фаерволлом между ними:

VLAN10 — офисные рабочие станции (192.168.10.0/24).
VLAN20 — серверы (192.168.20.0/24).
VLAN30 — гостевой Wi-Fi и принтеры (192.168.30.0/24).
VLAN40 — производственная сеть АСУ ТП (192.168.40.0/24, изолирована полностью).
VLAN50 — управление IT-инфраструктурой (192.168.50.0/24, доступ только с jump-сервера).

Между зонами — деталированные правила: рабочая станция может ходить на сервер 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). Что мы туда отправляем:

Логи Windows Security (вход, выход, неудачные попытки, операции с привилегиями) со всех серверов и рабочих станций.
Логи Sysmon с детальной телеметрией процессов и сетевых соединений.
Логи UserGate (NGFW), Suricata (IDS), MikroTik (фаервол).
Логи Kaspersky Security Center (детекты EDR).
Логи Veeam (успешность бэкапов).
Логи Active Directory (изменения групп безопасности, добавление пользователей в Domain Admins).

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

Слой 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 недель внедрения и за первый год эксплуатации:

Работы инженеров ITfresh: 720 000 ₽ (180 человеко-часов × 4000 ₽).
UserGate D200 + лицензия на год: 330 000 ₽.
Kaspersky EDR Optimum + KSMG на 47 пользователей и 8 серверов на год: 240 000 ₽.
YubiKey 5C × 8 шт: 24 000 ₽.
Wazuh + Elasticsearch — open source, сервер для них уже был.
Hardened Veeam Repository (отдельный сервер Dell R450 + 12× 16 TB SATA): 380 000 ₽.
Лента LTO-8 + ленточный библиотека Quantum Superloader (б/у): 180 000 ₽.
Аутсорс-поддержка ITfresh после внедрения: 55 000 ₽ в месяц.

Итого первый год: 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 ₽ в рамках аутсорс-контракта. Это меньше, чем средний выкуп за расшифровку (от 2 млн ₽ для МСБ в России в 2026).

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

Никогда. Во-первых, статистика говорит, что только 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-слойная луковица защиты — это страховка, которая стоит 2-3 миллиона рублей в год для офиса 47 РМ и спасает от потерь в десятки миллионов. Ключевая мысль: каждый из 12 слоёв снимает только часть атак. Работают они все вместе. Хотите построить такую же оборону у себя — приходите, у нас готовый плейбук на 6 недель внедрения.

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

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

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

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