Czy / usr / sbin / nologin jako powłoka logowania służy celowi bezpieczeństwa?

W moim /etc/passwdpliku widzę, że www-dataużytkownik używany przez Apache, a także różnego rodzaju użytkownicy systemu, mają powłokę logowania jako /usr/sbin/nologinlub /bin/false. Na przykład oto wybór linii:

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

W związku z tym, jeśli spróbuję zamienić się na któregokolwiek z tych użytkowników (co czasami chciałbym zrobić, aby sprawdzić, czy rozumiem ich uprawnienia, i które są prawdopodobnie inne co najmniej w połowie rozsądne powody), nie udaje mi się:

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

Oczywiście nie stanowi to dużej niedogodności, ponieważ nadal mogę uruchomić dla nich powłokę za pomocą metody takiej jak ta:

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

Ale to tylko sprawia, że ​​zastanawiam się, jaki jest cel , odmawiając tym użytkownikom powłoki logowania. Szukając wyjaśnień w Internecie, wiele osób twierdzi, że ma to coś wspólnego z bezpieczeństwem, i wszyscy wydają się zgadzać, że zmiana sposobu logowania tych użytkowników byłaby w pewnym sensie złym pomysłem. Oto zbiór cytatów:

Ustawienie powłoki użytkownika Apache na coś nieinteraktywnego jest ogólnie dobrą praktyką bezpieczeństwa (tak naprawdę wszyscy użytkownicy usług, którzy nie muszą logować się interaktywnie, powinni ustawić powłokę na coś, co nie jest interaktywne).

- https://serverfault.com/a/559315/147556

powłoka dla danych www użytkownika jest ustawiona na / usr / sbin / nologin i jest ustawiona z bardzo dobrego powodu.

- https://askubuntu.com/a/486661/119754

[Konta systemowe] mogą być lukami w zabezpieczeniach , szczególnie jeśli mają włączoną powłokę:

• Zły

  bin:x:1:1:bin:/bin:/bin/sh

• Dobry

  bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

Ze względów bezpieczeństwa utworzyłem konto użytkownika bez powłoki logowania do uruchamiania serwera Tomcat:

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

Chociaż posty te są jednomyślnie zgodne co do tego, że nieudzielanie użytkownikom systemu prawdziwych powłok logowania jest dobre dla bezpieczeństwa, żaden z nich nie uzasadnia tego roszczenia i nigdzie nie mogę go wyjaśnić.

Przed jakim atakiem próbujemy się chronić, nie dając tym użytkownikom prawdziwych powłok logowania?

Jeśli spojrzysz na nologinstronę podręcznika, zobaczysz następujący opis.

fragment

nologin wyświetla komunikat, że konto jest niedostępne i kończy działanie niezerowe. Ma to na celu zastąpienie pola powłoki, aby odmówić dostępu do konta.

Jeśli plik /etc/nologin.txtistnieje, nologinwyświetla jego zawartość użytkownikowi zamiast domyślnego komunikatu.

Kod wyjścia zwracany przez nologinto zawsze 1.

Tak więc faktyczna intencja nologinjest taka, że ​​gdy użytkownik próbuje zalogować się przy użyciu konta, które korzysta z niego, /etc/passwdjest wyświetlany przyjazny komunikat i że wszelkie skrypty / polecenia, które próbują użyć ten login otrzymuje kod wyjścia 1.

Bezpieczeństwo

Jeśli chodzi o bezpieczeństwo, zwykle zobaczysz jedno /sbin/nologinlub czasem /bin/falsemiędzy innymi w tej dziedzinie. Oba służą temu samemu celowi, ale /sbin/nologinprawdopodobnie jest to preferowana metoda. W każdym razie ograniczają bezpośredni dostęp do powłoki jako tego konkretnego konta użytkownika.

Dlaczego uważa się to za wartościowe pod względem bezpieczeństwa?

„Dlaczego” trudno jest w pełni opisać, ale wartość ograniczenia konta użytkownika w ten sposób polega na tym, że udaremnia bezpośredni dostęp za pośrednictwem loginaplikacji, gdy próbujesz uzyskać dostęp za pomocą tego konta użytkownika.

Użycie jednego z nich nologinlub /bin/falseosiągnięcie tego. Ograniczanie powierzchni ataku systemu jest powszechną techniką w świecie bezpieczeństwa, niezależnie od tego, czy wyłącza się usługi na określonych portach, czy ogranicza charakter logowania w systemach.

Nadal istnieją inne racjonalizacje użycia nologin. Na przykład, scpnie będzie już działać z kontem użytkownika, które nie określa rzeczywistej powłoki, jak opisano w pytaniach i odpowiedziach dotyczących błędu serwera zatytułowanym: Jaka jest różnica między / sbin / nologin i / bin / false? .

Zdecydowanie służy to celom bezpieczeństwa. Na przykład spójrz na poniższy błąd zgłoszony dla użytkownika systemu, który miał powłokę.

Mój serwer debian został przejęty, ponieważ konto demona ma prawidłową powłokę logowania i sambę otwartą na dostęp do Internetu. Włamanie nastąpiło poprzez zdalne ustawienie hasła przez sambę dla konta demona i zalogowanie się przez ssh. Niektóre lokalne exploity root zostały następnie wykorzystane do WŁASNEGO serwera.

Poleciłbym ci przeczytanie tej wspaniałej odpowiedzi Gillesa, w której również zamieścił linki do niektórych błędów.

W Debianie (274229, 330882, 581899) zgłoszono błędy dotyczące tego problemu, obecnie otwartego i sklasyfikowanego jako „lista życzeń”. Zgadzam się, że są to błędy i użytkownicy systemu powinni mieć / bin / false jako swoją powłokę, chyba że wydaje się to konieczne, aby zrobić inaczej.

Aby dodać do doskonałych odpowiedzi na @slm i @ramesh:

Tak, jak już zauważyłeś, nadal możesz przełączać się na użytkowników z nologin jako domyślną powłoką, uruchamiając sudoze zdefiniowaną powłoką, ale w tym przypadku musisz:

1. Zaloguj się jako inny użytkownik z prawidłową powłoką
2. Skonfiguruj uprawnienia sudo, aby ten użytkownik mógł uruchomić supolecenie, oraz
3. Gdyby Twoja próba su została zarejestrowana w dzienniku sudoers (zakładając oczywiście, że logowanie sudo jest włączone).

Użytkownicy, dla których nologin jest zdefiniowany jako domyślna powłoka, często mają wyższe uprawnienia / są w stanie wyrządzić więcej szkód w systemie niż zwykły użytkownik, więc uniemożliwiając im bezpośrednie zalogowanie, będą próbowali ograniczyć szkody, które może ponieść naruszenie systemu .

Oprócz doskonałych odpowiedzi, które zostały podane, służy on także innemu celowi.

Jeśli uruchomisz demona FTP na swoim serwerze, sprawdza on powłokę logowania użytkowników, którzy próbują się zalogować. Jeśli powłoki nie ma na liście /etc/shells, nie pozwala im się zalogować. Dlatego nadanie kontom demonów specjalnej powłoki zapobiega modyfikowaniu konta przez FTP.

Oprócz świetnych odpowiedzi, które już zostały podane, mogę wymyślić następujący scenariusz.

Błąd bezpieczeństwa w usłudze działającej jako użytkownik z ograniczonym dostępem umożliwia zapisanie pliku jako ten użytkownik. Ten plik może mieć postać ~ / .ssh / Author_keys.

Dzięki temu atakujący może zalogować się bezpośrednio w powłoce, co znacznie ułatwi wykonanie eskalacji uprawnień.

Wyłączenie powłoki logowania znacznie utrudni tę opcję.

Ogólnie powiedziałbym, że / bin / false i / sbin / nologin są takie same - ale przypuszczam, że zależy to od używanego serwera SSH.

Rozsądnie byłoby wskazać, że ten ostatni exploit na OpenSSH wydaje się wpływać na / bin / fałszywe loginy, ale NIE / sbin / nologin. Jednak stwierdza, że ​​Dropbear różni się w ten sposób (również exploit dotyczy konkretnie OpenSSH).

Exploit wpływa na większość wersji:

7.2p1 i niższe (wszystkie wersje; sprzed około 20 lat) Z włączonym przekazywaniem X11

https://www.exploit-db.com/exploits/39569/

Na tej podstawie - osobiście zrobiłbym / sbin / nologin, jednak nie jestem pewien, czy może to wpłynąć na usługi, które tworzą wpis / bin / false w / etc / passwd. Możesz eksperymentować i zobaczyć swoje wyniki, ale zrób to na własne ryzyko! Podejrzewam, że najgorszy przypadek, możesz po prostu zmienić go z powrotem i zrestartować dowolne usługi wpływające. Osobiście mam sporo wpisów za pomocą / bin / false - Nie jestem pewien, czy chcę się tym przejmować, ponieważ przekazywanie X11 nie jest włączone;)

Jeśli używasz OpenSSH (myślę, że wielu ludzi ...) ORAZ ma włączone przekazywanie X11 - możesz rozważyć / sbin / nologin (lub może przejść na Dropbear).

Ogólnie dobrą praktyką bezpieczeństwa jest ustawianie kont usług i aplikacji na nieinteraktywne logowanie. Autoryzowany użytkownik może nadal mieć dostęp do tych kont przy użyciu SU lub SUDO, ale wszystkie ich działania są śledzone w plikach dziennika Sudoers i można je prześledzić do użytkownika, który wykonał polecenia z uprawnieniami do konta serwisowego. Dlatego ważne jest przechowywanie plików dziennika w scentralizowanym systemie zarządzania dziennikami, aby administratorzy systemu nie mieli dostępu do zmiany plików dziennika. Użytkownik wykonujący polecenia w SU lub SUDO jest już upoważniony do dostępu do systemu.

Z drugiej strony zewnętrzny lub nieautoryzowany użytkownik systemu nie będzie miał całkowicie dostępu do logowania przy użyciu tych kont, co stanowi środek bezpieczeństwa.

Tak, służy to celom bezpieczeństwa. Jest to środek dogłębnej obrony.

Głównym powodem, dla którego służy temu celowi, jest to, że istnieją różne fragmenty oprogramowania, które sprawdzą pewną formę poświadczeń logowania dla określonego użytkownika, a następnie używają powłoki logowania tego użytkownika do uruchomienia polecenia. Być może najbardziej znaczącym przykładem jest SSH. Jeśli pomyślnie uwierzytelnisz się jako użytkownik przez SSH, SSH następnie uruchamia powłokę logowania użytkownika (lub używa jej do uruchomienia podanego polecenia, jeśli używasz ssh someuser@example.com 'command to run'składni).

Oczywiście idealnie byłoby, gdyby osoba atakująca nie mogła się uwierzytelnić jako użytkownik. Przypuśćmy jednak, że dzieje się następująca sytuacja:

• Serwer, który kontrolujesz, uruchamia usługę sieciową jako użytkownik, który ma katalog domowy i powłokę logowania
• Osoba atakująca odkrywa lukę w tej usłudze, która umożliwia atakującemu zapisywanie plików w katalogu osobistym użytkownika

Teraz twój napastnik może napisać klucz publiczny SSH ~/.ssh/authorized_keys, następnie wprowadzić SSH i - bum! - mają dostęp shellowy do twojego serwera.

Jeśli zamiast tego użytkownik ma /usr/sbin/nologinpowłokę logowania, to nawet po tym, jak osoba atakująca pomyślnie zapisuje klucz publiczny authorized_keys, nie jest to dla niego przydatne. Wszystko, co pozwala, to zdalne uruchamianie nologin, co nie jest zbyt przydatne. Nie mogą zdobyć pocisków, a ich atak został złagodzony.

W przypadku, gdy ten scenariusz wydaje się bardzo hipotetyczny, chciałbym zauważyć, że dokładnie w tym momencie w 2015 r. Padł na mnie ten atak, około rok po tym, jak zadałem to pytanie. Jak cholerny idiota, zostawiłem instancję Redis bez hasła otwartego na świat. Został zaatakowany przez atak crack Redis , w którym atakujący wstawia klucz publiczny SSH do bazy danych Redis, a następnie wysyła polecenie nakazujące Redisowi zapisanie zawartości bazy danych .ssh/authorized_keys, a następnie próbuje wprowadzić SSH. Uratowałem się przed konsekwencjami mojej własnej niekompetencji tylko dlatego, że opiekunowie redis-serverpakietu Apt (którego użyłem do instalacji Redisa) mieli mądrość, aby uruchomić Redis jakoredisużytkownik, który nie ma katalogu domowego ani powłoki logowania; gdyby ich nie było, mój serwer prawdopodobnie zostałby zainfekowany okupem lub stałby się częścią botnetu jakiegoś hakera.

To doświadczenie zapewniło mi pewien stopień pokory i sprawiło, że doceniłem znaczenie dogłębnej obrony , aw szczególności nieprzyznawania powłok logowania kontom z serwerami WWW, bazami danych i innymi usługami działającymi w tle.