Kdaj se je treba v Linuxu izogniti ukazu sudo in kdaj ga pravilno uporabljati

V svetu GNU/Linuxa se pogosto ponavlja, da Stalni dostop do root pravic je nevaren.To velja tako za strežnike Linux kot za druga okolja, kot je AWS. Vendar pa pogosto ni dovolj jasno pojasnjeno. Kdaj je primerno uporabljati sudo, kdaj je su boljši in v katerih situacijah se je sudo najbolje izogniti? ali pa ga čim bolj omejite. Vse to se prekriva z znanim načelom najmanjših privilegijev, ki ga v praksi ni vedno enostavno uporabiti, ne da bi vsako drugo minuto noro vnašali gesla.

Če delate upravljanje strežnikov Ali če imate preprosto namizni računalnik z Linuxom, se je normalno spraševati stvari, kot so: Ali je res tako slabo prijaviti se kot root? Zakaj nekatere distribucije onemogočijo root in vas prisilijo k uporabi sudo? Ali je negotovo, da si sudo nekaj minut zapomni geslo? Ali lahko sudo konfiguriram tako, da bo manj "permisivan"? V naslednjih vrsticah bomo videli Kako deluje sudo, kako se razlikuje od su in od neposredne prijave kot root?Kakšna tveganja prinaša vsak pristop in katere priporočene konfiguracije lahko uporabite za okrepitev varnosti sistema, ne da bi pri tem žrtvovali uporabnost?

Root, navadni uporabniki in načelo najmanjših privilegijev

Preden se lotimo Suda in njegovih del, se je vredno spomniti, kaj v resnici pomeni delati kot uporabnik root v primerjavi s tem kot navaden uporabnikRoot je vsemogočen račun: lahko izbriše katero koli datoteko, spremeni dovoljenja za karkoli želi, priklopi ali odklopi datotečne sisteme, ustvari ali izbriše uporabnike, namesti ali odstrani programsko opremo in celo spremeni raven izvajanja sistema.

V klasičnem okolju Unixa je skrbnik Povezal sem se neposredno kot root. na fizičnem terminalu ali teleprinterju in s tem računom opravljal vsa upravljavska opravila. Pogosto je imel isti skrbnik še en "nekorenski" račun za bolj vsakdanje stvari, kot sta branje e-pošte ali pisanje dokumentov, vendar je čisto upravljanje vedno potekalo s skrbnikom, brez filtrov ali časovnih omejitev.

Sčasoma, zlasti s širitvijo Linuxa v večuporabniške scenarije in strežnike, izpostavljene internetu, je načelo najmanjših privilegijevVsak uporabnik bi moral imeti le dovoljenja, ki jih potrebuje za opravljanje svojega dela, nič več in nič manj. Če uporabnik nalaga slike samo prek SFTP-ja v mapo, nima smisla, da se lahko prijavi kot root in posega v kritične storitve. To zmanjša površino za napad, če je ta račun ogrožen.

V praksi to pomeni, da je norma delo 99 % časa z "omejenim" uporabnikomin povečajte privilegije le, kadar je to potrebno za namestitev paketov, ponovni zagon storitev ali spreminjanje sistemskih konfiguracij. Tukaj prideta v poštev sudo in su, s precej različnima pristopoma.

Sudo in su: ključne razlike in primeri uporabe

Da bi razumeli, kdaj se je smiselno izogibati potenju ali ga vsaj omejiti, morate najprej jasno razumeti, kaj ... Kaj točno počne znoj in kaj počne njegovker se pogosto uporabljajo, kot da bi bili enakovredni ... pa niso.

Kaj je znoj in čemu je namenjen?

Ukaz sudo Izhaja iz »superuser do«. Uporabniku omogoča zagon programa s privilegiji drugega uporabnika, privzeto roota, vendar ni zgolj »su v drugi obliki«: zasnovan je tako, da lahko skrbnik delegirati enega ali več določenih ukazov enemu ali več uporabnikom, ne da bi jim omogočili poln root dostop.

Med njegovimi najpomembnejšimi značilnostmi je, da Zahteva uporabnikovo lastno geslo.ne uporabnik root; in da se vse izvede s sudo je registriran v sistemskih dnevnikih, običajno v datotekah, kot je /var/log/auth.log ali enakovrednih datotekah, odvisno od distribucije. To vam omogoča, da vidite, kdo je kaj naredil in kdaj, kar je bistveno v produkcijskih okoljih ali z več skrbniki.

Poleg tega sudo omogoča zelo natančno konfiguracijo v datoteki / etc / sudoersDoločite lahko, kateri uporabniki ali skupine lahko izvajajo katere ukaze, s katerih računalnikov, z geslom ali brez njega, ali celo zavrnete določene ukaze, kot je spreminjanje gesla root. In kot da to ne bi bilo dovolj, lahko njegovo delovanje natančno prilagodite z direktivami, kot so ... timestamp_timeoutki nadzoruje, kako dolgo si zapomni preverjanje pristnosti, preden ponovno zahteva geslo.

Kaj je to in kako se razlikuje?

Ukaz su Izhaja iz »switch user« (preklopi uporabnika). Njegov glavni namen je spreminjanje uporabniške identitete, običajno preklapljanje na uporabnika root, čeprav ga je mogoče uporabiti za preklapljanje na katerega koli drugega sistemskega uporabnika. Za razliko od sudo je tukaj običajno zahtevati geslo ciljnega uporabnikaTo je korenski ukaz, če preprosto izvedemo `su`.

Ko uporabite `su`, da postanete root, vaša lupina prevzame identiteto root in lahko zaženite toliko ukazov, kot želite, s temi privilegiji dokler ne zapustite sistema ali se odjavite. Za eskalacijo ni časovne omejitve ali poteka veljavnosti: uporabniško stikalo ostane aktivno ves čas trajanja seje. Poleg tega je revizijska sled slabša: ko se enkrat prijavite kot root, Težje je vedeti, kaj je vsak posameznik storil. če si geslo deli več ljudi.

Glede na to, kako se uporabi, obstajajo pomembne nianse. Na primer su - Naloži korensko okolje, kot da bi se uporabnik prijavil neposredno (vključno s POTJO, okoljskimi spremenljivkami itd.), medtem ko različica brez vezaja običajno podeduje del prvotnega uporabnikovega okolja. Obstaja tudi možnost su -c "ukaz", ki izvede določen ukaz kot drug uporabnik in se nato vrne na izvirnik.

Hibrid: sudo su in sudo -su

V mnogih sodobnih distribucijah je root račun privzeto onemogočen ali brez gesla (običajno v Ubuntuju), kar sili k uporabi ukaza `sudo`. Kljub temu je še vedno mogoče odpreti root lupino z nečim takim, kot je sudo su o jug na - (enakovredno sudo -su), ki združuje najslabše in najboljše iz obeh svetov, če se ne uporablja previdno.

Kar se tam zgodi, je, da se potim uporabite svoje uporabniško geslo da ga zaženete kot root, ne da bi morali poznati root geslo. Z varnostnega vidika, Še vedno je sled, da si opravil svoje (sudo je registriran), vendar od tega trenutka naprej delate kot "polni" root, dokler ne zaprete lupine, z vsemi tveganji, ki jih to prinaša.

Prednosti in slabosti neposredne uporabe roota

Obstajajo administratorji, ki še vedno raje delaj neposredno kot root To se počne "že stoletja", brez kakršnega koli truda, še posebej v okoljih, ki so skrbno nadzorovana. Drugi pa to prakso obsojajo in jo imajo za nepotrebno tveganje. Resničnost je, da ima svoje prednosti in slabosti.

Na pozitivni strani ima delovanje kot root veliko preprostost delovanjaPovežete se prek SSH kot root (če je dovoljeno), naredite, kar morate, in končali ste. Ni vam treba tipkati `sudo` pred vsakim ukazom, se ukvarjati s konfiguracijami sudoerja ali se boriti z omejitvami ukazov. Za obsežne naloge ali dolge vzdrževalne seje je to lahko zelo priročno.

Vendar pa je prav ta priročnost tisto, zaradi česar je uporaba neposrednega roota ... morebitna katastrofaNeumna napaka, kot je vnos napačne poti z `rm -rf`, lahko izbriše polovico sistema in ne bo nobenega potrditvenega pogovornega okna, kot v drugih operacijskih sistemih. Poleg tega ima napadalec popoln nadzor, če pride do razkritja ali kraje gesla root, ne da bi moral zaobiti dodatne varnostne plasti.

Druga velika pomanjkljivost je, da če si več skrbnikov deli root geslo, Ni čistega načina za preklic dostopa samo enemu.Geslo uporabnika root bi bilo treba spremeniti in ga sporočiti vsem ostalim, z vsemi težavami, ki jih to prinaša. Dnevnik dejanj pa postane veliko bolj nejasen: videli boste, da je »root« izvedel določen ukaz, ne pa tudi, katera oseba je stala za njim.

Nekatere distribucije so vse to upoštevale in privzeto Onemogočijo neposredno prijavo root-a prek SSH (kot Debian s PermitRootLogin tega ne počne), ali pa med namestitvijo sploh ne zahtevajo root gesla (Ubuntu) in za vsako skrbniško nalogo vsilijo uporabo sudo.

Vloga znoja v načelu najmanjših privilegijev

Če govorimo o resni uporabi načela najmanjših privilegijev, je sudo najboljše orodje, ker omogoča natančno določiti, kaj lahko počne vsak uporabnik s povečanimi privilegijiNe gre samo za to, da "pred to postaviš 'sudo' in to je to", ampak za oblikovanje smiselne politike v /etc/sudoers.

Na primer, lahko nastavite določenega uporabnika tako, da lahko samo znova zaženite nginx z uporabo sudoVendar ga ne more ustaviti, niti se ne more dotakniti drugih storitev ali namestiti paketov. Nekaj ​​takega, kot je dovoliti "sudo systemctl restart nginx", vendar izrecno zavrniti "sudo systemctl stop nginx". Drug tipičen primer je omogočiti uporabniku ustvarjanje imenikov in njihovo brisanje z /bin/mkdir in /bin/rm, vendar nič več.

Poleg tega olajša potenje selektivno odvzemanje privilegijevČe nekdo ne more več delovati kot superuporabnik, ga preprosto odstranite iz skupine sudo ali izbrišite njegov vnos v sudoers. Ni treba spreminjati gesla root ali se dotikati računov drugih uporabnikov. Z operativnega in varnostnega vidika je to pomembna izboljšava.

Dejstvo, da je Vsaka uporaba ukaza sudo se zabeleži Vključitev uporabnika, časa, izvedenega ukaza in konteksta (TTY, trenutni imenik itd.) doda še eno plast nadzora. Pri revizijah ali preiskavah incidentov je to zlati rudnik za razumevanje, kaj se je točno zgodilo in kdo je bil za tipkovnico.

Zaradi vseh teh razlogov se v okoljih z več skrbniki ali uporabniki, ki potrebujejo posebne pravice, na splošno šteje, da Neposredna uporaba roota ni priporočljiva In da je med sudo in su razumna možnost skoraj vedno dobro konfiguriran sudo.

Tveganja slabe konfiguracije sudo

Čeprav je sudo zelo močno orodje, ga pustite Način, kako pride privzeto, je lahko resen problemŠtevilne distribucije ga namestijo in aktivirajo skoraj brez prilagoditev, kar daje glavnemu uporabniku skoraj enakovredne pravice root, z nekajminutnim obdobjem mirovanja, ne da bi bilo treba ponovno zahtevati geslo.

To "Grace periodČasovna omejitev `timestamp_timeout`, ki je običajno 5 minut (včasih 15, odvisno od distribucije), je priročna, ker se izogne ​​​​ponavljajočemu vnosu gesla pri veriženju ukazov. Vendar pa je z varnostnega vidika tvegana: če pustite računalnik odklenjen v pisarni ali nekje, kjer bi lahko kdo drug za trenutek sedel pred njim, bi ga lahko v tem času kdo ogrozil. Ukaze lahko izvajate s sudo brez potrebe po geslu.

Še bolj resno je, ko se uporabi sudo brez gesla (NOPASSWD) za določene uporabnike ali skupine zelo široki ukazi (npr. VSI). Če napadalcu takrat uspe izvesti nekaj kot ta uporabnik, lahko kot root počne praktično vse, kar želi, brez dodatnih omejitev.

Poleg tega je bil pot prisoten skozi leta izkoriščevalne ranljivosti Te ranljivosti so uporabnikom omogočale, da so zaobšli omejitve ali pridobili root pravice. Številne od teh ranljivosti je bilo mogoče izkoristiti le, če je bilo orodje prisotno in napačno konfigurirano, medtem ko tiste, ki so delovale brez ukaza sudo ali z zelo strogimi pravilniki, včasih niso bile prizadete.

Zaradi vseh teh razlogov nekateri skrbniki, kljub priznavanju uporabnosti ukaza sudo, raje uporabljajo Namestite ga le, kadar je potrebno, ali pa celo živite brez njega. Na določenih strežnikih vedno skrbno upravljajte kot root. Drugi pa na distribucijah, kjer je to privzeto omogočeno, zaščitijo root z geslom, prekličete uporabnikova dovoljenja sudo v /etc/sudoers in pustite sudo nameščen, vendar z "omejenim" dostopom.

Kako strditi znoj: odprava obdobja mirovanja in še več

Če želite še naprej uporabljati sudo, vendar zmanjšati njegova tveganja, morate sprejeti več ukrepov za zaščito. Prvi in ​​zelo priporočljiv je odpraviti ali skrajšati obdobje mirovanja gesla.

Če želite to narediti, morate urediti datoteko / etc / sudoers Vedno uporabljajte visudo (ne odpirajte ga samo z nano ali vim). Visudo pred shranjevanjem preveri sintakso; če pride do napake, ne prekine sudo, kar je zelo pomembno.

Znotraj sudoers lahko dodate vrstico, kot je Privzete vrednosti timestamp_timeout=0 tako da sudo vedno vpraša po geslune da bi ga hranili niti minuto. To je najvarnejša možnost: vsakič, ko želite povečati privilegije, se boste morali znova overiti.

Če želite ravnovesje med varnostjo in udobjem, lahko pustite zelo majhen rob, na primer: Privzete vrednosti timestamp_timeout=1Zaradi tega preverjanje pristnosti poteče v eni minuti in se zmanjša tveganje, da bi kdo izkoristil vašo odprto in nespremljano sejo.

Drug zanimiv ukrep je omejitev še posebej občutljiva dejanja, kot je spreminjanje gesla root iz računov s sudo. Če želite to narediti, lahko v sistemih, podobnih Debianu, dodate vrstico, kot je ta: %sudo VSE=(VSE) VSE, !/usr/bin/passwd rootin v sistemih RHEL/CentOS/Fedora nekaj podobnega s skupino wheel: %wheel VSE=(VSE) VSE, !/usr/bin/passwd rootZato tudi če ima nekdo privilegije sudo, ne bo mogel neposredno spremeniti gesla root.

Možno je tudi prisiliti določene uporabe ukaza sudo, da delujejo le znotraj določenega območja. interaktivni psevdo-terminalTo vključuje beleženje vsakega ukaza v ločeno datoteko ali omejevanje poti PATH, da se zmanjša možnost, da bi se zlonamerne binarne datoteke prebile skozi. Vse to se nadzoruje z direktivami sudoers in možnostmi, kot so requiretty, log_output, secure_path in druge.

Kdaj se je bolje izogniti ukazu sudo in izbrati root ali su

Postavlja se delikatno vprašanje: Ali obstajajo situacije, ko se je smiselno izogibati potenju? Odgovor je, če sem iskren, pritrdilen, čeprav je veliko odvisno od konteksta, stopnje zaupanja v ekipi in vrste sistema, o katerem govorimo.

Na nekaterih močno nadzorovanih strežnikih, ki jih upravlja en sam izkušen skrbnik, je morda bolje vedno delati z neposredni koren ali z ukazom `su`, brez vmesnega ukaza `sudo`, prav zato, da se izognemo odvisnosti od dodatnega orodja, ki ima lahko svoje ranljivosti ali napačne konfiguracije. V teh primerih se predpostavlja, da operater ve, kaj počne, in da ni "polprivilegiranih" uporabnikov, ki jim je mogoče dodeliti le določene ukaze.

Drug tipičen scenarij je, ko administratorji sploh nočejo slišati o Grace period niti možnosti, da bi njihov redni uporabnik postal prikriti root. Raje imajo stvari jasno ločene Korenski račun za korenska opravila in vaš običajni račun za vse ostaloBrez mešanja. Na ta način je škoda veliko manjša, če ranljivost vpliva na sudo ali če je vaš neprivilegirani uporabnik ogrožen.

Vendar ima ta pristop svoje pomanjkljivosti: če isti stroj upravlja več ljudi, se bomo vrnili k problemu delite geslo root in nezmožnost individualnega preklica dovoljenj. Poleg tega, če se oddaljena prijava izvede kot root prek SSH, se napadalcem odprejo privlačnejša vrata, saj bi morali za poln dostop le uganiti geslo.

Na nasprotni strani pa so tisti, ki trdijo, da Resnično nevarna stvar ni znoj, ampak nepravilna konfiguracija.Z drugimi besedami, neposredni dostop s strani root-a bi bil še bolj tvegan kot ustrezno utrjen in dobro revidiran sistem sudo. Številni incidenti iz resničnega sveta podpirajo to stališče: napadi, ki izkoriščajo skupne root-poveritve, nenamerno izvedeni usodni ukazi ali nezmožnost rekonstrukcije dogodka zaradi pomanjkanja uporabniških dnevnikov.

Skratka, izogibanje ukazu sudo je smiselno le v zelo specifičnih in nadzorovanih scenarijih. V večini produkcijskih sistemov je najbolj smiseln pristop Vzdržujte sudo in ga strogo konfigurirajte (brez dolgih premorov, brez globalnega NOPASSWD, z jasnimi omejitvami) in rezervirajte neposredni root dostop za zelo specifične ali nujne naloge.

Namestitev, podelitev in preverjanje privilegijev sudo

V večini sodobnih distribucij je sudo privzeto nameščenČe sistem pri poskusu uporabe sporoči »ukaza ni bilo mogoče najti«, ga boste morali namestiti z ustreznim upraviteljem paketov: apt v Debianu/Ubuntuju, yum ali dnf v CentOS/RHEL/Fedori, zypper v SLES/openSUSE itd.

Tipičen namestitveni ukaz bi imel podobno obliko kot namestitev programa apt|yum|dnf|zypper sudo (zamenjava z dejanskim orodjem za vaš sistem). Ko je nameščeno, je naslednji korak podelitev privilegijev sudo uporabnikom, ki jih potrebujejo.

Obstajata dva pogosta pristopa: dodajanje posebnega pravila v / etc / sudoers ali pa uporabnika dodajte v privilegirano skupino, kot je sudo (v Debianu/Ubuntuju) ali wheel (v Red Hatu, CentOS-u, Fedori). Za urejanje sudo-jev vedno uporabite visudo; na primer, lahko dodate vrstico, kot je gost VSE=(VSE) BREZ GESLA:VSE tako da lahko uporabnik "gost" uporablja sudo brez gesla v katerem koli ukazu, čeprav je to, kot že omenjeno, z vidika varnosti občutljiva zadeva.

Če želite biti natančnejši, lahko obseg omejite na nekaj ukazov, na primer: gost VSE=(VSE) BREZ GESLA:/bin/mkdir,/bin/rmTako bo ta uporabnik lahko ustvarjal in brisal imenike samo s sudo, ne da bi moral vnesti geslo, vendar ne bo mogel početi drugih stvari, kot sta namestitev paketov ali ponovni zagon storitev.

Druga možnost je, da uporabnika dodate v skupino sudo z ukazom, kot je sudo usermod -aG sudo gost ali skupini wheel v sistemih tipa RHEL. Na ta način bo podedoval splošno politiko, ki jo je sistem določil za to skupino v sudoers, kar na splošno omogoča izvajanje skoraj vseh ukazov kot root po preverjanju pristnosti.

Če kdaj morate preveriti uporabnikove privilegije sudo, lahko uporabite sudo -l zase oz. uporabniško ime sudo -l -U Za drug račun, če ima vaš račun dovoljenje za poizvedovanje. Izhod vam bo pokazal, katere ukaze je mogoče izvesti, katere omejitve veljajo in katere privzete vrednosti se uporabljajo v vašem kontekstu.

Sudo proti su: geslo, vedenje in sledljivost

Primerjava med sudo in su ni omejena na sintakso; obstajajo temeljne razlike v kako se overjajo, kako se privzeto obnašajo in kakšno sled pustijo.To je v veliki meri odvisno od odločitve, katerega uporabiti in kdaj.

V razdelku z gesli sem uporabil sudo. Uporabi trenutnega uporabnikaČeprav vaš račun zahteva geslo ciljnega uporabnika (običajno root), to pomeni, da mora biti za uporabo vašega računa z več skrbniki skupno geslo root, kar velja za slabo prakso, saj otežuje nadzor in preklic dostopa.

Glede privzetega vedenja je sudo namenjen izvesti en sam ukaz s povišanimi privilegiji in se nato "vrnejo" v normalno stanje (razen obdobja mirovanja). Njegov pa, popolnoma spremeni identiteto Odpre novo lupino kot ciljni uporabnik, kar vam omogoča izvajanje neomejenega števila ukazov, dokler se ne odločite za izhod. Zaradi tega je bolj nevarno, če pozabite, da ste še vedno root in ukaze izdajate neprevidno.

Kar zadeva beleženje in nadzor, s sudo vsak ukaz postane povezano z resnično identiteto uporabnika kdo ga je izvedel, tudi če je bil zagnan kot root. Z ukazom `su`, ko ste enkrat prijavljeni kot root, bo vse, kar naredite, preprosto "root izvedel to in to", in veliko težje je izslediti, katera oseba je naredila spremembo, če delite ključ.

Končno je tu še vprašanje prilagodljivosti: sudo ponuja veliko podrobnosti pri omejevanju ukazov in kontekstovMedtem ko je pri rootu eskalacija običajno popolna in brez podrobnosti: kdor pozna root geslo, lahko počne praktično karkoli, in ni vgrajenega standardnega mehanizma, ki bi omejil njegovo uporabo na nekaj ukazov.

Glede na vse to večina trenutnih najboljših praks priporoča uporabo ukaza sudo kot primarnega orodja za stopnjevanje privilegijev in rezervirajte za zelo specifične primere (na primer -c za zagon določenega programa kot drug uporabnik ali su za odpravljanje napak v uporabniškem okolju brez preklopa na root).

Če pogledamo celotno sliko, je povsem jasno, da ključ ni le izbira med sudo, su ali neposrednim rootom, ampak v kako so konfigurirani in v kakšnem kontekstu se uporabljajoDobro utrjen sudo, brez pretiranih časovnih premorov, z omejenimi ukazi in dobrim nadzorom, ponuja zelo razumno ravnovesje med varnostjo in udobjem na večini sistemov. Uporaba neposrednega root dostopa je smiselna v zelo nadzorovanih scenarijih z izkušenimi skrbniki, vendar za ceno izgube sledljivosti in prilagodljivosti; medtem ko je lahko uporaba sudo "kot je" v mnogih distribucijah skoraj tako nevarna kot vedno biti root. Natančna nastavitev teh elementov in poznavanje, kdaj se je najbolje izogniti sudo, je tisto, kar naredi razliko med robustnim sistemom in tistim, ki se le zdi robusten.

Povezani članek:

Kako konfigurirati Google, Cloudflare in DNS vašega ponudnika internetnih storitev, ne da bi pri tem kaj zamočili