Czy powinniśmy wyłączyć użytkownika root?

21

Czy powinniśmy usunąć hasło roota, wyłączyć zdalne logowanie i zasadniczo wymagać od administratorów korzystania z sudo do wykonywania czynności administracyjnych?

alternatywny tekst

jldugger
źródło

Odpowiedzi:

16

Wszystkie moje serwery mają wyłączone konto root ( sp_pwdpustawione na *). Jest to wymagane sudodla wszystkich uprawnień roota. [1] Ma to na celu skontrolowanie wszystkich działań administratora, aby ludzie mogli zobaczyć, co zostało zrobione w systemie.

Aby uzyskać bardziej hardcorową opcję, możesz sudozapisać w pliku dziennika (w przeciwieństwie do syslog) i ustawić, aby plik był dołączany tylko jako dodatek (przy użyciu chattrw systemie Linux lub chflagsBSD). W ten sposób nikt nie może później edytować audytu.

[1] Mam również zasadę, aby nie uruchamiać powłoki roota lub robić ucieczki powłoki z procesu roota. (Można jednak używać sudo sh -c '...'do wykonywania potoków lub przekierowań).

Chris Jester-Young
źródło
3
„Również nie działa pociski!” Uhm, czy wiesz, ile programów zawiera polecenie „drop to shell”? Jeszcze zanim zaczniesz patrzeć na kontrolę zadań powłoki ...
womble
Mówię o „bez powłoki” jako polityce, a nie opcji sudo. (sudo ma opcję noexec, ale oczywiście nie jest wodoszczelne, chyba że ograniczysz określone programy, które użytkownik może uruchomić.)
Chris Jester-Young
Czy można skonfigurować sudo tak, aby nie można było używać „sudo -s”? Używałem sudoerów tylko do konfigurowania poszczególnych poleceń.
@Graham: Możesz. Jednak, jak widać z powyższych komentarzy, to niczego nie powstrzyma, jeśli użytkownicy w inny sposób mogliby cokolwiek uruchomić. Jedynym wodoszczelnym rozwiązaniem jest podejście z białej listy, w którym wyszczególnia się konkretny program, który użytkownicy mogą uruchomić, i wszystkie muszą być dynamicznie połączone (aby opcja „noexec” mogła to zrobić).
Chris Jester-Young
Jako zasada, w której ufasz administratorom, jest to dobre. Możesz zobaczyć, jakie polecenia uruchamiają ludzie, co może być naprawdę pomocne, gdy próbujesz dowiedzieć się, co się zmieniło.
Hamish Downer
15

I stanowczo odradzam wyłączenie użytkownika root. Wyłącz lub ogranicz logowanie do roota (przez securetty i przez sshd_config i przez PAM i przez to, co masz) Jeśli twój system na to pozwala, ogranicz uprawnienia roota lub podziel rolę roota (podobnie jak robi to RSBAC .) Ale proszę , zrób to nie wyłączaj konta root poprzez usunięcie hasła, w przeciwnym razie zalogowanie się do systemu będzie niemożliwe sulogin. suloginjest używany przez wszystkie skrypty startowe, które znam w przypadku poważnych błędów zgłaszanych przez fsck - a to oznacza, że ​​zostaniesz zablokowany w systemie, jeśli główny system plików zostanie uszkodzony.

Wyjaśnienie: Przez „wyłączenie konta root poprzez usunięcie hasła” mam na myśli różne mechanizmy, które kończą się na! lub * w polu hasła / etc / shadow lub podobnym. Nie mam na myśli „zmień mechanizm logowania roota, aby nie pojawiał się monit o podanie hasła”.

Mihai Limbăşan
źródło
Czy jest to problem w systemach takich jak Ubuntu, które nigdy nie ustawiają hasła roota? Wydaje mi się, że jestem w stanie wykonać „sudo sulogin”, ale być może nie rozumiem aspektu krytycznego.
jldugger
Niestety nie znam sposobu, w jaki Ubuntu obsługuje rootowanie. Ale jeśli jesteś w stanie zrobić „sudo sulogin” i uzyskać powłokę roota bez monitu o hasło roota, to nie, to nie jest problem, ponieważ możliwe jest, że ten sam mechanizm zostanie zastosowany przy starcie systemu. Możesz spróbować szukać greg dla Sulogin poprzez skrypty inits, aby sprawdzić, kiedy i jak jest wywoływany.
Mihai Limbăşan
1
Ubuntu nie używa suloginu. Jeśli przejdziesz do trybu pojedynczego użytkownika, natychmiast otrzymasz powłokę root. Jednak przeczytaj mój komentarz (w moim poście), aby zobaczyć, dlaczego w większości przypadków nie stanowi to problemu.
Chris Jester-Young
Ponadto istnieją twierdzenia, że ​​posiadanie sulub sudow systemie dostępnym dla użytkowników oznacza większe ryzyko bezpieczeństwa, którego można uniknąć, jeśli masz tylko dedykowanych użytkowników root. Jest to stanowisko popierane przez autorów bezpiecznej dystrybucji Owl (a wśród nich projektanta Solar) - unix.stackexchange.com/questions/8581/... próbuje przedstawić swoje stanowisko za pomocą referencji.
imz - Ivan Zachharyaschev
Właśnie miałem ten bardzo problem: zablokowałem użytkownika root i fsck został zmuszony z powodu twardego resetu. Na szczęście mogłem uruchomić mój wadliwy Linux z fastbootopcją, odblokować konto root i uruchomić ponownie, aby w końcu uruchomić fsckręcznie.
tommyd
3

Mam włączone konto root na wszystkich moich serwerach. Wszyscy administratorzy mają własnego użytkownika i muszą się zalogować. Stamtąd przechodzą do rootowania. (root ssh jest wyłączony)

Utrzymuj liczbę administratorów na niskim poziomie. Tylko osoby, które naprawdę potrzebują dostępu do konta root na tym serwerze, mają hasło.

Nie jestem fanem sudo. Zbyt łatwo jest zrobić „sudo bash” dla powłoki roota. Wiem, że można to wyłączyć, ale po co? Po prostu ogranicz użytkowników, którzy mogą wykonywać zadania administratora i rozmawiać ze sobą. Mamy politykę, aby nie dopuszczać do otwierania terminali root bez nadzoru. Więc to zaloguj się, su, wykonaj pracę, wyloguj się.

Uwaga: Pracuję w dość małej firmie (50-coś pracowników) i radzimy sobie tylko z 2 administratorami w niepełnym wymiarze godzin (1 windows / 1 Linux). Ten sposób robienia rzeczy może nie być najlepszy, gdy masz o rząd wielkości więcej użytkowników. Osobiście nadal nie używałbym sudo. Istnieją inne sposoby rejestrowania aktywności użytkownika root.

Gert M.
źródło
Jeśli chcesz rootować z konsoli, możesz po prostu zrobić „sudo -i” zamiast otwierać go z sudo bash. Osobiście nie podoba mi się pomysł zalogowania się jako użytkownik root bezpośrednio, ponieważ jest to zbyt ryzykowne w przypadku złośliwych zagrożeń (tj. Przypadkowe pozostawienie komputera odblokowanego z otwartą powłoką roota).
Spoike
Jednak tracisz przy tym rejestrowanie / audyt. Niech wszyscy używają sudo i zabraniają ludziom wykonywania sudo bash, sudo -i lub sudo -s z zasadami firmy. To daje ścieżkę audytu, a jeśli przekazujesz wszystkie logi do centralnego loghosta, łatwo jest sprawdzić, czy ludzie przestrzegają zasad.
Christopher Cashell
Takie podejście przyjęli i popierają autorzy bezpiecznej dystrybucji Owl (a wśród nich projektant Solar) - unix.stackexchange.com/questions/8581/... próbuje przedstawić swoje stanowisko za pomocą referencji.
imz - Ivan Zachharyaschev
2

Wyłączenie hasła roota to fałszywy „dobry pomysł”. Tego dnia będziesz tego potrzebować, naprawdę będziesz tego potrzebować. (w zależności od konfiguracji może być konieczne zalogowanie się w trybie pojedynczego użytkownika)

Wyłączenie zdalnego logowania roota może być istotne, ale tylko wtedy, gdy możesz zalogować się lokalnie.

Tak, sudo powinno być zainstalowane na każdym serwerze. Jest użyteczny i łatwy w konfiguracji. Dlaczego nie chcesz go używać?

Benoit
źródło
Co się stanie, jeśli uruchomienie w trybie pojedynczego użytkownika jest opcją grub?
jldugger
Jaki jest cel wyłączenia konta root? Co zrobisz, jeśli zahamujesz swój plik binarny lub konfigurację sudo (lub jakiekolwiek inne narzędzie, którego używasz)?
Benoit
Disabling root remote login might be relevant but only if you are able to log on locally.To jest po prostu rażąco nieprawdziwe. Możesz zalogować się zdalnie za pomocą dowolnego konta; wyłączenie zdalnego logowania roota nie ogranicza dostępu lokalnego.
Dan
2

Po prostu wyłączam dostęp SSH dla roota i wymagam od użytkowników (często tylko programistów) korzystania z kluczy ssh. Po prostu jest zbyt wiele ataków słownikowych i zmiana portu SSH nie jest dla nas opcją.

W ten sposób nie musisz ufać nikomu w zdolności do napisania dobrego hasła. Wewnątrz tylko administratorzy mają uprawnienia do sudo.

pablasso
źródło
Zmiana portu SSH i tak jest bezcelowa. Prosty portcan łatwo go rozdaje. Kiedy telnet do portu 22 na moim komputerze, otrzymuję SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
Matt Simmons
@MattSimmons Tak, ale większość ataków słownikowych jest zautomatyzowana i bardzo elementarna. Nie zawracają sobie głowy skanowaniem portów; próbują połączyć się z losowymi adresami IP na porcie 22, a jeśli przekroczą limit czasu, przechodzą do następnego adresu IP na swojej liście. To nie jest środek bezpieczeństwa, tylko pomaga pozbyć się automatycznych ataków na port 22. Oczywiście atak ukierunkowany to zupełnie inna gra w piłkę.
Dan
2

Wiem, że ten wątek jest naprawdę stary, ale istnieją pewne poważne błędy w logice powiązanych artykułów i czuję się „rant'ie” - sudo pozwala zarówno na dodawanie do białej, jak i czarnej listy. Nie tylko czarne, jak określono w połączonym artykule - Pomija to pojęcie AAA (uwierzytelnianie, autoryzacja i audyt) - su & sudo pozwalają zarówno na stopniowe uwierzytelnianie, jak i rozliczalność.

Scenariusz 1 Administrator przypadkowo wprowadza do systemu jakiś fałszywy kod, zalogowany jako root, kod ma pełny dostęp i administrator może nigdy nie wiedzieć, co się stało. Przynajmniej przy stopniowanym logowaniu (np. Su / sudo) administrator zostanie poproszony o uwierzytelnienie, jeśli nieuczciwy kod spróbuje użyć podniesionych uprawnień ... Jeśli nie podniesie uprawnień, ograniczy się do praw użytkowników, co powinno spowodować minimalne szkody.

Scenariusz 2 Nieuczciwy administrator chce uzyskać informacje / wprowadzić zmiany. Łączą się z konsolą (fizyczny dostęp do konsoli, HP iLo / podobny lub dostęp do konsoli vGuest), logują się jako root i robią, co chcą. O ile do uzyskania dostępu do konsoli nie jest używane nazwane konto / karta dostępu, prawdopodobnie nie ma zbyt wiele śladu audytu.

  1. Upewnij się, że naprawdę są tym, za kogo się podaje. Kradzież tożsamości nie jest problemem, weryfikacja tożsamości jest.
  2. Sprawdź ich uprawnienia, daj im tylko to, czego potrzebują w tym czasie. Stopniowa autoryzacja pozwala im na podniesienie uprawnień, kiedy tego potrzebują.
  3. Audytuj to wszystko, miej zapis, abyś wiedział, kto, co zrobił, kiedy i gdzie. Najlepiej też
Mikrofon
źródło
1

Powinieneś wymagać, aby wszyscy używali sudo do każdego polecenia roota jako zasady. Nigdy nie ma powodu, aby uruchamiać „sudo bash” itp., Jest to tylko dla wygody, z powodu ignorancji lub dla zakrycia własnych śladów.

Jeśli wyłączysz logowanie bezpośrednio do konta root, utrudnisz naprawę systemu w przypadku poważnych problemów.

Jeśli nie możesz przekonać administratorów, aby zalogowali się jako sami i uruchomili sudo dla każdego polecenia uruchamianego jako root, i aby nie włamać się do powłoki, masz poważne problemy, dla których nie ma rozwiązania technicznego.

Carlito
źródło
1

Autorzy bezpiecznej dystrybucji Owl (i projektant Solar) mają dokładnie przeciwnie dokładnie uzasadniony punkt widzenia; patrz np. odpowiedź /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 dla prezentacja ich roszczeń. Problem kontroli działań superużytkownika (która osoba to zrobiła) jest również rozwiązany z ich punktu widzenia (w zasadzie rozwiązaniem jest posiadanie kilku użytkowników root o różnych nazwach).

imz - Ivan Zakharyaschev
źródło