Krótko: Połączenia wychodzące serwera sprawdzają Państwo poleceniem ss -tunap lub lsof -i, które przypisują każde połączenie do procesu. Normalne są połączenia z bazą danych, serwerem pocztowym, serwerami aktualizacji i znanymi interfejsami. Połączenia procesów PHP lub serwera WWW z nieznanymi celami, nietypowe porty i trwałe połączenia bez powodu to sygnały ostrzegawcze zdalnego sterowania lub wycieku danych. Na stałe pomaga filtrowanie wyjścia, które zezwala tylko na potrzebne cele.
Dlaczego spojrzenie na zewnątrz tak wiele zdradza
Przy szukaniu włamania większość patrzy na pliki. Atakujący chce jednak coś zrobić ze swoim dostępem: doładować narzędzia, odbierać polecenia, wynieść dane albo użyć serwera do spamu lub ataków na innych. Wszystko to wymaga połączeń na zewnątrz.
Serwer WWW sam z siebie nawiązuje niewiele połączeń, a większość z nich jest przewidywalna: odpytuje bazę danych, przekazuje pocztę, wywołuje interfejsy płatności lub wysyłki i pobiera aktualizacje. Dlatego obce połączenia szczególnie tu się wyróżniają. Według znanych nam doniesień połączenia wychodzące należą do ogólnych sygnałów ostrzegawczych po włamaniu; potwierdzonych wskaźników kompromitacji (Indicators of Compromise) specjalnie dla PHP2Shell nie ma. Dalsze oznaki zbiera Czy już zostałem skompromitowany?.
Wypisanie połączeń wychodzących i przypisanie do procesów
Poniższe polecenia tylko odczytują dane. Proszę je wykonać jako root, w przeciwnym razie brakuje danych o procesach.
# Wszystkie nawiązane połączenia TCP z procesem
ss -tnp state established
# TCP i UDP łącznie z nasłuchującymi usługami
ss -tunap
# Połączenia według programu i użytkownika, bez rozwiązywania nazw
lsof -i -n -P | grep -v LISTEN
# Tylko połączenia procesów użytkowników serwera WWW
lsof -i -n -P -u www-data 2>/dev/null
W wyniku proszę zwrócić uwagę na trzy kolumny: proces, adres docelowy z portem i użytkownika. Połączenie php-fpm z bazą danych na porcie 3306 jest normalne. Połączenie programu o nieznanej nazwie z /tmp z obcym adresem na nietypowym porcie nie jest. To, pod jakim użytkownikiem działa PHP, zależy od dystrybucji i panelu.
Normalne czy podejrzane? Klasyfikacja
| Obserwacja | Raczej normalne | Raczej podejrzane |
|---|---|---|
| Cel | własna baza danych, serwer pocztowy, znane API, serwery aktualizacji | nieznane adresy bez związku z aplikacją |
| Proces | php-fpm, serwer WWW, usługi poczty i aktualizacji | nieznane programy, procesy z /tmp lub /dev/shm |
| Port | 443, 3306, 5432, 587 | nietypowe wysokie porty, porty typowe dla IRC |
| Czas trwania | krótko, pasuje do żądań | trwale otwarte, także w nocy bez odwiedzających |
| Ilość | niewielka i równomierna | nagłe skoki wychodzącego wolumenu danych |
| Ruch pocztowy | wysyłka przez przewidziany serwer pocztowy | wiele bezpośrednich połączeń na porcie 25 |
Wiele połączeń na porcie 25 wskazuje na wysyłkę spamu; na ten temat jest osobny artykuł, Serwer rozsyła spam.
Ocena nieznanego celu
Obcy adres na liście nie jest jeszcze dowodem. Zanim zdecydują Państwo, trzeba wyjaśnić, dokąd prowadzi połączenie i kto je nawiązał. Także te kroki niczego nie zmieniają:
- Ustalić proces: Wziąć PID z
ssi sprawdzić przezls -l /proc/PID/exeoraz wiersz poleceń, jaki program za tym stoi. - Sprawdzić cel: Przez
dig -x <IP>ustalić nazwę, a przezwhois <IP>operatora sieci. - Porównać z aplikacją: Zapytać programistę lub usługodawcę, czy Państwa aplikacja korzysta z tej usługi.
- Sprawdzić przebieg: Protokoły firewalla i sieci pokazują, od kiedy połączenie istnieje i ile danych przepłynęło.
- Zabezpieczyć wyniki: Zapisać wyniki z godziną, zanim cokolwiek zostanie zakończone lub zablokowane.
Proszę liczyć się z niejednoznacznymi wynikami. Wiele uzasadnionych usług działa u dużych dostawców chmury i CDN, których adresy nie pozwalają wnioskować o kliencie. I odwrotnie, także atakujący korzystają z wynajętych serwerów w chmurze. Znany operator sieci nie jest więc ani odwołaniem alarmu, ani dowodem; rozstrzygające jest, czy proces i cel pasują do Państwa aplikacji.
Zdjęcie chwilowe przez ss pokazuje tylko to, co właśnie jest otwarte. Krótkie połączenia nawiązywane co minutę widać tylko w protokołach. Dlatego protokoły firewalla lub przepływów (flow) są przy pytaniu o wyciek danych często ważniejsze niż spojrzenie na sam serwer.
Jeśli dane mogły opuścić Państwa serwer, a dotknięte są dane osobowe, może istnieć obowiązek zgłoszenia na podstawie RODO, zwykle w ciągu 72 godzin. Proszę to wcześnie uzgodnić z inspektorem ochrony danych; tło w Obowiązek zgłoszenia RODO w ciągu 72 godzin. Nie jest to porada prawna.
Nie zapominać o DNS i kontenerach
Nie każdy wyciek danych wymaga widocznego połączenia z obcym adresem. Rozwiązywanie nazw przez DNS trafia do resolvera Państwa centrum danych i na liście ss prawie nie rzuca się w oczy. Atakujący mogą pakować dane w długie, wyglądające na losowe subdomeny i w ten sposób wynosić je przez zapytania DNS. Wskazówki na to dostarczają protokoły resolvera: nietypowo wiele zapytań do tej samej obcej domeny, bardzo długie nazwy lub zapytania w porach, gdy nikt nie korzysta ze strony.
Jeśli Państwa aplikacje działają w kontenerach, host często widzi połączenia kontenerów tylko jako ruch sieci kontenerów. Wtedy proszę sprawdzać każdy kontener osobno, o ile są tam narzędzia, albo analizować połączenia na poziomie hosta i firewalla.
# Połączenia wewnątrz kontenera (o ile ss jest w obrazie)
docker exec <container> ss -tnp 2>/dev/null
# Na hoście: połączenia śledzone przez jądro, jeśli conntrack jest zainstalowany
sudo conntrack -L 2>/dev/null | head -50
Trwałe ograniczanie ruchu wychodzącego
Najskuteczniejszą prewencją jest filtrowanie wyjścia: serwer może docierać tylko do celów, których naprawdę potrzebuje, wszystko inne jest blokowane i protokołowane. Dla atakujących znacznie trudniejsze staje się doładowywanie narzędzi lub wyciąganie danych, nawet jeśli mogą wykonywać kod.
Droga do tego zaczyna się od listy potrzebnych celów, którą wyprowadzają Państwo ze zebranych powyżej połączeń. Potem następuje faza, w której zablokowane połączenia są tylko protokołowane, zanim blokada zostanie uruchomiona. Usługi płatności, serwery aktualizacji i interfejsy ze zmiennymi adresami wymagają przy tym szczególnej staranności. Jak ogólnie buduje się firewall dla serwerów WWW, opisuje Firewall dla serwerów WWW: otwierać tylko potrzebne porty.
Jak konkretnie pomaga PHP SOS?
- Sprawdzić połączenia: Przypisujemy wszystkie aktywne połączenia do procesów i celów oraz oceniamy nieznane cele.
- Oszacować wyciek danych: Analizujemy protokoły firewalla i sieci i wyjaśniamy, czy i kiedy dane zostały przesłane.
- Ograniczyć wyjście: Opracowujemy wspólnie z Państwem listę dozwolonych celów i wprowadzamy filtrowanie wyjścia krok po kroku.
- Monitorować na stałe: W ramach monitoringu bezpieczeństwa zgłaszamy nowe lub nietypowe połączenia.
Częste pytania
Jakie połączenia wychodzące są normalne dla serwera WWW?
Typowe są połączenia z bazą danych, serwerem pocztowym, usługami płatności i wysyłki, serwerami aktualizacji oraz znanymi interfejsami aplikacji. Wszystko, czego nie da się przypisać do żadnego z tych celów, zasługuje na dokładniejsze spojrzenie.
Jak zobaczyć, który proces nawiązał połączenie?
Poleceniem ss -tunap lub lsof -i -n -P jako root. Oba pokazują przy każdym połączeniu identyfikator procesu i nazwę programu. W ten sposób widać, czy połączenie pochodzi od PHP, serwera WWW czy obcego programu.
Czy nieznane połączenie oznacza, że dane wypłynęły?
Niekoniecznie. Jest jednak wskazówką, którą trzeba wyjaśnić. To, czy i jakie dane zostały przesłane, często da się ustalić tylko na podstawie protokołów firewalla lub sieci. Jeśli dotknięte są dane osobowe, mogą istnieć obowiązki zgłoszeniowe.
Czy serwer WWW w ogóle powinien móc nawiązywać połączenia wychodzące?
Tylko do celów, których potrzebuje. Filtrowanie wyjścia, które blokuje wszystko inne, znacznie utrudnia atakującym doładowywanie narzędzi i wyprowadzanie danych. Musi być jednak starannie przetestowane.