Kablys: Diena, kai Pipeline Bankrutavęs (Chmod 777)
Kai jis ateina į CI/CD Saugumo požiūriu, nedaug klaidų yra tokios pavojingos kaip „chmod 777“ paleidimas. Netinkamas jos naudojimas panaikina „Linux“ teises, panaikina apsaugos priemones ir atveria duris potencialiai užpakalinei atakai. Tai prasideda taip: ta CI/CD pipeline yra raudonas, komanda užblokuota, o terminalas išspjauna baimę keliantį:
nginx
Leidimas buvo atmestas
Užuot ieškojęs pagrindinės priežasties, kūrėjas griebiasi branduolinio varianto:
⚠️ Nesaugus pavyzdys: suteikia visišką prieigą visiems. Nepaleisti gamybinėje aplinkoje.
chmod 777 deploy.sh
Statybos darbai tampa žali. Įtampa sumažėja. Visi grįžta prie darbo. Tačiau fone ta viena komanda apeina visas „Linux“ leidimų teikiamas apsaugos priemones, taip sudarydama sąlygas galinei atakai, kuri gali pakenkti visai sistemai.
Tikrasis chmod 777 poveikis Linux leidimams
„Linux“ leidimai yra failų lygio saugumo pagrindas „Unix“ tipo sistemose. Jie apibrėžia, kas gali skaityti, rašyti arba vykdyti failą. Kiekvienas failas turi:
- Trys leidimų tipaiskaityti (r), parašyk w)ir vykdyti (x).
- Trys leidimų grupėssavininkas, grupė ir kiti.
Kai paleisite chmod 777, suteikiate skaitymo, rašymo ir vykdymo teises visoms trims grupėms. Tai tas pats, kas palikti visas namų duris neužrakintas ne tik draugams, bet ir nepažįstamiesiems bei visiems praeiviams.
Saugus demonstravimas:
Izoliuotuose kūrėjų kompiuteriuose tai gali atrodyti nekenksminga. Tačiau bendruose kūrimo agentuose, konteinerinėse aplinkose arba kelių vartotojų „Linux“ sistemose chmod 777 kiekvieną paliečiamą failą paverčia atviru kvietimu klastoti – puikiu pagrindu slapta atakai.
Atakos vektorius: nuo chmod 777 iki „Backdoor Attack“
Štai kaip vienas chmod 777 gali virsti užpakalinėmis durimis pulti:
- Kūrėjas nustato chmod 777 diegimo arba kūrimo scenarijuje, kad ištaisytumėte leidimų klaidą
- Failas tampa pasauliniu rašymo įrankiu; jį gali modifikuoti bet kuris vartotojas ar procesas.
- Užpuolikas į scenarijų įterpia kenkėjišką kodą
- Geriausios CI/CD pipeline paleidžia pakeistą scenarijų, vykdydamas užpuoliko naudingąją apkrovą su padidintomis teisėmis
⚠️ Nesaugus pavyzdys: neleiskite gamybinėje aplinkoje. Čia naudojamas rizikingoms teisėms iliustruoti.
chmod 777 build.sh
Paprastas atakos srautas:
Kai tai tampa ypač pavojinga:
- Bendrai naudojami kūrimo agentai su keliomis komandomis ar projektais
- Prijungti pagrindinio kompiuterio tomus „Docker“ arba „Kubernetes“ pod'uose
- Atvirojo kodo saugyklos kur bendraautoriai gali pateikti arba sujungti pakeitimus
Kai ši grandinė prasideda, galinė ataka gali pereiti į gamybinę aplinką, nutekinti prisijungimo duomenis, pakeisti artefaktus arba atidaryti nuolatinius prieigos taškus.
Atvejo analizė: užpakalinių durų ataka naudojant netinkamai sukonfigūruotą scenarijų
Apibendrinkime iki esminių dalykų:
- Kūrėjas veikia chmod 777 build.sh apeiti CI/CD klaida
- Kitas vartotojas arba kenkėjiškas procesas toje pačioje aplinkoje redaguoja scenarijų
- Geriausios pipeline vykdo pažeistą scenarijų su CI/CD paslaugos paskyros leidimai
- Jei šio proceso metu atnaujinamas pažeidžiamas atvirojo kodo paketas, „backdoor“ ataka gali išplisti į produkciją.
Štai taip chmod 777 Be to, ne itin griežti „Linux“ leidimai gali suteikti užpuolikams laisvę patekti į jūsų diegimo procesą.
Kodėl kūrėjai vis dar naudoja „chmod 777“ (ir kodėl tai spąstai)
Net patyrę kūrėjai pakliūna į šią spąstą, nes chmod 777 atrodo kaip greitas sprendimas, kai:
- Artefaktų pakuotė pateikia klaidas dėl leidimo atmetimo
- „Docker“ apvalkalo scenarijai neveikia, nes jie nėra vykdomi
- Bendrinamų tomų žurnalų failų rašyti negalima.
Bet štai kabliukas: tudainuoti chmod 777 ignoruoja pagrindinę priežastį, nepaiso „Linux“ leidimų valdiklių ir pažeidžia mažiausių privilegijų principą. Užuot pašalinęs kliūtį, jis skatina galinę ataką.
Saugios chmod 777 alternatyvos
If chmod 777 yra branduolinis variantas, tai yra chirurginiai smūgiai:
dockerfile geriausia praktika:
dockerfile
„GitHub“ veiksmai pavyzdys:
Jie tinkamai vykdo „Linux“ leidimus, blokuodami neleistinus pakeitimus ir sumažindami užpakalinių durų atakų riziką.
Kaip aptikti ir išvengti chmod 777 klaidingų konfigūracijų
Pre-commit etapas
- git hooks atmesti commits turintys chmod 777:
Statybos etapas
- integruoti SAST pažymėti nesaugias komandas
- Nepavyksta atlikti CI užduočių, jei rasti aptinka failus, kuriems leidžiama rašyti visame pasaulyje
Vykdymo etapas
Ieškokite failų su visuotine rašymo prieiga:
Sąrašo šifrai:
Politikos vykdymas
- Naudokite politiką kaip kodą, kad apibrėžtumėte leidžiamas „Linux“ teises
- Siųsti įspėjimus prieš pradedant rizikingus diegimus
Automatizuodami šiuos patikrinimus, sumažinate tikimybę, kad chmod 777 kada nors pasiekia gamybinę versiją, o kartu su ja – ir užpakalinių durų atakos galimybę.
„DevSecOps“ ir kultūra: „chmod 777“ prevencija šaltinyje
Saugumo kūrimas DevSecOps kultūra yra efektyviau nei taisyti vėliau:
- Politika kaip kodas, skirta saugiems „Linux“ leidimams užtikrinti kiekviename pipeline
- Scenarijų peržiūros, apimančios diegimo scenarijų leidimų patikrinimus
- Saugūs šablonai, skirti „Docker“, „Kubernetes“ ir kt. CI/CD configs
Mokymai apie tai, kaip chmod 777 sukuria vektorių užpakalinėms atakoms.
Kodėl „chmod 777“ niekada nėra pataisymas?
Chmod 777 nėra trumpesnis kelias; tai rizikos daugiklis. Tai nepaiso kruopščiai suplanuotų „Linux“ leidimų, pašalina apsaugos priemones ir atveria kelią užpakalinėms atakoms, kurios gali pakenkti CI/CD pipelineir gamybos sistemos.
Pataisymas neapsiriboja vien komandų keitimu; tai yra saugių leidimų priėmimas, patikrinimų automatizavimas ir mažiausių privilegijų mąstymo integravimas į jūsų sistemą. DevSecOps procesas. Įrankiai kaip Ksigeni gali padėti aptikti nesaugias konfigūracijas ir failus, kuriuos galima rašyti bet kur, prieš jiems pasiekiant gamybos aplinką, suteikdamas jums saugos tinklą nesulėtinant pristatymo.
