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

К нам, в ITfresh, пришла юрфирма – 35 рабочих мест, прямо из центра Москвы. Не просто так, конечно. Они насмотрелись на соседей по этажу: там менеджер случайно кликнул на «бухгалтерский плагин» из письма, и уже через сутки чья-то база контрагентов всплыла на закрытом форуме. Ну, партнёры сразу смекнули: так продолжаться не может. Их задача была кристально ясна: закрыть IT-периметр настолько, чтобы даже если кто-то опять что-то случайно поставит, этот софт не смог бы передать ни единого пакета данных куда-либо. Я приехал на встречу с готовым решением: даём whitelist-фаервол. По умолчанию всё блокируем, разрешаем только то, что строго в списке. И вот, что получилось: дальше расскажу, как мы это провернули за 11 рабочих дней, какие шесть сценариев обхода нашли во время пилота и как закрыли каждый из них.

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

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

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

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

Прежде чем что-то запрещать, я всегда действую по принципу «семь раз отмерь». Неделю я просто слушаю сеть. Для этого на периметре я ставлю Suricata, но пока только в IDS-режиме — то есть никаких блокировок. Просто собираю данные. Параллельно на сервере Dell PowerEdge R350 (мы оснастили его 32 ГБ RAM и сетевой картой Intel X710) запускаю ntopng. Весь трафик с их 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, а вот его отсутствие — это уже явный индикатор какой-то вредоносной маскировки. Дополнительно, на MikroTik я включил защиту от TCP-SYN-flood и настроил rate-limit на новые соединения с одной рабочей станции. Если таких соединений больше 30 в секунду к одному /24, мы тут же получаем тревожный алерт.

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

Современные браузеры сейчас научились ходить за DNS прямо в Cloudflare или Google по 443/HTTPS, полностью минуя при этом наш корпоративный резолвер. Дома, конечно, это очень удобно. Но для нашей whitelist-инфраструктуры это просто настоящая катастрофа! Почему? Да потому что если клиент сам резолвит DNS, он легко узнает 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. Конечно, мы действовали незамедлительно. Сначала, прямо на роутере, мы просто «зарезали» все соединения к нон-мейнстрим российским хостинг-подсетям. Это такие сервисы, как 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-прокси, тут же будет обнаружена. EDR ведь следит за листенерами на портах, не входящих в наш белый список разрешённых приложений.

# 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-функции на бесплатном тарифе? Миллион вызовов в месяц — это впечатляет. И на этом, кстати, можно построить свой прокси: клиент отправляет HTTPS-запрос на URL cloud-функции, она перенаправляет его на любой нужный адрес и возвращает ответ. Для нашего фаервола это выглядит как абсолютно легитимный трафик, направленный на 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-режиме, развернутый на двух машинах у партнёров. Вторая — масштабирование на десять рабочих мест в бухгалтерии. Третья — миграция оставшихся 23 машин и полный переход в block-режим. И вот что мы увидели за первый месяц после того, как всё заработало по полной:

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

Сколько же запросов на разблокировку прилетело? Всего семь штук. Шесть из них были абсолютно легитимными: новый сервис электронного документооборота, обновление 1С-плагина с другого CDN, региональный портал суда. Мы обработали их в среднем за 47 минут. А вот одна заявка пришла от менеджера, который хотел смотреть YouTube «для фоновой музыки». Ну, ему мы, конечно, вежливо отказали.

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

За первый месяц мы зафиксировали 1247 алертов. Из них 38 оказались реальными попытками исходящих соединений на домены, которых пока не было в нашем белом списке. Это была в основном браузерная телеметрия или обновления плагинов. Но один случай действительно заставил насторожиться: компьютер бухгалтера попытался установить соединение с C2 сразу после того, как был открыт PDF-файл из письма. Письмо якобы пришло от «налоговой инспекции». Оказалось, файл был дроппером, и антивирус, к сожалению, его пропустил. А наш whitelist-firewall — нет! Именно в тот момент партнёры впервые сказали: «Ну вот теперь понятно, за что мы платили».

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

Давайте поговорим о затратах. Железо обошлось клиенту в 112 000 рублей. Из этой суммы MikroTik CCR2004 стоил 76 800 ₽. Сервер Dell R350 у них уже был, так что нам оставалось докупить 16 ГБ оперативной памяти и сетевую 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 сотрудниками, маршрутизатор едва напрягается: загрузка CPU держится на смешных 6-8%.

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

Как мы строим whitelist? Всё начинается с доменов и DNS-резолвинга. Мы не просто прописываем адреса, а постоянно их обновляем. Возьмем, к примеру, Telegram, Zoom, банк-клиенты или Microsoft Teams. Для них мы создаем динамические address-list'ы, которые специальный скрипт на роутере сам перезаполняет каждые 15 минут. А вот когда речь идет о чем-то по-настоящему критичном, например, 1С-Облаке, мы предпочитаем другой путь. Тут у нас всегда явный, фиксированный список IP-подсетей, полученный прямо от вендора. Никаких сюрпризов!

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

Запускаем офис на 35 рабочих мест? Это, как правило, 18-22 часа работы нашего инженера на проектирование и настройку, плюс две недели плотного сопровождения. По нашему прайсу, одно такое внедрение обойдется в 95-120 тысяч рублей. А потом что? Обычно наши клиенты переходят на ежемесячное сопровождение за 12 000 ₽. И не забывайте про 'железо'! Маршрутизатор и сервер инспекции оплачиваются отдельно — это еще примерно 110 000 ₽. Но это единоразовые инвестиции.

Итог

Что такое Whitelist-firewall? Забудьте про «крепость на границе»! Это нечто большее, это полный переворот в том, как вы доверяете своей корпоративной сети. Да, поначалу может показаться, будто вы строите непробиваемый бункер. Но проходит месяц, и что вы видите? Рабочие станции реально «летают», потому что нет этого вечного лишнего трафика. Диагностика сетевых проблем? Мгновенная! Ведь любая аномалия сразу бросается в глаза. А ваши партнеры? Они вздыхают с облегчением, говорят: «Мы наконец-то спокойны за вашу ИТ-инфраструктуру». У нас был случай: одна юрфирма на 35 человек. Решение окупилось в первый же месяц — просто потому, что мы поймали всего одного-единственного дроппера.