Po DDoS: jak przywrócić serwer Minecraft i nie dopuścić do powtórki

Atak DDoS się skończył. Serwer albo leży, albo ledwo dyszy. W konsoli kasza z błędów, gracze piszą na Discordzie "kiedy naprawicie?", a ty siedzisz i nie wiesz, od czego zacząć. Znajome?

Ten artykuł jest dla tych, którzy już dostali DDoS-em i teraz rozgrzebują skutki. Nie będziemy gadać o tym, czym jest DDoS i jak działa. Skupimy się na konkretach: co robić teraz, jak sprawdzić serwer, jak się pozbierać i jak zrobić, żeby to się nie powtórzyło.

Podzieliłem proces na 12 kroków. Możesz iść po kolei albo skoczyć od razu do potrzebnej sekcji. Ale jeśli masz czas, przejdź wszystkie. Każdy jest ważny.

Krok 1: Oceń stan aktualny

Zanim cokolwiek naprawisz, musisz zrozumieć skalę problemu. Nie uruchamiaj serwera dla graczy od razu po ataku. Najpierw sprawdź wszystko po cichu. To krytycznie ważne: jeśli otworzysz serwer z uszkodzonymi danymi, gracze zaczną grać, a przy następnym zapisie uszkodzenia się utrwalą.

Czy serwer w ogóle działa?

Wejdź po SSH i sprawdź podstawy:

# Sprawdzamy, czy proces żyje
ps aux | grep java

# Patrzymy na obciążenie
top -bn1 | head -20

# Sprawdzamy wolne miejsce na dysku
df -h

# Patrzymy na połączenia sieciowe
ss -tulnp | grep 25565

Jeśli proces Java padł, nie rzucaj się od razu go restartować. Najpierw zajrzyj do logów. Jeśli serwer wisi i nie odpowiada, ale proces żyje, spróbuj zrobić thread dump (kill -3 <PID>) zanim go zabijesz. To może dać info o tym, co dokładnie zawisło.

Zwróć uwagę na czas działania procesu (kolumna TIME w top). Jeśli Java ciągnie 100% CPU już długo, pewnie serwer zawisł w nieskończonej pętli albo GC-sztormie. W takim wypadku thread dump będzie szczególnie przydatny.

Sprawdź sieć

Atak DDoS mógł przeciążyć interfejs sieciowy, a nawet po zakończeniu ataku mogą być resztkowe problemy:

# Sprawdzamy interfejs sieciowy
ip -s link show eth0

# Patrzymy na błędy i dropy
ifconfig eth0 | grep -i "error\|drop"

# Sprawdzamy, czy conntrack nie jest zapchany
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Jeśli conntrack jest zapchany pod korek, nowe połączenia nie będą się mogły nawiązać. Ale nie spiesz się z flush na żywca - poczekaj, aż stare wpisy wygasną same, albo zrestartuj serwer czysto.

Sprawdź też, czy hoster nie założył automatycznego null-route. Niektórzy providerzy przy wykryciu DDoS blokują twój IP na poziomie sieci na kilka godzin. W takim przypadku nawet po zakończeniu ataku twój serwer będzie niedostępny z internetu. Zajrzyj do panelu hostera albo napisz do supportu, żeby ustalić.

Sprawdź czas

Zapisz dokładny czas początku i końca ataku. Przyda się do:

• Wyznaczenia punktu przywrócenia backupu
• Analizy logów
• Zrobienia post-mortem
• Ewentualnego zgłoszenia organom ścigania

Jeśli nie znasz dokładnego czasu początku, poszukaj w logach serwera momentu pierwszego masowego rozłączenia graczy albo pierwszego wybuchu błędów.

Krok 2: Sprawdź spójność danych

To najważniejszy etap. Sam atak DDoS nie modyfikuje plików na serwerze. Ale jeśli serwer padł niepoprawnie (kill -9, OOM, zawieszenie), dane mogły się uszkodzić. Minecraft zapisuje świat okresowo, a jeśli proces został przerwany w momencie zapisu, pliki mogą się znaleźć w nieprawidłowym stanie.

Świat (World)

Uszkodzenie świata to najboleśniejszy problem. Objawy:

• Serwer wyrzuca przy ładowaniu konkretnych chunków
• Chunki "cofnęły się" do starszej wersji
• Pojawiły się "dziury" w świecie (puste chunki)
• Plik level.dat jest uszkodzony
• Serwer zgłasza błędy przy czytaniu plików region

Sprawdzanie:

# Rozmiar plików świata - nagły spadek podejrzany
ls -la world/region/
ls -la world/level.dat

# Szukamy plików o zerowym rozmiarze
find world/region/ -size 0

# Sprawdzamy region files pod kątem spójności
# Są do tego narzędzia w stylu MCASelector

Jeśli level.dat jest uszkodzony, spróbuj level.dat_old. Minecraft trzyma kopię poprzedniej wersji. Plik level.dat zawiera krytycznie ważne info: czas świata, pozycję spawnu, generator świata, reguły gry. Bez niego serwer się nie uruchomi.

Pliki region (.mca) trzymają bloki chunków. Każdy plik odpowiada za obszar 32x32 chunków. Jeśli konkretny region-file jest uszkodzony, stracisz tylko ten obszar, nie cały świat. MCASelector pozwala wizualnie znaleźć i usunąć uszkodzone chunki, po czym Minecraft je wygeneruje na nowo.

Dane graczy

# Sprawdzamy pliki playerdata
ls -la world/playerdata/

# Sprawdzamy rozmiar - pliki 0 bajtów = utrata danych
find world/playerdata/ -size 0

# Sprawdzamy advancements
find world/advancements/ -size 0

# Sprawdzamy stats
find world/stats/ -size 0

Pliki playerdata o 0 bajtach oznaczają, że dane gracza przepadły. Ekwipunek, pozycja, osiągnięcia, zdrowie, poziom doświadczenia - wszystko. Odzyskać można tylko z backupu.

Jeśli przepadły dane kilku graczy, ale nie wszystkich, to zwykle znaczy, że serwer padł dokładnie w momencie zapisu danych tych konkretnych graczy. Takie rzeczy zdarzają się, gdy OOM killer albo kernel zabija proces w środku cyklu autozapisu.

Osobno sprawdź dane ekonomii. Jeśli używasz pluginów w stylu Vault, EssentialsX albo CMI ze storage plikowym, sprawdź też ich pliki danych. Utrata salda gracza to poważny problem, który może doprowadzić do konfliktów w społeczności.

Konfiguracje

Zazwyczaj configi nie cierpią od DDoS. Ale sprawdź na wszelki wypadek:

# Sprawdzamy, czy configi nie zmieniły się od ostatniego znanego stanu
find . -name "*.yml" -newer /tmp/last_known_good -type f

# Sprawdzamy ops.json pod kątem podejrzanych zmian
cat ops.json

Szczególną uwagę zwróć na server.properties, spigot.yml, paper.yml i pliki pluginów. Jeśli podejrzewasz, że ktoś dostał dostęp do serwera w trakcie ataku (mało prawdopodobne przy czystym DDoS, ale bywa przy atakach kombinowanych), sprawdź ops.json, whitelist.json i banned-players.json.

Atak kombinowany to kiedy DDoS jest używany jako przykrywka. Kiedy ty walczysz z DDoS, atakujący próbuje wyeksploatować luki w pluginach, brute'ować hasła RCON albo SSH. Brzmi paranoicznie, ale zdarza się.

Baza danych

Jeśli używasz MySQL/MariaDB dla pluginów (LuckPerms, ShopGUI+, itd.), sprawdź spójność tabel:

-- Dla MySQL
CHECK TABLE luckperms_user_permissions;
CHECK TABLE luckperms_group_permissions;

-- Albo przez mysqlcheck
-- mysqlcheck --all-databases

Bazy danych są zwykle odporne na nagłe przerwanie dzięki journalingowi transakcji (WAL/InnoDB log). Ale sprawdzić nie zaszkodzi.

Krok 3: Analiza logów

Logi powiedzą ci, co się właściwie stało. Nie pomijaj tego kroku, nawet jak chce ci się szybko wszystko postawić. Zrozumienie charakteru ataku pomoże ci dobrze skonfigurować obronę.

Czego szukać w logach serwera

# Ostatnie wpisy przed padem
tail -200 logs/latest.log

# Szukamy wzorców ataku
grep -i "connection\|disconnect\|timeout\|overflow" logs/latest.log | tail -50

# Liczba połączeń w czasie
grep "logged in with entity" logs/latest.log | awk '{print $1, $2}' | uniq -c | sort -rn | head -20

Zwróć uwagę na:

• Nagły wybuch połączeń w krótkim okresie. Jeśli w ciągu minuty podłączyło się 500 "graczy", to atak botów
• Masowe rozłączenia z tym samym komunikatem błędu
• Timeouty odczytu/zapisu ("Read timed out", "Connection reset")
• OutOfMemoryError albo podobne krytyczne błędy
• Nietypowe adresy IP, które łączyły się wielokrotnie
• Komunikaty typu "Can't keep up! Is the server overloaded?"

Jeśli serwer używa Paper albo jego forków, w folderze logs/ mogą być pliki z datą. Sprawdź logi z dni ataku. Zwróć uwagę na raporty timings (jeśli były włączone) - pokażą, które komponenty serwera były obciążane najmocniej.

Logi systemowe

# Patrzymy na dmesg pod kątem problemów z siecią lub pamięcią
dmesg | tail -100

# OOM killer?
dmesg | grep -i "oom\|killed"

# Problemy sieciowe
dmesg | grep -i "eth0\|network\|link"

# Sprawdzamy syslog
grep -i "conntrack\|nf_conntrack" /var/log/syslog | tail -20

Jeśli kernel zabił proces przez OOM killer, zobaczysz odpowiedni wpis. To znaczy, że atak wyssał całą dostępną pamięć. W takim wypadku warto pomyśleć o zwiększeniu limitów pamięci albo konfiguracji swap.

Wpis nf_conntrack: table full, dropping packet w syslogu oznacza, że tabela śledzenia połączeń się przepełniła. Klasyczny znak ataku DDoS z dużą liczbą połączeń.

Logi hostingu/VPS

Jeśli twój serwer jest na VPS, sprawdź panel hostera. Wielu providerów rejestruje info o anomaliach sieciowych i udostępnia wykresy ruchu. Niektórzy automatycznie włączają null-route przy wykryciu DDoS, i twój IP mógł zostać zablokowany na poziomie providera. Ustal to w supporcie.

Poproś hostera o dane netflow albo przynajmniej wykres ruchu za okres ataku. Pomoże to zrozumieć rozmiar ataku (Gbps/Mpps) i dobrać odpowiedni poziom ochrony.

Ustal typ ataku

Po logach da się ustalić charakter ataku:

• Volumetric (UDP/ICMP flood): serwer był niedostępny, w logach mało info, hoster zgłosił skok ruchu przychodzącego. Twój serwer nie ma tu nic do rzeczy - kanał został po prostu zalany śmieciem.
• TCP SYN flood: dużo półotwartych połączeń, conntrack przepełniony, serwer działał, ale nowi gracze nie mogli się podłączyć.
• Application-layer (atak botów): w logach serwera masowe połączenia, serwer tnie z powodu obciążenia CPU, TPS spadł.
• Kombinowany: oznaki kilku typów naraz. Najgorszy wariant.

Typ ataku decyduje o tym, jaką ochronę trzeba skonfigurować. Przeciw volumetric pomoże tylko zewnętrzny filtr. Przeciw application-layer mogą pomóc pluginy i reguły firewalla.

Krok 4: Sprawdź, czy nie wyciekł twój IP

Jedną z głównych przyczyn powtórnych ataków jest to, że atakujący zna twój IP i może uderzyć ponownie w każdej chwili. Dopóki twój IP jest znany, jesteś zagrożony.

Jak IP mógł wyciec:

• Rekord DNS typu A wskazujący bezpośrednio na serwer. Każdy może zrobić nslookup twojej domeny
• Gracz z botem albo modem, który zapisuje IP przy podłączeniu
• Twój IP został opublikowany na monitoringu serwerów (mc-monitoring, minecraft-server-list i podobne)
• Ktoś z adminów wrzucił IP na czat albo forum
• Atakujący znalazł IP przez historię DNS (SecurityTrails, DNSHistory)
• Rekord SRV DNS, który rezolwuje się na rekord A z prawdziwym IP
• Któryś z pluginów robił zewnętrzne zapytania i wyświetlił serwerowy IP

Sprawdź, czy atakujący zna twój obecny IP. Jeśli atak szedł bezpośrednio na IP, a nie na domenę, to znaczy, że IP jest spalony i trzeba go zmienić. Historię DNS można sprawdzić na SecurityTrails - jeśli twój prawdziwy IP kiedyś był w rekordach DNS, już go znają.

Szczegółowy poradnik dotyczący ochrony IP: Jak ukryć IP serwera Minecraft.

Krok 5: Odzyskiwanie z backupów

Jeśli dane są uszkodzone, trzeba przywracać z backupu. Jeśli backupów nie ma, to bolesna lekcja. Po odzyskaniu koniecznie skonfiguruj automatyczne kopie zapasowe. Backupy to ta rzecz, która nie jest potrzebna dokładnie do momentu, kiedy jest potrzebna krytycznie.

Jak poprawnie odzyskać

1. Zatrzymaj serwer całkowicie. Nie przywracaj plików na działającym serwerze. Proces Javy może trzymać pliki otwarte, a twoje zmiany zostaną nadpisane przy następnym zapisie.

2. Wyznacz punkt przywrócenia. Znajdź ostatni backup zrobiony przed początkiem ataku. Nie używaj backupu stworzonego w trakcie ataku - może zawierać uszkodzone dane. Jeśli autobackup leci co 6 godzin, a atak zaczął się o 15:00, użyj backupu z 12:00.

3. Zrób backup aktualnego stanu przed przywracaniem. Tak, nawet uszkodzonego. Na wypadek, gdyby coś poszło nie tak, albo gdyby później się okazało, że w uszkodzonych danych jest coś użytecznego.

# Backup aktualnego (uszkodzonego) stanu
tar czf /backup/damaged_$(date +%Y%m%d_%H%M%S).tar.gz ./

4. Przywróć dane:

# Przywracamy tylko świat, jeśli problem jest tylko w nim
tar xzf /backup/world_backup_clean.tar.gz -C ./

# Albo pełne przywrócenie
tar xzf /backup/full_backup_clean.tar.gz -C ./

5. Sprawdź i uruchom serwer w trybie testowym, bez otwierania dla graczy. Wejdź sam, obejdź główne lokacje, sprawdź, czy świat ładuje się poprawnie.

Odzyskiwanie bez backupów

Jeśli nie masz backupów, a świat jest uszkodzony, spróbuj narzędzi do odzyskiwania:

• MCASelector - wizualne narzędzie do pracy z plikami region. Pozwala znaleźć i usunąć uszkodzone chunki. Minecraft wygeneruje je ponownie przy ładowaniu.
• NBTExplorer - do ręcznej edycji level.dat i innych plików NBT.
• Region Fixer - skrypt w Pythonie do automatycznego sprawdzania i naprawy plików region.

Nie daje to gwarancji, ale lepsze niż zaczynać od zera. Jeśli uszkodzonych jest kilka chunków w świecie, MCASelector da radę. Jeśli uszkodzony jest level.dat, NBTExplorer pomoże naprawić go ręcznie.

Więcej o strategiach backupu: Strategia kopii zapasowych dla serwerów Minecraft.

Krok 6: Wzmocnienie serwera

Odzyskać serwer to za mało. Trzeba zrobić tak, żeby następny atak nie doprowadził do tych samych skutków. Pomyśl o tym jak o aktualizacji obrony po oblężeniu.

Zmiana adresu IP

Jeśli atakujący zna twój IP, wróci. Zmiana IP to pierwsza rzecz, jaką trzeba zrobić. Dopóki jesteś na tym samym IP, jesteś podatny na powtórny atak w każdej chwili.

• Na VPS: zamów nowy IP u hostera albo zmigruj na inny serwer. Większość hosterów daje zmianę IP za darmo albo za niewielką opłatą
• Na serwerze dedykowanym: poproś providera o zmianę IP. Zwykle za darmo, ale może zająć trochę czasu
• Na serwerze domowym: zrestartuj router (jeśli IP jest dynamiczny) albo poproś dostawcę internetu o zmianę
• Po zmianie: zaktualizuj rekordy DNS, ale nie publikuj nowego IP publicznie

Ważne: nowy IP musi być schowany za proxy albo ochroną DDoS od pierwszego dnia. Inaczej znajdą go ponownie przez DNS albo monitoringi serwerów.

Konfiguracja firewalla

Bazowe reguły iptables, które powinny być na każdym serwerze Minecraft:

# Ograniczenie nowych połączeń na port 25565
iptables -A INPUT -p tcp --dport 25565 -m connlimit --connlimit-above 3 -j DROP

# Rate limiting dla nowych połączeń
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

# Zamykamy wszystkie porty oprócz potrzebnych
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP

To nie zatrzyma poważnego DDoS, ale odfiltruje drobne ataki i skany portów. Warto też ograniczyć dostęp do SSH po IP, jeśli łączysz się ze stałego adresu. Wyeliminuje to próby brute-force.

Więcej o iptables dla Minecrafta: Atak DDoS na serwer Minecraft: co robić.

Konfiguracja parametrów sieciowych kernela

Dla serwerów Linux warto zoptymalizować parametry sysctl:

# Zwiększamy tabelę conntrack
net.netfilter.nf_conntrack_max = 262144

# Przyspieszamy timeouty dla conntrack
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30

# Ochrona przed SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096

# Przyspieszamy reuse socketów
net.ipv4.tcp_tw_reuse = 1

Te parametry pomogą serwerowi lepiej radzić sobie z wybuchami połączeń i szybciej zwalniać zasoby z zakończonych połączeń.

Konfiguracja limitów serwera

W server.properties:

max-players=100
rate-limit=10
network-compression-threshold=256

Parametr rate-limit ogranicza liczbę pakietów od jednego klienta na sekundę. Jeśli klient przekroczy limit, połączenie zostaje zamknięte. Wartość 10 to dobry balans między ochroną a wygodą.

W spigot.yml:

settings:
  connection-throttle: 4000

connection-throttle to minimalny odstęp w milisekundach między połączeniami z jednego IP. Wartość 4000 (4 sekundy) nie przeszkadza zwykłym graczom, ale spowalnia boty.

W paper.yml (Paper 1.19+):

proxies:
  velocity:
    enabled: true
    secret: "twoj_sekretny_klucz"

Jeśli używasz Velocity jako proxy, koniecznie włącz modern forwarding. To zapobiega spoofingowi UUID i nieautoryzowanemu dostępowi przez bezpośrednie podłączenie do backendu.

Pluginy do ochrony

• EpicGuard - darmowy antybot ze sprawdzaniem CAPTCHA, blokadą VPN i filtrowaniem geo
• AntiBot - limit połączeń, sprawdzanie klienta, filtrowanie geo
• BotSentry - zaawansowana ochrona przed botami z machine learningiem

Pluginy pomogą od prostych ataków botów, ale od volumetric DDoS są bezradne. Do poważnej ochrony potrzebna jest usługa zewnętrzna. Plugin nie może filtrować ruchu, który nawet nie dociera do procesu Javy, bo kanał jest już zapchany.

Krok 7: Konfiguracja ochrony DDoS

Jeśli doczytałeś do tego kroku, to znaczy, że przeszedłeś już przez DDoS i rozumiesz, że to nie żarty. Pluginy i iptables dają podstawowy poziom. Przeciw poważnemu atakowi potrzebny jest zewnętrzny filtr DDoS, który będzie obrabiał ruch zanim dotrze on do twojego serwera.

Co powinien umieć dobry filtr:

• Filtrować ruch zanim dotrze do twojego serwera. Ruch powinien przechodzić przez node filtrującą, a nie lecieć bezpośrednio
• Ukrywać prawdziwy IP twojego serwera. Gracze łączą się z IP filtra, nie z twoim
• Obsługiwać protokoły TCP i UDP (Bedrock Edition używa UDP)
• Dawać minimalne opóźnienie (< 5 ms dodanej latencji)
• Automatycznie wykrywać i mitygować ataki bez ręcznej interwencji
• Przepuszczać prawdziwych graczy nawet w trakcie ataku

MineGuard zapewnia dokładnie taką ochronę: cały ruch idzie przez filtrujące proxy, prawdziwy IP jest ukryty, ataki są mitygowane automatycznie. Podłączenie zajmuje 5 minut i nie wymaga zmian w oprogramowaniu serwera.

Dlaczego nie CloudFlare albo zwykły hosting z "anty-DDoS"?

CloudFlare to świetna usługa dla stron WWW, ale nie proxy'uje ruchu TCP/UDP dla Minecrafta na darmowym planie. CloudFlare Spectrum potrafi, ale kosztuje od 5$/mies za 5 Gbps i nie ma wyspecjalizowanej filtracji pod Minecrafta.

Hosterzy często piszą "DDoS protection included", ale w praktyce oznacza to null-route przy wykryciu ataku (twój IP jest blokowany na 24 godziny) albo podstawowe filtrowanie na poziomie L3/L4, które nie pomaga przeciw atakom application-layer.

Krok 8: Konfiguracja autobackupów

Jeśli przed atakiem nie miałeś backupów, skonfiguruj je teraz. Nie odkładaj. Następny incydent może się zdarzyć jutro.

Strategia 3-2-1

Klasyczna strategia kopii zapasowych:

• 3 kopie danych
• Na 2 różnych typach nośników
• 1 kopia w zdalnej lokalizacji

Dla serwera Minecraft może to wyglądać tak:

• Lokalny backup na tym samym serwerze (do szybkiego odzyskiwania)
• Backup na osobny VPS albo NAS
• Backup w chmurze (S3, Google Cloud Storage, Backblaze B2)

Harmonogram

• Co 30 minut: autozapis świata (wbudowana komenda save-all)
• Co 4-6 godzin: pełny backup świata i danych graczy
• Codziennie: pełny backup z configami i pluginami
• Co tydzień: backup całego serwera włącznie z bazami danych

Automatyzacja

Prosty skrypt cron do backupu:

#!/bin/bash
# /opt/backup-minecraft.sh
BACKUP_DIR="/backup/minecraft"
SERVER_DIR="/opt/minecraft"
DATE=$(date +%Y%m%d_%H%M%S)

# Wysyłamy komendę save-all przez screen/tmux
screen -S minecraft -p 0 -X stuff "save-all\n"
sleep 5
screen -S minecraft -p 0 -X stuff "save-off\n"
sleep 2

# Tworzymy backup
tar czf "$BACKUP_DIR/world_$DATE.tar.gz" -C "$SERVER_DIR" world world_nether world_the_end

# Włączamy autozapis z powrotem
screen -S minecraft -p 0 -X stuff "save-on\n"

# Usuwamy backupy starsze niż 7 dni
find "$BACKUP_DIR" -name "world_*.tar.gz" -mtime +7 -delete

Dodaj do crontab: 0 */4 * * * /opt/backup-minecraft.sh

Więcej o strategiach backupu: Strategia kopii zapasowych dla serwerów Minecraft.

Krok 9: Komunikacja z graczami

Nie ignoruj społeczności. Gracze zauważyli, że serwer leżał, i chcą wiedzieć, co się stało. Przejrzystość jest ważniejsza niż "fajny" obraz. Gracze, którzy rozumieją sytuację, są bardziej lojalni niż ci, których trzyma się w niewiedzy.

Co powiedzieć

• Serwer dostał atak DDoS (nie ma się czego wstydzić, zdarza się najlepszym. Hypixel, 2b2t, MineHeroes - wszyscy przez to przeszli)
• Jakie dane mogły zostać dotknięte (cofnięcie świata, utrata postępów)
• Co zrobiłeś, żeby to naprawić
• Jakie środki podjąłeś, żeby się nie powtórzyło
• Jak gracze mogą zgłaszać problemy (zaginione przedmioty, zła pozycja)

Czego NIE mówić

• Nie oskarżaj konkretnych ludzi bez dowodów. Nawet jeśli kogoś podejrzewasz, publiczne oskarżenia mogą wywołać toksyczność w społeczności
• Nie publikuj technicznych detali ataku (typ, rozmiar, źródła). To info dla atakującego, co zadziałało
• Nie obiecuj "to się więcej nie zdarzy" - obiecuj "podjęliśmy środki, żeby temu zapobiec"
• Nie panikuj i nie dramatyzuj. "Zaatakowali nas hakerzy!!!" brzmi nieprofesjonalnie

Przykład komunikatu na Discorda

Cześć wszystkim. Wczoraj od 14:00 do 18:00 serwer był niedostępny z powodu
ataku DDoS. Przywróciliśmy działanie, ale świat cofnął się o około
2 godziny (do ostatniego autozapisu przed atakiem).

Co zrobiliśmy:
- Przywróciliśmy świat z backupu
- Zmieniliśmy adres IP
- Podłączyliśmy ochronę DDoS

Jeśli zauważycie brak przedmiotów albo inne problemy, załóżcie
ticket na #wsparcie. Postaramy się pomóc.

Przepraszamy za utrudnienia.

Krótko, szczerze, bez paniki. Gracze to doceniają. Jeśli atak doprowadził do poważnej utraty danych, pomyśl o kompensacji dla poszkodowanych graczy. Może to być przywrócenie przedmiotów, bonusy albo waluta wewnątrzgrowa. Nieobowiązkowo, ale robi dobre wrażenie.

Timing komunikatów

• W trakcie ataku: krótki komunikat "Serwer tymczasowo niedostępny, pracujemy nad przywróceniem"
• Od razu po przywróceniu: szczegółowy komunikat z opisem sytuacji
• Po 24-48 godzinach: update o podjętych środkach ochrony, jeśli były poważne zmiany

Krok 10: Aspekty prawne

Czy można zgłosić DDoS na policję? Technicznie - tak. Praktycznie - to skomplikowane, ale są sytuacje, kiedy to konieczne.

Polska

Atak DDoS w polskim prawie podpada pod artykuł 268a Kodeksu karnego (naruszenie integralności zapisu informatycznego) i artykuł 269a (sabotaż komputerowy). Kara - do 5 lat pozbawienia wolności.

Do zgłoszenia będziesz potrzebować:

• Logów serwera ze znacznikami czasu
• Danych od hostingu o charakterze ruchu (netflow, wykresy)
• Wszelkiej korespondencji z atakującym (jeśli są groźby albo wymuszenia)
• Informacji o szkodzie finansowej (utracone donaty, koszt wynajmu serwerów)

Realia: policja rzadko zajmuje się atakami DDoS na serwery growe, szczególnie jeśli chodzi o drobne ataki bez wymuszenia. Ale jeśli atakowi towarzyszy wymuszenie ("zapłać 500$ albo będziemy ddosować codziennie"), szanse na śledztwo znacząco rosną.

Międzynarodowo

W większości krajów ataki DDoS są nielegalne. W USA to Computer Fraud and Abuse Act (CFAA), w UE różne prawa krajowe o przestępstwach komputerowych, w Niemczech StGB §303b (Computersabotage). Ale śledztwo transgraniczne jest wyjątkowo trudne, szczególnie jeśli atakujący używa botnetu z różnych krajów.

Rada praktyczna

Zachowuj wszystkie logi i dowody, nawet jeśli nie planujesz iść na policję teraz. Jeśli ataki będą się powtarzać albo przerodzą się w wymuszenie, te dane będą potrzebne. Okres przedawnienia przestępstw komputerowych w większości jurysdykcji to od 2 do 6 lat, więc dowody mogą się przydać później.

Co zachować:

• Pełne logi serwera z okresu ataku
• Screenshoty wykresów ruchu od hostera
• Korespondencję z atakującym (jeśli jest)
• Dane o czasie przestoju i stratach finansowych
• Adresy IP z logów (choć są zwykle spoofowane albo należą do botnetu)

Krok 11: Plan reagowania na incydenty

Nie czekaj na następny atak, żeby zacząć myśleć, co robić. Przygotuj plan wcześniej. Kiedy DDoS jest w pełnym rozkwicie, będziesz się denerwować i zapominać oczywiste rzeczy. Gotowy plan oszczędza czas i nerwy.

Co powinno być w planie

1. Kontakty: kto odpowiada za serwer, jak skontaktować się z hosterem/dostawcą ochrony, kontakty do współadminów
2. Priorytety: co ważniejsze - prędkość przywrócenia czy bezpieczeństwo danych. Dla serwera PvP z rankingiem krytyczna jest każda minuta przestoju. Dla serwera RPG ważniejsze jest zachowanie postępów graczy
3. Procedury: instrukcje krok po kroku dla każdego typu incydentu. Napisz je tak, żeby nawet moderator bez wiedzy technicznej mógł wykonać pierwsze kroki
4. Backupy: gdzie są trzymane, jak przywrócić, kto ma dostęp. Trzymaj te info w kilku miejscach
5. Komunikacja: szablony komunikatów dla graczy, kanały powiadomień (Discord, VK, Telegram)
6. Eskalacja: kiedy dzwonić do hostera, kiedy podłączać dodatkową ochronę, kiedy pora zmienić IP
7. Post-mortem: co robić po przywróceniu (wypełnić szablon, zaktualizować plan)

Checklista do szybkiego reagowania

Wydrukuj tę checklistę albo wrzuć w zakładki. Kiedy zacznie się atak, sam sobie podziękujesz:

[ ] Atak wykryty, czas odnotowany
[ ] Ekipa powiadomiona (Discord/Telegram)
[ ] Ocena: serwer działa czy leży?
[ ] Jeśli jest ochrona DDoS: sprawdzić status filtracji
[ ] Jeśli nie ma ochrony: skontaktować się z hosterem
[ ] Gracze powiadomieni (krótko, bez paniki)
[ ] Logi zapisane (kopia w osobne miejsce)
[ ] Atak się skończył: sprawdzić stan serwera
[ ] Sprawdzić spójność danych (świat, playerdata, configi)
[ ] Przywrócić z backupu jeśli trzeba
[ ] Uruchomić serwer w trybie testowym
[ ] Otworzyć dla graczy
[ ] Post-mortem: zapisać co się stało i co poprawić

Krok 12: Szablon post-mortem

Po każdym incydencie warto zapisać, co się stało. Pomoże to tobie (i twojej ekipie) uczyć się na błędach i szybciej reagować następnym razem. Oto prosty szablon:

# Post-mortem: [Data incydentu]

## Chronologia
- [HH:MM] Wykryto problem (kto wykrył, jak)
- [HH:MM] Ustalono, że to DDoS
- [HH:MM] Podjęte działania
- [HH:MM] Serwer przywrócony
- [HH:MM] Otwarty dla graczy
- [HH:MM] Post-mortem wypełniony

## Wpływ
- Czas przestoju: X godzin Y minut
- Dane dotknięte: (świat cofnął się o N godzin / dane stracone / bez strat)
- Liczba dotkniętych graczy: ~N
- Straty finansowe: (utracone donaty, koszt przywracania)

## Przyczyna
- Typ ataku: (TCP SYN flood / UDP flood / atak botów / nieznany)
- Rozmiar: (jeśli znany od hostera, w Gbps albo Mpps)
- Czas trwania: (od pierwszych oznak do pełnego zakończenia)
- Przypuszczalny motyw: (konkurent / obrażony gracz / wymuszenie / nieznany)

## Co zadziałało
- (co pomogło przy przywracaniu)
- (które środki przygotowawcze się sprawdziły)

## Co nie zadziałało
- (co trzeba poprawić)
- (jakich procedur brakowało)

## Działania naprawcze
- [ ] (konkretne działanie 1, odpowiedzialny, deadline)
- [ ] (konkretne działanie 2, odpowiedzialny, deadline)
- [ ] (konkretne działanie 3, odpowiedzialny, deadline)

Nie trzeba pisać powieści. Pięć-dziesięć minut na wypełnienie szablonu po incydencie zaoszczędzi godziny przy następnym. Trzymaj post-mortemy w jednym miejscu (Google Docs, Notion, po prostu folder z plikami) i czytaj przed aktualizacją planu reagowania.

Podsumowanie: minimalny plan działań

Jeśli właśnie teraz przywracasz serwer po DDoS, oto zwięzły plan na jedną stronę:

1. Nie uruchamiaj serwera od razu. Sprawdź stan po SSH.
2. Sprawdź świat (level.dat, pliki region), dane graczy, configi.
3. Zajrzyj w logi. Zrozum typ i skalę ataku.
4. Przywróć z backupu, jeśli dane są uszkodzone.
5. Zmień adres IP. Stary jest spalony.
6. Skonfiguruj firewall, sysctl i limity serwera.
7. Podłącz ochronę DDoS zanim otworzysz serwer.
8. Skonfiguruj autobackupy, jeśli jeszcze ich nie masz.
9. Powiedz graczom, co się stało. Szczerze i bez paniki.
10. Zapisz post-mortem, póki detale są świeże.

Atak DDoS to nie koniec. To incydent, z którym można i trzeba sobie poradzić. Serwery, które przechodzą przez DDoS i wyciągają właściwe wnioski, stają się bardziej odporne. Wiele największych sieci Minecraft przeszło przez dziesiątki ataków i tylko się wzmocniło. Najważniejsze - nie ignoruj problemu i nie licz na "a nuż się nie powtórzy". Powtórzy się. Pytanie tylko, czy będziesz gotowy.