Zmień nazwę / etc / passwd i / etc / shadow ze względów bezpieczeństwa [zamknięte]

Mam serwer Mój serwer jest bezpieczny, ale wyobraźmy sobie dobrego hakera, który wejdzie. Może teraz przeglądać /etc/passwdi /etc/shadow. Chciałbym zmienić nazwę tych plików /etc/passwdna coś podobnego /etc/xxanoda.

Myślałem, że mogę zrobić link, ale dla hakera będzie to łatwe ls -l.

Można zmienić nazwy tych plików i nadal mieć działający system operacyjny, bez problemów ze zgodnością, czy jest to całkowicie bezużyteczne? Tylko w poszukiwaniu wiedzy.

Standard hierarchii systemu plików dla systemów uniksowych zawiera /etc/passwdw stałej lokalizacji, i narzędzia są w związku z tym zwykle sztywno spojrzeć tam dla niego. Podczas gdy teoretycznie można ponownie skompilować wszystkie odpowiednie narzędzia do wyszukiwania w nowej lokalizacji, każdy atakujący zawsze może po prostu szukać ciągów w tych plikach binarnych w celu zlokalizowania nowego pliku lub użyć wyrażeń regularnych, aby znaleźć pliki o passwdpodobnej zawartości.

shadowPlik powinien być czytelny tylko root(i ewentualnie do grupy o nazwie shadow). Jeśli atakującemu udało się uzyskać dostęp do systemu root, masz całkowitą kontrolę i to, czy może on odczytać twoje pliki passwd / shadow, jest w tym momencie zupełnie nieistotne.

Można sobie wyobrazić kilka sytuacji, w których posiadanie plików poza oczekiwanymi miejscami może pomóc, np. Jeśli masz źle skonfigurowany serwer WWW, który pozwala komuś na żądanie http://myserver/../../etc/passwd, ale generalnie tego rodzaju pośrednictwo będzie wymagało dużo pracy dla minimalnej korzyści bezpieczeństwa.

Najlepszą rzeczą, jaką można by powiedzieć, jest „całkowicie bezużyteczna”, jak to ująłeś. (Nie stanowi to dodatkowej przeszkody dla intruza)

/etc/passwd zawiera nazwy kont, ale każdy, kto ma dostęp do powłoki w systemie, będzie mógł je znaleźć.

/etc/shadowzawiera poufne informacje (skróty hasła), ale można je odczytać tylko dla roota. Jeśli intruzowi udało się uzyskać uprawnienia root'a - cóż, jak przeliterować katastrofę ?

We współczesnych Unices (i systemach uniksowych, w tym Ubuntu), /etc/passwdnie zawiera żadnych tajemnic. Zmiana nazwy będzie bardziej kłopotliwa niż jest warta, biorąc pod uwagę, ile narzędzi trzeba będzie przebudować, aby szukać jej w nowej lokalizacji.

/etc/shadowto inna sprawa, ponieważ w tym pliku są sekrety, ale zmiana nazwy nie pomoże. Można go odczytać tylko przez roota, więc nawet jeśli haker dostanie się do systemu jak jakiś inny użytkownik, to nie wystarczy, aby dostać się do pliku. Właśnie dlatego hasła zostały usunięte /etc/passwd: każdy musi umieć czytać /etc/passwd, ale tylko root musi mieć dostęp do rzeczywistych haseł, więc hasła zostały przeniesione do pliku, który tylko root mógł odczytać.

Jeśli haker robi się zakorzenić, a następnie zmiana nazwy nie będzie cię uratować. Prosty rekursywny grepmoże dać hakerowi listę plików w /etc/shadowpodobnym formacie, a wtedy haker musi tylko je przejrzeć, aby znaleźć dane, których potrzebuje. Opóźniłeś go najwyżej o kilka godzin, a prawdopodobnie mniej: znowu, nie warte czasu, który zajęłoby zmodyfikowanie i ponowne skompilowanie wszystkich narzędzi, które zależą od /etc/shadowlokalizacji.

Nie możesz po prostu zmienić nazwy tych plików. Wiele procesów i programów będzie ich szukać, ponieważ jest to standard w systemach Linux. Co możesz zrobić, to odpowiednio zabezpieczyć serwer.

Chociaż prawdopodobnie nie ma sensu zmieniać nazw plików /etc/passwdi /etc/shadow, jeśli chcesz zwiększyć bezpieczeństwo, możesz przyjrzeć się PAM (wtykowym modułom uwierzytelniającym) i NSS (Name Service Switch). Jak tutaj.

Za pomocą PAM można dodawać moduły uwierzytelniające, które zamiast odczytywać swoje informacje uwierzytelniające ze standardowych plików, odczytują je z innego źródła, np. Z ldap lub bazy danych. Użycie tego oznaczałoby /etc/shadowprawie całkowite wyeliminowanie.

NSS uzupełnia PAM, uniezależniając część rozpoznawania nazw (np. Do których grup należy ten użytkownik) od standardowych plików ( /etc/passwd, /etc/groups). Użycie go oznaczałoby, że plik passwd potencjalnie będzie zawierał tylko opcję awaryjną dla roota i nic więcej. Użycie kluczy SSH do sprawdzenia poprawności logowania roota wyeliminowałoby również potrzebę posiadania hasła roota w pliku cienia (chociaż może być pożądane, jeśli połączenie SSH zostanie przerwane).

Alternatywnie, jeśli nie chcesz uwierzytelniać użytkowników za pomocą oddzielnej bazy danych lub hosta LDAP, możesz również utworzyć własne moduły PAM i NSS, które odczytują ich dane z niestandardowego pliku, chociaż nie polecam tej opcji.

Kiedy chcesz spróbować ich użyć, nigdy nie zapomnij zachować rezerwy na znaną, działającą warstwę uwierzytelniania, w przeciwnym razie możesz zablokować się poza systemem, nawet z rootem.

Pamiętaj, że nie wszystkie aplikacje obsługują PAM (wiele z nich jednak). NSS może jednak służyć do implementacji uwierzytelniania dla aplikacji, które nie obsługują PAM, a niektóre witryny, które czytałem o NSS, faktycznie sugerują takie podejście. Oznacza to jednak, że moduł NSS dostarczy (potencjalnie) zaszyfrowane hasło każdemu, kto może uzyskać dostęp do warstwy uwierzytelniania NSS, co prawie zawsze jest czymś, czego chcesz uniknąć (jest to w zasadzie to samo, co zapewnienie dostępu do pliku cienia użytkownika innego niż root) )! Jeśli więc wybierasz to podejście, zawsze upewnij się, że NSS jest używany tylko do dostarczenia użytkownikowi podstawowych danych (takich jak zawartość /etc/passwd), a PAM jest używany jako warstwa uwierzytelniająca.