Midlertidige lenker til IP-tillatelseslister: hva tillatelsen egentlig slipper inn

Å gjøre ett klikk til en midlertidig brannmurregel er praktisk, og det bygger samtidig et autorisasjonssystem som avgjør hvem som kan nå en tjeneste. Det utsteder en adresse i stedet for en person, og den forskjellen betyr noe i det øyeblikket to personer deler én NAT. Avgrens tillatelsen, bekreft den bevisst, og gi utløpet en mening før lenken bygges. Beslutningen foran deg er hvor grensen skal ligge, ikke om det bør finnes en.

Avgjør hvilket spørsmål tillatelsen svarer på

Start med kravet. Hvis en navngitt person må nå tjenesten og applikasjonen allerede autentiserer den personen, holder en autentisert gateway identiteten ved håndhevelsespunktet og trenger ikke noen adgangstillatelse på adressenivå i det hele tatt. Hvis målet er en byggeagent, en administrativ hoppeport eller en enhet som ikke kan delta i brukerinnlogging, kan en avgrenset adressetillatelse være den eneste praktiske kontrollen som finnes.

Å velge adgangstillatelse på adressenivå for en brukervendt applikasjon flytter det egentlige autorisasjonsproblemet et annet sted, og portalen arver da skylden for et hull den aldri lukket.

Avgrens forespørselen på serveren

Nettleseren skal ikke velge destinasjonen, porten eller prefikset. Portalen slår opp tjenesten fra egne registre og kontrollerer rettigheten med en test på serversiden, som er det samme prinsippet som OWASPs veiledning for autorisasjon anvender på hver forespørsel. Utledning av adressen hører også til ved den beskyttede grensen: når en omvendt proxy rapporterer klientadressen, godta bare den konfigurerte proxykjeden og dens dokumenterte håndtering av headere. En videresendingsheader som en besøkende leverer, er en påstand om opphav, ikke et bevis for det.

Kontroller deretter at portalen og tjenesten ser samme kilde. Delt tunnellering, ett proxysprang og IPv4 kontra IPv6 kan gi to destinasjoner to ulike adresser, så en tillatelse aktivert via én vei dekker kanskje ikke den neste forespørselen.

Vis tillatelsen før den installeres

Å åpne en lenke bør vise den foreslåtte tjenesten, den observerte kilden og varigheten, og ennå ikke endre noe. Det ene trinnet gjør lenken fra e-posten fra en handling til et forslag, og det hindrer en forhåndsvisningsbot eller en e-postskanner i å gi tilgang bare ved å hente den.

Bekreftelsen bør være en tilstandsendrende forespørsel med de vanlige forsvarene mot kryssnettsteder og opphav. Tokenet bør være engangs og forbrukes atomisk i det øyeblikket regelen installeres, og posten bør fange eier, tjeneste, adresse, tillatelsesidentifikator og utløp uten noen gang å logge det rå tokenet.

Levering av tokenet fortjener samme omhu som regelen selv. En utløpt eller allerede forbrukt lenke som fortsatt lager en regel, er en andre dør montert med den samme nøkkelen.

Adressen deles selv mens tillatelsen lever

Kontor-NAT, leverandør-NAT og en delt VPN-utgang setter hver flere personer bak én adresse. Å tillate den adressen tillater alle bak den — så langt tjenestens neste grense angår —, mens det ikke beviser noe om hvem som har kontoen tjenesten forventer.

Å fjerne regelen er heller ikke en universell frakobling. Etablerte forbindelser, bufrede applikasjonstokener og langlivede sesjoner kan overleve regelen i minutter eller langt lenger, så levetiden du velger bør gjenspeile hva tjenesten gjør etter adgangen, ikke bare hvor lenge regelen finnes.

Test fire tilfeller, og begge adressefamiliene

En tillatelse er bare så god som de fire tilfellene den overlever: en ny tillatt forespørsel, en ikke-godkjent forespørrer, en gjenoppspilling av den samme lenken og den samme forespørselen etter utløp.

Test deretter hver familie for seg, fordi kildeadressen tjenesten observerer kan variere mellom dem.

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

Det nyttige resultatet er en midlertidig, reviderbar adgangsbeslutning under normal brukerautorisasjon, ikke en permanent åpning som bærer navnet til den som klikket først.