Как публичен прокси достига до частен източник през VPN

Публикуването на сайт през тунел и даването на потребителите на VPN достъп са две различни уредби, които споделят един кабел. При първата публичен обратен прокси приема заявката на посетителя и я препраща през тунела към източник, до който никой не може да стигне директно. При втората потребителят трябва да се присъедини към VPN, преди приложението да стане достъпно изобщо. Смесването на двете описания е начинът, по който частен бекенд в крайна сметка се оказва публично изложен.

Два модела, които изглеждат еднакво на диаграма

Начертайте стрелките, преди да изберете нещо. Моделът на публично публикуване минава от браузър към прокси по HTTPS, после от прокси към източника през тунела, и източникът никога не приема връзка от интернет. Моделът само с VPN минава от клиент към шлюз, и приложението е достъпно само отвътре в този път. Лаптопът на потребителя стои в същата мрежа като приложението, а това е целият смисъл на този модел.

Моделите се различават по това кой удостоверява и къде. При първия проксито е публичният вход и препраща всяка пристигнала заявка, включително враждебна, съобразно настроената върху него политика. При втория самата достижимост е портата, което е грубо, но истинско допускане.

Къде спира TLS и какво всъщност доказва

TLS между браузъра и проксито защитава този отсек и позволява на браузъра да провери сайта, който е възнамерявал да посети. Ако проксито прекрати TLS, заявката съществува в четим вид вътре в този процес, преди да бъде препратена. Втора TLS сесия към източника може да защити следващия отсек и отделно да провери крайната точка на приложението. Нито една от сесиите не решава кой човек може да използва приложението. Сертификат със заместващ знак на проксито също не се разпростира върху този втори отсек.

Това е частта, която хората свиват в думата криптирано. Поверителността, целостта и самоличността на сървъра са транспортни свойства; оторизацията е решение на приложението. Частен адрес зад тунел променя кой може да стигне до сокета, а не кой може да влезе, след като го направи.

Доверявайте се на препратените заглавки само от проксито

Приложенията, които водят журнал или оторизират по адреса на клиента, обикновено четат заглавка, която проксито добавя. Тази заглавка е просто текст, така че всичко, което може да стигне директно до източника, може да претендира за какъвто адрес пожелае. Ограничете източника така, че само тунелният адрес на проксито да може да се свързва, и настройте приложението да приема заглавката само от този адрес.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Ако тази заявка успее от хост, който не е проксито, източникът се доверява на заглавка, която би трябвало да игнорира. Поправете слушателя, преди да пипате приложението. Отказът е много по-добър изход от ред в журнала, носещ подправен адрес.

Дръжте източника достъпен точно от едно място

Обвържете слушателя на източника с тунелния адрес или го оградете със защитна стена към проксито, после потвърдете какво всъщност слуша. Услуга, стартирана с обвързване към всички интерфейси, приема връзки на всеки интерфейс, който хостът има, включително такъв, за който сте забравили, че е маршрутизируем. Таблицата на слушане е основната истина, а не конфигурационният файл, който сте възнамерявали да приложите. Ако обвързването към всички интерфейси е умишлено, файлуолът пак трябва да е компонентът, който го стеснява.

ss -ltnp | grep -E ':(80|443)'

Направете същия преглед за интерфейсите за управление, които обикновено са случайното излагане. После запишете двата модела поотделно: публичният сайт през проксито и интерфейсът за администриране, достъпен само през тунела. Изречението, че сървърът е зад VPN, не казва нищо от това.