Dlaczego wszyscy są tak zaniepokojeni etc / passwd?

Oto zawartość mojej błędnej maszyny tego konkretnego pliku:

root:x:0:0:root:/root:/bin/bash
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
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/us$
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:100:103::/home/syslog:/bin/false

Czy ktoś mógłby mi wyjaśnić, dlaczego źle jest, jeśli jakiś zły facet może zdobyć ten plik z mojego serwera produkcyjnego?

security passwd-file

— zabawny gość
źródło

W dawnych czasach zawierał zaszyfrowane hasła dla każdego użytkownika - gdzie teraz jest: x:. Jeśli go masz (co było łatwe, ponieważ wszyscy mogą je odczytać, więc potrzebujesz tylko jednego loginu), możesz złamać hasło metodą brutalnej siły. Teraz są przechowywane w / etc / shadow, który nie jest czytelny dla wszystkich, więc mniej prawdopodobne jest, że „wyjdzie”, ale który miałby ten sam problem, gdyby tak się stało.

— Mark Smith

Na przykład mogę powiedzieć, że masz serwer WWW na tym komputerze. W połączeniu z adresem IP może być możliwe do włamania>: - D

— Rinzwind

@MarkSmith Zawierał zaszyfrowane hasła, kiedy? AFAIK zaczął życie jako hashowane hasła. Z pewnością odkąd pierwszy raz użyłem Uniksa w 1982 roku.

— user207421,

@funguy: Użytkownik www-data jest zwykle używany przez serwery internetowe. Ubuntu i prawdopodobnie Debian używali tego użytkownika jako domyślnego użytkownika Apache.

— Lie Ryan,

@ funguy www-data jest domyślnym użytkownikiem apache. Jest więcej: uucp to uniks na kopie unix; oznacza to, że kopiujesz pliki między systemami. „Irc” i „komary” są również łatwe do wykrycia.

— Rinzwind

Odpowiedzi:

Najważniejsze jest to, że Pentesters / biało-kapelusze / etycznych hakerów, a także cel czarny kapelusz /etc/passwd jako proof of concept, jako sprawdzian możliwości uzyskania dostępu do systemu.

Technicznie /etc/passwdnie jest to takie straszne. Kiedyś przechowywał prywatne dane, oczywiście hasła, ale na dzień dzisiejszy powinieneś się bardziej martwić /etc/shadow- większość systemów Linux używa obecnie shadowzestawu narzędzi do przechowywania zaszyfrowanego i solonego hasła /etc/shadow, które w przeciwieństwie do innych /etc/passwdnie jest światem -czytelny. (chyba że użyjesz pwunconvpolecenia, które faktycznie przenosi zaszyfrowane hasła z powrotem do `/ etc / passwd).

Jedyną mniej lub bardziej wrażliwą informacją są nazwy użytkowników. Jeśli masz sshdlub telnetna serwerze i nazwę użytkownika ze słabym hasłem, istnieje możliwość ataku siłowego.

Nawiasem mówiąc, twoje pytanie zostało zadane wcześniej . Tutaj po prostu odtworzyłem niektóre z wymienionych tam pojęć.

Mały dodatek: jest to trochę zbyt daleko idące, ale zauważyłem, że masz bashjako root root. Załóżmy, że masz w systemie użytkownika, który ma bashpowłokę, a nawet gorzej - ten użytkownik jest sudoer. Teraz, jeśli bash jest przestarzały lub niezałatany, osoba atakująca może próbować wykorzystać lukę Shellshock w celu kradzieży danych lub wykonania bomby wideł, aby tymczasowo wyłączyć system. Tak, technicznie rzecz biorąc, /etc/passwdnie jest to wielka sprawa, ale daje atakującemu pojęcie o niektórych informacjach o tym, co należy podjąć

Dodatkowa edycja, 18.11.2016

Po wykorzystaniu serwera Ubuntu na Oceanie cyfrowej na chwilę, to przyszło do mojej uwagi, że większość ataków brute force przeciwko mojego serwera przeprowadzono dla rootużytkownika - 99% wpisów do nieudanej hasło w /var/log/auth.logbyły za root. /etc/password, jak wspomniałem wcześniej, pozwala atakującemu spojrzeć na listę użytkowników, nie tylko użytkowników systemu, ale także użytkowników, co oznacza więcej potencjalnych miejsc ataku. Pamiętajmy, że nie wszyscy użytkownicy są świadomi bezpieczeństwa i nie zawsze tworzą silne hasło, więc osoba atakująca na błąd ludzki lub zbytnią pewność siebie ma dość duże szanse na wygraną.

— Sergiy Kolodyazhnyy
źródło

+1, świetna odpowiedź. Dodając do tego, chciałbym również powiedzieć, że ogólnie informacja jest potęgą; pomijając niesławny Shellshock, można na przykład zebrać informacje o uruchomionych procesach, które również można wykorzystać; na przykład na komputerze OP działa Apache, a to jeszcze jedna potencjalna dziura, która pozostała nie odkryta

— kro

Hmm ... Czy zasugerowałbyś zmianę domyślnych nazw użytkowników, aby zmylić atakującego?

— Freedo,

@ Freedom To nie pomaga. Identyfikatory użytkownika i grupy pozostają takie same, jeśli zmienisz logowanie. Na przykład, oto moja testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Po biegnę sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , wpis ma inną nazwę, ale i uid gid są takie same: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Jeśli hasło pozostanie niezmienione, atakujący może zgadywać i nadal łamać system. Wymaganie, aby hasło wygasało i było zmieniane co jakiś czas, jest lepszym podejściem, ale również nie jest kuloodporne.

— Sergiy Kolodyazhnyy

Przydatna jest zmiana domyślnych nazw użytkowników dla tych kont, które mają loginy SSH (lub inne loginy zdalne). Zmienia się oczywiście domyślne porty dla tych loginów. Wszystko, co pozwala trzymać dzienniki z dala od miliardów przypadkowych skanów drive-by przez dzieciaków ze skryptów, oznacza, że możesz skupić się na bardziej celowych atakach. Jeśli Twoje niestandardowe nazwy pojawiają się w dziennikach nieudanego logowania, wiesz, że to poważna próba zalogowania się, a nie jazda.

— Dewi Morgan

Aby zalogować się do komputera, musisz znać zarówno nazwę użytkownika, jak i hasło.

/etc/passwd dostarcza informacji o użytkownikach, co daje połowę potrzebnych informacji i wykorzystanych do włączenia skrótu hasła.

Skrót jest czymś obliczonym na podstawie hasła. Trudno jest znaleźć hasło z skrótu, ale nie na odwrót. Jeśli masz jedno i drugie, możesz spróbować brutalnej próby znalezienia hasła offline, a następnie spróbuj połączyć się z komputerem dopiero po jego znalezieniu.

Dzisiaj poprawiono bezpieczeństwo, ponieważ skróty są przechowywane w innym pliku, /etc/shadowktóry domyślnie nie jest czytelny dla większości użytkowników.

Ale gdybym miał dostęp do obu /etc/passwdi /etc/shadowprawdopodobnie mógłbym znaleźć twoje hasło za pomocą ataku „słownikowego” brutalnej siły. Ponieważ mogę to zrobić lokalnie na moim komputerze, nie zauważysz wielu nieudanych prób znalezienia twojego hasła i będę musiał ponownie połączyć się z twoim komputerem, gdy tylko poznam hasło. Mogę wtedy robić, co chcę.

Więcej informacji znajduje się tutaj na Wikipedii

— Warren Hill
źródło

Wygląda na to, że powinieneś wspomnieć tutaj o „tęczowych stołach”, aby dać pojęcie o tym, jak działa ten atak brutalnej siły.

— Rick Chatham