Pytanie:
Dziwne polecenie grep / etc / shadow pojawiające się w moim dzienniku
boozedog
2016-12-03 21:47:51 UTC
view on stackexchange narkive permalink

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.

Czy dzieje się to codziennie o tej samej porze? Co jeszcze dzieje się w tym samym czasie? Możesz grepować swoje dzienniki i zwracać dzienniki otaczające, używając opcji -C (np. Grep -C 3 / bin / grep -E ^ pi: / etc / shadow /var/log/auth.log - lub / var / log / syslog)
Dwa odpowiedzi:
techraf
2016-12-04 07:05:46 UTC
view on stackexchange narkive permalink

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  
goldilocks
2016-12-03 23:03:29 UTC
view on stackexchange narkive permalink

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:

  • To jest po prostu odczytanie uprzywilejowanych informacji przez proces, który najwyraźniej chciał być tak uprzywilejowany. To niekoniecznie czyni go złośliwym.
  • Informacje, do których uzyskiwany jest dostęp, są dość przyziemne (patrz 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ą).
  • Jeśli ktoś chciał się ukryć robiąc to, tak nie jest. Jednak nie musi to oznaczać, że nie jest częścią czegoś złośliwego.

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 .

Tak, dlaczego zadali sobie trud stworzenia `pi`user, a następnie dali mu prawie taką samą moc jak` root` - jest znacznie bezpieczniejsze (a dla użytkowników * nix PC o wiele prostsze) utworzenie konta użytkownika z tym samym użytkownikiem- nazwa, której używają w swoich systemach PC ... a Twoja notatka przypomina mi, żebym sprawdził, co zrobiła Fundacja z konfiguracją `sudo`!


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...