Kako javni proksi preko VPN-a stiže do privatnog izvora

Objavljivanje sajta kroz tunel i davanje korisnicima pristupa VPN-u dvije su različite postavke koje dijele isti kabl. U prvoj javni obrnuti proksi prihvata zahtjev posjetioca i prosljeđuje ga kroz tunel do izvora do kojeg niko ne može doći direktno. U drugoj korisnik mora pristupiti VPN-u prije nego što aplikacija uopšte postane dostupna. Miješanje ova dva opisa je način na koji privatni backend na kraju završi javno izložen.

Dva modela koja na dijagramu izgledaju isto

Nacrtajte strelice prije nego što bilo šta odaberete. Model javnog objavljivanja ide od preglednika do proksija preko HTTPS-a, zatim od proksija do izvora kroz tunel, a izvor nikada ne prihvata vezu iz interneta. Model samo s VPN-om ide od klijenta do mrežnog prolaza, a aplikacija je dostupna samo iznutra, s te putanje. Prijenosnik korisnika nalazi se na istoj mreži kao aplikacija, i to je cijela poenta tog modela.

Modeli se razlikuju po tome ko provjerava identitet i gdje. U prvom je proksi javni ulaz i prosljeđuje svaki zahtjev koji stigne, uključujući neprijateljski, u skladu s politikom postavljenom na njemu. U drugom je sama dostupnost kapija, što je grubo ali stvarno primanje.

Gdje TLS staje i šta zapravo dokazuje

TLS između preglednika i proksija štiti taj skok i omogućava pregledniku da provjeri sajt koji je namjeravao posjetiti. Ako proksi prekine TLS, zahtjev postoji u čitljivom obliku unutar tog procesa prije nego što se proslijedi. Druga TLS sesija prema izvoru može zaštititi sljedeći skok i odvojeno provjeriti krajnju tačku aplikacije. Nijedna sesija ne odlučuje koji čovjek smije koristiti aplikaciju. Ni certifikat sa zamjenskim znakom na proksiju ne proteže se na taj drugi skok.

To je dio koji ljudi sažimaju u riječ šifrovano. Povjerljivost, integritet i identitet servera su svojstva transporta; autorizacija je odluka aplikacije. Privatna adresa iza tunela mijenja ko može doći do socketa, a ne ko smije prijaviti se kad do njega dođe.

Vjerujte proslijeđenim zaglavljima samo od proksija

Aplikacije koje bilježe ili autoriziraju po adresi klijenta obično čitaju zaglavlje koje proksi dodaje. To zaglavlje je samo tekst, pa sve što može doći do izvora direktno može tvrditi koju god adresu želi. Ograničite izvor tako da se samo tunelska adresa proksija može povezati, i konfigurirajte aplikaciju da prihvata zaglavlje samo s te adrese.

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

Ako taj zahtjev uspije s hosta koji nije proksi, izvor vjeruje zaglavlju koje bi trebalo ignorisati. Popravite listener prije nego što dirnete aplikaciju. Odbijanje je mnogo bolji ishod od linije u logu koja nosi krivotvorenu adresu.

Držite izvor dostupnim s tačno jednog mjesta

Vežite listener izvora na tunelsku adresu ili ga zaštitite firewallom prema proksiju, pa potvrdite šta zapravo sluša. Usluga pokrenuta s wildcard vezom prihvata veze na svakom interfejsu koji host ima, uključujući onaj za koji ste zaboravili da je rutabilan. Tabela slušanja je osnovna istina, a ne konfiguracijska datoteka koju ste namjeravali primijeniti. Ako je wildcard veza namjerna, firewall i dalje mora biti komponenta koja je sužava.

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

Uradite isti pregled za upravljačke interfejse, koji su uobičajena slučajna izloženost. Zatim zapišite dva modela odvojeno: javni sajt kroz proksi i administrativni interfejs dostupan samo kroz tunel. Rečenica da je server iza VPN-a ne kaže ništa od toga.