Dlaczego użytkownik „bin” potrzebuje powłoki logowania?

Podczas audytu /var/log/auth.logna jednym z moich publicznych serwerów znalazłem:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

Na pierwszy rzut oka wygląda to jak typowy sshspam logowania od losowych hakerów; jednak, gdy przyjrzałem się bliżej, zauważyłem coś innego. Większość nieudanych /var/log/auth.logwpisów mówi invalid userw nich, takich jak ten:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

Niepokojące rzeczy na temat tej nieudanej wiadomości logowania na binto, że jest to ważny użytkownik w /etc/passwdtym nawet ma powłokę logowania:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Myślałem, że pokryła wszystkie domyślne nazwy użytkowników, które mogłyby się zalogować zdalnie kiedy wyłączony PermitRootLoginw /etc/ssh/sshd_config; odkrycie tego wpisu otworzyło nowe możliwości w moim paranoicznym umyśle. Jeśli usługi w jakiś sposób działały bin, to jest możliwe, że ktoś mógłby w jakiś sposób wstawić klucz ssh do katalogu binużytkownika z uruchomionej usługi na pudełku, więc chciałbym całkowicie wyłączyć logowanie dla binużytkownika, jeśli to możliwe.

pytania

• Ten serwer jest zdalny i kosztowny do naprawienia (tj. Zapłacę za zdalne ręce, aby podłączyć KVM, a także wynajem KVM). Próbuję wymyślić, co mogę złamać, jeśli zmienię /etc/passwdwpis, binaby wyglądał tak:

  bin:x:2:2:bin:/bin:/bin/false

• Uruchomiłem następujące polecenia, próbując dowiedzieć się, co binjest potrzebne ... Jednak te polecenia wymyśliły brak plików i nie mogłem znaleźć żadnych procesów należących do bin. Co w ogóle robi binużytkownik?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Czy są jeszcze inni użytkownicy, dla których należy ustawić powłoki logowania /bin/false? FYI, mam już /bin/falsena www-data.

• Czy jestem zbyt paranoikiem?

Używam Debiana, jeśli to ma znaczenie.

Użytkownik, który ma prawidłową powłokę i nie ma hasła, może nadal logować się metodami nieopartymi na hasłach, przy czym najczęściej jest to klucz ssh. Prawidłowa powłoka jest niezbędna do uruchamiania zadań cron. Prawidłowa powłoka jest również niezbędna su bin -c 'wibble'do działania (przynajmniej w systemie Linux su bin -s /bin/sh -c 'wibble'będzie działać).

W przypadku binwiększości systemów nigdy nie uruchamia polecenia, jak binpodczas normalnej pracy, więc ustawienie powłoki na /bin/falseOK byłoby w porządku.

Nie ma ryzyka bezpośredniego ataku pozwalającego binzalogować się przez SSH, ponieważ wymagałoby to utworzenia /bin/.ssh/authorized_keysużytkownika binlub użytkownika root. Innymi słowy, jedynym sposobem na wejście jest wejście. Jednak posiadanie prawidłowej powłoki zwiększa ryzyko błędnej konfiguracji. Może także dopuszczać niektóre zdalne ataki za pomocą usług innych niż SSH; na przykład użytkownik zgłasza, że osoba atakująca może ustawić hasło daemonzdalnie za pośrednictwem Samby, a następnie użyć tego hasła do zalogowania się przez SSH.

Możesz zamknąć otwór SSH, wymieniając nazwy użytkowników systemu w DenyUsersdyrektywie w /etc/ssh/sshd_config(niestety nie możesz użyć zakresu liczbowego). Lub odwrotnie, możesz wprowadzić AllowGroupsdyrektywę i zezwalać tylko na grupy zawierające użytkowników fizycznych (np. usersJeśli przyznasz wszystkim użytkownikom fizycznym członkostwo w grupie).

Zgłoszono błędy dotyczące tego problemu w Debianie ( # 274229 , # 330882 , # 581899 ), obecnie otwartym i sklasyfikowanym jako „ lista życzeń”. Zgadzam się, że są to błędy i użytkownicy systemu powinni je mieć /bin/falsejako powłokę, chyba że wydaje się konieczne, aby zrobić inaczej.

Nie musisz się tym martwić jako użytkownik. Są „użytkownikami” w znaczeniu grup bezpieczeństwa, a nie użytkownikami w sensie „logowania się i używania” osób. Jeśli spojrzysz na „/ etc / shadow”, zobaczysz, że wszyscy ci „użytkownicy” nie mają haseł („x” lub „!” Zamiast długiego solonego skrótu). Oznacza to, że ci użytkownicy nie mogą się zalogować, bez względu na wszystko.

To powiedziawszy, nie wiem, czy dobrym pomysłem jest zmiana „/ bin / sh” na „/ bin / false” dla wszystkich tych użytkowników. Ponieważ programy działają w tych grupach, może nie pozwolić im na wykonywanie poleceń, których potrzebują. Zostawiłbym je jako „/ bin / sh”.

Nie musisz się martwić o tych użytkowników. Martw się tylko o użytkowników, których tworzysz (i tych z hashami w „/ etc / shadow”)

Uważam, że nie stanowi to problemu, ponieważ aby skonfigurować klucz publiczny SSH w binkatalogu domowym ( /bin), osoba atakująca musiałaby mieć dostęp do systemu plików jako użytkownik root, co oznacza, że ​​i tak masz problemy.

Jeśli chcesz, możesz wyłączyć wszystkie metody uwierzytelniania dla binużytkownika w konfiguracji sshd przy użyciu MatchUserbloku.

To powiedziawszy, wygląda na to, że użytkownik bin nie jest używany w nowoczesnych systemach opartych na Debianie i jest jedynie ukłonem w stronę tradycji lub jest zgodny z niektórymi standardami.