Nebula-blokkeringsliste: distribuer den, fyrtårnet gjør det ikke

Håndheving av blokkeringslisten er en egenskap ved verten som utfører kontrollen, ikke ved sertifikatet som kontrolleres. En maskin som aldri har lastet oppføringen, fortsetter å godta identiteten, og ingenting i håndtrykket varsler om at to parter er uenige. Den billige og den dyre løsningen for samme eksponerte påloggingsinformasjon skiller seg i rekkevidde og i hvor vidt den kan reverseres, så velg med vilje. Avsnittene nedenfor dekker hva oppføringen gjør, hvor den må leveres, når rotasjon er det bedre svaret, og hvordan man beviser at en av dem virket.

Hva en blokklistoppføring faktisk gjør

PKI-konfigurasjonen lister opp fingeravtrykk som en vert må avvise selv om sertifikatet er gyldig signert og ikke utløpt. Håndhevingen skjer lokalt, mot listen som verten lastet da tjenesten startet. Ingenting om oppføringen reiser inne i sertifikatet, så en peer kan ikke lære avgjørelsen fra påloggingsinformasjonen den blir vist. Derfor spiller et fyrtårn ingen rolle her: fyrtårn hjelper parter å finne hverandre og videresende trafikk der en direkte vei svikter. De er et lag for oppdagelse og videresending, ikke en kanal for distribusjon av konfigurasjon.

Oppdatering av én maskin endrer den maskinens avgjørelser og lar hver annen peer være nøyaktig som den var. En peer som stoler på signeringsmyndigheten og aldri har sett oppføringen, har ingen grunn til å avvise noe. Derfor beviser testing av tilbakekalling ved å se på fyrtårnet ingenting, fordi komponenten du ser på aldri ble bedt om å håndheve listen.

Identifiser sertifikatet, ikke enheten

Bruk fingeravtrykket til påloggingsinformasjonen du vil avvise, fordi et vertsnavn, en enhetsetikett eller en gjeldende adresse identifiserer en maskin i dag og noe annet neste måned. Ingen av disse strengene vises i blokkeringslisten, og ingen av dem overlever en reinstallasjon. Skriv ut sertifikatet, les fingeravtrykket, og kontroller at det tilhører påloggingsinformasjonen som fases ut og ikke erstatningen. Å lese begge filene er viktig når en erstatning allerede er utstedt, siden det gamle og det nye sertifikatet kan dele navn og avvike i hvert annet felt.

Registrer hvilket fingeravtrykk som ble blokkert og når, slik at en senere revisjon skiller en fullført endring fra en planlagt. Noter også hva oppføringen ikke gjør: den ugyldiggjør ikke signeringsmyndigheten, og den hindrer ikke at et fremtidig sertifikat fra den myndigheten godtas. Å blokkere et vertssertifikat og å erstatte en kompromittert myndighet er forskjellige operasjoner med forskjellige konsekvenser.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Distribuer den som enhver annen konfigurasjon

Behandle listen som konfigurasjon med en leveringsmekanisme, ikke som en fil noen redigerer når de husker det. Send hele listen i stedet for en delta, slik at en vert som gikk glipp av en tidligere oppdatering konvergerer i stedet for å samle hull. Nebula PKI-dokumentasjonen anbefaler nettopp dette, og rådet er verdt å følge bokstavelig i stedet for å omformulere det til en manuell prosess.

Bekreft at tjenesten som kjører, lastet innholdet på nytt, ikke bare at filen på disken ble endret. Følg med på hvilke maskiner som brukte endringen, og hold listen over gjenstående synlig til den er tom. En laptop som er lukket i en uke, er en peer som aldri lærte avgjørelsen, og den kan koble til på nytt fra et nettverk ingen forventet. Registrer leveringsmetoden ved siden av fingeravtrykket, fordi neste tilbakekalling bruker den igjen, og det er ved den første prosessen feilsøkes.

Blokkeringsliste eller rotasjon av myndighet

En blokklistoppføring er smal: én identitet slutter å virke og alt annet fortsetter. Rotasjon av signeringsmyndigheten er bred: hvert sertifikat den utstedte blir ikke betrodd, og hver vert trenger ny påloggingsinformasjon og et nytt tillitsanker. Den første er en målrettet tilbakekalling og den andre er en migrering, så de trenger forskjellige godkjenninger og forskjellige vedlikeholdsvinduer. Tabellen setter de to side ved side på rekkevidde, innsats og reverserbarhet.

En bortkommen laptop krever blokkeringslisten, fordi skadens radius er én identitet og endringen er reverserbar hvis du blokkerte feil fingeravtrykk. En lekket myndighetsnøkkel krever rotasjon, fordi blokkeringslisten ikke kan hjelpe med sertifikater som ennå ikke er utstedt. Mellom disse ytterpunktene, spør om den eksponerte påloggingsinformasjonen kunne ha signert noe annet, siden en myndighet er mer enn én vert.

Skriv ned avgjørelsen før en hendelse, fordi valg under press har en tendens til å gi det brede alternativet som standard. Uansett hvilken vei du velger, er det gjenstående arbeidspunktet det samme: bevis at håndhevingen skjedde på vertene som betyr noe. Å registrere fingeravtrykket og datoen i det øyeblikket er det som gjør beviset mulig senere.

Verifiser avvisningen og resten

Koble til fra den blokkerte identiteten og bekreft feilen, og koble deretter til fra en autorisert peer og bekreft at den fortsatt når det den trenger. En endring som bryter alle, er ikke en vellykket tilbakekalling. Gjør begge fra nye økter, fordi bufret tilstand kan skjule resultatet.

Sjekk om en etablert økt avsluttes etter endringen, og noter oppførselen for din versjon og konfigurasjon i stedet for å anta at redigering av en fil avslutter noe. Alternativet disconnect_invalid dekker klienter hvis sertifikater er utløpt eller ugyldige, så bekreft hvordan det gjelder din sak før du stoler på det. Hvis umiddelbar avslutning er et krav, test det spesifikt og registrer det du observerte. Gjenta deretter testen etter en omstart, fordi en vert som håndhever listen bare til neste omstart, har et leveringsproblem som den første testen skjulte. Et friskt fyrtårn forteller deg at oppdagelsen virker, ikke at noen peer har brukt en policy.