Jak śledzić działania administratora

Chciałbym wiedzieć, jakie są najlepsze podejścia do śledzenia działań administratora w środowisku Linux.

W szczególności szukam tych funkcji:

• A) Rejestrowanie naciśnięć klawiszy na bezpiecznym serwerze syslog
• B) Możliwość odtworzenia sesji powłoki (coś w rodzaju skryptu)
• C) Idealnie byłoby to obejście niemożliwe (lub dość trudne) bez fizycznego dostępu do serwera.

Pomyśl o tym z perspektywy bezpieczeństwa / audytu, w środowisku, w którym różni administratorzy (lub nawet osoby trzecie) muszą mieć możliwość wykonywania uprzywilejowanych operacji na serwerze.

Każdy administrator miałby swoje własne konto nominalne, a każda sesja interaktywna powinna być w pełni zalogowana, z możliwością odtworzenia go w razie potrzeby (na przykład, jeśli ktoś użył mc do usunięcia lub zmiany krytycznych plików, nie wystarczy wiedzieć, że ta osoba wydała polecenie mc; musi istnieć sposób, aby zobaczyć dokładnie, co zrobiono po uruchomieniu mc).

Dodatkowe uwagi :

1. Jak zauważył womble, najlepszą opcją może być nie logowanie ludzi z uprawnieniami administratora do dokonywania zmian na serwerach, ale zamiast tego poprzez system zarządzania konfiguracją. Załóżmy więc , że nie mamy takiego systemu i musimy przyznać dostęp na poziomie administratora różnym osobom na tym samym serwerze .
2. Nie jestem zainteresowany tym, by robić to w ukryciu: każda osoba logująca się do serwera z uprawnieniami roota byłaby w pełni świadoma, że ​​sesja zostanie nagrana (w taki sam sposób, na przykład, że operatorzy call center wiedzą, że ich rozmowy są nagrywane)
3. Nikt nie używałby ogólnego konta administratora („root”)
4. Jestem świadomy ttyrpld i wydaje się, że robi to, czego szukam. Ale zanim przejdę w ten sposób, chciałbym wiedzieć, czy można to rozwiązać za pomocą niezmodyfikowanego jądra. Chcę wiedzieć, czy istnieją jakieś narzędzia dla Debiana (lub ogólnie Linuksa), które pozwalają na pełną kontrolę kont superużytkowników bez łatania powłoki lub jądra.

W środowiskach z wieloma administratorami po prostu nie używaj roota - nigdy, jeśli to możliwe.

Używaj sudo do wszystkiego - sudo jest niezwykle konfigurowalne i łatwe do logowania.

Zaloguj dowolne / wszystkie loginy lub su, aby zrootować i zbadać je, gdy ktoś będzie obchodził ustalone reguły.

Po pierwsze, jakiego rodzaju dostępu użytkownika root chcesz monitorować? Głupie błędy administracyjne lub złośliwe informacje? Pierwszy - będziesz potrzebować dobrego rozwiązania do zarządzania konfiguracją, jak już zasugerowano. Drugi - jeśli wiedzą, co robią, możesz mieć tylko nadzieję, że złapiesz wystarczająco dużo, aby wskazać, że wydarzyło się coś wartego zbadania. Chcesz tylko wiedzieć, że rozpoczęła się jakakolwiek forma nieautoryzowanej działalności i być o tym poinformowanym. Jeśli są inteligentni, wyłączą większość logowania, w które się włączysz (zmieniając stan serwera lub wprowadzając własne narzędzia), ale mam nadzieję, że uda Ci się uchwycić początki incydentu.

Biorąc to pod uwagę, sugeruję kilka narzędzi, których możesz użyć. Najpierw zacznij od dobrej polityki sudo (która została już zasugerowana). Po drugie, sprawdź sudoshell, jeśli musisz przyznać tym administratorom dostęp do roota. Po trzecie, prawdopodobnie twój najlepszy zakład (choć najbardziej intensywny), zajrzyj do kontroli jądra Linuksa.

Możesz użyć tej biblioteki do sudo, dać każdemu swoje własne konto użytkownika i umieścić sudo -i w profilu everyones. W ten sposób mają natychmiastowy dostęp do konta root, a każde użyte polecenie jest rejestrowane.

Oni mają root. Najlepsze, na co możesz liczyć, to przynajmniej zobaczyć, kiedy zdecydowali się zerwać z małą utopią monitorowania, ale poza tym, co zrobili, można się domyślić.

„Najlepszą” opcją, jaką mogę wymyślić, jest narzucenie wszechstronnej automatyzacji i zarządzania konfiguracją oraz zarządzanie manifestami za pomocą systemu kontroli wersji i wdrażanie aktualizacji za jego pośrednictwem. Następnie zapobiegaj faktycznym logowaniom root na serwery. (Dostęp awaryjny „och nie, coś zepsułem” może być zapewniony przez niepodzielone i zmienione hasło po każdym użyciu lub klucz SSH, a wszyscy mogą obserwować administratora, który się spieprzył, aby upewnić się, że nie zmienić cokolwiek).

Tak, będzie to niewygodne i denerwujące, ale jeśli jesteś wystarczająco paranoikiem, aby chcieć monitorować działania wszystkich osób w takim stopniu, domyślam się, że znajdujesz się w środowisku, które jest niewygodne i wystarczająco denerwujące na inne sposoby, aby wygrać Wydaje się, że to duży problem.

Jak powiedzieli inni, nie ma prawie sposobu na zalogowanie użytkowników z pełnym dostępem do roota w sposób, którego nie mogą wyłączyć, ale jeśli używasz debian / ubuntu, spójrz na snoopy , które jest bardzo zbliżone do tego, czego chcesz

snoopy jest jedynie biblioteką współdzieloną, która jest używana jako opakowanie funkcji execve () dostarczanej przez libc do rejestrowania każdego wywołania do syslog (authpriv). administratorzy systemu mogą uznać snoopy za przydatne w zadaniach takich jak monitorowanie lekkiego / ciężkiego systemu, śledzenie działań innych administratorów, a także dobre wyczucie tego, co dzieje się w systemie (na przykład apache uruchamiający skrypty cgi).

Zgadzam się z komentarzami niepełnosprawnych na temat używania sudo do wszystkiego. Z pewnością ułatwia to rejestrowanie.

Dodam też okresowo tworzenie kopii zapasowej pliku historii bash. Niby często pomijane, ale czasem może być świetnym źródłem informacji ... po prostu zapytaj Goldmana Sachsa. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

To byłoby trudne ...

root może uruchamiać dokładnie sprawdzone skrypty, które mogą naruszać wszystkie środki bezpieczeństwa (zabija procesy monitorowania), niszczą pliki dziennika / przycinają je itp. Ale nadal ...

Zakładając, że wielu administratorów posiadających uprawnienia roota pracuje jako zespół. I root może również zabić każdy proces monitorowania. I niestety ten login / hasło staje się publiczne. Albo dostaną niechciane towarzystwo.

W tym przypadku może mieć zastosowanie tworzenie wielu kont głównych z UID 0, choć nie jest to zalecane.

W / etc / ssh / sshd_config Zmiana linii na: PermitRootLogin no

jest polecany. W ten sposób użytkownik loguje się przy użyciu swojego normalnego konta (znacznik daty i godziny jest rejestrowany razem (być może sfałszowany adres IP)), a następnie przechodzi do rootowania. za pomocą polecenia su

Bezpośrednie logowanie jako root jest w ten sposób niemożliwe.

Musimy pomyśleć, co root tutaj nie może zrobić.

sudo powinno być dobre. Tworzenie kopii zapasowej katalogu / etc Pliki konfiguracyjne powinny być dobre. / var / katalog Pliki dziennika należy okresowo przesyłać pocztą elektroniczną lub przechowywać w osobnym systemie plików NFS.

Co powiesz na pisanie skryptów integrujących interfejsy API od firm Mobile Gateway, które grupują SMS-y wszystkich telefonów użytkowników root, że jeden z nich jest poza domem do pracy. Wiem, że byłoby to irytujące, ale jednak.

Przełamanie SSH jest w większości przypadków wykluczone.

Mamy następujące ustawienia na stronie klienta:

• Podobnie otwarty w celu uwierzytelnienia za pomocą Kerberos w AD (konta osobiste)
• Autoryzacja tylko dla niektórych grup AD administratorów Uniksa
• grupa sudoers == grupa AD
• Agenci OSSEC HIDS na każdym serwerze i menedżer na hartowanym serwerze
• Interfejs sieciowy OSSEC
• Splunk 3 z Splunk-for-OSSEC

Będzie rejestrować każde użycie sudo na serwerach, a także śledzić wszelkie zmiany plików, instalację pakietów, podejrzane procesy itp.

Mamy kilka serwerów terminali, aby uzyskać dostęp do całego naszego sprzętu, co oznacza, że ​​można zalogować się do dowolnej rzeczy z serwera terminali lub jeśli ma się dostęp fizyczny.

Sshd na serwerach terminali jest uzupełniony http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , działa dobrze, ale nie był aktualizowany przez długi czas. Zmodyfikowałem go trochę, aby działał na openssh 4.7, ale nie udało mi się tego zrobić z 5.1. Poprawione problemy z sshd i dopóki nie mam wystarczająco dużo czasu, aby to naprawić, prawie przełączyłem się na ttyrpld.

Do tej pory mam to:

• sudosh : wydaje się wspierać A i B (choć nie do końca jestem pewien co do A)
• Sudoscript : wydaje się obsługiwać B (Sudoscript ma komponent o nazwie sudoshell, a jeśli to właśnie sugeruje romanda, dziękuję za podpowiedź)
• Snoopy Logger lub sudo_exetrace : nie do końca to, czego szukam, ale może być dobrym uzupełnieniem (dzięki therereceive i blauwblaatje dla tych linków)

Czy znasz inne podobne narzędzia, które nie wymagają łatania jądra lub innych składników systemu?