autentificare root sau utilizator sudo pentru administrarea serverului?

Încerc să înțeleg argumentele tehnice/implicațiile de securitate dintre ssh'ing cu root direct sau crearea unui utilizator sudo auxiliar în contextul întreținerii unui server. Pentru a clarifica, vorbim despre servere deținute de un singur administrator. Pentru mai multe persoane care lucrează la mașină, este evident că există avantajul urmăririi de audit de a avea utilizatori unici pentru fiecare persoană reală și permisiuni detaliate.

Gândul meu este că, dacă aceasta este o stație desktop, are sens și este recomandat să folosiți un utilizator non-root pentru lucrurile zilnice, dar pe un server, de obicei, vă autentificați pentru a o întreține și de 99% din ori toate activitățile dvs. necesită root. permisiuni.

Deci, există beneficii de securitate în crearea unui utilizator „proxy” pe care îl veți face oricum pentru a-l roota, în loc să oferiți direct acces ssh la root?

Singurul beneficiu la care mă pot gândi este securitatea prin obscuritate, adică roboții ar încerca în mod normal să caute utilizatorul „rădăcină”. Dar, din cum văd eu, dacă un utilizator sudoers este compromis, este la fel cu compromiterea utilizatorului root, așa că jocul s-a terminat.

În plus, majoritatea cadrelor de administrare la distanță, sistemele NAS, hipervizoarele încurajează utilizarea unui utilizator root pentru autentificarea pe web.

Un lucru de luat în considerare: dacă folosiți chei SSH pentru autentificarea de la distanță, ce se întâmplă dacă cheia privată este compromisă?

Dacă root: accesul root este compromis. Sper că nu ați folosit acea cheie pentru accesul root pe mai multe mașini.

Dacă utilizator: acel utilizator este compromis. in orice caz, un atacator ar putea să nu poată rula sudo, deoarece parola utilizatorului nu este compromisă. Inca. (Presupunând că este necesară o parolă pentru a utiliza sudo)

Încă o situație proastă, dar poate una mai bună. (De asemenea, puțin mai bine dacă utilizați fraze de acces pentru cheile dvs. SSH)

Pentru toate utilizările, vă recomand cu tărie a nu folosi rădăcină; chiar și pentru a-l dezactiva dacă este posibil. În mod obișnuit, am root dezactivat pe serverele Linux/UNIX. Utilizatorul root nu poate fi îngrădit, acțiunile sale nu sunt înregistrate. Cel puțin, o comandă sudo va fi înregistrată, foarte utilă în caz de manipulare greșită a administratorului. De asemenea, puteți îmbunătăți permisiunile de cereale pentru utilizatori, oferind doar anumite privilegii. Desigur, cu root dezactivat, nu este posibilă înregistrarea ssh folosind root.

Din experiență, root-ul este omis doar în cazul în care trebuie să porniți cu un singur utilizator sau boot de urgență; un scenariu rar când un server nu poate porni corect. Dar dacă acesta este cazul, îl puteți activa, schimba parola și trece la recuperare.
Un alt caz este copierea fișierelor folosind sftp (sau ftp, ceea ce ar trebui evitat, desigur, cu excepția cazului în rețelele interne), unde trebuie să copiați direct în/din directoare doar cu permisiuni root. În acest scenariu, puteți utiliza ACL-uri pentru a acorda permisiuni unui alt utilizator și puteți continua.

pe un server, de obicei vă autentificați pentru a-l menține și de 99% din ori toate activitățile dvs. necesită permisiuni root.

Aș vrea să contest asta. Există multe sarcini de rutină care caută pur și simplu informații pe care orice utilizator le poate vedea. „sus”, „ps”, „df”, uitându-se la jurnalele etc.

Obișnuiește-te să rulezi doar comenzile care necesită root ca root. Și verificați de trei ori acele comenzi pentru a vă asigura că nu ați scris greșit nimic.

Dacă rulați totul ca root, veți deveni neglijent. Se întâmplă tuturor.
Când ești neglijent, vei face greșeli. Se întâmplă tuturor.

Nu lua acest obicei.

(De asemenea, sunt de acord cu ceea ce au spus alții despre a fi singurul administrator astăzi, nu înseamnă că vei fi singurul administrator mâine)

Consultant de securitate aici.

Cele mai bune practici în toată lumea toate aplicații, sisteme, soluții, sisteme de operare și orice altceva la care vă puteți gândi este să utilizați numai contul root pentru a configura lucrurile și apoi a-l dezactiva.

Creați prin toate mijloacele un cont de utilizator individual cu privilegii de administrator pentru gestionarea zilnică, dar contul root, oricare ar fi acesta, ar trebui să fie dezactivat odată ce configurarea este finalizată.

Încălcarea conturilor nu este o idee rea, adică nu vă numiți conturile de administrator, dar valoarea reală a acesteia este incredibil de scăzută.Cele mai multe „hack-uri” au loc pe parcursul săptămânilor și lunilor, mai degrabă decât în ​​secunde și minute, așa cum le-ar fi prezentat mass-media/filmele/emisiunile TV și oricine va seta abilitățile pentru a „hacker”; (este întotdeauna S-1-5-32-544 pentru administratorul Windows încorporat).

Pentru majoritatea companiilor, o mare problemă de securitate este că aveți nevoie de o pistă de audit și de responsabilitate personală.

Conturi implicite (de administrator), cum ar fi rădăcină conturile sunt, prin definiție, nu personale. Lăsarea lor deschisă duce la (echivalentul) practicii proaste de securitate a parolelor partajate și lipsa răspunderii personale/individuale.

În mod normal, atunci când un coleg părăsește compania, vrei să-i dezactivezi contul și știi că îi blochează accesul.

Nu doriți ca părăsirea lor să necesite resetarea parolelor (și fișierelor ~/.ssh/authorized_keys) ale fiecărei conturi rădăcină și altor conturi partajate la care cei care au părăsit (s-ar putea) să fi avut acces. Aceasta este o sarcină administrativă PITA care deseori nu se întâmplă, așa că trebuie să preveniți ca aceasta să devină o problemă în primul rând.

Deci, chiar și într-un departament IT de o singură persoană, vă rugăm să configurați un cont personal pentru dvs. ca administrator, acordați-vă sudo privilegii sau alte roluri de administrator și nu vă conectați direct ca root sau orice cont implicit de super utilizator/administrator este disponibil.

Așadar, atunci când compania dvs. crește și deveniți un departament IT de două persoane sau ori de câte ori plecați, nu veți lăsa o mizerie incertă de privilegii excesive care trebuie curățate.

Într-un loc de muncă nou, nu vrei să-ți petreci primele zile lucrătoare curățind „accesul la ușa din spate” lăsat de un predecesor și nici nu trebuie, ca părăsitor, să riscați accesul tău care nu a fost... t anulat provocând breșe de securitate.

Ca toate întrebările de securitate, este o chestiune de apetit pentru risc. După cum au afirmat alții, SSH-ul ca utilizator non-root cu o cheie și apoi ridicarea la rădăcină înseamnă că există un al doilea factor în joc (aveți cheia, știți parola), care poate limita raza de explozie a unui compromis. . Mai este și aspectul auditului, pe care l-au menționat și alții.

Dacă tu sunteți mulțumit că nu aveți acel strat suplimentar de protecție (oricât de mic ar fi acesta), apoi faceți cum doriți.

Majoritatea ghidurilor de securitate recomandă dezactivarea rădăcină SSH, în primul rând pentru că vă obligă să listați permisiunea unui utilizator pentru a face ceva. Este necesară o acțiune pozitivă din partea dvs. pentru a acorda unui utilizator privilegii sudo. Puteți controla în continuare ce acțiuni poate face utilizatorul, astfel încât este posibil să aveți utilizatori separati chiar și pentru sarcini separate.Sau un utilizator automat care poate rula anumite comenzi sudo, dar nu altele.

Oricum - multe benchmark-uri de securitate recomandă interzicerea SSH-ului și chiar interzicerea root-ului de pe consolă în sine. Fac asta numai dacă pot fi sigur de instrumentele mele de backup/reconstrucție/imuabile infra, deoarece altfel nu există nicio modalitate de a reveni pe server fără a face niște trucuri de pornire live-CD.

Aceasta este pur și simplu o problemă de securitate versus comoditate.

Conectarea ca root va fi întotdeauna mai convenabilă, dar semnificativ mai puțin sigură. Deci, dacă sunteți de acord cu aceste avertismente, vă puteți conecta ca root.

Cu toate acestea, cu cât compania dvs. este mai mare, cu atât se va ocupa de securitate mai serioasă.

De exemplu, angajatorul meu actual este o companie cu peste 50.000 de angajați în 5 țări. Obținerea de autentificare ROOT este absolut imposibilă. Și obținerea accesului SUDO durează, de asemenea, aproximativ 2 săptămâni, cu aprobarea de la nivelurile de Director.

Dacă utilizați chei ssh, este de obicei destul de sigur să faceți ssh direct la root în loc să faceți utilizatori „Proxy” confuzi.