Tijdelijke links naar IP-toelatingslijsten: wat de vergunning werkelijk toelaat

Eén klik omzetten in een tijdelijke firewallregel is handig, en het bouwt tegelijk een autorisatiesysteem dat bepaalt wie een dienst mag bereiken. Het geeft een adres uit in plaats van een persoon, en dat verschil telt vanaf het moment dat twee mensen één NAT delen. Beperk de reikwijdte van de vergunning, bevestig die bewust en geef het verloop betekenis voordat de link wordt gebouwd. De beslissing voor u is waar de grens moet liggen, niet of er een zou moeten bestaan.

Bepaal op welke vraag de vergunning antwoordt

Begin bij de eis. Als een genoemde persoon de dienst moet bereiken en de toepassing die persoon al authenticeren, houdt een geauthenticeerde gateway de identiteit op het handhavingspunt en is er helemaal geen adresopname nodig. Als het doel een buildagent, een administratieve sprongpoort of een apparaat is dat niet aan gebruikersaanmelding kan deelnemen, kan een beperkte adresvergunning de enige praktische controle zijn.

Adresopname kiezen voor een gebruikersgerichte toepassing verplaatst het echte autorisatieprobleem naar elders, en het portaal erft dan de schuld van een gat dat het nooit heeft gedicht.

Begrens het verzoek op de server

De browser mag de bestemming, de poort of het prefix niet kiezen. Het portaal bepaalt de dienst uit zijn eigen gegevens en controleert het recht met een test aan de serverkant, wat hetzelfde principe is dat de autorisatierichtlijnen van OWASP op elk verzoek toepassen. Ook het afleiden van het adres hoort bij de beschermde grens: wanneer een omgekeerde proxy het clientadres meldt, accepteer dan alleen de geconfigureerde proxyketen en de gedocumenteerde omgang met headers. Een doorgifteheader die een bezoeker aanlevert, is een bewering over de herkomst, geen bewijs ervan.

Controleer daarna of het portaal en de dienst dezelfde bron zien. Split tunneling, één proxysprong en IPv4 tegenover IPv6 kunnen twee bestemmingen twee verschillende adressen geven, dus een vergunning die via één pad is geactiveerd, dekt het volgende verzoek misschien niet.

Toon de vergunning voordat u die installeert

Het openen van een link zou de voorgestelde dienst, de waargenomen bron en de duur moeten tonen en nog niets moeten wijzigen. Die ene stap maakt van de gemailde link een handeling die een voorstel wordt, en het weerhoudt een voorbeeldbot of een mailscanner ervan toegang te geven door de link alleen op te halen.

De bevestiging zou een toestandswijzigend verzoek moeten zijn met de gebruikelijke cross-site- en oorsprongsverdediging. Het token zou eenmalig moeten zijn en atoomisch verbruikt moeten worden op het moment dat de regel wordt geïnstalleerd, en het record zou eigenaar, dienst, adres, vergunningsidentificatie en verloop moeten vastleggen zonder ooit het ruwe token te loggen.

De aflevering van het token verdient dezelfde zorg als de regel zelf. Een verlopen of al verbruikte link die nog steeds een regel oplevert, is een tweede deur met dezelfde sleutel.

Het adres wordt gedeeld terwijl de vergunning leeft

Een kantoor-NAT, een provider-NAT en een gedeelde VPN-uitgang zetten elk meerdere personen achter één adres. Dat adres toelaten laat iedereen erachter toe — voor zover het de volgende grens van de dienst betreft —, terwijl het niets bewijst over wie het account heeft dat de dienst verwacht.

De regel verwijderen is ook geen universele ontkoppeling. Bestaande verbindingen, gecachte applicatietokens en langlevende sessies kunnen de regel minuten of veel langer overleven, dus de levensduur die u kiest, zou moeten weerspiegelen wat de dienst na de toelating doet en niet alleen hoe lang de regel bestaat.

Test vier gevallen en beide adresfamilies

Een vergunning is slechts zo goed als de vier gevallen die ze overleeft: een nieuw toegestaan verzoek, een niet-goedgekeurde aanvrager, een herhaling van dezelfde link en hetzelfde verzoek na het verloop.

Test daarna elke familie afzonderlijk, omdat het bronadres dat de dienst waarneemt tussen beide kan verschillen.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Het nuttige resultaat is een tijdelijke, controleerbare toelatingsbeslissing onder normale gebruikerautorisatie, in plaats van een permanente opening die de naam draagt van wie het eerst klikte.