Blocklist ng Nebula: ikaw ang magpamahagi, hindi ang parola
Ang entry sa blocklist ay nalalapat lamang sa mga host na nag-load nito. Ihambing ang pamamahagi ng listahan sa pag-rotate ng CA, pagkatapos ay i-verify ang tinanggihang peer at ang gumaganang peer.
Ang pagpapatupad ng blocklist ay katangian ng host na nagsasagawa ng pagsusuri, hindi ng certificate na sinusuri. Ang makina na hindi kailanman nag-load ng entry ay patuloy na tumatanggap ng pagkakakilanlan, at walang anuman sa handshake ang nagbababala sa iyo na hindi nagkakasundo ang dalawang peer. Ang murang at mamahaling solusyon para sa isang naibukas na credential ay magkaiba sa abot at sa pagiging maibabalik, kaya piliin nang sinasadya. Saklaw ng mga seksyon sa ibaba kung ano ang ginagawa ng entry, saan ito dapat ihatid, kailan mas mabuting sagot ang pag-rotate, at paano patunayan na gumana ang alinman sa dalawa.
Ano talaga ang ginagawa ng entry sa blocklist
Inililista ng configuration ng PKI ang mga fingerprint na dapat tanggihan ng host kahit wastong naka-sign at hindi pa nag-expire ang certificate. Lokal na nangyayari ang pagpapatupad, laban sa listahan na ni-load ng host noong nagsimula ang serbisyo. Walang anumang bahagi ng entry ang naglalakbay sa loob ng certificate, kaya hindi matututunan ng peer ang desisyon mula sa credential na ipinapakita rito. Kaya walang papel ang parola dito: tumutulong ang mga parola sa mga peer na maghanap sa isa't isa at nagpapadala ng trapiko kung saan nabibigo ang direktang landas. Layer sila ng pagtuklas at pagpapadala, hindi channel ng pamamahagi ng configuration.
Ang pag-update ng isang makina ay nagbabago ng mga desisyon ng makinang iyon at iniiwan ang bawat iba pang peer nang eksaktong tulad ng dati. Ang peer na nagtitiwala sa signing authority at hindi kailanman nakita ang entry ay walang dahilan para tumanggi sa anuman. Kaya ang pagsubok sa revocation sa pamamagitan ng pagtingin sa parola ay walang pinapatunayan, dahil ang component na tinitingnan mo ay hindi kailanman hiniling na ipatupad ang listahan.
Kilalanin ang certificate, hindi ang device
Gamitin ang fingerprint ng credential na balak mong tanggihan, dahil ang hostname, label ng device o kasalukuyang address ay tumutukoy sa isang makina ngayon at sa ibang bagay sa susunod na buwan. Wala sa mga string na iyon ang lumilitaw sa blocklist, at wala sa mga ito ang nakakaligtas sa muling pag-install. I-print ang certificate, basahin ang fingerprint, at tiyakin na kabilang ito sa credential na tinatapos at hindi sa kapalit nito. Mahalaga ang pagbasa ng dalawang file kapag naisyu na ang kapalit, dahil maaaring magbahagi ng pangalan ang luma at bagong certificate at magkaiba sa bawat iba pang field.
Itala kung aling fingerprint ang na-block at kailan, para mapaghihiwalay ng susunod na audit ang natapos na pagbabago sa nilalayon pa lang. Pansinin din ang hindi ginagawa ng entry: hindi nito binabalewala ang signing authority, at hindi nito pinipigilan ang pagtanggap sa hinaharap na certificate mula sa authority na iyon. Ang pag-block ng host certificate at ang pagpapalit ng kompromisong authority ay magkaibang operasyon na may magkaibang bunga.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"Ipamahagi ito tulad ng anumang configuration
Tratuhin ang listahan bilang configuration na may mekanismo ng delivery, hindi bilang file na ine-edit ng isang tao kapag naalala. Itulak ang buong listahan sa halip na delta, para ang host na nakaligtaan ang naunang update ay magtugma sa halip na mag-ipon ng puwang. Inirerekomenda ng dokumentasyon ng PKI ng Nebula nang eksakto iyon, at ang payo ay dapat sundin nang tumpak sa halip na gawing manu-manong proseso.
Tiyakin na ni-load muli ng tumatakbong serbisyo ang nilalaman, hindi lamang na nagbago ang file sa disk. Subaybayan kung aling mga makina ang naglapat ng pagbabago at panatilihing nakikita ang natitirang listahan hanggang mawala ito. Ang laptop na sarado nang isang linggo ay peer na hindi kailanman natutunan ang desisyon, at maaaring muling kumonekta mula sa network na walang inaasahan. Itala ang paraan ng delivery sa tabi ng fingerprint, dahil gagamitin itong muli ng susunod na revocation at sa una doon dini-debug ang proseso.
Blocklist o pag-rotate ng authority
Ang entry sa blocklist ay makitid: isang pagkakakilanlan ang tumitigil at nagpapatuloy ang lahat ng iba. Ang pag-rotate ng signing authority ay malawak: bawat certificate na inilabas nito ay hindi na mapagkakatiwalaan, at bawat host ay nangangailangan ng bagong credential at bagong trust anchor. Ang una ay naka-target na revocation at ang pangalawa ay migration, kaya kailangan nila ng magkaibang approval at magkaibang maintenance window. Inilalagay ng talahanayan ang dalawa nang magkatabi sa abot, pagsisikap at pagiging maibabalik.
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
Ang nawalang laptop ay nangangailangan ng blocklist, dahil isang pagkakakilanlan ang saklaw ng pinsala at maibabalik ang pagbabago kung mali ang na-block mong fingerprint. Ang tumagas na authority key ay nangangailangan ng pag-rotate, dahil hindi matutulungan ng blocklist ang mga certificate na hindi pa naisyu. Sa pagitan ng mga sukdulang iyon, itanong kung ang naibukas na credential ay maaaring makapag-sign ng iba pa, dahil ang authority ay higit sa isang host.
Isulat ang desisyon bago ang isang insidente, dahil ang pagpili sa ilalim ng pressure ay may tendensiyang magbigay ng malawak na opsyon bilang default. Alinmang landas ang tahakin, ang natitirang gawain ay pareho: patunayang nangyari ang pagpapatupad sa mga host na mahalaga. Ang pagtatala ng fingerprint at petsa sa sandaling iyon ang nagpapangyari sa patunay mamaya.
I-verify ang pagtanggi at ang natitira
Kumonekta mula sa na-block na pagkakakilanlan at kumpirmahin ang kabiguan, pagkatapos ay kumonekta mula sa awtorisadong peer at kumpirmahing naaabot pa rin nito ang kailangan. Ang pagbabagong sumisira sa lahat ay hindi matagumpay na revocation. Gawin ang dalawa mula sa bagong session, dahil maaaring itago ng naka-cache na estado ang resulta.
Suriin kung nagtatapos ang naitatag na session pagkatapos ng pagbabago, at itala ang pag-uugali para sa iyong bersyon at configuration sa halip na ipagpalagay na may tinatapos ang pag-edit ng file. Sinasaklaw ng opsyon na disconnect_invalid ang mga kliyenteng nag-expire o di-wasto ang certificate, kaya tiyakin kung paano ito nalalapat sa iyong kaso bago umasa rito. Kung kinakailangan ang agad na pagtatapos, i-test iyon nang partikular at itala ang naobserbahan mo. Pagkatapos ay ulitin ang pagsubok pagkatapos ng restart, dahil ang host na nagpapatupad ng listahan hanggang sa susunod na reboot lamang ay may problemang delivery na itinago ng unang pagsubok. Ang malusog na parola ay nagsasabi na gumagana ang pagtuklas, hindi na may naglapat ng patakaran ang sinumang peer.