Handhaving van de blokkeerlijst is een eigenschap van de host die de controle uitvoert, niet van het certificaat dat wordt gecontroleerd. Een machine die het item nooit heeft geladen, blijft de identiteit accepteren, en niets in de handshake waarschuwt u dat twee peers het oneens zijn. De goedkope oplossing en de dure oplossing voor één gelekt inlogbewijs verschillen in bereik en in omkeerbaarheid, dus kies bewust. De onderstaande secties behandelen wat het item doet, waar het moet worden afgeleverd, wanneer rotatie het betere antwoord is, en hoe u bewijst dat een van beide heeft gewerkt.

Wat een item op de blokkeerlijst werkelijk doet

De PKI-configuratie vermeldt vingerafdrukken die een host moet weigeren, ook al is het certificaat geldig ondertekend en niet verlopen. Handhaving gebeurt lokaal, tegen de lijst die die host laadde toen de dienst startte. Niets van het item reist mee in het certificaat, dus een peer kan de beslissing niet afleiden uit het inlogbewijs dat hem wordt getoond. Daarom speelt een vuurtoren hier geen rol: vuurtorens helpen peers elkaar te vinden en relayeren verkeer waar een direct pad faalt. Ze zijn een ontdekkings- en relaylaag, geen distributiekanaal voor configuratie.

Eén machine bijwerken verandert de beslissingen van die machine en laat elke andere peer precies zoals hij was. Een peer die de ondertekenende autoriteit vertrouwt en het item nooit heeft gezien, heeft geen reden om iets te weigeren. Het intrekken testen door naar de vuurtoren te kijken bewijst dus niets, want het onderdeel waarnaar u kijkt is nooit gevraagd de lijst te handhaven.

Identificeer het certificaat, niet het apparaat

Gebruik de vingerafdruk van het inlogbewijs dat u wilt weigeren, want een hostnaam, een apparaatlabel of een actueel adres identificeert vandaag een machine en volgende maand iets anders. Geen van die strings staat in de blokkeerlijst, en geen ervan overleeft een herinstallatie. Druk het certificaat af, lees de vingerafdruk, en controleer dat die bij het inlogbewijs hoort dat wordt uitgefaseerd en niet bij zijn vervanger. Beide bestanden lezen is belangrijk wanneer er al een vervanger is uitgegeven, omdat het oude en het nieuwe certificaat een naam kunnen delen en in elk ander veld verschillen.

Leg vast welke vingerafdruk werd geblokkeerd en wanneer, zodat een latere audit een voltooide wijziging onderscheidt van een bedoelde. Noteer ook wat het item niet doet: het maakt de ondertekenende autoriteit niet ongeldig, en het stopt niet dat een toekomstig certificaat van die autoriteit wordt geaccepteerd. Een hostcertificaat blokkeren en een gecompromitteerde autoriteit vervangen zijn verschillende operaties met verschillende gevolgen.

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

Verspreid het als elke andere configuratie

Behandel de lijst als configuratie met een aflevermechanisme, niet als een bestand dat iemand bewerkt wanneer hij eraan denkt. Push de hele lijst in plaats van een delta, zodat een host die een eerdere update miste convergeert in plaats van gaten te verzamelen. De Nebula PKI-documentatie raadt precies dat aan, en het advies is het waard letterlijk te volgen in plaats van het om te zetten in een handmatig proces.

Controleer dat de draaiende dienst de inhoud opnieuw heeft geladen, niet alleen dat het bestand op schijf is veranderd. Houd bij welke machines de wijziging hebben toegepast en houd de openstaande lijst zichtbaar tot die leeg is. Een laptop die een week dicht is, is een peer die de beslissing nooit heeft geleerd, en hij kan opnieuw verbinden vanaf een netwerk dat niemand verwachtte. Noteer de aflevermethode naast de vingerafdruk, want de volgende intrekking hergebruikt die, en bij de eerste wordt het proces foutgezocht.

Blokkeerlijst of rotatie van de autoriteit

Een item op de blokkeerlijst is smal: één identiteit werkt niet meer en al het andere gaat door. De ondertekenende autoriteit roteren is breed: elk certificaat dat zij heeft uitgegeven wordt niet meer vertrouwd, en elke host heeft een nieuw inlogbewijs en een nieuw vertrouwensanker nodig. Het eerste is een gerichte intrekking en het tweede is een migratie, dus ze vragen verschillende goedkeuringen en verschillende onderhoudsvensters. De tabel zet de twee naast elkaar op bereik, inspanning en omkeerbaarheid.

QuestionBlocklist entryAuthority rotation
What stops workingOne identityEvery certificate from that authority
Fleet workPush one file and confirm a reloadNew credentials and a new trust anchor everywhere
ReversibleYes, remove the lineNo, the old authority stays distrusted
FitsA lost or stolen deviceA leaked authority key

Een verloren laptop vraagt om de blokkeerlijst, omdat de schade beperkt blijft tot één identiteit en de wijziging omkeerbaar is als u de verkeerde vingerafdruk hebt geblokkeerd. Een gelekt autoriteitssleutel vraagt om rotatie, omdat de blokkeerlijst niet helpt bij certificaten die nog niet zijn uitgegeven. Vraag tussen die uitersten of het geëxposeerde inlogbewijs iets anders had kunnen ondertekenen, want een autoriteit is meer dan één host.

Schrijf de beslissing op vóór een incident, want kiezen onder druk levert standaard vaak de brede optie op. Welke weg u ook neemt, het resterende werkitem is identiek: bewijs dat handhaving gebeurde op de hosts die ertoe doen. De vingerafdruk en de datum op dat moment vastleggen is wat het bewijs later mogelijk maakt.

Controleer de weigering en de rest

Maak verbinding vanuit de geblokkeerde identiteit en bevestig de fout, maak daarna verbinding vanuit een geautoriseerde peer en bevestig dat die nog bereikt wat hij nodig heeft. Een wijziging die iedereen breekt is geen geslaagde intrekking. Doe beide vanuit verse sessies, want gecachte toestand kan het resultaat verbergen.

Controleer of een bestaande sessie na de wijziging eindigt, en noteer het gedrag voor uw versie en configuratie in plaats van aan te nemen dat het bewerken van een bestand iets beëindigt. De disconnect_invalid-optie dekt clients waarvan de certificaten verlopen of ongeldig zijn, dus bevestig hoe die op uw geval van toepassing is voordat u erop vertrouwt. Als onmiddellijke beëindiging een vereiste is, test dat dan specifiek en leg vast wat u zag. Herhaal de test daarna na een herstart, want een host die de lijst alleen tot de volgende herstart handhaaft, heeft een afleverprobleem dat de eerste test verborg. Een gezonde vuurtoren vertelt u dat ontdekking werkt, niet dat een peer beleid heeft toegepast.

Gerelateerde artikelen