Krótko: Automatyczne ataki na serwery WWW przebiegają falami: programy przeszukują internet w poszukiwaniu osiągalnych serwerów, klasyfikują je według cech zewnętrznych i masowo próbują znanych luk, takich jak PHP2Shell. Wielkość firmy nie ma przy tym znaczenia. Ochronę dają załatane PHP, mała powierzchnia ataku i monitoring, który szybko zauważa udane trafienia.
Punkt wyjścia: „Kogo miałaby interesować nasza strona?”
To pytanie słyszymy po PHP2Shell często, zwłaszcza od mniejszych firm. Szczera odpowiedź: prawdopodobnie nikogo osobiście. Ale przy lukach tego rodzaju nie jest to nawet potrzebne. Ataki wykonują programy, które nie szukają nazw, lecz okazji.
BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) spodziewało się w przypadku PHP2Shell szybkiego, szeroko zakrojonego wykorzystania. Cloudflare informował o próbach ataków i o tym, że atakujący zmieniali swoje wzorce, aby obejść reguły ochronne. Jedno i drugie pasuje do tego, co przy krytycznych lukach w szeroko rozpowszechnionym oprogramowaniu dzieje się regularnie.
Jak przebiegają automatyczne ataki na serwery WWW
Zautomatyzowane kampanie podążają zwykle podobnym wzorcem. Poniższe zestawienie opisuje fazy ogólnie, bez szczegółów ataku:
| Faza | Co się dzieje | Co pomaga |
|---|---|---|
| Szukanie | Programy sprawdzają duże zakresy adresów lub publiczne rejestry, takie jak dzienniki certyfikatów, w poszukiwaniu osiągalnych serwerów WWW | mało publicznie dostępnych systemów, inwentarz wszystkich adresów |
| Klasyfikacja | Odpowiedzi są analizowane: serwer WWW, wersja PHP, CMS, typowe ścieżki | ukryć informacje o wersjach, usunąć zbędne pliki |
| Próbowanie | znane luki są testowane masowo, często bez wcześniejszej klasyfikacji | aktualne PHP, restart, WAF jako dodatkowa warstwa |
| Utrwalenie | po sukcesie zostawiana jest tylna furtka, na przykład webshell lub zadanie cron | ograniczone prawa zapisu, brak wykonywania PHP w katalogach przesyłania |
| Wykorzystanie | serwer jest używany, na przykład do spamu, kopania kryptowalut, przekierowań lub kradzieży danych | monitoring procesów, plików i połączeń wychodzących |
Ważny jest trzeci wiersz. Wiele kampanii nie zadaje sobie w ogóle trudu, by wcześniej dokładnie klasyfikować serwery. Po prostu próbują wszystkiego, co jest osiągalne. Dlatego sama niewidoczność nie chroni.
Dlaczego ataki przychodzą falami
Zautomatyzowane kampanie rzadko przebiegają raz i nigdy więcej. Typowy jest wzorzec w falach. Pierwsza fala następuje krótko po ujawnieniu luki, często jeszcze z niedopracowanymi narzędziami. Kolejne fale przychodzą, gdy atakujący ulepszają swoje narzędzia lub dostosowują je do reguł ochronnych. Cloudflare zaobserwował przy PHP2Shell dokładnie to: zmienione wzorce ataków mające obejść reguły.
Dla Państwa oznacza to: serwer, który przetrwał pierwszą falę bez szkód, nie jest trwale bezpieczny, dopóki jest niezałatany. A nowo postawiony serwer jest celem od chwili, gdy staje się osiągalny. Kto na przykład zleca wystawienie nowego certyfikatu TLS, ujawnia nazwę w publicznych dziennikach certyfikatów, które analizują także skanery. Nowy system powinien więc trafić do sieci dopiero wtedy, gdy jest już zaktualizowany.
Dlaczego małe firmy są dotknięte tak samo
Dla automatycznych ataków liczy się nie wartość pojedynczego celu, lecz ich liczba. Serwer małego zakładu oferuje moc obliczeniową, domenę z dobrą reputacją, wysyłkę poczty, a czasem dane klientów. Dla atakujących to wystarczy.
Dochodzi do tego: mniejsze firmy często nie mają własnego IT, które natychmiast instaluje aktualizacje. Ich serwery pozostają dłużej podatne i dlatego częściej trafiają na listy wyników skanerów. Kto załata pierwszy, wypada z tych list.
Kolejny punkt to łańcuch dostaw. Wiele małych stron znajduje się na serwerach agencji lub małych dostawców hostingu, na których obok siebie działają dziesiątki projektów klientów. Dla atakujących taki serwer jest szczególnie opłacalny, bo jedno trafienie dotyka wielu stron naraz. Państwa ryzyko zależy wtedy nie tylko od Państwa własnej staranności, ale także od staranności usługodawcy.
Skanowania w Państwa logach są normalne i nie są dowodem włamania. Udany atak widać po innych śladach: nowych plikach, obcych procesach, nieznanych kontach, nietypowych połączeniach wychodzących.
Co mogą Państwo sprawdzić sami
Spojrzenie do logów pokazuje, jak intensywnie Państwa serwer jest skanowany. Poniższe polecenia tylko czytają i niczego nie zmieniają:
# Dziesięć adresów z największą liczbą żądań w bieżącym logu dostępu
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Żądania, na które odpowiedziano „nie znaleziono”, według częstotliwości
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Czy serwer ujawnia wersję PHP w nagłówku?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Wiele żądań na nieistniejące ścieżki to typowy szum skanowań. Uwagę należy zwrócić wtedy, gdy po takich żądaniach nagle następują udane odpowiedzi, gdy w katalogach przesyłania wywoływane są pliki, których Państwo nie znają, lub gdy użytkownik serwera WWW uruchamia procesy, których zwykle nigdy nie uruchamia. Potwierdzonych cech rozpoznawczych specjalnie dla PHP2Shell jak dotąd nie ma, ocena opiera się więc na takich nietypowych zachowaniach. Jak dokładniej analizować logi, opisuje poradnik Analiza logów serwera WWW. Jeśli trzecie zapytanie pokazuje wersję PHP, warto ustawić expose_php = Off; tło opisano pod hasłem Ukrywanie informacji o wersji.
Warstwy ochrony we właściwej kolejności
- Zaktualizować PHP i zrestartować: Bez tego kroku wszystkie inne środki pozostają łataniem dziur.
- Zmniejszyć powierzchnię ataku: nieużywane strony, systemy testowe i stare mikrostrony wyłączyć lub umieścić za logowaniem.
- Reguły na brzegu: Web Application Firewall z utrzymywanym zestawem reguł, na przykład OWASP Core Rule Set z ModSecurity, przechwytuje część prób.
- Hamować powtarzane próby: Narzędzia takie jak Fail2ban blokują adresy, które generują wyjątkowo wiele błędów. Przeciw rozproszonym skanowaniom pomaga to tylko w ograniczonym stopniu.
- Monitorować: Mieć na oku procesy użytkownika serwera WWW, nowe pliki PHP i połączenia wychodzące, aby udane trafienie nie pozostawało niezauważone przez tygodnie.
Jak konkretnie pomaga PHP SOS?
- Rozpoznanie powierzchni ataku: Ustalamy, które Państwa systemy są osiągalne z zewnątrz i co ujawniają o sobie.
- Łatanie i utwardzanie: Aktualizujemy PHP, restartujemy i ograniczamy informacje o wersjach, prawa zapisu i zbędne usługi.
- Reguły i blokady: Wdrażamy reguły WAF i mechanizmy blokowania dopasowane do Państwa aplikacji.
- Stały monitoring: Zgłaszamy nietypowe procesy, pliki i połączenia, zanim trafienie stanie się incydentem.
Jak wygląda to w pracy ciągłej, opisuje monitoring bezpieczeństwa dla serwerów WWW.
Podsumowanie
Automatyczne ataki nie pytają, do kogo należy serwer. Pytają tylko, czy jest podatny. Najlepsza odpowiedź na to jest niewidowiskowa: szybko łatać, mało oferować, uważnie patrzeć. Kto to robi, nadal jest skanowany, ale nie jest już znajdowany.
Częste pytania
Czy małe firmy są celem automatycznych ataków?
Tak. Automatyczne skanowania sprawdzają osiągalne serwery bez względu na operatora. To, czy za serwerem stoi koncern czy zakład rzemieślniczy, nie ma dla oprogramowania znaczenia. Decydujące jest, czy serwer wygląda na podatny.
Po czym poznam skanowania w swoich logach?
Typowe są liczne żądania na ścieżki, których na Państwa stronie w ogóle nie ma, często ze zmieniających się adresów i z rzucającymi się w oczy identyfikatorami. Takie wpisy są normalne i nie dowodzą jeszcze udanego ataku, ale pokazują, że Państwa serwer jest sprawdzany.
Czy pomaga ukrycie wersji PHP?
Utrudnia skanerom nieco ukierunkowane rozpoznanie Państwa serwera i jest sensownym ustawieniem podstawowym. Nie chroni jednak przed atakami, które po prostu próbują każdego serwera. Aktualizacja pozostaje obowiązkiem.
Czy mogę całkowicie zapobiec skanowaniom?
Nie. Każdy publicznie dostępny serwer jest regularnie skanowany. Celem nie jest zapobieganie skanowaniom, lecz zadbanie o to, by nic nie znalazły: aktualne oprogramowanie, mała powierzchnia ataku i monitoring, który zgłasza nieprawidłowości.