Eén URL voor kantoor en VPN? Waarom de mythe van de allowlist faalt

Verbind de tunnel, open dezelfde bladwijzer, en de toegestane site antwoordt precies zoals hij dat vanaf kantoor deed. Dat is de aanname waarop de meeste plannen voor toegang op afstand stil rusten, en die geldt alleen zolang drie afzonderlijke dingen tegelijk waar blijven. Geen ervan is een functie van de VPN-client, en geen DNS-record kan er een leveren. Wanneer de bladwijzer thuis faalt, geeft de browser u één generieke fout, of de oorzaak nu een ontbrekende route, een niet-goedgekeurd uitgangsadres of een proxy is die de bron heeft vervangen die hij rapporteert. Die drie als één probleem behandelen is de manier waarop een kleine beleidscorrectie een week van het verbreden van allowlists wordt.

Het ontwerp dat contact met een echt kantoornetwerk overleeft, is smaller dan de aanname: een expliciete beslistabel van drie rijen, één handhavingspunt dat niet kan worden omzeild, en een weigeringstest die iets bewijst. Het afbreken van de aanname komt eerst, omdat alles daarna ervan afhangt te weten welke laag de bron verkeerd voorstelt.

De mythe: verbinden is geen routeren

Er wordt een tunnel opgezet en de client installeert routes voor een bepaalde set prefixen. Dat is alles wat verbinden doet. Of een losstaand HTTPS-verzoek door de tunnel reist, en van welk openbaar adres het lijkt te komen wanneer het aankomt, zijn beslissingen die later door andere componenten worden genomen: de routetabel kiest het pad, en de uitgang kiest de bron.

Daarom lopen kantoor en keukentafel uiteen met dezelfde laptop, hetzelfde browserprofiel en dezelfde bladwijzer. Op kantoor verlaat het verzoek een onderhouden openbaar adres waarmee de sitebeheerder heeft ingestemd. Via een volledige tunnel kan het de VPN-uitgang verlaten, dat is een ander adres en, tot iemand het toevoegt, een niet-goedgekeurd adres. Via een split-tunnel komt het misschien helemaal niet in de tunnel. Slechts twee van die drie paden maakten ooit deel uit van de afspraak met de site-eigenaar, en het derde is geen defect dat met een extra allow-regel moet worden gepatcht.

Drie verzoekstatussen, twee goedgekeurde uitgangen

Schrijf de matrix op voordat u een firewall aanraakt, want de tabel is het ontwerp en de regel is er maar één implementatie van. De adressen hieronder zijn documentatieranges; vervang ze door uw eigen onderhouden waarden en bewaar ze waar de site-eigenaar ze kan auditen.

De middelste rij is waar de meeste van deze plannen breken. Wat telt is het adres dat het handhavingsapparaat ziet, niet het privéadres dat de laptop binnen de tunnel heeft en niet zijn LAN-adres. Een waarde als 10.8.0.6 betekent niets voor een openbare site, en 192.168.1.44 ook niet. Een tunneladres is een adresseringsdetail van de tunnel, geen credential die de site kan controleren.

Als uw VPN geen stabiele, gedocumenteerde uitgang kan bieden, heeft de matrix geen geldige middelste rij en geen enkele hoeveelheid allowlists verzint er een. De eerlijke opties op dat punt zijn een privésite die via expliciete privéroutes wordt bereikt, of een identiteitsbewuste toegangsgateway voor de applicatie. Beide hebben een ander contract dan een openbare allowlist, en beide zijn makkelijker aan een auditor uit te leggen dan een lijst die groeide tot hij toevallig werkte.

Lees de bron waar de beslissing wordt genomen

Zet de beperking op het apparaat dat het verzoek beëindigt, en bevestig dat geen alternatief herkomstpad het omzeilt. De Nginx-toegangsmodule evalueert de allow- en deny-richtlijnen op volgorde, de eerste overeenkomst wint, en regels die van een omringend blok zijn geërfd gelden nog steeds binnen location. Een smalle allow naast een brede allow op dezelfde plek betekent meestal dat de brede beslist. Lees de volledige effectieve configuratie voor die location voordat u er één regel van wijzigt.

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;
    }
}

Achter een loadbalancer of reverse proxy ziet die regel de proxy, tenzij u hem anders vertelt. Herstel het adres van de aanroeper alleen via het ondersteunde vertrouwde-proxymechanisme, met een expliciete lijst van proxyadressen. Een verzoekheader die een goedgekeurd adres beweert, is geen bewijs dat de aanroeper het bezit, en op een openbare listener maakt een niet-gevalideerde doorgestuurde header de allowlist tot decoratie.

Controleer dan de andere adresfamilie. Een regelset die alleen IPv4 dekt, is een onvolledige beslissing voor een hostnaam die ook op AAAA antwoordt, en een client met werkende IPv6 bereikt dezelfde applicatie via een pad dat u nooit hebt beoordeeld.

Split-tunnel: het verzoek dat nooit binnenkomt

Een split-tunnel vervoert alleen de prefixen op zijn lijst. Interne kantoor-subnetten staan meestal op die lijst; een openbare website niet. De browser lost de naam op, vergelijkt het gekozen adres met de routetabel en vindt toch de lokale standaardgateway voor zich.

Zo komt het verzoek van de thuisverbinding van de gebruiker, wordt het geweigerd, en het rapport zegt dat de VPN kapot is terwijl de tunnel precies doet waarvoor hij is geconfigureerd. Twee correcties zijn legitiem: leid die bestemming door de tunnel en laat de goedgekeurde uitgang hem dragen, of accepteer dat de site rechtstreeks wordt bereikt en geef gebruikers op afstand een ander goedgekeurd pad, zoals de toegangsgateway. De openbare allowlist van de site verbreden tot er toevallig een thuisadres in staat, is geen van beide, en het verwijdert de grens die het ontwerp moest handhaven. De eerste twee houden de matrix eerlijk; de derde wist er stil een rij uit.

Bewijs de weigering, dan het herstel

Test met een verzoek dat de echte beslissing uitoefent, vanaf een client die op elke rij van de tabel staat. Een bereikbaarheidstest tegen een of andere losstaande pagina die het adres toont, bewijst niets, omdat die bestemming een ander pad kan volgen dan de applicatie.

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/'

Vergelijk het toegangsrecord aan de grens met wat de tabel voorspelde. Laat dan de tunnel zakken en doe een nieuw verzoek dat geweigerd zou moeten worden; een pagina die al geladen is, of een verbinding die al open is, test helemaal niets. Als er geen weigering verschijnt, staat het handhavingspunt niet waar u denkt.

Houd applicatieauthenticatie na netwerktoelating, want een kantooruitgang en een VPN-uitgang staan elk voor veel mensen en geen van beide identificeert een individu. De instructie voor gebruikers blijft kort: breng de goedgekeurde tunnel op, probeer het dan opnieuw. Dat is wat één URL handig houdt terwijl de bronregel een beslissing blijft en geen gok.