Mój serwer Linux został zhakowany. Jak mogę dowiedzieć się, jak i kiedy zostało to zrobione?


11

Mam serwer domowy z dystrybucją stacjonarną Ubuntu. Znalazłem to w moim crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

a podczas przeglądania tego katalogu (spacja po nazwie użytkownika / to nazwa katalogu) znalazłem wiele skryptów, które oczywiście robią coś, czego nie powinny.

Przed wyczyszczeniem tego komputera i ponownym zainstalowaniem rzeczy chciałbym dowiedzieć się, co spowodowało naruszenie bezpieczeństwa i kiedy zostało wykonane. Więc nie otwieram ponownie tej samej dziury.

W jakich plikach dziennika powinienem szukać? Jedyne znane mi serwery działające na komputerze to sshd i lighttpd.

Co powinienem zrobić, aby wykryć, czy coś takiego się powtórzy?


@Person, który głosował na przeniesienie do SU: Jak myślisz, w jaki sposób kryminalistyka / hakowanie kryminalistyczne odnosi się do superużytkownika bardziej niż błędu serwera?
Chris S

3
Cieszę się, że plan polega na wyczyszczeniu komputera i ponownej instalacji. Jest to absolutnie słuszne, bez względu na to, co znajdziesz, ponieważ zawsze istnieje spora szansa, że ​​jest coś gorszego, czego nie znalazłeś.
mattdm,

Tak, naprawdę powinien głosować, aby przejść do bezpieczeństwa IT ( security.stackexchange.com ), a nie SU lub awaria serwera!
Rory Alsop,

Odpowiedzi:


4

Najpierw upewnij się, że komputer jest odłączony od jakichkolwiek sieci.
Po drugie, upewnij się, że pozbyłeś się ważnych danych z dysków przed ponownym uruchomieniem zaatakowanego systemu operacyjnego.

Zacznij od sprawdzenia znaczników czasu na danych plikach. Często są one dokładne.
Odwołaj się do dziennika httpd i dziennika uwierzytelniania, jeśli nie zostały wyczyszczone. Jeśli jedno z nich zostało usunięte, możesz się założyć, że to był sposób wejścia. Jeśli nadal są w takcie, możesz uzyskać więcej informacji o tym, jak dostali się z dziennika.

Jeśli wszystkie zostaną wyczyszczone, jesteś całkiem spieprzony. Prawdopodobnie zajęłoby to więcej czasu, aby dowiedzieć się, co się stało, niż jest warte.

Wspomniałeś, że te dwie usługi były uruchomione, czy była tam dobra zapora ogniowa, aby uniemożliwić dostęp do wszystkiego innego? Czy zezwoliłeś SSH na porcie 22; czy logowanie jest dość łatwe do odgadnięcia; czy zezwoliłeś na logowanie się hasłem; czy miałeś jakieś rzeczywiste ograniczenie prędkości logowania loginów? Czy masz zainstalowane dodatkowe oprogramowanie z lighttpd; perl; php; cgi; CMS lub podobny? Czy korzystasz z zaktualizowanej wersji całego oprogramowania; czy subskrybujesz powiadomienia bezpieczeństwa dla wszystkich uruchomionych programów i dokładnie oceniasz wszystkie powiadomienia, aby sprawdzić, czy dotyczą one oprogramowania, które uruchamiasz / udostępniasz publicznie?


Instalacja była standardową wersją Ubuntu Desktop Edition 10.x, nic szczególnego nie zrobiono dla bezpieczeństwa. Zakładałem, że domyślnie jest wystarczająco dobra zapora ogniowa. Czy to nie jest poprawne? Pozwoliłem zalogować się hasłem na porcie 22, ale hasło było losowym ciągiem 8 znaków. Czy powinno być wystarczająco dobre?
Jonatan Kallus,

Uważam, że domyślną zaporą jest „Szeroko otwarty - bez zapory”. O ile go nie skonfigurujesz, nic nie robi.
Chris S,

Pytanie brzmi, jakie usługi korzystałeś bardziej niż firewall. O ile zapora ogniowa nie jest skonfigurowana do konfigurowania określonych adresów IP w celu uzyskania dostępu, najlepszą zaporą ogniową jest przede wszystkim nie uruchamianie niepotrzebnych usług. A jaka była twoja konfiguracja sieci? Otwarty na Internet? Wewnątrz sieci prywatnej? Czy nie miałeś zapory w miejscu, w którym twoja sieć wewnętrzna weszła do Internetu, czy też twój serwer był w strefie DMZ?
Bart Silverstrim,

Serwer był podłączony bezpośrednio do Internetu. Użyłem go również jako routera. Jeśli domyślna zapora sieciowa jest szeroko otwarta, myślę, że mam wystarczające wyjaśnienie, jak to się mogło stać.
Jonatan Kallus,

4

Sam w sobie jest to temat; możesz znaleźć w Google dla Linuksa, aby uzyskać więcej informacji. Zasadniczo musisz najpierw zrobić zdjęcie dysków do analizy offline, a następnie wyczyścić komputer i zainstalować z czystej tablicy.

I pamiętaj o wszystkich incydentach. Każdy, kto korzysta z komputera, mógł mieć złamane hasło. Zmieniaj hasła, utrzymuj je w trybie offline itp., Aż znajdziesz je w „czystym pokoju” (izolowana maszyna wirtualna).

W przeciwnym razie jest to dużo sprawdzania dzienników (które można sfałszować) i sprawdzania aplikacji (skrypty php? Bazy danych? Zaktualizowano o najnowsze poprawki? Inni użytkownicy podają hasła?)

Dosłownie nie ma łatwego sposobu na udzielenie odpowiedzi na twoje pytanie, ponieważ musisz wykonać czynności kryminalistyczne na serwerze i sprawdzić, czy nie ma dziur. Możesz użyć niektórych zautomatyzowanych narzędzi, ale pamiętaj, że jeśli osoba atakująca miała uprawnienia rootowania, nie możesz już ufać systemowym plikom binarnym i nie możesz ufać dziennikom.

Jeśli chodzi o przyszłe ataki, w zależności od tego, jak bezpieczne chcesz to zrobić, możesz zacząć od przekierowania dzienników do systemu, który służy tylko do zapisywania dzienników systemowych. Brak innego dostępu, aby zmniejszyć ślad ataku.

Uruchomiłbyś również oprogramowanie sumy kontrolnej w swoim systemie, takie jak Tripwire, aby sprawdzić integralność swoich plików.

I oczywiście bądź na bieżąco z aktualizacjami i uruchamiaj oprogramowanie skanujące, które sprawdza rootkity.

Ponownie, bezpieczeństwo nie jest kwestią przełomową. Może być również specjalnością samą w sobie. Warstwowe zabezpieczenia mogą być tak ścisłe, jak sprawdzanie hostów / adresów IP, które nie należą do Twojej sieci, szyfrowanie całego dostępu do systemu, codzienne dzienniki zmian znalezionych w systemie i konfigurowanie honeypot w sieci, aby poszukaj dziwnej aktywności (dlaczego mój serwer próbuje połączyć się z portem 25 na komputerze typu honeypot?)

Przede wszystkim, jeśli chcesz sprawdzić aktywność, pobierz obraz dysku i ponownie zainstaluj oprogramowanie serwera. Od zera. Plikom binarnym serwera nie można już ufać.

EDYCJA - kilka innych rzeczy, które mi się przydarzają od czasu uruchomienia SSH - zainstaluj denyhosts. Można go skonfigurować tak, aby automatyczne ataki na system na dysku SSHD były blokowane po X próbach. Można go również skonfigurować do aktualizacji z innych serwerów odmowy hosta w „chmurze” w celu udostępniania zablokowanych adresów IP, aby zminimalizować zautomatyzowane ataki. Możesz także przenieść port, na którym nasłuchuje; wiele osób wskazuje, że to tylko bezpieczeństwo poprzez zaciemnienie, ale biorąc pod uwagę liczbę botów skanujących, znacznie zmniejsza to przypadkowe próby włamania.


Dzięki! Naprawdę odpowiedziałeś na połowę pytania, chciałbym zaznaczyć oba jako zaakceptowaną odpowiedź.
Jonatan Kallus,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.