До чого ще може дістатися скомпрометований веб-шлюз?
Веб-шлюз обмежує те, що відкриває відвідувач, а не те, до чого може дістатися скомпрометований хост. Дві перевірки, таблиця повноважень і команди вимірювання доступності.
Припустимо, що хост шлюзу скомпрометовано, поки його сертифікат ще дійсний. Кожне правило, яке визначало, які сторінки відвідувач може запитувати, залишається чинним, і жодне з цих правил не обмежує з'єднання, яке атакувальник тепер відкриває з цього хоста в бік підмережі бази даних. Саме ця прогалина робить точку входу лише для вебу не тим самим твердженням, що й сегментована мережа. Обидва твердження потребують окремих перевірок, з різних відправних точок, перш ніж будь-яке з них можна зробити чесно.
Два твердження, і лише одне з них починається у відвідувача
Перше твердження про людину: відвідувач із браузером і чинною сесією може відкрити один застосунок і нічого більше. Точка входу лише для вебу добре відповідає на це твердження, бо відвідувач отримує сторінку, а не маршрут. Ця відповідь варта того, і вона ж єдине твердження, яке фіксує більшість схем.
Друге твердження про компонент: припускається, що шлюз або процес застосунку за ним перебуває під чужим контролем. З цього припущення питання змінюється з того, які URL дозволені, на те, до яких призначень і ідентичностей процес ще може дістатися.
Два твердження мають різних власників, дають різні докази й зазнають невдачі незалежно. Команда ідентичності може показати перше тестом сесії; друге потребує мережевої політики, перегляду службового облікового запису й контролю хоста. Проєкт, що фіксує лише половину відвідувача, виглядає повним на слайді перевірки й тонким під час інциденту, бо засоби контролю, важливі після компрометації, ніколи не входили до обсягу. Назвіть, яке твердження підтримує кожен контроль, інакше одне правило шлюзу зарахують обом.
Опрацьований приклад служби витрат і два способи, якими вона програє
Візьмімо службу витрат: публічний шлюз на 10.60.4.10 автентифікує персонал і передає схвалені запити слухачеві застосунку на порту 8443, а цей застосунок досягає одного слухача PostgreSQL на 10.60.4.20:5432 у ролі expenses_app. Працівники не повинні отримувати загальний внутрішній доступ. За нормальної роботи проєкт справді дає вхід, специфічний для застосунку, ніде не публікуючи слухача бази даних. Адреси важливі, бо кожна подальша перевірка в цій статті їх називає.
Тепер приберіть шлюз із довіреного набору. До яких призначень може дістатися 10.60.4.10, коли його процес належить атакувальнику? Фільтр URL, який обмежував відвідувачів, нічого не каже про з'єднання, яке хост шлюзу відкриває в бік підмережі бази даних.
Приберіть натомість процес застосунку, і повноваження змінюють форму: роль expenses_app, служби, до яких може дістатися цей сервер, і файли, які може читати цей обліковий запис. В обох випадках вхідні двері можуть залишатися лише вебовими, поки межа бекенду відсутня. Тому табличка на вхідних дверях не є відповіддю на жодне з двох питань.
Складіть карту повноважень, які кожна сторона справді має
Договір, написаний як передбачувані дозволи, схильний повторювати проєкт вам. Напишіть його як утримувані повноваження, перевірку, що спростовує надлишок, і власника цієї перевірки, і кожен рядок стане перевірюваним. Ця таблиця — пропозиція для наведеного прикладу, а не твердження про продукт:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
Власність іде за повноваженнями. Команда ідентичності володіє твердженнями, команда мережевої платформи — маршрутами, команда застосунку — роллю бази даних, адміністратор бази даних — слухачем і його правилами на основі хоста, а власник платформи — площиною керування. Відмова без власника — це речення в документі, а не контроль.
Поділ також унеможливлює подвійний облік. Обмеження порту не може виразити привілей таблиці, а роль бази даних не може завадити хосту відкрити сокет до не пов'язаної підмережі.
Перелічіть, до чого може дістатися шлюз, замість того щоб це стверджувати
Твердження про межу цінне рівно настільки, наскільки добрий перелік за ним. На хості шлюзу три команди охоплюють вибір маршруту, живу перевірку й політику виходу:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputЧитайте вивід у цьому порядку. Маршрут каже, чи 10.60.4.20 узагалі вибирається з цього хоста; перевірка каже, чи відповідає слухач; список правил показує, чи політика зупиняє пакет, чи на його шляху ніколи нічого не було.
Повторіть перелік з хоста застосунку. Звідти бік бази даних — один запит, виконаний у ролі застосунку:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Успішне з'єднання під роллю, яка не може читати іншу схему, — інший результат, ніж успішне з'єднання під роллю власника. Лише друге є знахідкою.
Зафіксуйте відмови, потім поставте дату перевірки
Приймання записується як результати, а не наміри: сесія працівника не може дістатися слухача, хост шлюзу не може дістатися не пов'язаної підмережі, а роль застосунку не може створити базу даних. Кожна — окрема перевірка з названим власником і датою.
Тримайте моніторинг, встановлення виправлень і відновлення доступними через шлях керування, призначений для них. Межа, яка блокує і свого власника, стає збоєм, і звичайна перша реакція на такий збій — знову розширити правило. Настанови CISA щодо периметра вимагають обмежити вхідний і вихідний доступ обґрунтованими портами й протоколами, включно з трафіком між внутрішніми мережами, тобто напрямком, який ініціює бекенд і який більшість схем пропускає.
Поставте дату перевірки й назвіть її власника. Повторно виконайте перелік і запит привілеїв після будь-якої зміни образу шлюзу, таблиці маршрутизації або ролі застосунку.