| Włamanie na mój serwer |
|
Do napisania tego tekstu chciałem się zabrać już dawno, choćby dla siebie żeby mieć coś na przyszłość lub dla innych w celach naprawczo-poglądowych. Otóż cała historia rozgrywa się na serwerze z zainstalowanym RedHatem 9, ale może oczywiście dotyczyć każdego innego systemu (ostatnio bardzo się zdziwiłem sposobem dystrybucji Debiana, w którym np. pakiet ssl był w bardzo starej i dziurawej wersji). Pewnego pechowego dla mnie dnia dostałem maila od mojego ISP (providera internetowego), że maszyna wspomniana wyżej skanuje inne komputery przez ssh. Podstawową rzeczą, którą należało zrobić to sprawdzenie procesów (może mam jakiegoś nadgorliwego użytkownika). Moim oczom ukazał się taki oto obrazek: # ps auxw (przytoczony wyżej fragment jest tak naprawdę zaczerpnięty ze strony http://guide.ovh.com/MachineSemiHackee/ na której wprawdzie po francusku ale jest obszerny opis całej procedury sprawdzania systemu) Widzimy tu kilka procesów, które powinny nas mocno zaniepokoić. Te procesy to przede wszystkim sshscan, które występują w dużych ilościach i w imieniu użytkownika nobody, który zwykle przypisany jest do obsługi Apache. Drugim niepokojącym mnie procesem był proces sh -i, który występuje w zbyt dużych ilościach i jest to proces shell-a. Zacząłem rozgryzanie problemu od wycięcia procesów użytkownika nobody (przy okazji tak się zagalopowałem ze wyciąłem sobie serwer WWW). Jak się okazało zostawienie procesów sh -i powodowało, że za chwilę powstawały nowe procesy sshscan. Co jednak z tego że procesy były czyste jak łza skoro niestety za jakieś pół dnia pojawiły się znowu. Przy pomocy find-a zacząłem szukać ostatnio modyfikowanych plików i generalnie tych, które były własnością nobody. Podstawowym moim błędem było zostawienie katalogu temp z pełnym dostępem do niego, na tą bolączkę generalnie pomaga albo montowanie bez prawa wykonywania - noexec albo ograniczenie praw do katalogu dla użytkowników. Okazało się, że i to nie do końca daje rozwiązanie, bo raz że ktoś nam po serwerze buszuje dwa że nie wiadomo skąd to paskudztwo się naprawdę bierze. W poszukiwaniach dotarłem w końcu do logu Apache. A w nim znalazłem dość groźnie wyglądający zapis:
--09:43:30-- http://www.jakis_host.domena/jakis_plik.roz => `jakis_plik_roz' Connecting to nazwa_hosta:port... connected. Proxy request sent, awaiting response... 200 OK Length: 1,400,426 [text/plain] 100%[====================================>] 1,400,426 584.70K/s 09:43:32 (584.17 KB/s) - `jakis_plik.roz' saved [1,400,426/1,400,426]
Ile czasu się zastanawiałem skąd wget wziął się w logach Apache to moje, ale w końcu doszedłem do tego. Zacząłem w końcu od tego, co trzeba było zrobić od początku:
a) sprawdzić logi logowań użytkowników. b) przejrzeć katalogi użytkowników. Niestety okazało się, że powodem była zbyt łagodna (no dobra - brak) polityka nadawania haseł. Opis działania naszego włamywacza: 1) Testowanie kolejnych hostów przy pomocy słownika haseł/loginów poprzez ssh. 2) złowionych w ten sposób „dawców" testuje pod względem uprawnień do katalogu domowego i dostępu do katalogu /temp. 3) sprawdzanie czy apache ma standardową kompilację i konfigurację, jeśli tak to zakładany jest katalog: public_html a w nim skrypt php (oczywiście obsługa php musi być wcześniej zapewniona) będący tak naprawdę shellem (no dobrze nie do końca tak, ale chodzi tu o funkcjonalność). 4) wgrywane są programy skanujące sieć 5) następuje skanowanie kolejnych potencjalnych „dawców" Na koniec polecam pewien programik, który potrafi przeskanować nasz system pod kątem szczelności : Rkhunter (WWW.rootkit.nl) sprawdza on, jakie oprogramowanie, w jakich wersjach jest zainstalowane na serwerze i w przypadku, gdy napotka takie z dziurami informuje w odpowiedni sposób użytkownika, program ma też parę innych zalet m.in. aktualizację definicji plików/zmian w systemie powodujących złe jego funkcjonowanie oraz definicję programów posiadających znane błędy w działaniu. Tekst nadesłał Maciej Theuss Liczba komentarzy (1) - Dodaj swój komentarz do tego artykułu... |