Whitelist-firewall в юрфирме на 35 РМ: как мы закрыли периметр и обошли 6 сценариев утечки

К нам в ITfresh обратилась юрфирма на 35 рабочих мест из ЦАО Москвы — после инцидента у соседнего по этажу клиента, где менеджер случайно установил «бухгалтерский плагин» из почты, и через сутки на закрытом форуме появилась база контрагентов. Партнёры в фирме сделали правильный вывод: дальше так нельзя. Задача — закрыть периметр настолько, чтобы случайно установленный софт физически не мог никуда пакет отправить. Я приехал на встречу с понятной мыслью: даём whitelist-firewall, дефолт — drop, всё остальное — по списку. Дальше — реальный отчёт, как мы это сделали за 11 рабочих дней, какие 6 сценариев обхода нашли в процессе пилота и как закрыли их все.

Зачем юрфирме именно whitelist, а не «обычный антивирус»

Стандартная корпоративная схема защиты — это «всё разрешено, кроме явно вредного». На периметре стоит роутер с фильтрацией по чёрным спискам, на машинах — антивирус с эвристиками, в почте — антиспам-шлюз. Эта модель проигрывает по двум направлениям. Первое — современные вредоносы научились маскироваться под легитимный TLS-трафик и выходить на уровень C2 через домены, которых нет ни в одной чёрной базе на момент атаки. Второе — у юрфирмы нет ни одного бизнес-сценария, в котором бы рабочий компьютер юриста должен был ходить на произвольный сервер в интернете. Все нужные ресурсы известны заранее: 1С-Облако, КонсультантПлюс, Гарант, банк-клиенты, корпоративная почта, портал суда, ЕФРСБ, ФССП. Список стабильный, изменения редкие.

Поэтому мы перевернули логику: запретить всё, разрешить — поштучно. Один из партнёров фирмы спросил на встрече: «А мы не превратим контору в спецслужбу?». Я ответил фразой, которую он потом цитировал коллегам: «У вас в сейфе не лежит инструкция, какие папки клиенты могут не показывать судье. Лежит правило — если документ важен, он в сейфе. Это и есть whitelist, просто для денег. Сетевой трафик не отличается».

Аудит: что вообще куда ходит до начала работ

Прежде чем что-то запрещать, я неделю слушаю. На периметре устанавливаю Suricata в IDS-режиме (без блокировок), параллельно ntopng на сервере Dell PowerEdge R350 с 32 ГБ RAM и сетевой картой Intel X710. Зеркалирую весь трафик с MikroTik CCR2004-1G-12S+2XS на этот сервер. Получаю телеметрию по двум осям: какой хост ходит куда и с какой частотой.

За семь календарных дней набралось интересное. Из 35 рабочих мест регулярных «хороших» назначений набралось 187 — это домены 1С-Облака, банк-клиентов Сбера и Альфа-банка, КонсультантПлюс, почтовый сервис на Я.360, Microsoft Update (для патчей Windows), несколько внутренних SaaS, голосовая SIP-телефония. Плюс — 41 «непонятный» назначения: телеметрия Adobe, какие-то китайские CDN от драйверов мониторов, и две машины систематически стучали на адрес в Нидерландах — это оказался pre-trial debugger одного юридического шаблонизатора, который вендор давно не выключил.

Самое интересное — две рабочие станции бухгалтерии полтора часа в день ходили на TikTok и Instagram. Это были даже не пользователи: какие-то браузерные плагины делали HTTP-запросы в фоне. Партнёры узнали и попросили заодно это перекрыть «без отдельного приказа».

Архитектура: два слоя whitelist на одном периметре

Я редко делаю фильтрацию в один уровень. По моему опыту, надёжный whitelist — это два слоя: L3 (по IP-адресу и порту) на роутере и L7 (по SNI и DNS-запросу) на следующем хопе. Без L7 любой клиент, который сам резолвит DNS и идёт на разрешённый IP по другому SNI, проскакивает.

Схема у клиента получилась такая. На периметре — MikroTik CCR2004 с двумя WAN-аплинками (МТС и Билайн) и LAN-сеткой 192.168.10.0/23, разделённой на VLAN: 10 для рабочих станций, 11 для серверов, 12 для гостевого Wi-Fi (полностью изолированный, у него отдельная политика). Дефолт-цепочка output и forward на роутере имеет default policy drop. Разрешения раскиданы по address-list-ам и interface-list-ам.

За маршрутизатором — Suricata 7.0 в режиме NFQ inline на сервере Dell. Через mark/route на MikroTik трафик из VLAN 10 заходит на интерфейс сервера, проходит через Suricata, возвращается обратно. Suricata проверяет SNI в TLS ClientHello и доменное имя в DNS-запросе. Если SNI не из списка — пакет дропается даже при «разрешённом» IP.

# MikroTik: базовая логика whitelist на forward
/ip firewall filter
add chain=forward connection-state=established,related action=accept comment="Already allowed"
add chain=forward src-address=192.168.10.0/23 dst-address-list=WL_BUSINESS \
    action=accept comment="L3 whitelist business"
add chain=forward src-address=192.168.10.0/23 dst-address-list=WL_INFRA \
    action=accept comment="L3 whitelist infra (DNS, NTP, updates)"
add chain=forward src-address=192.168.10.0/23 dst-address-list=WL_BANKING \
    in-interface-list=LAN action=accept comment="Banking subnets"
add chain=forward src-address=192.168.10.0/23 \
    action=log log-prefix="WL_DROP_" comment="Log first"
add chain=forward src-address=192.168.10.0/23 \
    action=drop comment="Default drop"

Address-list WL_BUSINESS наполняется автоматически. Раз в 15 минут на роутере отрабатывает скрипт, который резолвит список доменов через 1.1.1.1 и 77.88.8.8 и кладёт результаты с TTL 1 час. Это решает проблему с CDN, у которых IP плавают.

# Скрипт обновления WL_BUSINESS на MikroTik
:local domains {
    "online.sberbank.ru";
    "auth.alfabank.ru";
    "1cfresh.com";
    "online.consultant.ru";
    "garant.ru";
    "fssp.gov.ru";
    "fedresurs.ru";
    "kad.arbitr.ru";
    "mail.yandex.ru";
    "calendar.yandex.ru";
    "vc.cdek.ru"
}

/ip firewall address-list remove [find list=WL_BUSINESS dynamic=no]
:foreach d in=$domains do={
    :do {
        :local ips [:resolve $d server=77.88.8.8]
        /ip firewall address-list add list=WL_BUSINESS \
            address=$ips timeout=1h comment=$d
    } on-error={
        :log warning "WL resolve failed: $d"
    }
}

На стороне Suricata — отдельный набор правил под TLS SNI и DNS. Файл sni-whitelist.rules грузится через include в suricata.yaml:

# Разрешённые SNI явно — всё остальное alert+drop
alert tls $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"WL: SNI not in business list"; \
    tls.sni; \
    pcre:"/^(?!.*(sberbank\.ru|alfabank\.ru|1cfresh\.com|consultant\.ru| \
    garant\.ru|fssp\.gov\.ru|fedresurs\.ru|kad\.arbitr\.ru|yandex\.ru| \
    yandex\.net|microsoft\.com|windowsupdate\.com|mts\.ru|cdek\.ru)$).*/"; \
    flow:to_server; \
    sid:9000001; rev:1;)

# DNS-белый список — отбрасываем запросы на левые домены
alert dns $HOME_NET any -> any 53 ( \
    msg:"WL: DNS query outside whitelist"; \
    dns.query; \
    pcre:"/^(?!.*\.(sberbank\.ru|alfabank\.ru|1cfresh\.com|consultant\.ru)$).*/"; \
    sid:9000002; rev:1;)

Сценарий обхода 1: HTTPS по IP без SNI

На пилоте у нас неделю крутился Suricata в IDS-режиме. Я попросил админа клиента поставить себе на ноут «вредонос-симулятор» — простую утилиту, которая пытается пробить периметр шестью способами. Первый способ — пойти на разрешённый IP (например, на любой Yandex.Cloud) по 443 порту, но без SNI в ClientHello. Это классический трюк современных C2: «прячемся в инфраструктуре крупного провайдера».

Suricata такое ловит за счёт правила, которое отбрасывает любой TLS-трафик без SNI. Я поставил это правилом по умолчанию: нормальный браузер всегда шлёт SNI, отсутствие SNI — индикатор вредонос-маскировки. Дополнительно на MikroTik включил TCP-SYN-flood защиту и rate-limit на новые соединения с одной рабочей станции — больше 30 в секунду к одному /24 — алерт.

Сценарий обхода 2: DoH (DNS-over-HTTPS) на сторонний резолвер

Современные браузеры умеют ходить за DNS прямо в Cloudflare или Google по 443/HTTPS, минуя корпоративный резолвер. Это удобно дома, но в whitelist-инфраструктуре — катастрофа: если клиент сам резолвит, он узнает IP «левого» домена и пойдёт по разрешённому 443 порту куда угодно.

Мы закрыли DoH тремя слоями. Первый — на MikroTik через address-list-ы заблокировали все известные DoH-эндпоинты Cloudflare (1.1.1.1, 1.0.0.1), Google (8.8.8.8, 8.8.4.4), Quad9 и Mozilla (mozilla.cloudflare-dns.com). Второй — через GPO в домене всем браузерам Chrome, Edge и Firefox принудительно установили DnsOverHttpsMode = off и DnsOverHttpsTemplates = пусто. Третий — через Suricata блокируем любой TLS-трафик с known-DoH-SNI вне нашего белого списка резолверов.

# GPO: Chrome — отключить DoH принудительно
HKLM\Software\Policies\Google\Chrome
    DnsOverHttpsMode = "off"          (REG_SZ)
    DnsOverHttpsTemplates = ""        (REG_SZ)
    BuiltInDnsClientEnabled = 0       (REG_DWORD)

# GPO: Edge — то же самое
HKLM\Software\Policies\Microsoft\Edge
    DnsOverHttpsMode = "off"
    DnsOverHttpsTemplates = ""

# GPO: Firefox через policies.json
{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

Сценарий обхода 3: VLESS+Reality на российский VPS

Это сценарий «информированный сотрудник». Если у юриста есть знания и желание — он может купить за 200 рублей в месяц российский VPS, поднять там Xray с VLESS+Reality и ходить «через Yandex». Reality идеально мимикрирует под легитимный TLS-сессии Yandex или Google, и без машинного обучения такой трафик почти не отличить от настоящего.

Для нас это не теоретическая угроза. На пилоте за десять дней мы поймали два таких эпизода: один партнёр пробовал ходить на YouTube через свой личный VLESS-сервер, второй — оказался стажёр, который нашёл инструкцию в Telegram. Закрыли мы это так. Во-первых, на роутере зарезали соединения к non-mainstream российским хостинг-подсетям (Reg.Ru, Timeweb, FirstVDS, Aeza) — оставили только подсети 1С-Облака, Я.Облака и пары конкретных вендоров, у которых хостится корпоративный софт. Во-вторых, на каждой рабочей станции через GPO заблокировали запуск исполняемых файлов вне Program Files и Windows через AppLocker. Reality-клиент негде запустить — нет прав на установку.

# MikroTik: блокировка популярных хостинг-подсетей
/ip firewall address-list
add list=BLOCKED_HOSTING address=185.225.0.0/16 comment="Aeza ranges"
add list=BLOCKED_HOSTING address=89.108.64.0/18 comment="Reg.Ru"
add list=BLOCKED_HOSTING address=92.255.0.0/16 comment="FirstVDS"
add list=BLOCKED_HOSTING address=185.20.224.0/22 comment="Timeweb subset"

/ip firewall filter
add chain=forward src-address=192.168.10.0/23 \
    dst-address-list=BLOCKED_HOSTING action=drop \
    comment="No personal VPN VPSes"

Третий слой — AppLocker на рабочих станциях. Через GPO мы запретили запуск любых .exe, .ps1, .vbs, .msi из путей пользователя (C:\Users\, %TEMP%, %APPDATA%). Разрешены только подписанные сертификатами Microsoft, 1С, Adobe и банк-клиентов исполняемые файлы. Это прикрывает не только VLESS-клиенты, но и весь класс portable-утилит.

Сценарий обхода 4: WebRTC через Yandex Telemost и аналоги

Самый хитрый сценарий. WebRTC-сервисы вроде Yandex Telemost разрешены — людям надо проводить совещания, звонить нотариусам, общаться с клиентами. Но WebRTC использует DataChannel, через который технически можно гонять произвольные данные. Существуют утилиты вроде olcRTC, которые поднимают SOCKS5-прокси через WebRTC-туннель, маскируясь под совещание Telemost.

Этот сценарий мы разобрали с клиентом честно: его невозможно закрыть на 100% без отказа от видеосвязи. Что мы сделали. Первое — ограничили WebRTC только до конкретных доменов Telemost и Я.Видеозвонков. Второе — поставили на каждую рабочую станцию EDR-решение (Kaspersky EDR Optimum), которое мониторит запуск процессов и сетевую активность на уровне ОС. Любая утилита вроде ofcRTC, поднимающая локальный SOCKS-прокси, ловится за счёт наблюдения за листенерами на портах вне белого списка приложений.

# Suricata: алерт на любой UDP/TCP listener в подозрительных портах
alert tcp $HOME_NET 1024:65535 -> $HOME_NET any ( \
    msg:"Internal SOCKS proxy listener detected"; \
    flow:to_server,established; \
    content:"|05 01 00|"; \
    sid:9100001; rev:1;)

Сценарий обхода 5: Yandex Cloud Functions / API Gateway как туннель

Я.Облако предоставляет serverless-функции на бесплатном тарифе с миллионом вызовов в месяц. На этом можно построить proxy: клиент отправляет HTTPS-запрос на cloud-functions URL, функция перенаправляет на любой адрес и возвращает ответ. С точки зрения нашего фаервола — это легитимный трафик на legitimate yandex.net.

Закрыли мы это через хитрый трюк: в Suricata написали правило, которое отбрасывает HTTPS-запросы к Yandex Cloud по характерным URL-паттернам *.functions.yandexcloud.net и *.apigw.yandexcloud.net. Юристы такие домены не используют. Если что-то пойдёт не так — алерт + блок.

alert tls $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"WL: Yandex serverless tunnel attempt"; \
    tls.sni; \
    content:"functions.yandexcloud.net"; nocase; \
    sid:9100002; rev:1;)

alert tls $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"WL: Yandex API gateway tunnel attempt"; \
    tls.sni; \
    content:"apigw.yandexcloud.net"; nocase; \
    sid:9100003; rev:1;)

Сценарий обхода 6: Захват пользовательского устройства через смартфон

Самый частый и самый человеческий сценарий. Сотрудник вспоминает, что хотел отправить себе домой проект договора. Подключает USB-кабель, телефон становится сетевым адаптером (USB tethering), и трафик идёт мимо корпоративной сети. То же — Bluetooth-tethering или просто пересылка через мессенджер на личном телефоне.

Здесь техника бессильна, нужны политики. Мы ввели три уровня. Первый — через GPO запретили драйверы класса «Network Adapter» от Apple, Samsung, Huawei, Xiaomi на рабочих станциях. Второй — через Kaspersky EDR заблокировали MTP-режим телефонов, оставили только массовое-устройство (фотки и pdf). Третий — самое важное — добавили в трудовой договор пункт о запрете обработки клиентских данных на личных устройствах с дисциплинарной ответственностью. Без юридического слоя никакая техника не закрывает «ушёл с ноутбуком в обед».

# GPO: блокировка USB-tethering драйверов
Computer Configuration → Administrative Templates →
  System → Device Installation → Device Installation Restrictions

Prevent installation of devices using drivers that match these device setup classes:
    {6BDD1FC6-810F-11D0-BEC7-08002BE2092F}  - USB Network Adapter

Prevent installation of devices that match any of these device IDs:
    USB\Class_E0&SubClass_01&Prot_03   - Bluetooth tethering
    USB\Class_FF&SubClass_42&Prot_01   - Apple iPhone tethering
    USB\Class_02&SubClass_06           - CDC ECM tethering

Что в итоге, цифры и личные впечатления

На производство мы вышли через 11 рабочих дней. Первая неделя — пилот в IDS-режиме на двух машинах партнёров. Вторая — расширение на 10 рабочих мест бухгалтерии. Третья — миграция остальных 23 машин и переход в block-режим. За первый месяц после полной активации:

Заявок на разблокировку

Пришло 7 штук. Шесть — легитимные (новый сервис электронного документооборота, обновление 1С-плагина с другого CDN, региональный портал суда), обработали в среднем за 47 минут. Одна — заявка от менеджера, который хотел смотреть YouTube «для фоновой музыки», вежливо отказали.

Срабатываний Suricata

1 247 алертов за первый месяц. Из них 38 — реальные попытки исходящих соединений на нерасширенные домены (преимущественно браузерная телеметрия, обновления плагинов), один — действительно подозрительный: компьютер бухгалтера пробовал стучать на C2 после открытия PDF из почты от «налоговой инспекции». Файл оказался дроппером, антивирус его пропустил, а whitelist-firewall — нет. Это был тот самый момент, когда партнёры впервые сказали «понятно, за что мы платили».

Стоимость и срок окупаемости

Железо обошлось клиенту в 112 000 ₽ (MikroTik CCR2004 — 76 800 ₽, сервер Dell R350 — был в наличии, докупили 16 ГБ RAM и сетевую X710 за 35 200 ₽). Работа инженера — 22 часа на проектирование и настройку, 14 часов на пилот и сопровождение первой недели. По нашему тарифу — 108 000 ₽. Дальше клиент перешёл на сопровождение 12 000 ₽/мес (3 часа в среднем уходит на разбор алертов и расширение белого списка).

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

В чём суть whitelist-firewall и зачем он юрфирме?

Whitelist-firewall — это фаервол, который запрещает весь исходящий трафик кроме явно разрешённых адресов и доменов. Юристам он критичен, потому что внутри сети ходят персональные данные клиентов, банковские реквизиты, тексты сделок. Если случайно установленная программа начнёт сливать данные на левый сервер, обычный фаервол этого не заметит — а whitelist остановит на первом же пакете.

Не сломает ли это работу сотрудников?

При грамотной настройке — нет. Мы две недели собираем телеметрию реальных подключений, смотрим, куда ходят 1С, КонсультантПлюс, банк-клиенты, почта, корпоративные облака. Только после этого включаем block-режим. У клиента, о котором речь в статье, после старта пришло 4 запроса на разблокировку за первый месяц — все обработали за час.

Какое железо нужно для 35 рабочих мест?

Мы взяли MikroTik CCR2004-1G-12S+2XS (около 75 000 ₽) как пограничный маршрутизатор и сервер Dell PowerEdge R350 с Suricata + ntopng для глубокой инспекции и логов. Этого хватает с запасом до 200 РМ. Для 35 человек загрузка маршрутизатора в среднем 6-8% CPU.

Что делать с приложениями, которые ходят по динамическим IP вроде Telegram или Zoom?

Мы строим whitelist по доменам через DNS-резолвинг с регулярным обновлением списка IP. Telegram, Zoom, банк-клиенты, Microsoft Teams — это address-list-ы, которые автоматически перезаполняются раз в 15 минут скриптом на роутере. Для критичных сервисов (например, 1С-Облако) держим явный список IP-подсетей вендора.

Сколько стоит проект под ключ?

Для офиса на 35 РМ — 18-22 рабочих часа инженера на проектирование и настройку, плюс две недели сопровождения. По нашему тарифу — 95-120 тысяч рублей за разовое внедрение, дальше 12 000 ₽/мес на сопровождение. Железо — отдельно, в среднем 110 000 ₽ за роутер и сервер инспекции.

Итог

Whitelist-firewall — это не «крепость на границе», это смена парадигмы доверия в корпоративной сети. Сначала кажется, что вы строите бункер. Через месяц понимаете: рабочие станции стали быстрее (нет лишнего трафика), сетевые проблемы диагностируются быстрее (любая аномалия видна сразу), а у партнёров появилось то, что они называют «спокойствием по поводу ИТ». Для юрфирмы 35 РМ это окупилось в первый месяц одним-единственным пойманным дроппером.