Dlaczego logowanie użytkownika root przez SSH jest tak złe, że wszyscy radzą go wyłączyć?

83

Wszyscy w Internecie radzą wyłączyć logowanie roota przez SSH, ponieważ jest to zła praktyka i dziura w systemie bezpieczeństwa, ale nikt nie wyjaśnia, dlaczego tak jest.

Co jest takiego niebezpiecznego w włączaniu logowania roota (szczególnie przy wyłączonym logowaniu się hasłem)?

Jaka jest różnica między nazwą użytkownika symbolu X a hasłem symbolu Y lub nazwą użytkownika root a hasłem symbolu X + Y z punktu widzenia bezpieczeństwa, na wypadek gdyby autoryzacja hasłem była dozwolona?

ssh security root wysypka
źródło
2
Posiadanie użytkownika root w większości systemów jest samo w sobie złe, nie wspominając o umożliwieniu logowania SSH dla tego użytkownika!
Suman,
1
Korzeń logowanie przez ssh jest konieczne dla ehealth-aussie.blogspot.com/2012/01/... . Wszystko jest kompromisem.
emory
2
Umm ... powinniśmy przenieść to pytanie do bezpieczeństwa? Ponieważ temat dotyczy bardziej bezpieczeństwa niż systemów * nix.
Braiam
Istnieje administracyjny powód wyłączenia rootowania. Na serwerach komercyjnych zawsze chcesz kontrolować dostęp osobiście. root nigdy nie jest osobą. Nawet jeśli pozwalają niektórzy użytkownicy mają dostęp do katalogu głównego, należy zmusić ich, aby zalogować się za pomocą własnej użytkownika, a następnie su -albo sudo -idlatego, że ich rzeczywista logowania mogą być nagrywane. To sprawia, że ​​odwołanie całego dostępu do osoby jest znacznie prostsze, więc nawet jeśli mają hasło roota, nie mogą nic z tym zrobić.
Philip Couling

Odpowiedzi:

62

Dlaczego rootowanie przez SSH jest złe

Istnieje wiele botów, które próbują zalogować się do komputera za pośrednictwem SSH. Te boty działają w następujący sposób.

Wykonują coś podobnego, ssh root@$IPa następnie próbują standardowych haseł, takich jak „root” lub „password123”. Robią to tak długo, jak to możliwe, dopóki nie znajdą odpowiedniego hasła. Na ogólnodostępnym serwerze możesz zobaczyć wiele wpisów w swoich plikach dziennika. Mogę zwiększyć do 20 na minutę lub więcej.

Gdy atakujący mają szczęście (lub wystarczająco dużo czasu) i znajdują hasło, mają dostęp do konta root, a to oznacza, że ​​masz kłopoty.

Ale jeśli nie zezwolisz rootowi na logowanie się przez SSH, bot musi najpierw odgadnąć nazwę użytkownika, a następnie pasujące hasło. Powiedzmy, że lista prawdopodobnych haseł zawiera Nwpisy, a lista prawdopodobnych użytkowników jest Mduża. Bot ma zestaw N*Mwpisów do przetestowania, więc jest to nieco trudniejsze dla bota w porównaniu z przypadkiem root, gdzie jest to tylko zestaw wielkości N.

Niektórzy powiedzą, że to dodatkowe Mnie jest prawdziwym zyskiem w zakresie bezpieczeństwa i zgadzam się, że jest to tylko niewielkie ulepszenie bezpieczeństwa. Ale myślę o tym bardziej jako o tych małych kłódkach, które same w sobie nie są bezpieczne, ale utrudniają wielu ludziom łatwy dostęp. Jest to oczywiście ważne tylko wtedy, gdy twój komputer nie ma innych standardowych nazw użytkowników, takich jak tor lub apache.

Lepszym powodem, aby nie zezwalać na rootowanie, jest to, że root może wyrządzić o wiele więcej szkód na komputerze niż zwykły użytkownik. Jeśli więc przy odrobinie szczęścia znajdą hasło, cały system zostanie utracony, a przy standardowym koncie użytkownika można tylko manipulować plikami tego użytkownika (co jest nadal bardzo złe).

W komentarzach wspomniano, że normalny użytkownik może mieć prawo do korzystania, sudoa jeśli odgadnie hasło tego użytkownika, system również zostanie całkowicie utracony.

Podsumowując, powiedziałbym, że nie ma znaczenia, które hasło użytkownika otrzyma atakujący. Kiedy odgadną jedno hasło, nie możesz już ufać systemowi. Osoba atakująca może wykorzystać prawa tego użytkownika do wykonywania poleceń sudo, osoba atakująca może również wykorzystać słabość systemu i uzyskać uprawnienia roota. Jeśli atakujący miał dostęp do twojego systemu, nie możesz już mu ufać.

Należy pamiętać, że każdy użytkownik w twoim systemie, który może logować się przez SSH, jest dodatkową słabością. Wyłączając root usuwasz jedną oczywistą słabość.

Dlaczego hasła nad SSH są złe

Powód wyłączenia haseł jest naprawdę prosty.

  • Użytkownicy wybierają złe hasła!

Cały pomysł wypróbowania haseł działa tylko wtedy, gdy można je odgadnąć. Kiedy użytkownik ma hasło „pw123”, twój system staje się niepewny. Innym problemem związanym z hasłami wybranymi przez ludzi jest to, że ich hasła nigdy nie są tak naprawdę losowe, ponieważ byłoby to trudne do zapamiętania.

Ponadto zdarza się, że użytkownicy ponownie używają swoich haseł, logując się na Facebooku lub na swoich kontach Gmail i na serwerze. Gdy haker otrzyma hasło do konta tego użytkownika na Facebooku, może dostać się na Twój serwer. Użytkownik może łatwo zgubić go przez phishing lub serwer Facebooka może zostać zhakowany.

Ale kiedy używasz certyfikatu do logowania, użytkownik nie wybiera swojego hasła. Certyfikat oparty jest na losowym ciągu, który jest bardzo długi od 1024 bitów do 4096 bitów (hasło ~ 128 - 512 znaków). Ponadto ten certyfikat służy tylko do logowania się na serwerze i nie jest używany z żadnymi usługami zewnętrznymi.

Spinki do mankietów

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Ten artykuł pochodzi z komentarzy i chciałem nadać mu nieco bardziej widoczną pozycję, ponieważ zagłębia się nieco w sprawę botnetów, które próbują zalogować się przez SSH, jak to robią, jak wyglądają pliki dziennika i co można zrobić, aby ich powstrzymać. Zostało napisane przez Petera Hansteena.

Raphael Ahrens
źródło
10
Dobre podsumowanie. Ale klucze prywatne ssh również mogą zostać skradzione.
Faheem Mitha,
16
@Faheem Mitha Tak, ale skradziony różni się od zgadywania, co robią boty. Również twój klucz prywatny jest tylko w twoich rękach (lub na dysku twardym), a nie w rękach stron trzecich, takich jak Stack Exchange lub Google.
Raphael Ahrens,
2
+1. Ta odpowiedź może sprowadzać się do prostego N*M > N. Ponieważ większość hostów * nix ma rootużytkownika, jeśli zezwolisz rootowi na logowanie się bezpośrednio z hosta zdalnego, rozmiar matrycy testowej to liczba haseł do wypróbowania; nie zezwalając na bezpośrednie logowanie do konta root, liczba możliwych kombinacji mnożona jest przez liczbę nazw użytkowników, które chcesz przetestować (i nadal nie ma gwarancji, że będziesz testować prawidłowe nazwy użytkowników!).
CVn
3
@ MichaelKjörling Chciałbym dodać, że uzyskanie nazwy użytkownika nie jest trudne, ponieważ zwykle nazwa użytkownika nie jest tajna i prawdopodobnie mógłbym poprosić kogoś o jej uzyskanie. Ale pomaga w walce z botami i prostymi próbami.
Raphael Ahrens,
2
@ Każdy, jeśli nazwa użytkownika ma symbole X i hasło Y, # of X length words* # of Y length wordsmożna wypróbować * kombinacje. Gdy nazwa użytkownika jest stała (np. Root), ale hasło ma długość X + Y, # of X+Y length wordsmożliwe są hasła. I # of X+Y length words=# of X length words * # of Y length words
skarap
10

Mogą to być niektóre z powodów, dla których bezpośrednie logowanie do roota nie powinno być dozwolone.

  • Bruteforce próbuje. Bezpośrednie logowanie do roota może spowodować większe obrażenia podczas udanego ataku bruteforce.
  • Nieprawidłowa konfiguracja kluczy SSH „bez hasła” (zdarza się błąd ludzki) może narazić komputer na działanie Internetu

Ale to tylko WSKAZÓWKA góry lodowej. Musisz skonfigurować inne ograniczenia i konfiguracje, takie jak:

  • Zmień domyślny port (22)
  • Silne hasła i hasła
  • Wyłącz uwierzytelnianie oparte na hoście
  • Utwórz listę dozwolonych użytkowników
  • Skonfiguruj limit czasu bezczynności
  • Wymuś protokół SSHv2
  • Wyłącz puste hasła
  • Użyj fail2ban jako środka przeciwko brutalnej sile
  • Zaloguj wszystko
  • Skonfiguruj klucze SSH i ufaj tylko kluczom publicznym w .ssh / uprawnione_ klucze

źródło
5
„Bezpośrednie logowanie roota może spowodować większe obrażenia podczas udanego ataku bruteforce”. Nie bardzo, w porównaniu z domyślną sudokonfiguracją. Prawdziwy zabójca to efekt multiplikacji, gdy nie masz jednej nazwy użytkownika, na którą można liczyć, że będzie ważna na danym hoście.
CVn
@ MichaelKjörling - Tak, na pewno, że pomieszane sudo może być tak samo szkodliwe jak PermitRoot;)
Zobacz unix.stackexchange.com/a/2944/9454
Martin Schröder
1
Zmiana portu jest w rzeczywistości szkodliwa w wielu scenariuszach sama w sobie. I nie jest to nic więcej niż bezpieczeństwo przez zaciemnienie.
0xC0000022L,
+1 za wzmiankę o fail2ban, ponieważ ataki brutalne nie dotyczą tylko SSH, ale także wszystkiego innego na maszynie. Nie musisz uzyskiwać nigdzie uprawnień administratora ani systemu, aby „przejąć” maszynę w celach praktycznych (dostęp do prywatnych danych, wykorzystanie jako zrzut pliku, użycie do phishingu itp.).
Eric Grange
8

Masz rację, że nazwa użytkownika root i hasło symbolu X + Y są kryptograficznie co najmniej tak bezpieczne, jak nazwa użytkownika symbol X + hasło symbolu Y. W rzeczywistości jest to jeszcze bardziej bezpieczne, ponieważ nazwiska ludzi są łatwe do odgadnięcia (boty mogą po prostu wypróbować Johna, Mike'a, Billa itp. ... i tak dalej: to właśnie robi wielu z nich zamiast próbować rootowania). I szczególnie nie masz szczęścia, jeśli jest to atak ukierunkowany, ponieważ jeśli ktoś chce złamać serwer firmy, nie byłoby problemu ze znalezieniem nazwy (pseudonimu) sysadmin.

A gdy tylko atakujący uzyska dostęp do konta, którego sysadmin używa do logowania ssh (a następnie używa sulub sudowykonuje swoje zadania), może zainfekować sesję tego użytkownika programem, który wyśle ​​hasło roota atakującego, gdy sysadmin wpisze następne czas.

Jest to dowolny rodzaj loginu głównego, który jest (lub powinien być) uważany za złą praktykę z punktu widzenia bezpieczeństwa. „Normalny” login użytkownika -> łańcuch su / sudo dodaje ścieżkę audytu. Mówiąc wprost: pozwala dowiedzieć się, kto co zrobił.

Szczególnym przypadkiem może być ten, w którym tylko jedna osoba ma dostęp do konta root. W takim przypadku użycie dodatkowego „normalnego” użytkownika nie doda dużej wartości (przynajmniej nigdy nie widziałem tej wartości). Ale i tak - powinieneś mieć prostego użytkownika w systemie (do zadań nieadministracyjnych, uruchamiania wget itp .;-)).

skarap
źródło
4

Co jest takiego niebezpiecznego w włączaniu logowania roota (szczególnie przy wyłączonym logowaniu się hasłem)?

Atakujący (bot / botnet / hacker) musi tylko odgadnąć hasło i ma pełną kontrolę nad systemem, jeśli jesteś otwarty na Internet. Ponadto żadne konto systemowe (dane www, serwer proxy itp.) Nie powinno być w stanie zalogować się przez SSH z tych samych powodów.

Jeśli wyłączyłeś logowanie hasłem (na przykład za pomocą klucza publicznego), weź pod uwagę, że ktokolwiek, kto przejmie klucz prywatny, uzyska pełną kontrolę nad systemem. Zobacz, dlaczego używanie klucza publicznego z użytkownikiem jest lepsze poniżej.

Jaka jest różnica między nazwą użytkownika symbolu X a hasłem symbolu Y lub nazwą użytkownika root a hasłem symbolu X + Y z punktu widzenia bezpieczeństwa, na wypadek gdyby autoryzacja hasłem była dozwolona?

Dodatkowa nazwa użytkownika może dodać warstwę bezpieczeństwa, ponieważ: a) osoba atakująca powinna znać zarówno parę, nazwę użytkownika, jak i hasło; b) w przypadku, gdy atakujący naruszy Twój system, nie będzie miał natychmiastowego dostępu do konta uprzywilejowanego, co doda odrobinę niuansów dla atakującego.

W tym przypadku klucz publiczny jest również plusem, ponieważ:

  1. Atakujący potrzebuje twojego klucza publicznego
  2. Atakujący potrzebuje hasła (lub metody uwierzytelnienia), aby uzyskać podwyższone uprawnienia
Braiam
źródło
1
Bardzo mało haseł, których używam, zawiera mniej niż około 20 losowych znaków alfanumerycznych (ustaw [A-Za-z0-9] plus kilka znaków specjalnych). 20 takich znaków (czyli długość 20 z zestawu znaków 40) daje w kolejności 10 ^ 32 kombinacji. 128 bitów entropii jest rzędu 10 ^ 38. Nie jest to wielka różnica, biorąc pod uwagę wszystko, a serwer SSH może dowolnie wdrażać dowolne ograniczenia prędkości, więc nie jest tak, że robisz w tym przypadku atak siłowy offline. Nie ma nic złego w hasłach, jeśli możesz żyć z nimi tak trudnymi do zapamiętania jak klucz 128-bitowy.
CVn
@ Michael Shh ... nie podawaj zasięgu, teraz hakerzy wiedzą, że powinni używać tęczowych tabel o długości 20 znaków ...?
Braiam
6
Tabele @Braiam Rainbow są użyteczne tylko wtedy, gdy atakujący ma dostęp do skrótów w celu wyszukiwania offline. W tym przypadku atakujący ma tylko odpowiedź serwera, aby zweryfikować, co jest prawdopodobnie ograniczone tylko do tylu prób - i znacznie wolniej.
Peter
@Peter podnosi, pomieszałem zarówno słownik, jak i skróty, ale w każdym razie OP zapytał, dlaczego nie powinien używać słabych lub pustych haseł, wiedźma jest niedorzeczna, dlatego przyszedłem z niedorzecznymi sytuacjami, dlaczego nie powinien. Przepraszam, że nie byłem interpretowany w ten sposób i zostałem uznany za FUD.
Braiam
2
Jeśli masz ochotę wypróbować jakieś 1,8 * 10 ^ 35 haseł (a to tylko dla zakresu od 18 do 22 losowych znaków z zestawu 40, a nie wiesz, które znaki spoza zestawu [A-Za-z0- 9] Używam), prawie powiedziałem, baw się dobrze. To około 117,1 bitów ekwiwalentu entropii (2 ^ 117,1 ~ 1,78 * 10 ^ 35) i jak zauważył @Peter, najprawdopodobniej będziesz musiał wykonać atak online . Przechowywanie wszystkich haseł (bez uciekania się do kompresji) wydaje się wymagać około 3,6 * 10 ^ 36 bajtów lub 3 * 10 ^ 24 TiB (a jeśli ta liczba jest błędna o kilka rzędów wielkości, kogo to obchodzi? ). Słowo kluczowe losowe .
CVn
1

Nie jest to takie złe, o ile podejmujesz środki ostrożności. Jako przykład możesz zainstalować CSF (Skonfiguruj zaporę serwera) i ustawić liczbę dozwolonych prób niepowodzenia, więc jeśli ktoś spróbuje, powiedzmy ponad 5 prób awarii, to są one automatycznie blokowane. Tak więc cała pierwsza część najlepszego odpowiadającego nie będzie wcale problemem. Zdarzyło mi się to wiele razy i na szczęście wszyscy wprowadzający zostali na stałe zablokowani. Myślę, że dla serwera nie jest to duży problem, jeśli jesteś jedyną osobą zarządzającą serwerem, ale oczywiście, jeśli jest wielu administratorów systemu lub pracujesz w organizacji, to oczywiście nie używaj korzeń. Wydaje mi się, że także w przypadku komputerów stacjonarnych użycie innego konta jest lepsze, ponieważ istnieje ryzyko bezpieczeństwa, ponieważ używasz dużo oprogramowania, ale na serwerze nie „ Jeśli wybierzesz losowe oprogramowanie, któremu nie ufasz, upewnij się, że utrzymujesz je na jak najniższym poziomie. Wniosek jest następujący: nie, to nie jest naprawdę szkodliwe, jeśli wiesz, jak prawidłowo zarządzać serwerem.

Don Dilanga
źródło