Коли захисний пристрій стає входом

Наприкінці вересня 2026 року вийшло два повідомлення, які читаються як одна історія: пристрої, що мали охороняти периметр, стали дорогою всередину. Ці історії окремі, джерела їх не пов'язують.

Перша про криптобіржу Bitget. За BleepingComputer, 24 вересня 2026 року зловмисник, як встановила Mandiant, отримав привілейований доступ до двох сторонніх захисних пристроїв (security appliances). Він скористався zero-day, тобто вразливістю, для якої ще не було патча. На одному з пристроїв розмістив вебшел, невеликий скрипт для віддаленого керування, і звідти дістався сервера, що обслуговує гаманці, де розгорнув шкідливі пакети. Викрадено близько $387,5 млн. У Bitget заявили, що причина в zero-day у сторонніх продуктах безпеки, про це пише й The Hacker News. Вендора пристроїв не названо, тому гадати ми не будемо.

Кілька деталей важливі для практики. SlowMist, друга компанія, яка розслідувала інцидент, знайшла в журналах найраніші ознаки шкідливої активності ще за 31 серпня, задовго до крадіжки. За її даними, зловмисник виконав команду, що прочитала змінну середовища з паролем до бази даних, а схожу активність прихованого скрипта бачили ще на двох вузлах, 23 і 25 вересня. А за The Hacker News, 25 вересня він зайшов на платформу керування одним із пристроїв під ідентичністю внутрішнього співробітника. Гроші вивели з гарячих і теплих гаманців (тих, що підключені до мережі й працюють з виплатами).

Друга історія про Citrix NetScaler. 27 вересня 2026 року Citrix опублікувала бюлетень про вісім вразливостей у NetScaler ADC (пристрій, що розподіляє трафік до застосунків) і NetScaler Gateway (шлюз віддаленого доступу, зокрема VPN). Дві з них, CVE-2026-88771 і CVE-2026-88772, SecurityWeek описує як zero-day, обидві мають оцінку 9,5 за шкалою CVSS. Перша дає віддалене виконання коду без автентифікації, зокрема й на типових налаштуваннях; друга зачіпає пристрої з увімкненим DTLS, а це типове налаштування віртуальних VPN-серверів. У бюлетені CISA сказано, що зловмисники активно експлуатують їх у світі, а обидві вразливості додано до каталогу відомих експлуатованих вразливостей (KEV). Федеральним агенціям США дали строк до 30 вересня 2026 року. CISA також радила, якщо можливо, перевірити ознаки компрометації ще до встановлення патча.

Це не збіг, а закономірність

За VulnCheck, у 2025 році 28,96% вразливостей з їхнього каталогу KEV почали експлуатувати в день публікації CVE або раніше. Роком раніше було 23,6%. CVE це публічний ідентифікатор вразливості. Тобто часто патча ще нема, а атака вже йде. Дослідники застерігають: не кожна вразливість, яку атакують у день публікації CVE, є zero-day. Але для захисників результат той самий: часу на спокійне планування може не бути.

Серед цілей експлуатації найчастіше трапляються саме периметрові пристрої: firewall, VPN, proxy. VulnCheck пояснює це так: вони доступні з інтернету й нерідко стають трампліном у корпоративну мережу. За 2025 рік VulnCheck виявив 884 вразливості, за якими вперше побачив ознаки експлуатації, а каталог CISA поповнився на 245 записів, тож орієнтуватися лише на нього небезпечно.

З практики додамо, чому периметр такий привабливий. Він доступний ззовні, тож фішинговий лист не потрібен. Зазвичай це «чорна скринька» з прошивкою вендора, як правило, без агента захисту. Через нього проходять облікові дані користувачів, а маршрут досередини вже прокладено. І патч там часто означає перезапуск, тому його відкладають на «зручне вікно».

Звідси висновок без драматизму. Периметровий пристрій такий самий актив, як сервер: він має вразливості, облікові записи, журнали й власника. Тільки його звикли вважати захистом, а не поверхнею атаки. Коли читаєте новину про чужий інцидент, перше питання не «хто винен», а «чи є в нас такий пристрій і хто його патчить». Нижче сім кроків, які допомагають відповісти на це заздалегідь. Але почнемо з того, без чого вони не працюють.

Як провести інвентаризацію периметра

Це практика, а не вимога стандарту. Не починайте з порожньої таблиці. Візьміть два незалежні джерела й порівняйте. Перше: що ви знаєте самі. Це список мережевої команди, договори підтримки, закупівлі, резервні копії конфігурацій, CMDB (база облікових одиниць ІТ), якщо вона є. Друге: що видно ззовні. Це сканування власних публічних діапазонів IP-адрес, DNS-записи, сертифікати. Усе, що є в другому списку й немає в першому, і є ваші забуті пристрої.

Де їх зазвичай знаходять:

• старий VPN-шлюз, який лишився після міграції на новий, але досі відповідає з інтернету;

• пристрій у віддаленому офісі чи філії, який ставили «на місці» й не внесли до жодного списку;

• обладнання, яке встановив і підтримує підрядник, а ваша команда ніколи не заходила в його налаштування;

• тестовий стенд: копія бойової конфігурації з реальними обліковими даними, виставлена назовні «на тиждень» і забута.

Тестові стенди небезпечні подвійно: за ними ніхто не стежить, а паролі й ключі в них часто ті самі, що в бойовому середовищі.

Що записати в реєстр: модель і версію програмного забезпечення, власника, адресу керування, строк підтримки, чи ввімкнено MFA, куди йдуть журнали, дату останньої перевірки. Хто відповідає: власник реєстру в команді інформаційної безпеки, дані постачає мережева команда. Як перевірити: візьміть будь-які п'ять публічних IP-адрес компанії й знайдіть кожну в реєстрі з власником. Якщо хоча б одна не знайшлась, інвентаризація не завершена. Повний збір повторюйте щокварталу, а звіряння зовнішнього скану з реєстром робіть щомісяця.

Перші три кроки: бачити, керувати, чути

Крок перший. Реєстр периметрових пристроїв. Запишіть кожен firewall, VPN-шлюз, балансувальник і проксі: модель, версію, власника, адресу керування, строк підтримки. Без реєстру про вразливий NetScaler ви дізнаєтесь з новин, а не з власного списку, і не будете певні, чи він у вас узагалі є. Хто відповідає: команда інформаційної безпеки, дані дає мережева. Як перевірити: на новину про нову вразливість ви відповідаєте «є у нас чи ні» за годину, а не за день.

Крок другий. Окремий канал керування з MFA. MFA це багатофакторна автентифікація, другий фактор поза паролем. Адміністрування пристроїв не повинне бути доступне з того самого інтернету, який вони охороняють. Потрібна окрема мережа керування, вхід через захищений вузол і MFA для кожного адміністратора. Якщо облікові дані співробітника відкривають платформу керування, як це описано у випадку Bitget, другий фактор стає останнім бар'єром. Хто відповідає: мережева команда налаштовує, інформаційна безпека затверджує. Як перевірити: спробуйте відкрити сторінку керування з інтернету. Вона не повинна відкритися. Перегляньте список адміністраторів: у кожного є MFA, а спільних облікових записів немає.

Крок третій. Журнали з пристроїв у моніторинг. На такі пристрої зазвичай не ставлять EDR (endpoint detection and response, агент, що стежить за підозрілою поведінкою на сервері чи ноутбуці), тому самі вони про злам не повідомлять. Збирайте журнали в центральну систему моніторингу й налаштуйте сигнали на зміну конфігурації, нові облікові записи, незвичні входи та невідомі файли. Питання не в тому, чи журнали є. Питання, хто й коли їх читає. У Bitget перші сліди були в журналах за кілька тижнів до крадіжки. Хто відповідає: команда моніторингу (SOC) або, якщо її нема, виділена людина з ІБ. Як перевірити: внесіть тестову зміну, наприклад нового адміністратора, і подивіться, чи спрацював сигнал і за який час.

Решта чотири: час, межі, секрети, гроші

Крок четвертий. Строк на патчі для периметра в годинах. Для звичайних серверів ще можливі тижні, для периметра з відомою експлуатацією вже ні: Citrix оприлюднила бюлетень 27 вересня, а агенціям США дали строк до 30 вересня. Запишіть у політиці конкретну кількість годин для критичних вразливостей периметра, які вже експлуатують, і визначте, хто має право вимкнути сервіс, якщо патча ще нема. Орієнтир пріоритету: чи є вразливість у каталозі KEV. Але патч це не кінець роботи. Пристрій могли зламати до виходу виправлення, тому разом із патчем перевірте ознаки компрометації, як і радила CISA, і змініть облікові дані та ключі, що були на пристрої. Хто відповідає: власник пристрою виконує, керівник ІБ має право ухвалити рішення про вимкнення. Як перевірити: проведіть навчання на уявній вразливості й заміряйте, за скільки годин рішення ухвалено й застосовано.

Крок п'ятий. Сегментація між периметром і критичними системами. Припустіть, що пристрій зламано, і запитайте, що він бачить. З периметра не повинно бути прямого маршруту до баз даних, платіжних серверів і гаманців. У Bitget, за Mandiant, зловмисник перейшов з пристроїв на сервер гаманців. Дозволений трафік між зонами описуйте явно, решту закривайте. Тоді зламаний пристрій дає зловмиснику одну кімнату, а не весь будинок. Хто відповідає: мережева архітектура разом з ІБ. Як перевірити: з тестового вузла в зоні периметра спробуйте дістатися баз даних і платіжних серверів. Усе, що відповіло без явного правила, є знахідкою.

Крок шостий. Секрети не в змінних середовища. Змінну бачить кожен процес і кожен, хто потрапив на сервер. За SlowMist, пароль до бази даних прочитали саме так. Тримайте паролі й ключі в сховищі секретів, видавайте тимчасові, обмежуйте доступ окремо для кожного сервісу, змінюйте після будь-якої підозри. Хто відповідає: команди розробки й адміністрування, правила задає ІБ. Як перевірити: пошукайте паролі в конфігураціях, сценаріях розгортання й змінних середовища. Кожну знахідку перенесіть у сховище й змініть пароль, бо старий міг побачити хтось сторонній.

Крок сьомий. Подвійний контроль на великі фінансові операції. Якщо зловмисник дійшов до платіжної системи, останній бар'єр це процес. Операції вище порогу мають підтверджувати друга людина або незалежна система, а нові адреси отримувачів і зміна лімітів проходять окрему перевірку. Ми не стверджуємо, що це зупинило б Bitget: як там влаштовано гаманці, публічно не описано. Хто відповідає: фінансовий директор або керівник операцій, технічно реалізує ІТ. Як перевірити: проведіть тест, у якому одна людина з повними правами намагається сама провести операцію вище порогу. Система має зупинити її й повідомити.

Сценарій для red team: «периметр уже зламано»

Red team (команда, що імітує реальних атакувальників) може починати не з пошуку вразливості, а з припущення: на периметровому пристрої сторонній уже є. Далі перевіряють, чи він дотягнеться до мережі керування, чи знайде секрети, чи дійде до критичних систем і платіжних процесів. І головне, чи хтось це помітить і за який час. Такий сценарій перевіряє кроки з другого по сьомий разом, а не окремі налаштування. Це корисно, бо показує реальний шлях атаки, а не перелік окремих недоліків. Про формат читайте на сторінці Red Team Assessment.

Ось умовний приклад, не опис реального проєкту. Команда отримує доступ до VPN-шлюзу так, ніби вразливість уже використали. Вона дивиться, що видно звідти: маршрут до мережі керування, облікові дані адміністраторів на пристрої, інші зони. Потім шукає секрети на сусідніх серверах і підбирається до систем, де зберігаються гроші чи дані. На кожному етапі фіксують, чи спрацював моніторинг, хто отримав сигнал і що з ним зробив.

Що отримує компанія: карту шляху від периметра до найцінніших систем, виміряні час виявлення й час реакції, перелік перепон, які спрацювали, і тих, що ні. А також пріоритети: що виправити першим, щоб цей шлях перерізати. Такий результат зручніше показати керівництву, ніж список окремих вразливостей.

Пентест (тест на проникнення) доповнює його з іншого боку: шукає вразливості й помилки конфігурації самого периметра, див. тест на проникнення. А огляд захищеності системної інфраструктури допомагає навести лад у налаштуваннях, ролях і журналах пристроїв.

Для фінансових установ: TIBER-EU і DORA

Фінустанови ЄС можуть розглянути TIBER-EU, формат тестування на основі реальних загроз. За описом Європейського центрального банку, це європейська рамка для етичного red teaming на основі розвідки загроз. Тест імітує тактики реальних атакувальників і проходить на діючих системах. Про нього знає лише вузьке коло співробітників, щоб побачити, як організація реагує насправді. ЄЦБ також зазначає, що рамку оновили відповідно до вимог DORA (закону ЄС про цифрову операційну стійкість фінансового сектору) щодо тестування на проникнення на основі загроз, і що вона може допомогти ці вимоги виконати.

Номерів статей ми не наводимо й не оцінюємо, чи підпадає конкретна установа під обов'язкове тестування: це залежить від наглядового органу. Практична думка інша. Сценарій «периметр уже зламано» добре лягає в логіку таких тестів: це шлях від входу до критичної функції, а не окремий пункт чекліста. Реєстр, журнали й відпрацьована реакція стануть у пригоді, чи проходитимете ви офіційний тест, чи ні.

Типові помилки

• Реєстр склали раз і більше не оновлювали. Через пів року в ньому немає половини нових пристроїв.

• Інвентаризацію ведуть тільки за списком мережевої команди й не звіряють із зовнішнім сканом.

• Журнали збирають, але сигналів немає, або вони приходять на пошту, яку ніхто не читає.

• Патч поставили й вважають справу закритою, не перевіривши ознаки компрометації та не змінивши облікові дані.

• Строк патча записано як «якнайшвидше», без годин і без особи, яка може вимкнути сервіс.

• Тестовий стенд лишається доступним ззовні з бойовими паролями.

З чого почати

З реєстру: решта кроків без нього будуються навмання. Якщо хочете звірити свій периметр із цим списком, поговоримо про ваш кейс.

Часті запитання

З чого почати, якщо ресурсів мало?

З інвентаризації й керування. Реєстр і закритий від інтернету вхід в адміністрування з MFA не потребують нових продуктів, лише часу й домовленостей. Далі додайте відправлення журналів і чітке правило про строки патчів.

Чи достатньо вчасно ставити патчі?

Ні. Патч закриває вразливість, але не виганяє зловмисника, який уже встиг зайти. У випадку Bitget найраніші сліди в журналах датовано 31 серпня, а крадіжка сталася наприкінці вересня. Тому поруч із патчем потрібні перевірка ознак компрометації, моніторинг журналів і зміна облікових даних.

Чи можна поставити EDR на firewall або VPN-шлюз?

Зазвичай ні: вендори, як правило, не дозволяють встановлювати сторонні агенти на такі пристрої. Це практичне спостереження, а не правило без винятків, тож уточніть у свого постачальника. Відсутність агента компенсуйте журналами, контролем змін конфігурації, окремим каналом керування та індикаторами компрометації, які публікує вендор.

Чим red team для периметра відрізняється від пентесту?

Пентест шукає вразливості й помилки конфігурації та дає перелік знахідок. Red team імітує зловмисника з конкретною метою й перевіряє весь шлях, зокрема те, чи помітила команда захисту його дії. Сценарій «периметр уже зламано» належить до другого типу.

Чи обов'язковий TIBER-EU?

Це залежить від наглядового органу й країни. ЄЦБ заохочує органи влади впроваджувати цю рамку, а участь установи визначає її регулятор. Якщо ви фінансова установа в ЄС, уточніть вимоги у свого наглядового органу.