Nebulas blockeringslista: distribuera den själv, fyren gör det inte

Efterlevnad av blockeringslistan är en egenskap hos värden som gör kontrollen, inte hos certifikatet som kontrolleras. En maskin som aldrig laddade posten fortsätter att acceptera identiteten, och inget i handskakningen varnar dig om att två peerar inte är överens. Den billiga och den dyra lösningen för en enda röjd autentiseringsuppgift skiljer sig i räckvidd och i reversibilitet, så välj medvetet. Avsnitten nedan täcker vad posten gör, var den måste levereras, när rotation är det bättre svaret och hur du bevisar att endera fungerade.

Vad en post i blockeringslistan faktiskt gör

PKI-konfigurationen listar fingeravtryck som en värd måste avvisa även om certifikatet är giltigt signerat och inte har gått ut. Efterlevnaden sker lokalt, mot den lista som värden laddade när tjänsten startade. Inget av posten färdas inuti certifikatet, så en peer kan inte lära sig beslutet från den autentiseringsuppgift som visas för den. Det är därför en fyr inte har någon roll här: fyrar hjälper peerar att hitta varandra och vidarebefordrar trafik där en direkt väg misslyckas. De är ett lager för upptäckt och vidarebefordran, inte en distributionskanal för konfiguration.

Att uppdatera en maskin ändrar den maskinens beslut och lämnar varje annan peer exakt som den var. En peer som litar på den signerande myndigheten och aldrig såg posten har ingen anledning att vägra något. Att testa återkallelse genom att titta på fyren bevisar därför ingenting, eftersom komponenten du tittar på aldrig ombads att tillämpa listan.

Identifiera certifikatet, inte enheten

Använd fingeravtrycket för den autentiseringsuppgift du tänker avvisa, eftersom ett värdnamn, en enhetsetikett eller en aktuell adress identifierar en maskin i dag och något annat nästa månad. Ingen av dessa strängar förekommer i blockeringslistan, och ingen av dem överlever en ominstallation. Skriv ut certifikatet, läs fingeravtrycket och kontrollera att det tillhör den autentiseringsuppgift som fasas ut och inte dess ersättare. Att läsa båda filerna spelar roll när en ersättare redan är utfärdad, eftersom det gamla och det nya certifikatet kan dela ett namn och skilja sig i varje annat fält.

Anteckna vilket fingeravtryck som blockerades och när, så att en senare granskning skiljer en genomförd ändring från en avsedd. Notera också vad posten inte gör: den ogiltigförklarar inte den signerande myndigheten och den hindrar inte att ett framtida certifikat från den myndigheten accepteras. Att blockera ett värdcertifikat och att ersätta en komprometterad myndighet är olika operationer med olika konsekvenser.

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

Distribuera den som vilken annan konfiguration som helst

Behandla listan som konfiguration med en leveransmekanism, inte som en fil någon redigerar när den kommer ihåg. Skicka hela listan i stället för en delta, så att en värd som missade en tidigare uppdatering konvergerar i stället för att samla luckor. Nebulas PKI-dokumentation rekommenderar just det, och rådet är värt att följa bokstavligt i stället för att omformulera det till en manuell process.

Bekräfta att den körande tjänsten läste in innehållet igen, inte bara att filen på disken ändrades. Följ upp vilka maskiner som tillämpade ändringen och håll den utestående listan synlig tills den är tom. En laptop som varit stängd en vecka är en peer som aldrig fick lära sig beslutet, och den kan ansluta igen från ett nätverk som ingen förväntade sig. Anteckna leveransmetoden bredvid fingeravtrycket, eftersom nästa återkallelse återanvänder den, och vid den första är det där processen felsöks.

Blockeringslista eller rotation av myndigheten

En post i blockeringslistan är smal: en identitet slutar fungera och allt annat fortsätter. Att rotera den signerande myndigheten är brett: varje certifikat den utfärdade blir misstroget, och varje värd behöver en ny autentiseringsuppgift och en ny förtroendeankare. Det första är en riktad återkallelse och det andra är en migrering, så de kräver olika godkännanden och olika underhållsfönster. Tabellen ställer de två sida vid sida vad gäller räckvidd, arbete och reversibilitet.

En förlorad laptop kräver blockeringslistan, eftersom skadeomfånget är en identitet och ändringen är reversibel om du blockerade fel fingeravtryck. En läckt myndighetsnyckel kräver rotation, eftersom blockeringslistan inte kan hjälpa till med certifikat som ännu inte har utfärdats. Mellan dessa ytterligheter, fråga om den röjda autentiseringsuppgiften kunde ha signerat något annat, eftersom en myndighet är mer än en värd.

Skriv ned beslutet före en incident, eftersom val under press tenderar att som standard ge det breda alternativet. Vilken väg du än tar är den återstående arbetsuppgiften identisk: bevisa att efterlevnaden skedde på de värdar som spelar roll. Att registrera fingeravtrycket och datumet i det ögonblicket är det som gör beviset möjligt senare.

Verifiera avvisandet och resten

Anslut från den blockerade identiteten och bekräfta felet, anslut sedan från en auktoriserad peer och bekräfta att den fortfarande når det den behöver. En ändring som bryter allt är ingen lyckad återkallelse. Gör båda från nya sessioner, eftersom cachat tillstånd kan dölja resultatet.

Kontrollera om en etablerad session avslutas efter ändringen, och anteckna beteendet för din version och konfiguration i stället för att anta att redigering av en fil avslutar något. Alternativet disconnect_invalid täcker klienter vars certifikat har gått ut eller är ogiltiga, så bekräfta hur det gäller i ditt fall innan du förlitar dig på det. Om omedelbar avslutning är ett krav, testa det specifikt och anteckna vad du observerade. Upprepa sedan testet efter en omstart, eftersom en värd som tillämpar listan bara till nästa omstart har ett leveransproblem som det första testet dolde. En frisk fyr berättar att upptäckt fungerar, inte att någon peer har tillämpat en policy.