# DDoS czy atak hakerski? Jak prawidłowo ocenić atak

> DDoS czy atak hakerski? Typowe oznaki w porównaniu, pierwsze polecenia kontrolne na serwerze i co konkretnie zrobić w pierwszych godzinach.

Źródło: https://phpsos.de/pl/ratgeber/ddos-oder-exploit/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Czy to DDoS, czy atak hakerski, widać po śladach. DDoS generuje bardzo wiele żądań i czyni stronę wolną lub niedostępną, ale niczego nie zmienia. Exploit często potrzebuje tylko kilku żądań i zostawia nowe pliki, konta, procesy lub połączenia. Prawidłowa ocena decyduje o tym, czy trzeba odpierać obciążenie, czy ograniczać incydent.

## Różnica prostymi słowami

**Atak DDoS** (Distributed Denial of Service) jest jak tłum blokujący wejście do sklepu. Nikt nie wchodzi, ale w sklepie nic nie jest kradzione. Celem jest przeciążenie Państwa strony lub serwera, aby prawdziwi klienci nie mogli się przedostać.

**Exploit** to natomiast włamanie przez otwarte drzwi. Atakujący wykorzystuje podatność, na przykład w PHP, w CMS lub w rozszerzeniu, aby wykonać kod na Państwa serwerze. Może to nastąpić cicho, bez spowolnienia strony. Skutki sięgają od stron ze spamem, przez kradzież danych, po przejęcie serwera.

Dla zarządu różnica jest decydująca: DDoS to problem dostępności, który kończy się wraz z atakiem. Udany exploit to incydent bezpieczeństwa, który trwa, dopóki nie zostanie znaleziony, oczyszczony i udokumentowany.

## DDoS czy atak hakerski: oznaki w porównaniu

Poniższa tabela pomaga w pierwszej ocenie. Nie zastępuje analizy, ale pokazuje, gdzie zajrzeć w pierwszej kolejności.

| Cecha | Raczej DDoS | Raczej exploit lub włamanie |
|---|---|---|
| Dostępność | wolna lub niedostępna | często normalna |
| Żądania w logu | bardzo liczne, często jednolite | nieliczne, celowane żądania |
| Pliki | niezmienione | nowe lub zmienione pliki PHP |
| Konta | niezmienione | nowi administratorzy, zmienione hasła |
| Procesy | serwer WWW i PHP pod pełnym obciążeniem | nieznane procesy, kopanie kryptowalut, wysyłka spamu |
| Sieć | dużo ruchu przychodzącego | nietypowe połączenia wychodzące |
| Po zakończeniu | wszystko jak przedtem | ślady pozostają |

Uwaga na nakładanie się: masowe skanowanie w poszukiwaniu luki może wyglądać jak mały DDoS. Właśnie tego należało się spodziewać wokół PHP2Shell, gdy atakujący szukali podatnych serwerów. Duże obciążenie może więc też oznaczać, że ktoś właśnie próbuje się włamać.

## Pierwsze kontrole na serwerze

Poniższe polecenia niczego nie zmieniają w systemie i dają szybki przegląd. W razie podejrzenia włamania proszę zabezpieczyć logi, zanim przeprowadzą Państwo większe ingerencje.

```bash
# Obciążenie i czas działania
uptime

# Podsumowanie połączeń i najczęstsze strony przeciwne
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Najczęstsze adresy klientów w logu dostępu (dostosuj ścieżkę)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Pliki PHP zmienione w ostatnich 7 dniach
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Procesy o największym obciążeniu CPU
ps aux --sort=-%cpu | head -15
```

W przeglądzie połączeń czwarta kolumna pokazuje stronę przeciwną. Wiele połączeń z niewielu adresów lub wzrost do wielokrotności normalnej wartości wskazuje na przeciążenie. Nowe pliki PHP w katalogach uploadu lub pamięci podręcznej, procesy pod użytkownikiem serwera WWW z obcymi nazwami lub połączenia wychodzące do nieznanych celów wskazują raczej na włamanie. Obszerną listę znajdą Państwo na stronie [Oznaki kompromitacji po PHP2Shell](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/).

## Dlaczego duże obciążenie może być też manewrem odwracającym uwagę

Zdarza się, że atakujący wywołują przeciążenie, jednocześnie celowo się włamując. Zespół zajmuje się wtedy dostępnością, a właściwe ślady toną w szumie logów. Dlatego obowiązuje zasada: nawet jeśli DDoS jest oczywisty, po jego zakończeniu proszę sprawdzić pliki, konta i połączenia wychodzące.

W przypadku PHP2Shell dochodzi to, że według php.net i firm bezpieczeństwa nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Wykrywanie opiera się na analizie zachowania. Serwer, który w okresie skanowania od połowy października był niezałatany, powinien więc zostać sprawdzony niezależnie od zaobserwowanego obciążenia.

Kolejnym wariantem są e-maile z szantażem, w których grozi się atakiem DDoS, jeśli nie zostanie zapłacone. Takie wiadomości proszę zachować, nie płacić bez uzgodnienia ze specjalistami i rozważyć [zawiadomienie Centralnego Punktu Kontaktowego ds. Cyberprzestępczości (ZAC, Niemcy)](https://phpsos.de/pl/compliance/anzeige-polizei-zac/). Równolegle proszę poinformować swój hosting, aby można było przygotować środki ochronne. Jak w tym celu analizować logi, opisuje poradnik [Analiza logów serwera WWW po ataku](https://phpsos.de/pl/ratgeber/logfiles-auswerten/).

## Co zrobić w pierwszych godzinach

**W razie podejrzenia DDoS:**

- Poinformować hosting lub centrum danych; tam często są filtry przed serwerem.
- Włączyć lub zaostrzyć usługę ochronną przed serwerem albo [WAF z wirtualnym łataniem](https://phpsos.de/pl/leistungen/waf-virtuelles-patching/).
- Ustawić limity żądań na serwerze WWW i szczególnie chronić kosztowne strony, takie jak wyszukiwarka czy koszyk.
- Zachować logi, aby atak dało się później odtworzyć.

**W razie podejrzenia włamania:**

- Niczego nie usuwać i nie stawiać serwera od nowa, zanim logi i dotknięte pliki nie zostaną zabezpieczone.
- Zaktualizować PHP do naprawionej wersji i zrestartować wszystkie procesy robocze, jeśli jeszcze tego nie zrobiono.
- Jeśli aktualizacja nie jest możliwa od razu, tymczasowo odłączyć stronę od sieci, tak jak zaleca BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji).
- Odnowić dane dostępowe z czystego urządzenia, a nie z serwera, który może być dotknięty.
- Zlecić sprawdzenie, czy mogły zostać dotknięte dane osobowe; wtedy mogą biec terminy zgłoszenia.

W obu przypadkach pomaga krótka, rzeczowa notatka dla hostingu i usługodawców: od kiedy istnieje problem, które strony są dotknięte, co zaobserwowano i co już zmieniono. Proszę zapisać też, kto podjął jaką decyzję. Ta oś czasu oszczędza czas w analizie i jest później cenna dla ubezpieczenia, ochrony danych i wewnętrznego podsumowania. Jeśli nie jest jasne, czy w ogóle doszło do ataku, proszę prewencyjnie traktować sytuację jako incydent, dopóki nie zostanie udowodnione coś przeciwnego.

## Jak konkretnie pomaga PHP SOS?

- Oceniamy sytuację zdalnie na podstawie obciążenia, logów, plików i połączeń i mówimy Państwu, z czym prawdopodobnie mamy do czynienia.
- Przy przeciążeniu ustawiamy filtry, limity żądań i wstępne reguły ochronne, aż atak wygaśnie.
- Przy podejrzeniu włamania przejmujemy uporządkowane [reagowanie na incydenty](https://phpsos.de/pl/leistungen/incident-response/): zabezpieczyć, ograniczyć, znaleźć przyczynę, oczyścić.
- Na końcu dokumentujemy, co się stało i jakie środki wdrożono, aż do zamknięcia incydentu.


## Częste pytania

**Czy atak DDoS może wykraść dane?**  
Czysty atak DDoS ma na celu dostępność, a nie dane. Nie zmienia plików i nie czyta baz danych. Może jednak wystąpić równocześnie z próbą włamania, dlatego mimo to warto spojrzeć na pliki i konta.

**Po czym poznać, że moja strona została zhakowana?**  
Typowe wskazówki to nowe lub zmienione pliki PHP, nieznane konta administratorów, przekierowania na obce strony, nieoczekiwane połączenia wychodzące i procesy, które nie pasują do Państwa aplikacji. Pojedyncza oznaka nie jest dowodem, kilka naraz to poważny sygnał.

**Czy CDN lub WAF pomaga przeciw obu rodzajom ataków?**  
Przeciw atakom opartym na wolumenie usługa wstępna zwykle dobrze pomaga. Przeciw exploitom reguły działają tylko wtedy, gdy rozpoznają wzorzec. W przypadku PHP2Shell sam Cloudflare zwraca uwagę, że same reguły oparte na danych żądania nie wystarczą.

**Czy muszę zgłosić atak DDoS?**  
Zależy to od indywidualnego przypadku i Państwa branży. Bez dostępu do danych osobowych obowiązek zgłoszenia z RODO co do zasady nie obowiązuje, mogą jednak istnieć obowiązki branżowe. Proszę to wyjaśnić z inspektorem ochrony danych lub prawnikiem.

## Źródła

- [BSI: sytuacja i zalecenia (Niemcy)](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)