Widzę ten wpis w moich dziennych danych wyjściowych, sekcja sudo:
/ bin / grep -E ^ pi: / etc / shadow
Powinienem się martwić? Z pewnością sam nie uruchomiłem tego polecenia.
Widzę ten wpis w moich dziennych danych wyjściowych, sekcja sudo:
/ bin / grep -E ^ pi: / etc / shadow
Powinienem się martwić? Z pewnością sam nie uruchomiłem tego polecenia.
To jest ślad domyślnego skryptu (wprowadzonego w wydaniu Raspbian z listopada 2016 r.), który sprawdza, czy zmieniłeś hasło użytkownika pi
.
Skrypt jest przechowywany w /etc/profile.d/sshpasswd.sh
i wyświetla ostrzeżenie, jeśli demon SSH był włączony, ale hasło użytkownika pi
nie zostało zmienione z domyślny ( raspberry
). Jest wywoływana przy każdym logowaniu.
Skrypt w oryginalnej postaci:
check_hash () {local SHADOW = "$ (sudo -n grep -E '^ pi : '/ etc / shadow 2> / dev / null) "test -n" $ {SHADOW} "|| return 0 local SALT = $ (echo "$ {SHADOW}" | sed -n 's / pi: \ $ 6 \ $ //; s /\$.*// p') local HASH = $ (mkpasswd -msha- 512 raspberry "$ SALT"), jeśli systemctl jest aktywny ssh -q && echo "$ {SHADOW}" | grep -q "$ {HASH}"; następnie echo echo "SSH jest włączone, a domyślne hasło użytkownika 'pi' nie zostało zmienione." echo "Jest to zagrożenie bezpieczeństwa - zaloguj się jako użytkownik 'pi' i wpisz 'passwd', aby ustawić nowe hasło." echo fi} check_hashunset check_hash
W Raspbian Stretch skrypt został zmieniony na jeden sprawdzający istnienie pliku / run / sshwarn
(z drugiej strony , utworzony / usunięty podczas rozruchu). Nie sprawdza / etc / shadow
przy każdym logowaniu, ale z drugiej strony, jeśli ktoś użył zautomatyzowanego narzędzia do zmiany hasła, musi również jawnie usunąć plik lub zrestartować komputer :
export TEXTDOMAIN = Linux-PAM. gettext.shif [-e / run / sshwarn]; następnie echo echo $ (/ usr / bin / gettext "SSH jest włączone, a domyślne hasło użytkownika 'pi' nie zostało zmienione.") echo $ (/ usr / bin / gettext "Jest to zagrożenie bezpieczeństwa - zaloguj się jako użytkownika „pi” i wpisz „passwd”, aby ustawić nowe hasło. ”) echofi
Powinienem się martwić?
To zależy od tego, co rozumiesz przez „zaniepokojony”. Jeśli masz na myśli motywację do przeprowadzenia dokładniejszego audytu w celu ustalenia, który proces jest za to odpowiedzialny, to na pewno dlaczego nie. Jeśli jednak nie masz gotowych środków, aby to zrobić, myślę, że zależy to od tego, jak zmotywowany jesteś, aby go znaleźć i użyć (co może dać wynik „To właśnie robiłem w sobotę / weekend / pierwszy tydzień grudnia… ”); Nie zawracałbym sobie głowy, chyba że interesuje Cię to z szerszych powodów.
Kilka kwestii do rozważenia:
man 5 shadow
i pamiętaj, że dostęp do „zaszyfrowanego hasła” nie oznacza dostępu do samo hasło; hasła nie są nigdzie przechowywane, tylko ich jednokierunkowy hash, który nie jest przydatny poza weryfikacją). Domyślam się, że pochodzi to z jakiegoś niewinnego, ale specyficznego dla pi skryptu. Raspbian jest niezwykły ze względu na nieograniczone supermoce, które zapewnia zwykłemu użytkownikowi, 1 , więc ta metodologia (grepping / etc / shadow
przez sudo
) byłaby bezcelowa w większości systemów GNU / Linux. Jeśli odpowiedzialny proces musi to zrobić, normalnie byłby uruchamiany jako proces z UID, który nie musiałby używać sudo
, więc jest bardzo prawdopodobne, że jest napisany przez kogoś, kto wie, jak składa się Raspbian (np. osoba odpowiedzialna za pewne oprogramowanie dla Raspbian).
Nie jest trudno wyobrazić sobie tutaj „nie-niewinnego”, ale równie dobrze można spekulować na ten temat bez tego, tj. bez żadnych dowodów. Jeśli ktoś chce psocić, nie ma nic w czytaniu / etc / shadow
, co wskazuje na to z definicji. Można by argumentować, że i tak nie ma większego sensu ograniczanie dostępu do odczytu tego pliku.
1. Okropne, błędne, absurdalne. Jedną z pierwszych rzeczy, które robię podczas instalacji Raspbian (czasami, zanim nawet uruchomię go po raz pierwszy), jest całkowite usunięcie użytkownika pi
i wycięcie większości koszmarów w / etc / sudoers
.