Üks URL kontori ja VPN-i jaoks? Miks lubatud loendi müüt läbi kukub

Ühendage tunnel, avage sama järjehoidja ja lubatud sait vastab täpselt nii, nagu ta seda kontorist tegi. See on eeldus, millele enamik kaugjuurdepääsu kavasid vaikselt toetub, ja see kehtib ainult seni, kuni kolm eraldi asja on korraga tõesed. Ükski neist ei ole VPN-kliendi funktsioon ja ükski DNS-kirje ei saa ühtegi neist pakkuda. Kui järjehoidja kodus ebaõnnestub, annab brauser ühe üldise vea, olenemata sellest, kas põhjuseks on puuduv marsruut, kinnitamata väljumisaadress või puhverserver, mis asendas teatatud allika. Nende kolme käsitlemine ühe probleemina on viis, kuidas väikesest poliitikaparandusest saab nädal lubatud loendite laiendamist.

Disain, mis peab vastu kokkupuutele tõelise kontorivõrguga, on eeldusest kitsam: selgesõnaline kolme reaga otsustustabel, üks jõustamispunkt, millest ei saa mööda minna, ja keeldumise test, mis midagi tõestab. Eelduse lahtivõtmine tuleb esimesena, sest kõik pärast seda sõltub teadmisest, milline kiht allikat vääralt esitab.

Müüt: ühendamine ei ole marsruutimine

Tunnel luuakse ja klient paigaldab marsruudid teatud prefiksite hulgale. See on kõik, mida ühendamine teeb. Kas seostamata HTTPS-päring läbib tunneli ja millisest avalikust aadressist see saabudes näib tulevat, on otsused, mille teevad hiljem teised komponendid: marsruutimistabel valib tee ja väljumine valib allika.

Seetõttu lahknevad kontor ja köögilaud sama sülearvuti, sama brauseriprofiili ja sama järjehoidjaga. Kontoris väljub päring hooldatud avaliku aadressi kaudu, millega saidi operaator on nõustunud. Täistunneli kaudu võib see väljuda VPN-i väljumise kaudu, mis on teine aadress ja kuni keegi seda lisab, kinnitamata. Jaotatud tunneli kaudu ei pruugi see tunnelisse üldse siseneda. Ainult kaks neist kolmest teest olid kunagi saidi omanikuga sõlmitud kokkuleppe osa, ja kolmas ei ole viga, mida tuleks parandada täiendava allow-kirjega.

Kolm päringu olekut, kaks kinnitatud väljumist

Kirjutage maatriks üles enne tulemüüri puudutamist, sest tabel on disain ja reegel on vaid üks selle teostus. Allpool olevad aadressid on dokumentatsioonivahemikud; asendage need oma hooldatud väärtustega ja hoidke neid kohas, kus saidi omanik saab neid auditeerida.

Keskmine rida on koht, kus enamik neist kavadest murdub. Loeb aadress, mida jõustav seade näeb, mitte privaatne aadress, mida sülearvuti tunnelis hoiab, ja mitte selle LAN-aadress. Väärtus nagu 10.8.0.6 ei tähenda avaliku saidi jaoks midagi, ja 192.168.1.44 samuti mitte. Tunneli aadress on tunneli adresseerimise detail, mitte tõend, mida sait saab kontrollida.

Kui teie VPN ei suuda pakkuda stabiilset, dokumenteeritud väljumist, ei ole maatriksil kehtivat keskmist rida ja ükski hulk lubatud loendeid ei mõtle seda välja. Ausad valikud on sel hetkel privaatne sait, mis on kättesaadav selgesõnaliste privaatsete marsruutide kaudu, või identiteediteadlik juurdepääsulüüs rakenduse ees. Mõlemal on avalikust lubatud loendist erinev leping ja mõlemat on auditeerijale lihtsam selgitada kui loendit, mis kasvas, kuni see juhuslikult tööle hakkas.

Lugege allikat seal, kus otsus tehakse

Pange piirang seadmele, mis päringu lõpetab, ja kinnitage, et ükski alternatiivne päritolute seda ei möödu. Nginxi juurdepääsumoodul hindab allow- ja deny-direktiive järjekorras, võidab esimene vaste, ja ümbritsevast plokist päritud reeglid kehtivad endiselt locationi sees. Kitsas allow laia allowi kõrval samas kohas tähendab tavaliselt, et otsustab lai. Lugege enne selle locationi ühegi rea muutmist kogu kehtivat konfiguratsiooni.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Koormusjaoturi või vastupuhverserveri taga näeb see reegel puhverserverit, kui te ei ütle talle teisiti. Taastage kutsuja aadress ainult toetatud usaldusväärse puhverserveri mehhanismi kaudu, selgesõnalise puhverserveri aadresside loendiga. Kinnitatud aadressi väitev päringu päis ei ole tõestus, et kutsuja selle omanik on, ja avalikul kuulajal muudab valideerimata edastatud päis lubatud loendi dekooriks.

Seejärel kontrollige teist aadressipere. Ainult IPv4-d kattev reeglistik on puudulik otsus hostinime jaoks, mis vastab ka AAAA-le, ja töötava IPv6-ga klient jõuab sama rakenduseni teed, mida te pole kunagi üle vaadanud.

Jaotatud tunnel: päring, mis kunagi sisse ei tule

Jaotatud tunnel kannab ainult oma loendis olevaid prefikseid. Kontori sisesed alamvõrgud kuuluvad tavaliselt sellesse loendisse; avalik veebisait mitte. Brauser lahendab nime, võrdleb valitud aadressi marsruutimistabeliga ja leiab ikkagi enda ees kohaliku vaikelüüsi.

Nii saabub päring kasutaja koduyhendusest, lükatakse tagasi, ja aruanne ütleb, et VPN on katki, samal ajal kui tunnel teeb täpselt seda, milleks see konfigureeriti. Kaks parandust on seaduslikud: suunake see sihtkoht tunnelist läbi ja laske kinnitatud väljumisel seda kanda, või leppige, et saiti külastatakse otse, ja andke kaugkasutajatele teine kinnitatud tee, näiteks juurdepääsulüüs. Selle saidi avaliku lubatud loendi laiendamine, kuni kodu-aadress juhuslikult sisse satub, ei ole kumbki neist, ja see eemaldab piiri, mida disain pidi jõustama. Esimesed kaks hoiavad maatriksi ausana; kolmas kustutab sealt vaikselt ühe rea.

Tõestage keeldumine, siis taastumine

Testige päringuga, mis rakendab tegelikku otsust, kliendilt, mis seisab tabeli igal real. Kättesaadavuse kontroll mõne kõrvalise aadressi kuvava lehe vastu ei tõesta midagi, sest see sihtkoht võib järgida rakendusest erinevat marsruuti.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Võrrelge piiri juurdepääsukirjet sellega, mida tabel ennustas. Seejärel laske tunnel alla ja tehke uus päring, mis peaks tagasi lükatama; juba laaditud leht või juba avatud ühendus ei testi üldse midagi. Kui keeldumist ei ilmne, ei ole jõustamispunkt seal, kus te arvate.

Hoidke rakenduse autentimine pärast võrku lubamist, sest kontori väljumine ja VPN-i väljumine esindavad kumbki paljusid inimesi ja kumbki ei tuvasta isikut. Kasutajate juhend jääb lühikeseks: tõmmake kinnitatud tunnel üles, seejärel proovige uuesti. Just see hoiab ühe URL-i mugavana, samal ajal kui allika reegel jääb otsuseks, mitte oletuseks.