Какво още може да достигне компрометиран уеб шлюз?
Уеб шлюзът ограничава какво отваря посетителят, а не какво може да извика компрометиран хост. Два прегледа, таблица с правомощия и команди за проверка на достижимостта.
Да предположим, че хостът на шлюза е компрометиран, докато сертификатът му е още валиден. Всяко правило, което е определяло кои страници посетителят може да заяви, остава в сила и нито едно от тези правила не ограничава връзката, която нападателят сега отваря от този хост към подмрежата на базата данни. Именно тази празнина прави уеб входната точка различна от сегментираната мрежа. Двете твърдения изискват отделни прегледи, от различни начални точки, преди което и да е от тях да бъде направено честно.
Две твърдения и само едно от тях започва при посетителя
Първото твърдение е за човек: посетител с браузър и валидна сесия може да отвори едно приложение и нищо друго. Уеб входната точка отговаря добре на това твърдение, защото посетителят получава страница, а не маршрут. Този отговор си заслужава, и той е единственото твърдение, което повечето схеми записват.
Второто твърдение е за компонент: шлюзът или процесът на приложението зад него се приема за под чужд контрол. От това допускане въпросът се променя от това кои 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 за периметъра изискват входящият и изходящият достъп да бъдат ограничени до оправдани портове и протоколи, включително трафика между вътрешните мрежи, което е посоката, инициирана от бекенда, която повечето схеми пропускат.
Датирайте прегледа и назовете собственика му. Изпълнете отново изброяването и заявката за привилегии след всяка промяна на образа на шлюза, таблицата за маршрутизация или ролята на приложението.