Jaki jest najbezpieczniejszy sposób uzyskania uprawnień roota: sudo, su lub login?

Chciałbym mieć konto root bezpiecznie, nawet jeśli mój nieuprzywilejowany użytkownik jest zagrożony.

W systemie Ubuntu domyślnie można używać sudo tylko ze względów bezpieczeństwa. Nie jestem jednak pewien, czy jest to bezpieczniejsze niż logowanie przy użyciu konsoli tekstowej. Jest zbyt wiele rzeczy, które mogą pójść nie tak, jeśli osoba atakująca może uruchomić kod jak mój normalny użytkownik. Na przykład dodawanie aliasów, dodawanie elementów do mojej ŚCIEŻKI, ustawianie keyloggerów LD_PRELOAD i X11, żeby wymienić tylko kilka. Jedyną zaletą, którą widzę, jest limit czasu, więc nigdy nie zapomnę się wylogować.

Mam takie same wątpliwości co do su, ale nie ma nawet limitu czasu. Niektóre operacje (szczególnie przekierowanie IO) są bardziej wygodne z su, ale ze względów bezpieczeństwa wydaje się, że jest gorzej.

Logowanie na konsoli tekstowej wydaje się najbezpieczniejsze. Ponieważ jest uruchamiany przez init, jeśli atakujący może kontrolować PATH lub LD_PRELOAD, jest już rootem. Zdarzenia naciśnięcia klawisza nie mogą zostać przechwycone przez programy działające na X. Nie wiem, czy programy działające na X mogą przechwycić [ctrl] + [alt] + [f1] (i otworzyć okno pełnoekranowe, które wygląda jak konsola) lub jest bezpieczny jak [ctrl] + [alt] + [del] w systemie Windows. Poza tym jedynym problemem, jaki widzę, jest brak limitu czasu.

Czy coś mi umknęło? Dlaczego faceci Ubuntu postanowili zezwolić tylko na sudo? Co mogę zrobić, aby poprawić bezpieczeństwo którejkolwiek z metod?

Co z SSH? Tradycyjnie root nie może zalogować się przez SSH. Ale użycie powyższej logiki nie byłoby najbezpieczniejszym rozwiązaniem:

• zezwalaj na rootowanie przez SSH
• przejdź do trybu tekstowego
• zaloguj się jako root
• ssh do drugiej maszyny
• zalogować się jako root?

Bezpieczeństwo zawsze polega na kompromisach. Podobnie jak przysłowiowy serwer, który jest bezpieczny, odłączony na dnie oceanu, rootbyłby najbardziej bezpieczny, gdyby w ogóle nie było możliwości uzyskania do niego dostępu.

Ataki LD_PRELOAD i PATH, takie jak te, które opisujesz, zakładają, że istnieje osoba atakująca, która ma już dostęp do twojego konta lub przynajmniej do plików dotfiles. Sudo w ogóle nie chroni przed tym zbyt dobrze - jeśli mają twoje hasło, w końcu nie musisz próbować oszukiwać cię na później ... mogą po prostu użyć sudo teraz .

Ważne jest, aby zastanowić się, do czego Sudo zostało pierwotnie zaprojektowane: przekazanie określonych poleceń (takich jak te do zarządzania drukarkami) „subadministratorom” (być może stopniowanym studentom w laboratorium) bez podawania root całkowicie. Używanie sudo do robienia wszystkiego jest obecnie najczęstszym zastosowaniem, ale niekoniecznie jest to problem, który program miał rozwiązać (stąd śmiesznie skomplikowana składnia pliku konfiguracyjnego).

Ale sudo-for-nieograniczony-korzeń ma rozwiązać inny problem bezpieczeństwa: zarządzania haseł korzeniowych. W wielu organizacjach są one zwykle przekazywane jak cukierki, zapisywane na tablicach i pozostawione na zawsze. Pozostawia to dużą podatność, ponieważ cofnięcie lub zmiana dostępu staje się dużą liczbą produkcyjną. Nawet śledzenie, która maszyna ma hasło, jest wyzwaniem - nie mówiąc już o śledzeniu, kto wie, który.

Pamiętaj, że większość „cyberprzestępczości” pochodzi z wewnątrz. Z opisaną sytuacją hasła roota trudno jest ustalić, kto co zrobił - coś sudo ze zdalnym logowaniem radzi sobie całkiem nieźle.

W twoim systemie domowym myślę, że bardziej chodzi o wygodę, że nie musisz pamiętać dwóch haseł. Jest prawdopodobne, że wiele osób po prostu ustawiało je tak samo - lub gorzej, początkowo były takie same, a następnie pozwalały im zsynchronizować się, pozostawiając hasło roota zepsute.

Używanie haseł w ogóle w SSH jest niebezpieczne, ponieważ trojanowane demony ssh wykrywające hasła są wdrażane w około 90% rzeczywistych kompromisów systemowych, które widziałem. O wiele lepiej jest używać kluczy SSH, i może to być również działający system do zdalnego dostępu do roota.

Problem polega jednak na tym, że przeszedłeś z zarządzania hasłami na zarządzanie kluczami, a kluczy ssh nie da się tak naprawdę zarządzać. Nie ma możliwości ograniczenia kopiowania, a jeśli ktoś zrobi kopię, podejmą wszystkie próby, by brutalnie wymusić hasło. Możesz wprowadzić zasady mówiące, że klucze muszą być przechowywane na urządzeniach wymiennych i montowane tylko w razie potrzeby, ale nie można tego egzekwować - a teraz wprowadziłeś możliwość zgubienia lub kradzieży urządzenia wymiennego.

Najwyższe bezpieczeństwo zapewni jednorazowe klucze lub tokeny kryptograficzne oparte na czasie / liczniku. Można to zrobić w oprogramowaniu, ale sprzęt odporny na manipulacje jest jeszcze lepszy. W świecie open source są WiKiD , YubiKey lub LinOTP , i oczywiście istnieje również zastrzeżony RSA SecurID . Jeśli jesteś w średniej lub dużej organizacji, a nawet w małej firmie dbającej o bezpieczeństwo, zdecydowanie polecam przyjrzenie się jednemu z tych podejść do dostępu administracyjnego.

Prawdopodobnie jest to przesada w domu, gdzie tak naprawdę nie masz problemów z zarządzaniem - o ile przestrzegasz rozsądnych praktyk bezpieczeństwa.

To bardzo złożone pytanie. mattdm omówił już wiele punktów .

Pomiędzy su i sudo, gdy rozważasz jednego użytkownika, su jest nieco bezpieczniejsze, ponieważ osoba atakująca, która znalazła twoje hasło, nie może natychmiast uzyskać uprawnień roota. Ale wystarczy, że atakujący znajdzie lokalną dziurę w katalogu głównym (stosunkowo rzadko) lub zainstaluje trojana i czeka, aż uruchomisz su.

Sudo ma przewagę nawet nad logowaniem do konsoli, gdy jest wielu użytkowników. Na przykład, jeśli system jest skonfigurowany ze zdalnymi dziennikami odpornymi na manipulacje, zawsze możesz dowiedzieć się, kto ostatnio uruchomił sudo (lub którego konto zostało naruszone), ale nie wiesz, kto wpisał hasło roota na konsoli.

Podejrzewam, że decyzja Ubuntu była częściowo w interesie prostoty (tylko jedno hasło do zapamiętania), a częściowo w interesie bezpieczeństwa i łatwości dystrybucji poświadczeń na współdzielonych komputerach (biznesowych lub rodzinnych).

Linux nie ma bezpiecznego klucza uwagi ani innego bezpiecznego interfejsu użytkownika do uwierzytelniania. O ile wiem, nawet OpenBSD nie ma żadnych. Jeśli obawiasz się o dostęp do roota, możesz całkowicie wyłączyć dostęp do roota z działającego systemu: jeśli chcesz być rootem, musisz wpisać coś w wierszu bootloadera. Nie jest to oczywiście odpowiednie dla wszystkich przypadków użycia. (* Bezpieczny poziom BSD działa w ten sposób: na wysokim poziomie bezpieczeństwa istnieją rzeczy, których nie można zrobić bez ponownego uruchomienia, takie jak obniżenie poziomu bezpiecznego lub bezpośredni dostęp do zamontowanych urządzeń raw.)

Ograniczenie sposobu, w jaki można zostać rootem, nie zawsze jest korzyścią dla bezpieczeństwa. Pamiętaj o trzecim członku triady bezpieczeństwa : poufność , integralność , dostępność . Zamknięcie się z systemu może uniemożliwić reagowanie na zdarzenie.

Projektanci zabezpieczonej dystrybucji OpenWall GNU / * / Linux również wyrazili krytyczne opinie na temat su(jak zostać rootem) i sudo. Być może zechcesz przeczytać ten wątek:

... niestety zarówno su, jak i sudo są subtelnie, ale zasadniczo wadliwe.

Oprócz omawiania wad sui innych rzeczy, Solar Designer ma również jeden konkretny powód do użycia su:

Tak, zwykłą mądrością sysadmin było „su root”, a nie logowanie jako root. Ci nieliczni, którzy zapytani, mogliby faktycznie przedstawić uzasadnienie tej preferencji, odnieśliby się do lepszej rozliczalności uzyskanej dzięki temu podejściu. Tak, to naprawdę dobry powód dla takiego podejścia. Ale to także jedyny. ...(Czytaj więcej)

W swojej dystrybucji „całkowicie pozbyli się programów rootujących SUID w domyślnej instalacji” (tj. W tym su; i nie używają do tego możliwości):

W przypadku serwerów myślę, że ludzie muszą ponownie rozważyć i, w większości przypadków, zabronić użytkownikom wywoływania su i sudo. Nie ma żadnych dodatkowych zabezpieczeń od starego „logowania jako użytkownik inny niż root, a następnie su lub sudo do rootowania„ mądrości ”sysadmin, w porównaniu do logowania jako użytkownik inny niż root i jako root (dwie oddzielne sesje). Przeciwnie, to drugie podejście jest jedyne prawidłowe z punktu widzenia bezpieczeństwa:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(W celu rozliczenia wielu sysadminów system musi obsługiwać wiele kont uprzywilejowanych jako root, jak robi to Owl).

(W przypadku komputerów stacjonarnych z X jest to trudniejsze.)

Musisz także absolutnie poradzić sobie z ...

BTW, mieli zastąpić suloginw msulogincelu umożliwienia konfiguracji z wieloma kontami korzeniowych: msuloginpozwala, aby wpisać nazwę użytkownika również podczas wchodzenia w trybie pojedynczego użytkownika (i zachować „odpowiedzialności”) (ta informacja pochodzi od tej dyskusji w języku rosyjskim ) .

Wydaje się, że zakładasz, że użycie sudozawsze zachowuje zmienne środowiskowe, ale nie zawsze tak jest. Oto fragment strony sudo:

Istnieją dwa różne sposoby radzenia sobie ze zmiennymi środowiskowymi. Domyślnie opcja env_reset sudoers jest włączona. Powoduje to wykonywanie poleceń w minimalnym środowisku zawierającym TERM, PATH, HOME, SHELL, LOGNAME, USER i USERNAME oraz zmienne z procesu wywoływania dozwolonego przez opcje sudoers env_check i env_keep. W rzeczywistości istnieje biała lista zmiennych środowiskowych.

Jeśli jednak opcja env_reset jest wyłączona w sudoers, wszelkie zmienne, które nie zostały wyraźnie odrzucone przez opcje env_check i env_delete, są dziedziczone z procesu wywoływania. W takim przypadku env_check i env_delete zachowują się jak czarna lista. Ponieważ nie jest możliwe umieszczenie na czarnej liście wszystkich potencjalnie niebezpiecznych zmiennych środowiskowych, zalecane jest użycie domyślnego zachowania env_reset.

We wszystkich przypadkach zmienne środowiskowe o wartości rozpoczynającej się od () są usuwane, ponieważ można je interpretować jako funkcje bash. Lista zmiennych środowiskowych, które sudo zezwala lub odrzuca, znajduje się w danych wyjściowych sudo -V, gdy jest uruchamiany jako root.

Jeśli więc env_resetjest włączony (domyślnie), atakujący nie może przesłonić twoich PATHlub innych zmiennych środowiskowych (chyba że dodasz je specjalnie do białej listy zmiennych, które powinny zostać zachowane).

Najbezpieczniejszym rozwiązaniem jest logowanie za pomocą ssh przy użyciu (co najmniej) długiego klucza 2048 (z wyłączonym logowaniem do hasła) za pomocą fizycznego urządzenia do przechowywania klucza.

Chcę tylko dodać coś nieco poza tematem. (w temacie jedno sprawdzenie „/ bin / su -” tutaj po)

Myślę, że powyższe „bezpieczeństwo” powinno być również powiązane z faktycznymi danymi, które chcemy zabezpieczyć.

Będzie i powinno być inaczej, jeśli chcemy zabezpieczyć: moja_data, moja_firma_dane, moja_firma_sieć.

Zwykle, jeśli mówię o bezpieczeństwie, mówię także o „bezpieczeństwie danych” i tworzeniu kopii zapasowych. Możemy również dodać systemy odporne na uszkodzenia i tym podobne.

Biorąc to pod uwagę, uważam, że bezpieczeństwo jako całość jest równowagą między użytecznością, „bezpieczeństwem danych” i wymaganym wysiłkiem w celu wdrożenia bezpiecznego systemu.

Ostatecznym celem Ubuntu był i nadal jest użytkownik końcowy: domyślnym jest Sudo.

Fedora to darmowa wersja RedHat, która z kolei jest bardziej zorientowana na serwery: Sudo było wyłączone.

W przypadku innych dystrybucji nie mam bezpośrednich informacji.

Używam teraz głównie fedory. Jako użytkownik starego stylu nigdy nie wpisałem „su”. Ale mogę wpisać „/ bin / su -” w bardzo krótkim czasie, nawet jeśli nie jestem maszynistą. Zmienna PATH .. nie powinna stanowić problemu (wpisuję ścieżkę). Również „-” (minus) w zasadzie powinien usunąć moje zmienne środowiskowe użytkownika i załadować tylko te główne. tj. unikanie dodatkowych możliwych problemów. Prawdopodobnie również LS_PRELOAD.

Co do reszty, chyba @mattdm był dość precyzyjny.

Ale umieśćmy to w odpowiednim polu. Załóżmy, że inteligentny zestaw skryptów ma dostęp do moich danych. Jak myślisz, do diabła, on zamierza z tym zrobić? - Opublikować moje zdjęcia? mój? - Próbujesz znaleźć imię mojej dziewczyny i powiedzieć jej, że odwiedzam strony porno?

Na zdjęciu jednego użytkownika dwie najgorsze sytuacje to: - Dziecko usuwa wszystkie moje dane: dla zabawy lub przez pomyłkę - Dziecko używa mojej maszyny, aby wykonać kolejny atak na inną jednostkę. Lub podobne cele.

W pierwszym przypadku wspomniałem powyżej, że lepiej jest położyć nacisk na tworzenie kopii zapasowych niż na bezpieczeństwo sieci. Tak, jesteś uratowany. Mam na myśli, że awaria sprzętu nie różni się tak bardzo.

Drugi przypadek jest bardziej subtelny. Ale są sygnały o tych działaniach. W każdym razie możesz zrobić to, co możliwe, ale nie skonfigurowałbym mojego domowego komputera do ochrony przed atakami terrorystycznymi!

Pominę inne scenariusze.

na zdrowie F

Jeśli chodzi o to, że do przechwycenia hasła użytego dla sudolub sumożna użyć przejętego konta użytkownika , a następnie użyć jednorazowego hasła dla sudoi su.

Możesz wymusić użycie kluczy dla zdalnych użytkowników, ale to może nie przejść zbiórki dla celów zgodności. Bardziej efektywne może być skonfigurowanie skrzynki bramy SSH, która wymaga uwierzytelnienia dwuskładnikowego, a następnie zezwala na użycie klucza stamtąd. Oto dokumentacja takiej konfiguracji: Zabezpiecz wdrożenie SSH za pomocą uwierzytelniania dwuskładnikowego WiKID .

Możesz także rzucić okiem na privacyIDEA , który nie tylko daje ci możliwość korzystania z OTP do logowania na maszynie (lub do wykonywania su / sudo), ale może także wykonywać OTP offline.

Ponadto jest w stanie zarządzać kluczami SSH. To znaczy, jeśli masz wiele komputerów i kilku użytkowników root, wszystkie klucze SSH są przechowywane centralnie. Dlatego łatwo jest „odwołać” / usunąć klucz SSH, jeśli nie można już mu ufać.

Oczywiście istnieją zadania organizacyjne i przepływy pracy w celu zabezpieczenia systemu.