Cześć, za każdym razem jak konfiguruję nowy serwer Linux, zastanawiam się nad tym czy zyski płynące z tworzenia nowego użytkownika do logowania do systemu zamiast roota są na tyle duże żeby był sens robienia takiej konfiguracji.
Przyjrzę się kilku przykladom i postaram odpowiedzieć na pytanie: “Umożliwiać logowanie do ssh przy użyciu roota?”
W tym wątku będę brał pod uwagę scenariusze:
-
Użytkownik do logowania do systemu o nazwie fakeroot, z włączonym logowaniem tylko przy użyciu klucza ssh, ale fakeroot ma takie same uprawnienia jak root. Jedyna różnica to inna nazwa.
-
Użytkownik do logowania do systemu o nazwie abc, włączony logowaniem tylko przy użyciu klucz ssh, ale ma dostęp do sudo bez używania hasła (to jest istotne).
-
Logowanie do systemu przy użyciu użytkownika root, ale z włączonym logowaniem tylko przy użyciu klucza ssh.
Oczywiście na samym początku można zauważyć, że konfiguracja numer 2 jest lepsza od pozostałych. Konieczność użycia komendy sudo przed poleceniami, które mogą bardziej zaszkodzić systemowi od pozostałych chroni nasz system de facto od przypadkowego użycia tych poleceń.
Powiedzmy, że zdajemy sobie sprawę z tego, że nie musimy używać sudo, a wszystkie polecenia są wykonywane w sposób zautomatyzowany i są wcześniej sprawdzone, aby uniemożliwić przypadkowe uszkodzenie systemu.
Skoro nie mamy bezpośrednich zysków z używania sudo. To i tak właściwie jesteśmy zainteresowani tylko i wyłącznie zabezpieczeniem serwera przed nieautoryzowanym dostępem do niego. Rozpatrując kilka teoretycznych przypadków, postaram się wskazać różnicę między super-użytkownikiem pod domyślną nazwą root, a super-użytkownikiem pod bardziej unikalną nazwą:
- Potencjalnie inna nazwa super-użytkownika może chronić nas przed atakami typu bruteforce, ale prawdopodobnie nikt nie będzie na tyle zdeterminowany żeby próbować robić bruteforce klucza ssh. No, a jeśli nawet to pewnie nie starczy mu czasu.
- Jeśli kiedykolwiek klucz ssh dzięki któremu jest autoryzowany użytkownik wycieknie, a dostęp do SSH jest publicznie dostępny + nie korzystamy z niestandardowego portu. To inna bardziej unikalna nazwa super-użytkownika może ochronić serwer przed botami, które najpierw poszukują takie klucze w internecie, a później próbują się nimi logować (o ile takie istnieją). Jednak jest to trochę skrajna sytuacja, do której najpewniej nie będziemy chcieli dopuścić. Nawet jeśli do tego dopuścimy to raczej przypadkowo, ale ze świadomością o takiej rzeczy po np. przypadkowym wklejeniu klucza na pastebin, etc. Więc będziemy mieć szansę żeby od razu na to zareagować i zmienić klucze autoryzacyjne.
- Istnieje jednak szansa, że ktoś włamie się na naszą maszynę, na której trzymamy klucze ssh. To zakładam, że wtedy też taka osoba będzie potrafiła się dostać do adresów IP naszych serwerów, ich portów oraz nazw użytkowników, których używamy do logowania. No, ale jak wyżej - to raczej skrajny przypadek i włamywacz nie może dostać się do nazwy naszego użytkownika.
Podsumowanie
Niewątpliwie konieczność korzystania z sudo będzie chronić serwer przed samymi nami.
W momencie kiedy nie mamy bezpośrednich zalet z używania sudo. Nie widzę zbyt dużych zysków z korzystania z niestandardowej nazwy super-użytkownika.
Oczywiście w skrajnych przypadkach inna nazwa użytkownika będzie w stanie nas uchronić. No, ale przecież nie chcemy popadać w paranoje. Można spokojnie założyć, że nie dojdzie do tych skrajnych przypadków, bo musi wiele rzeczy ułożyć się po naszej myśli (nie jest to dla nas pozytywne, ale jak już do tego dojdzie to lepiej żeby tak się stało).
W mojej osobistej klasyfikacji w skali od 0 do 10, umiejscowię każdy z przypadków pod odpowiednią wartością liczbową żeby zobrazować jakie widzę zyski z każdej wymienionych wyżej metod:
0 - brak jakichkolwiek zabezpieczeń, logowanie użytkownika root bez potrzeby podania hasła
8.5 - użytkownik root z włączonym logowaniem tylko przy użyciu klucza ssh
8.6 - użytkownik fakeroot z włączonym logowaniem tylko przy użyciu klucza ssh
9 - niestandardowy użytkownik, ale z dostępem do sudo bez potrzeby używania hasła
10 - dostęp do ssh tylko z localhosta
Odpowiadając na pytanie: “Umożliwiać logowanie do ssh przy użyciu roota?” - Myślę, że można sobie na to pozwolić pod warunkiem, że nie chce mieć się dodatkowej bariery w postaci sudo przed użyciem “niebezpiecznych” poleceń oraz logujemy się przy użyciu klucza ssh.
Mam nadzieję, że moje przemyślenia nie mają z góry jakiegoś kardynalnego błędu.
Starałem się wziąć pod uwagę wiele punktów widzenia, ale tak żeby nie za bardzo skomplikować temat.
Jeśli jednak znajdzie się ktoś kto będzie chciał wypunktować: błędy ortograficzne, błędy logiczne oraz braki to zapraszam do dyskusji
Temat początkowo miał powstać żebym to ja uzyskał w nim odpowiedź, ale jak tak się bardziej zastanowiłem to na wiele rzeczy jestem sam w stanie sobie odpowiedzieć.
Dodatkowe wyjaśnienie
Umożliwienie logowania do ssh przy użyciu roota nie znaczy, że na co dzień będziemy z niego pracować, uruchamiać z niego aplikacje lub się logować na konto root. Nadal możemy mieć alternatywne konta. Chodzi tu tylko o sensowność blokowania tej możliwości.
Sam na co dzień korzystam z sudo oraz uruchamiam aplikacje z takim dostępem do serwera jakie są przez nie wymagane.
I zachęcam Cię żebyś Ty też pracował na co dzien zgodnie z tematem Nigdy nie pracuj na koncie ROOT
