Soproga vtičnice ali posredovana glava: kateremu naslovu zaupati?

Zahteva, ki prispe v vašo aplikacijo, nosi dve vrsti dokazov o naslovu: soproga, ki je odprl omrežno povezavo, in polje HTTP, ki trdi naslov prejšnjega odjemalca. Odgovarjata na različni vprašanji. Soproga vtičnice se opazuje, medtem ko glavo trdi tisti, ki jo je napisal, in nobeno ne bi smelo tiho nadomestiti drugega v dnevniku ali v pravilu dostopa. Spodnja primerjava ju drži ločeno in nato pokaže edino razporeditev, v kateri glava postane uporabna.

Opišite pot, preden karkoli primerjate:

Client -> approved reverse proxy -> application origin

V tej razporeditvi je soproga vtičnice na strani izvora običajno proxy, posredovalna glava pa lahko nosi trditev proxyja o odjemalcu. Njena vrednost izhaja iz nadzorovanega odnosa s tem proxyjem, ne iz imena glave.

Dve vrsti dokazov o naslovu

Soproga vtičnice je dejstvo o eni povezavi TCP: nekaj je dokončalo rokovanje s tega naslova. Ni nujno oseba, naprava ali račun, ki vas zanima, ker sta lahko VPN ali izhod Tor upravičeno vir, ki ga storitev opazuje. Je pa še vedno edini naslov, ki ga je preveril sam gostitelj, in v tem je vsa njegova vrednost.

Polje posredovanja so metapodatki o verigi. X-Forwarded-For, X-Real-IP in standardizirano polje Forwarded lahko napiše vsak odjemalec, ki doseže končno točko, ki jih odmeva, zato je njihova zanesljivost v celoti odvisna od tega, komu je bilo dovoljeno, da jih nastavi.

Oboje hranite v kontekstu zahteve pod različnimi imeni. Aplikacija, ki prepiše soprogo z glavo, izgubi zmožnost poznejše rekonstrukcije napake zaupanja, in to je natanko tisti trenutek, ko jo potrebujete.

Glava nikoli ne preusmeri povezave

Pisanje naslova v polje posredovanja ne spremeni vira povezave TCP, ki prispe na strežnik, in nikjer na poti ne spremeni usmerjanja. Običajno usmerjanje VPN ali izvorni NAT dostavi promet popolnoma brez kakršne koli glave HTTP. Prav tako prehodna postaja ne prepiše ustrezno zaščitene izmenjave HTTPS, ne da bi spremenila razporeditev končne točke TLS.

Obratna napaka je enako pogosta: HTTPS ne naredi glave posredovanja, ki jo zagotovi odjemalec, resnične. Ščiti prenos napačne trditve natanko tako dobro kot resnične.

Če sodelavec predlaga spremembo glave za odpravo težave z usmerjanjem, je diagnoza že šla narobe. Popravite pot ali popravite konfiguracijo proxyja, ki piše glavo.

Imenujte proxy, ki sme trditi

Dve pravili naredita polje posredovanja uporabno in oba sta konfiguracija, ne koda. Rob normalizira ali zavrže vse, kar pride od zunaj, v skladu z lastnim dokumentiranim vedenjem za ta polja. Nato izvor vzame nadomestni naslov iz poti proxyja, ki ste jo imenovali, in od nikoder drugod. Drugo pravilo velja le toliko časa, dokler odjemalci ne morejo doseči izvora drugače, ker izvor, ki odgovarja na neposredne in na zahteve prek proxyja, ne ve, kateri od njiju služi.

Modul NGINX za pravi IP jasno pokaže delitev. set_real_ip_from imenuje pošiljatelje, katerih trditev šteje, in real_ip_header pove, katero polje jo nosi; prvo izvaja zaupanje, drugo samo pove, kam gledati.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Sama direktiva za izbiro glave še vedno ničesar ne ugotovi o tem, kdo je poslal vrednost.

Varnost prenosa mora delovati po vsej poti med komponentami, ki jim zaupate. Rob, ki pravilno normalizira, izgubi to vrednost v trenutku, ko nezaščiten preskok nižje dovoli nekomu drugemu, da med potjo uredi trditev.

Zavestno ravnajte z verigami z več preskoki

Več proxyjev zahteva izrecen model verige. Ne vzemite skrajne leve ali desne vrednosti, ločene z vejicami, samo zato, ker je tako storil nek blog zapis; ugotovite, kateri od vaših proxyjev dodaja, kateri nadomešča in kateri ohranja vhodno polje. NGINX lahko na primer prehodi seznam nazaj proti svoji množici zaupanja in se ustavi na prvem naslovu, ki ga ne poseduje, in to je pravilo tega izdelka, ne zakon, ki bi ga upošteval vsak okvir. Berite dokumentacijo lastnega proxyja z istima dvema vprašanjema: katero vrednost izbere in katerim pošiljateljem verjame?

Zapišite verigo: vrstni red preskokov, kateri preskok nastavi polje in kateri preskok odstrani vhodne kopije. Nato hranite to opombo ob konfiguraciji proxyja, ne le v zahtevku. Nato to preizkusite tako, da pošljete zahtevo s ponarejeno glavo skozi odobreni postopek preverjanja in potrdite, da jo izvor prezre.

Ko dodate preskok, ponovno pregledajte ta dokument. Novo porazdeljevalnik obremenitve, vstavljen pred zaupanja vredni proxy, lahko spremeni, kateri naslov zmaga, ne da bi kdo urejal aplikacijo.

Obe opažanji hranite v dnevniku

Kjer je diagnostika dovoljena, beležite soprogo povezave in normaliziran naslov odjemalca kot dve ločeni polji, in dodajte le tiste metapodatke posredovanja, ki jih namen resnično potrebuje. Nato dokažite uvedbo z dvema zahtevama: eno prek proxyja, ki bi morala smiselno zabeležiti obe vrednosti, in enim poskusom neposredno na izvor, ki mora biti zavrnjen.

Zapomnite si, kaj par pomeni. Glava doda kontekst, ki ga zagotovi komponenta, ki ste se ji odločili zaupati; soproga ostaja edini naslov, ki ga je vaš gostitelj dejansko videl. Nobeno ni dokaz individualne identitete in zasnova, ki katero koli od njiju obravnava kot dokaz, se bo o nekom zmotila.