Як ми доводимо, що двері зачинені, до go-live.
Перед go-live ми доводимо, що двері зачинені: атакуємо ваш справжній origin з машини поза мережею, якій firewall ніколи не довіряв, і бачимо те, що бачить незнайомець. Зачинені двері відповідають connection refused, а не сторінкою входу.
У цій статті 7 розділів
- Перед будь-яким go-live і після будь-якої зміни на edge ми ставимо одне запитання: що насправді бачить незнайомець в інтернеті? Відповідаємо на нього з машини в іншому нашому дата-центрі, на вихідній адресі, якій наш власний firewall ніколи не казали довіряти.
- Ми знаходимо справжній origin так, як це зробив би зловмисник (зазвичай він витікає через власний поштовий DNS домену), прив’язуємо кожен інструмент до голого origin замість CDN і проганяємо повну батарею заново.
- Ми скануємо всі 65 535 портів з цієї точки поза мережею, щоб могти ствердно сказати, що закрито. Надійне виправлення замикає origin на опубліковані діапазони CDN, за підтримки справжнього WAF рівня 7 і спільних списків блокування.
- Потім ми не беремо виправлення на віру. Ми знову атакуємо голий origin ззовні, і зачинені двері відповідають connection refused, а не сторінкою входу. Це доказ, а не обіцянка.
Найпоширеніший спосіб завершити роботу з hardening такий: хтось змінює налаштування, оновлює сторінку, бачить те, що очікував, і йде далі. Це «залатати і сподіватися». Воно доводить симптом, на який ви дивилися; воно нічого не доводить про двері. Далі йде метод, який натомість виконують наші інженери, перед будь-яким go-live і після будь-якої зміни на edge. У нього одне головне правило: кожна перевірка виконується ззовні, з точки, яка не отримує жодної особливої довіри, бо єдине запитання, яке має значення, це до чого насправді може дістатися незнайомець в інтернеті. Першу половину цього ви могли б запустити проти власного сайту сьогодні ввечері. Причина доручити це нам полягає в тому, хто виконує всю батарею і звідки.
Єдине запитання, яке має значення: що насправді бачить незнайомець?
Ми запускаємо сканування з виділеної машини в іншому нашому дата-центрі, з вихідної IP, якій наш власний firewall ніколи не казали довіряти. Вона не має запису в списку дозволених, винятку чи поблажки. Вона бачить рівно те, що бачить інтернет.
Це працює, лише якщо точка спостереження справжня і поза вашим периметром довіри, і саме тому це машина в іншому нашому власному дата-центрі, на нашій власній AS, а не орендований сканер. З тієї самої причини володіння мережею взагалі має значення. Більше про це в дописі вам не належить ваша мережа.
З цієї точки три речі перестають бути твердженнями і стають вимірюваннями. Чи справді ваш CDN стоїть перед вашим origin. Чи закриті порти, які ви вважаєте закритими. І, після виправлення, чи справді зачинені двері, які ви щойно зачинили. Решта допису про те, як ми читаємо кожне з них.
Знайдіть справжній origin так, як це зробив би зловмисник
Origin зазвичай витікає через власний поштовий DNS домену, бо запис SPF, який дозволяє вашу пошту, називає той самий хост, що її надсилає. Щойно справжній origin відомий, ви прив’язуєте ім’я хоста прямо до нього, щоб кожен інструмент бив у голий origin замість CDN, і проганяєте проти нього повну батарею заново.
# the origin usually leaks in the domain's own mail DNS
scanner$ dig +short TXT origin.example # the SPF record often names the sending host
scanner$ dig +short MX origin.example
# pin the hostname straight to the origin so nothing touches the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/
# now re-run the full battery against the naked origin, not the edge
scanner$ <scan battery> --target <origin-ip>Думка, яку це доводить, проста. Якщо origin відповідає на прив’язане сканування так само, як публічне ім’я хоста, віддаючи ті самі сторінки, ту саму форму входу, то CDN і WAF перед ним обходять. Кожен запит, який зловмисник хоче надіслати, може пройти повз них.
Проскануйте кожен порт, потім скажіть, що закрито
З точки поза мережею ми скануємо всі 65 535 портів.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>Сканування всієї поверхні не є простим «так/ні» для кожного порту. Що відповідає і як, дає відбиток машини. Три ознаки повторюються.
a mismatched TLS cert on a production subnet -> a forgotten host, fingerprinted
an absurdly low firewall hit-count -> traffic isn't flowing the way you think
a DNS server answering REFUSED -> good: you are not an open resolverFirewall не є WAF
Перебір паролів входу невидимий на рівнях 3/4, тож захист живе на edge, на рівні 7.
Обмежуйте частоту на edge, там, де відбуваються входи.
Рахуйте невдалі входи на кожне джерело на рівні HTTP, єдиному місці, де вони видимі, і блокуйте джерело, яке перетинає межу. Firewall ніколи не бачив атаки; edge не бачить нічого іншого.
Ескалюйте до підмережі після двох порушень.
Одну заблоковану адресу тривіально змінити. Після другого порушення з того самого району блокування розширюється на підмережу-порушницю, щоб зловмисник не міг просто зсунутися на одну IP.
Ми кажемо незручну частину вголос: блокування підмережі може зачепити законного користувача, який двічі помилився паролем зі спільної адреси, корпоративного NAT, кампусу, кафе. Це реальна ціна, а не похибка округлення. Тому правило постачається із задокументованим запобіжним клапаном для спільних IP, а не як постійна стіна.
Надійне виправлення: замкніть origin на CDN, потім атакуйте його знову
Виправлення полягає в тому, щоб обмежити origin на firewall опублікованими діапазонами CDN. Потім той самий прив’язаний запит, з тієї самої недовіреної машини:
# BEFORE: pin the naked origin, it serves the login page around the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
HTTP/1.1 200 OK # the origin answered. the CDN was bypassed.
# AFTER: origin firewalled to accept only the CDN's published ranges
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
curl: (7) Failed to connect to <origin-ip> port 443: Connection refusedЗа замком origin стоїть справжній WAF рівня 7, те, що інспектує запити, які CDN усе ж пересилає, і спільний список блокування: зловмисника, спійманого на зондуванні одного клієнта, блокують у всіх, тож розвідка, яка картографує один сайт, платить мито на кожному іншому.
Що виправляємо ми, а що передаємо вам
Коли аудит щось знаходить, робота ділиться на два стовпчики. Один наш, і ми робимо його в тому самому сеансі: зміцнюємо інфраструктурний edge, негайно. Інший у вашому застосунку, і ми не торкаємося вашого коду. Ми передаємо вам точну знахідку і тим часом прикриваємо її, щоб ви не були відкриті, поки виправляєте.
| Що ми виправляємо в тому самому сеансі | Що передаємо вам на виправлення (тим часом прикрите) |
|---|---|
| Замикаємо origin на опубліковані діапазони CDN | Оновити або видалити вразливий плагін, CMS чи застосунок |
| Піднімаємо захист від перебору на рівні 7 на edge | Змінити спільні або типові облікові дані |
| Закриваємо на firewall відкриті сховища даних у приватну мережу | Увімкнути MFA на важливих облікових записах |
| Усуваємо витоки інформації на веб-сервері | Виправити вразливість рівня застосунку у вашому коді |
Потім ми атакуємо знову і доводимо, що зачинено
Кожне виправлення вище закінчується однаково: ми повертаємося на машину, якій firewall ніколи не казали довіряти, проганяємо заново батарею, що знайшла проблему, і підтверджуємо, що те саме вимірювання тепер повертає «зачинено». Прив’язка до origin повертає connection refused. Порт, який відповідав, темний. Знахідка, яку ми вам передали, щойно ви її закриєте, відмовляє і нам.
Та сама позиція, спрямована на те, чи взагалі ми контролюємо мережу, якою їде ваш трафік, є в дописі вам не належить ваша мережа.
Прямі відповіді
Як ви доводите, що виправлення безпеки справді спрацювало?+
Ми не довіряємо латці. Ми знову атакуємо справжній origin з машини на вихідній адресі, якій наш firewall ніколи не казали довіряти, тож вона бачить те, що бачить інтернет. Якщо двері зачинені, прив’язане сканування голого origin відповідає connection refused, а не сторінкою входу. У такому разі це доказ, а не обіцянка.
Як зловмисник може обійти CDN або WAF і вдарити прямо в origin?+
Origin зазвичай витікає через власний поштовий DNS домену, бо запис SPF, який дозволяє вашу пошту, називає хост, що її надсилає. Маючи справжню адресу origin, прив’язують ім’я хоста прямо до неї, щоб кожен інструмент бив у голий origin замість CDN. Якщо origin відповідає так само, як публічне ім’я хоста, CDN і WAF обходять: вони дієві, лише якщо origin замкнений на них. Надійне виправлення полягає в тому, щоб обмежити origin на firewall трафіком лише з опублікованих діапазонів CDN, після чого той самий запит отримує connection refused.
Як перевірити, що порт справді закритий ззовні?+
Скануйте всі 65 535 портів із точки поза мережею, а не кілька поширених, щоб могти ствердно заявити, що все, чого ви не збиралися відкривати, закрите. Повне сканування також виявляє ознаки: невідповідний сертифікат TLS дає відбиток забутого хоста, абсурдно низький лічильник спрацювань firewall означає, що трафік іде не так, як ви думаєте, а DNS-сервер, що відповідає REFUSED, підтверджує, що ви не є відкритим резолвером.
Що виправляєте ви, а що мусимо виправити ми самі?+
У тому самому сеансі ми зміцнюємо інфраструктурний edge: замикаємо origin на діапазони CDN, піднімаємо захист від перебору на edge, закриваємо на firewall відкриті сховища даних у приватну мережу і усуваємо витоки інформації на веб-сервері. Потім передаємо вам точну знахідку і тим часом прикриваємо її: оновити або видалити вразливий плагін/CMS/застосунок, змінити спільні або типові облікові дані, увімкнути MFA і виправити вразливість рівня застосунку у вашому коді.
Ми не просто закриємо тікет. Ми доведемо, що двері зачинені.
Поговоріть з інженером, який знову атакує ваш origin з машини, яку ми ніколи не додавали до списку дозволених, і покаже вам connection refused, що доводить: двері зачинені.
Поговоріть з інженеромЯкщо хочете позицію, що лежить під усім цим, вона починається з володіння мережею, від якої вас захищають: вам не належить ваша мережа.
Ви дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером