Zyski płynące z blokady logowania użytkownikiem ROOT

Pytania i problemy
tirex
tirex

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:

  1. 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.

  2. 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).

  3. 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ą:

  1. 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.
  2. 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.
  3. 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.

[u]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ć. [/u]

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 https://lvlup.rok.ovh/t/nigdy-nie-pracuj-na-koncie-root/6048

Axerr
Axerr

Według mnie tworzenie osobnego konta, które nawet posiada uprawnienia sudo jest opłacalne. Nie tylko z wymienionych przez Ciebie względów:

  • nieznajomość loginu przy jednoczesnym posiadaniu klucza
  • konieczności wpisania magicznego słowa klucz -- "sudo" przed komendami tego wymagającymi

Zakładając, że ktoś uzyska nieautoryzowany dostęp do naszego konta przy użyciu dziurawej, wadliwej aplikacji uruchomionej na takim koncie -- wykluczając wszystkie podatności podnoszenia uprawnień -- atakujący będzie potrzebował jeszcze hasła do konta. Jeżeli tandetna aplikacja będzie uruchomiona na użytkowniku root -- atakujący, który uzyskał dostęp ma wolną rękę co do systemu.

Przykładem może być, chociażby niedawno odnaleziony błąd w Log4J. Było o nim dość głośno. Jedną wiadomością w Minecraftcie atakujący był w stanie otworzyć połączenie reverse shell. Gdyby aplikacja serwera Minecraft uruchomiona była na koncie root -- pełne uprawnienia są na wyciągnięcie ręki. Jeżeli administrator pomyślał wcześniej i stworzył osobne konto i ustawił mu hasło, którego entropia jest dość wystarczająca, aby skutecznie zniwelować możliwość zastosowania ataku bruteforce na takie konto (czyt. >200 bit) -- śmiałek nadal potrzebuje wklepać hasło, aby wykonać działania administracyjne.

Generalnie odwdzięczającą się regułą jest pozostawienie konta root dla operacji administratorskich, a zwykłe aplikacje/procesy uruchamiać na standardowym użytkowniku.

Nieznajomy11
Nieznajomy11 Moderator forum.lvlup.pro

tirex:

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ń.

tirex:

Niewątpliwie konieczność korzystania z sudo będzie chronić serwer przed samymi nami.

Nie będzie, jeśli wraz z takim setupem administracja stanie się bardziej uciążliwa, a finalnie pojawi się nawyk dodawania niepotrzebnie sudo (przyznać się, ile z was dodaje -rf lub inne "zbędne" parametry do każdego rm?). Użytkownika nie da się naprawić.

tirex:

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.

Konfiguracja z sudo może miała więcej sensu dawno temu, dla bardziej zaawansowanych użytkowników. Teraz właśnie będzie natomiast prawdopodobnie taki admin żyć w świecie automatyzacji, gdzie nie musi wpisywać rm -rf /home /myoldserver (spacja) z palca, a być może wszystko jest z auto provision i głównie stateless. Dalej może nawet wiele środowisk, czy też canary stages, które dają większe szanse na wyłapanie problemu wcześniej. Skoro admin z głową, to potem jeszcze ostatnia linia obrony — kopie zapasowe.

tirex:

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.

Całą tę sekcję teoretyzowania o włamaniach i zostawianiu kluczy w losowych miejscach można podsumować, że jak ktoś ma aż takie obawy, to powinien mieć przynajmniej silne passphrase na swoim kluczu, a być może logowanie do serwerów z yubikey. Sudo, czy zmiany użytkownika tutaj kompletnie nic nie zamieniają dla targetowanego ataku — skoro ktoś może poznać adresy serwerów, bo ma dostęp do jednego z naszych serwerów/urządzen, to znalezienie użytkownika pewnie nie będzie trudne, nawet przez brute-force (co pewnie nie będzie potrzebne, bo, a to log, a to konfiguracja dla wygody). Używanie nazw użytkownika, które są hasłami, może sobie odpuścimy, bo to user-hostile, jeszcze bardziej nieskuteczna konfiguracja, gdzie aż się prosi o zapisanie gdzieś tego.

tirex:

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

Bardzo dziwna skala, proponuję:

  1. hasło
  2. klucz ssh
  3. sensowny klucz ssh + sensowne passphrase
  4. sensowny klucz ssh + sensowne passphrase + yubikey

Dodatkowe punkty za setup z firewallem/vpn, ale w przypadku wszystkiego poza hasłem to głównie potencjalna ochrona dla bardziej wyrafinowanych ataków, z czego i tak nie daje żadnej gwarancji, a przy yubikey jest praktycznie zbędna. Jak już się bawimy w skrajności to zawsze potencjalny 0day — no dobra, nie żartujmy sobie aż tak — wykorzystanie dziurawego oprogramowania bez aktualizacji od lat mniej.

Pozwolę też nie zgodzić się co do przydzielenia 10/10 dla dostępu do ssh tylko z localhost. Może nie jest to stricte ssh, ale wątek to głównie rożważania co do security, więc — a to IPMI, a to po prostu podatności samego systemu poza ssh. Zabezpieczenie SSH nic nie da jeśli stoi na otwartym porcie otwarta vestacp dziurawa jak sito... 😎

Axerr:

Przykładem może być, chociażby niedawno odnaleziony błąd w Log4J. Było o nim dość głośno. Jedną wiadomością w Minecraftcie atakujący był w stanie otworzyć połączenie reverse shell. Gdyby aplikacja serwera Minecraft uruchomiona była na koncie root – pełne uprawnienia są na wyciągnięcie ręki.

Administrowanie z serwerem z określonego konta nie jest równoznaczne z dobrymi praktykami uruchamiania aplikacji. Prędzej osoba, która dostanie konto usera będzie robić hacki i inne rzeczy, bo zacznie mieć problemy z uprawnieniami albo innymi, jeszcze bardziej skomplikowanymi rzeczami.

Opalanie serwera Minecraft na własnym użytkowniku nic nie daje, jeśli nie zadba się o oddzielnego użytkownika na każdy podserwer i odebranie odczytu do innych. Chyba nie muszę mówić, że konieczność zarządzania z np. 5 kont jest dość problematyczna i bardzo łatwo się potknąć. Zdaje sobie sprawę, że domyślnie nie będzie np. możliwości modyfikacji zasobów systemowych, czy innych trybów, ale to dużo nie zmienia — sprofilowany atak i wykradnięcie wszystkich danych z serwera to niestety klops.

Axerr:

Generalnie odwdzięczającą się regułą jest pozostawienie konta root dla operacji administratorskich, a zwykłe aplikacje/procesy uruchamiać na standardowym użytkowniku.

Problemy, problemy i problemy. Dla procesów, które wymagają każdego grama wydajności, są jakimiś hypervisorami — może tak, ale niekoniecznie, np. performance hit natowania przez dockera, można w większości ominąć, używając host networking.

Zaawansowany użytkownik może użyć konteneryzacji, która zapewnia faktyczną izolację i kontrolę nad środowiskiem, a nie "wydaje mi się, że dany proces nie ma dostępu do x". To najłatwiejsze i dość solidne rozwiązanie.

Jest tutaj parę haczyków takich jak nie dawanie kontenerom nadmiernych "uprawnień" czy to bezpośrednio, czy to przez podpinanie lokacji z hosta, ale domyślnie wszystko jest dramatycznie bardziej bezpieczne.

system
system

Ten temat został automatycznie zamknięty 32 dni po ostatnim wpisie. Tworzenie nowych odpowiedzi nie jest już możliwe.