Miks Port-Share paneb kõik veebisaidi külastajad localhostina näima

Iga rida juurdepääsulogis näitab sama loopback-aadressi, samal ajal kui leht laeb ja sertifikaat kontrollitakse õigesti. Miski ei ole katki selles mõttes, et see oleks kättesaamatu, ja just seetõttu püsib see kuud. Katki läks omistamine: veebi taustaprogramm salvestab selle hüppe aadressi, mis ühenduse edasi saatis, ja iga hilisem otsus, mis logi usaldas, päris sama vale vastuse.

Allpool olevad kontrollid liiguvad kaablist sissepoole. Peatuge esimesel, mis selgitab väärtust, mida näete, sest iga järgmine samm eeldab, et eelmised on juba tõesed. Ükski neist ei nõua front-endi konfiguratsiooni oletamist.

Jälgige kahte ühendust, mitte logirida

Port-Share multipleksib kaks protokolli ühel TCP-kuulajal. OpenVPN uurib sissetuleva ühenduse esimesi baite, hoiab selle alles, kui see näeb välja nagu tema enda protokoll, ja annab kõik muu teisele sihtkohale. See sihtkoht on tavaliselt veebiserver samas hostis, seega on veebiserveri vastuvõetud sokli partneriks OpenVPN-i protsess.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Esimene käsk näitab, kellele avalik kuulaja kuulub. Teine näitab ühendusi, mis saabuvad taustaprogrammi pordile, ja nende partneri aadress on see, mille juurdepääsulogi välja trükib. Kui see partner on loopback, on log täpne ja teave läks kaduma ühe kihi võrra varem. Logivälja ümbernimetamine või kliendi-IP mooduli lubamine ei taasta aadressi, mida ühendus kunagi ei kandnud.

See on kontroll, mis otsustab kõik muu. Kui taustaprogrammi partner on brauseri aadress, siis pordi jagamine ei ole teie probleem ja logi vorming on.

Transpordi edasisaatmine ei ole päise süstimine

Edasisaatja liigutab baite. See ei parsi HTTP-d, seega ei saa see lisada päist päringusse, mida ta kunagi päringuna ei loe, ega lisada midagi TLS-i voogu, mille ta laseb puutumata läbi. Möödaviimispäist ootav moodul jääb ootama seda, mida ükski komponent ei tooda.

Algset aadressi võivad kanda kaks mehhanismi ja mõlemad nõuavad kokkulepet mõlemas otsas. PROXY-protokoll lisab ühenduse ette väikese päise ja taustaprogramm peab olema konfigureeritud seda ootama; taustaprogramm, mis seda ei oota, käsitleb neid baite päringu algusena ja ebaõnnestub segasel viisil. Usaldusväärsed puhverserveri päised nagu X-Forwarded-For töötavad siis, kui HTTP-d mõistev puhverserver need seab ja taustaprogrammile öeldakse, millised partnerid tohivad neid väita.

Kumbki ei ole automaatne ja kumbki ei ole vaikimisi turvaline. Taustaprogramm, mis usub iga sissetulevat edasisaadetud päist, laseb kliendil valida oma aadressi, mis muudab logi ebatäpsuse juurdepääsukontrolli möödasõiduks. Käivitage demonstratsioon üks kord testhostis, enne kui usaldate ükskõik millist päist tootmisteel.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Valikuline lähtekaardistuse kataloog

Pordi jagamisel on valikuline kataloogiargument, mis salvestab vastenduse algse lähteaadressi ja edasisaatmisühenduse vahel platvormidel, kus funktsioon on rakendatud. Eeldatakse, et veebipool konsulteerib selle vastendusega; see ei ole päis ja seda ei süstita päringusse.

See disain on väärt teadmist, sest see selgitab, miks mõned kasutuselevõtud teatavad tegelikest aadressidest ja teised mitte, näiliselt identse front-endi konfiguratsiooni juures. Erinevus on vastuvõtvas pooles ja see elab tavaliselt moodulis või paigas, mida enamik pakendatud veebiservereid vaikimisi ei luba. Lugege oma veebiserveri dokumentatsiooni täpse konksu kohta, mida see pakub, ja kinnitage, et moodul on laaditud, selle asemel et seda eeldada.

Kui lähete seda teed, käsitlege seda kahest poolest koosneva integratsioonina: vastendus, mille edasisaatja kirjutab, ja otsing, mille taustaprogramm teeb. Kontrollige mõlemat ja kinnitage, et kataloog elab üle taaskäivituse ega kasva koormatud kuulajal piiramatult.

Otsustage, milline komponent aadressi eest vastutab

Enne konfiguratsiooni muutmist nimetage komponent, millel on lubatud väita kliendi aadressi, ja komponendid, millel on lubatud seda uskuda. Üks kirja pandud vastus hoiab ära tavapärase triivi, kus kolm erinevat kihti usaldavad igaüks erinevat allikat.

Kolm disaini katavad enamiku vajadustest. Hoidke avalik kuulaja ja veebikuulaja eraldi, nii et veebiserver näeb tõelisi partnereid ega teki omistamisprobleemi. Pange ette HTTP-d mõistev pöördpuhverserver, lõpetage või parsige päring seal ja laske sellel seada edasisaadetud päis taustaprogrammile, mis usaldab ainult seda puhverserverit. Või jätke pordi jagamine alles ja leppige sellega, et logid näitavad hüpet, kusjuures juurdepääsureeglid on kirjutatud rakenduse identiteedi, mitte aadressi vastu.

Mis ei tööta, on edasisaadetud loopback-aadressi käsitlemine tõendina, et päring tekkis selles masinas. See järeldus on täpselt vastupidine: aadress on olemas just seetõttu, et kohalik komponent tegi ühenduse. Nii kirjutatud reegel laseb sisse igaühe, kes kuulajani jõuab.

Testige reeglit, mitte lehte

Leht, mis laeb, tõestab, et edasisaatmise tee töötab, ja ei ütle omistamise kohta midagi. Testige aadressi tarbijat: juurdepääsureeglit, kiiruspiirangut, auditeerimiskannet, geo-otsingut.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Võrrelge volitatud välist päringut nii front-endi kui ka taustaprogrammi kirjetega ja kinnitage, et reegel, mis peaks keelduma, keeldub endiselt, ja see, mis peaks lubama, lubab endiselt. Kui logirida on õige, aga reegel käitub endiselt nii, nagu oleksid kõik kohalikud, loeb reegel teist välja kui see, mille te parandasite.

Lõpetage omistamisahela kirjutamisega juurutamismärkmetesse: milline kuulaja, milline edasisaatja, milline päis või vastendus ja milline taustaprogramm on konfigureeritud seda usaldama. Järgmine inimene, kes logirida loeb, vajab kõiki nelja, ja selle märkme puudumine on põhjus, miks sama pilet aasta hiljem uuesti avaneb. Hoidke seda konfiguratsiooni kõrval, mitte vestluslõimes.