Wiadomości jądra Linux po starcie systemu powinny być dostępne tylko dla administratora. To samo tyczy się jego wskaźników. Analogicznie możemy postąpić z logami jądra, które są wyświetlane na konsoli podczas i po starcie serwera. Za ich wyświetlanie odpowiedzialna jest jedna z najbardziej znanych funkcji z interfejsu jądra Linuksa – printk(). Jest to standardowe narzędzie, które służy do wyświetlania wiadomości i zazwyczaj najbardziej podstawowy sposób na śledzenie i debugowanie kodu jądra. Jeśli jesteśmy zaznajomieni z printf(3) to można powiedzieć, że printk() jest na nim oparty, chociaż ma pewne funkcjonalne różnice: jego komunikaty mogą zostać określone za pomocą poziomu szczegółowości (na czym się skupimy tutaj) oraz ciąg formatu (ang. format string) – choć w dużej mierze zgodny z C99, nie podąża dokładnie za tą samą specyfikacją.
[ czytaj całość… ]

W

szyscy znają sudo, prawda? Polecenie to pozwala administratorowi systemu nadać niektórym użytkownikom możliwość uruchamiania wybranych uprzywilejowanych poleceń, jednocześnie rejestrując ich argumenty i wykonanie. Program ten jest instalowany domyślnie prawie we wszystkich dystrybucjach systemu Linux i jest dostępny dla większości komercyjnych systemów Unix – umożliwiając precyzyjne dostosowywanie polityk dostępu. Mimo to nawet administratorzy systemów często wiedzą, że jest to “prefiks”, którego należy użyć przed uruchomieniem polecenia wymagającego uprawnień root nie zdając sobie sprawy z jego prawdziwych możliwości.
[ czytaj całość… ]

W

poprzedniej części zaprezentowałem, jak prosto za pomocą PAM możemy przesyłać informację o logowaniu się na uprzywilejowane konto root. W tej części zajmiemy się prawie permanentną inwigilacją poleceń wydawanych przez administratora i zwykłych użytkowników systemu. Wykorzystamy do tego bibliotekę snoopy.
[ czytaj całość… ]

Z

ałóżmy, że posiadamy centralny system logowania, który gromadzi różne dane z wszystkich naszych serwerów. Może być on oparty o komercyjne usługi typu Loggly, Logentries, DataDog lub własne rozwiązania, których sercem jest Elasticsearch, czy RethinkDB. Zależy nam na tym, aby każde normalne logowanie i to na uprzywilejowane konto root, czy to bezpośrednio na maszynę, czy to za pomocą sudo było przesyłane do naszego centrum danych. Dane te mogą posłużyć nie tylko jako ewidencja i kontrola osób, które mają prawo do tego typu działań, ale również umożliwia nam ich analizę i wykrywanie potencjalnych naruszeń bezpieczeństwa.
[ czytaj całość… ]