Odpowiedzi:
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ń).
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”.
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.
fastbootopcją, odblokować konto root i uruchomić ponownie, aby w końcu uruchomić fsckręcznie.
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.
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ć?
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.
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.
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.
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.
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).