Jak zmienić nazwę roota?

Nie dlatego, że warto to zmienić, ale dla zabawy. Według tego wątku, nadal istnieją pewne problemy, nawet po zmianie wpisów /etc/passwd, /etc/shadoworaz /etc/sudoers. Jakieś sugestie?

Teoretycznie zmieniając to /etc/passwdi /etc/shadowwszystko, czego potrzebujesz, aby zmienić nazwę roota. Problem występuje, ponieważ prawie każdy istniejący program uniksowy zakłada, że ​​nazwa użytkownika „root” istnieje i że jest to superużytkownik - aliasy poczty, różne demony, cron ...

Jeśli naprawdę zależy ci na wypróbowaniu go, find /etc -type f -exec grep -l root {} +powinieneś zacząć od znalezienia listy wszystkich plików konfiguracyjnych, które prawdopodobnie musisz zmienić - ale jak już powiedziałeś, jest to naprawdę zły pomysł w prawie każdej możliwej sytuacji.

EDYCJA Kolejna myśl - jeśli jeszcze tego nie zrobiłeś (co powinieneś ), upewnij się, że /etc/aliaseszawiera wpis rooti nazwę użytkownika lub adres e-mail, który jest oceniany poprawnie. Wiele zautomatyzowanych zadań systemowych ( cronna przykład) wysyła swoje wyniki pocztą elektroniczną na adres root, który jest tradycyjnie aliasowany do administratorów systemów odpowiedzialnych za operacje tego systemu.

Cały ten strach walczy, mówiąc: „Nie rób tego!” jest niedorzeczny. Pewnego razu tak, prawdopodobnie złamało wiele źle napisanych skryptów, ale podejrzewam, że nie są już tak powszechne; przynajmniej nie w standardowych dystrybucjach.

Powiedziano nam, aby zmienić nazwę konta root na podzbiorze serwerów Linux. Po próbie zbadania, jak zrobić to poprawnie, znalazłem wiele postów z napisem „Nie rób tego!” z wieloma strasznymi ostrzeżeniami o „złych rzeczach”, jeśli zdecydujesz się to zrobić. Ale muszę jeszcze znaleźć jakieś konkretne przykłady „złych rzeczy”, które mogą się zdarzyć.

Więc pozwól mi wrócić i wyjaśnić, gdzie jestem i jak się tu dostaliśmy. Budujemy środowisko zgodne z PCI, a jedno z narzędzi, które pomaga nam spełnić te „wymagania”, mówi nam, że musimy zmienić nazwę konta root oraz konta administratora i gościa na coś innego. Dla osób niewykształconych w zakresie PCI masz możliwość albo przestrzegania wytycznych, albo udokumentowania, dlaczego nie możesz lub nie chcesz stosować się do tych wytycznych, i jaką strategię łagodzenia musisz zachować dla bezpieczeństwa systemów. Tak więc wyobrażam sobie, że większość miejsc dokumentuje, dlaczego nie zamierzają zmieniać nazw swoich kont root, jednak nasza grupa zdecydowała, że ​​jeśli możemy bez problemu zmienić nazwę kont administratora Windows, zmienią też nazwę kont root.

Jestem dobrze zaznajomiony z argumentami „bezpieczeństwo przez zaciemnienie”; Wiem, że zmiana nazwy konta root tak naprawdę nie poprawia bezpieczeństwa, rootowanie powinno być wyłączone w SSH itp. Wiem, że nie o to chodzi, nie chcę więcej słyszeć. Nie interesuje mnie też więcej ostrzeżeń „spadnie niebo”. Szukam takich stwierdzeń: „> ta zła rzecz <stanie się z> tym standardowym pakietem <(chyba że> to zrobisz <)”.

Do tej pory mam 3 systemy CentOS (RHEL), które najwyraźniej nie mają problemów ze zmianą nazwy konta root. Oto co zrobiłem: Zmieniłem nazwę konta w / etc / passwd, / etc / shadow, / etc / group i / etc / gshadow. Następnie grep dla nazwy root w / etc / i zmodyfikował plik aliasów Postfiksa, aby root był aliasem dla naszej nowej nazwy konta, nazwij to rojotoro. (Coś podobnego należy zrobić w przypadku innych systemów e-mail). Odkryłem również, że muszę zmienić niektóre konfiguracje programu logrotate, opisując, kto powinien być właścicielem plików, które utworzy automatycznie. I to wszystko zmieniłem do tej pory.

Przejrzałem wiele skryptów init.d, ale nic nie zmieniłem i wszystko wydaje się, że wszystko zaczyna się dobrze przy starcie. Muszę podać nowe konto, gdy używam sudo: „sudo -u rojotoro vim / etc / passwd” jako przykład, ale tak naprawdę nie musiałem nic zmieniać w pliku sudoers. Spodziewałem się może pewnych problemów z selinux, które mamy i które egzekwujemy, ale jak dotąd nie musiałem dotykać tego systemu.

Widzę też, że skrypty mkdev lub mkfs mogą wymagać dostosowania, ale nie planuję ich używać, więc nie spojrzałem na nie z taką uwagą, na jaką zasługują.

Jeśli naprawdę łatwo jest to zmienić bez negatywnych skutków dla systemu obsługującego selinux, to dlaczego kontynuacja całego strachu?

sugestia: nie rób tego.

Niektóre narzędzia próbują rozmawiać z rootem przez UID, tam nie powinieneś mieć problemów. niektóre narzędzia zakładają, że twoje konto root nazywa się root i ulegnie awarii. chyba że jesteś przygotowany, na przykład, dla ponownej kompilacji połowy systemu „dla zabawy”, po prostu nie próbuj.

Moim zdaniem najłatwiej jest stworzyć nowego użytkownika (alias) o UID 0 i /rootjako dom.

Dlaczego nie przełączysz domyślnej powłoki roota na ( /bin/falselub /sbin/nologinnikt nie może się do niej zalogować, ale system nadal z niej korzysta) i zalogować się do utworzonego nowego aliasu?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

Jeśli zmienisz powłokę roota na nologin, sudo, mail lub ftw nie zostaną uszkodzone.

Linux nie jest systemem Windows, a nazwy root nie można obecnie łatwo zmienić bez tworzenia nieznanych przyszłych problemów.

Wyłączenie zdalnego, a nawet lokalnego logowania jako root to bezpieczniejsze podejście, ponieważ aktywnie wyłącza rootowanie konta! UBUNTU zasadniczo to robi i wymusza sudo zamiast dostępu do roota.

Zasadniczo nikt nie może używać konta roota do atakowania twojego systemu, ponieważ nie można go już używać do logowania się do systemu!

Byłoby miło, gdyby utworzono standardowy sposób łatwej modyfikacji zarówno nazwy konta root, jak i losowego generowania jego identyfikatora UID podczas instalacji i, jeśli to możliwe, przy każdym zimnym starcie, aby zapobiec celowaniu UID, ale to obecnie nie istnieje.

Dostosowywanie / etc / passwd Zmień root: x: 0: 0: root: / root: / bin / nologin

Utwórz jedno zastępcze konto administratora TYLKO DO UŻYTKU W SYTUACJACH AWARYJNYCH! fallbackadmin: x: 0: 0: root: / root: / bin / bash

Wdróż sudo dla wszystkich administratorów, aby można było wdrożyć kontrolę dziennika zmian, aby dokładnie śledzić, kto wprowadza zmiany w zakresie odpowiedzialności!

To implementuje wymagania PCI US Gov w celu wyłączenia domyślnych kont administratora / gości i utworzenia pojedynczego konta administratora do użytku awaryjnego.

Jednym ze sposobów archiwizowania dzienników do kontroli jest zebranie historii terminali od wszystkich użytkowników z dostępem do konta sudo, jeśli scentralizowane AAA nie jest zaimplementowane.

Rozwiązaniem do wdrożenia kont tylko dla administratorów jest utworzenie jednego konta tylko dla użytkownika i jednego konta z włączonym sudo, a następnie zmusienie użytkownika do zalogowania się na konto z włączonym sudo w celu uzyskania dostępu administracyjnego.

Możesz także zaimplementować uwierzytelnianie za pomocą karty inteligentnej, jeśli chcesz poprawić bezpieczeństwo, dostępne są rozwiązania dla systemu GNU / Linux, które są porównywalne z rozwiązaniami CAC dla US Common Access Card dla uwierzytelniania dwuskładnikowego.