Crash-exploity w Minecraft: book ban, chunk ban i jak się przed nimi bronić

Gdy mówi się o bezpieczeństwie serwerów Minecraft, pierwsza rzecz, która przychodzi do głowy, to ataki DDoS. Tysiące botów, gigabity ruchu, serwer idzie w offline. Ale jest inna kategoria zagrożeń, która często zostaje w cieniu: crash-exploity.

Jeden gracz. Jeden specjalnie sformowany przedmiot albo pakiet. I twój serwer leci. Albo gorzej, konkretny gracz nie może już wejść na serwer, bo jego klient crashuje przy ładowaniu chunka albo inwentarza.

W tym artykule rozbierzemy wszystkie główne typy crash-exploitów, mechanikę ich działania i konkretne kroki ochrony.

Czym jest crash-exploit

Crash-exploit to celowany atak, który wykorzystuje bugi lub słabości w kodzie serwera/klienta do wywołania krytycznego błędu. W odróżnieniu od DDoS, gdzie atakujący zalewa serwer objętością ruchu, crash-exploit działa punktowo. Wystarczy jedno odpowiednio sformowane zapytanie.

Główne rodzaje:

• Book ban - przepełnienie danych NBT przez księgi
• Chunk ban - uszkadzanie chunków crashujących klienta przy ładowaniu
• Packet exploits - niepoprawne pakiety sieciowe wywołujące wyjątki na serwerze
• Sign exploit - przepełnienie danych przez tabliczki
• Map exploit - nadużywanie danych map
• Entity cramming - tworzenie ogromnej liczby encji w jednym bloku

Każdy z nich działa po swojemu, i ochrona przed nimi też się różni.

Book ban: klasyka gatunku

Book ban to chyba najbardziej znany crash-exploit w Minecraft. Sedno jest proste: gracz tworzy księgę z ogromną objętością danych NBT i podrzuca ją innemu graczowi. Gdy ofiara próbuje otworzyć inwentarz lub załadować chunk, gdzie leży ta księga, klient wylatuje z powodu braku pamięci.

Jak to działa

NBT (Named Binary Tag) to format danych, którego Minecraft używa do przechowywania informacji o przedmiotach. Każdy przedmiot ma tag NBT, a u ksiąg może on zawierać tekst stron.

Problem polega na tym, że w vanilla Minecraft ograniczenia na rozmiar NBT były przez długi czas zbyt łagodne. Księga może zawierać do 100 stron, każda do 32767 znaków. Daje to potencjalnie ogromną objętość danych w jednym przedmiocie.

Atakujący używają zmodyfikowanych klientów lub komend, żeby stworzyć księgi z maksymalnie napęczniałymi tagami NBT. Taka księga, gdy trafi do czyjegoś inwentarza lub shulker-boxa, sprawia, że ten gracz jest "zbanowany" - nie może wejść na serwer, bo klient crashuje przy próbie deserializacji NBT.

Typowy wektor ataku

1. Atakujący tworzy księgę z ogromnym NBT przez hack-klienta
2. Kładzie ją w shulker-boxie albo rzuca obok ofiary
3. Ofiara podnosi przedmiot lub otwiera kontener
4. Przy następnym wejściu klient crashuje przy ładowaniu inwentarza
5. Gracz jest faktycznie zbanowany, choć formalnie bana nie ma

Ochrona przed book ban

Paper dawno dodał ograniczenia na rozmiar NBT:

# paper-global.yml
item-validation:
  book:
    page-max: 100
    max-page-length: 1024
  book-size:
    page-max: 2560
    total-multiplier: 0.98

Parametr max-page-length: 1024 ogranicza długość jednej strony do 1024 znaków zamiast vanilla-ograniczenia 32767. Radykalnie obniża to maksymalny rozmiar NBT księgi.

book-size kontroluje ogólny rozmiar zserializowanych danych księgi. page-max: 2560 to maksymalny rozmiar jednej strony w bajtach przy sprawdzeniu, a total-multiplier: 0.98 gwarantuje, że każda kolejna strona jest liczona trochę mniej niż poprzednia (do obliczenia limitu).

Także ważne:

# paper-global.yml
packet-limiter:
  kick-message: '<red>Too many packets!'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

To nie jest bezpośrednia ochrona przed book ban, ale zapobiega masowemu wysyłaniu pakietów, które często idzie w pakiecie z tym exploitem.

Chunk ban: pułapka w świecie

Chunk ban działa inaczej. Zamiast zatrutego przedmiotu w inwentarzu, atakujący uszkadza chunk w świecie gry. Gdy jakikolwiek gracz próbuje załadować ten chunk, jego klient crashuje.

Mechanika

Jest kilka sposobów stworzenia "trującego" chunka:

Przepełnienie encjami. Gracz tworzy tysiące przedmiotów, mobów lub innych encji w jednym chunku. Przy ładowaniu klient próbuje wyrenderować je wszystkie i wylatuje.

Uszkodzone tile-entities. Kontenery (skrzynie, wsypy) z uszkodzonymi danymi NBT. Serwer wysyła klientowi dane tile-entity, a klient nie potrafi ich obsłużyć.

Ogromne konstrukcje ze znaków i tabliczek. Setki tabliczek z długim tekstem w jednym chunku tworzą ogromną objętość danych, które trzeba wysłać klientowi.

Jak to wygląda

Wyobraź sobie: gracz leci na elytrze i wlatuje w chunk-pułapkę. Klient zawiesza się, potem crashuje. Przy następnym wejściu serwer spawnuje gracza w tym samym chunku - i znów crash. Gracz utknął.

Na serwerach anarchii typu 2b2t to dawno zamieniło się w broń. Wokół baz buduje się "pola minowe" z pułapek chunk ban.

Ochrona przed chunk ban

# paper-global.yml
chunk-system:
  gen-parallelism: default
  io-threads: -1
  worker-threads: -1

# spigot.yml
world-settings:
  default:
    entity-activation-range:
      animals: 32
      monsters: 32
      raiders: 64
      misc: 16
      water: 16
      villagers: 32
      flying-monsters: 32
    merge-radius:
      exp: 3.0
      item: 2.5

Ale główna ochrona to ograniczenie liczby encji:

# paper-world-defaults.yml (Paper)
entities:
  spawning:
    per-player-mob-limit: true
    max-per-chunk: 50

# bukkit.yml
spawn-limits:
  monsters: 70
  animals: 10
  water-animals: 5
  water-ambient: 20
  water-underground-creature: 5
  axolotls: 5
  ambient: 15

Parametr max-per-chunk: 50 jest krytycznie ważny. Ustawia twardy limit na liczbę encji w jednym chunku.

Packet exploits: atak na protokół

Packet exploits to szeroka kategoria ataków opartych na wysyłaniu serwerowi niepoprawnych lub zbyt dużych pakietów sieciowych. W odróżnieniu od book ban i chunk ban, które eksploatują mechanikę gry, packet exploits biją po warstwie sieciowej.

Główne rodzaje

Oversized packets. Wysyłanie pakietów przekraczających maksymalnie dopuszczalny rozmiar. Vanilla serwer domyślnie przyjmuje pakiety do 2 MB. Atakujący wysyła pakiet 2 GB, a serwer marnuje całą pamięć próbując go przetworzyć.

Invalid packet data. Pakiety z poprawnym nagłówkiem, ale niepoprawnymi danymi w środku. Na przykład pakiet z ID ruchu gracza, ale ze współrzędnymi NaN lub Infinity. Serwer próbuje przetworzyć te współrzędne i dostaje wyjątek.

Packet spam. Masowe wysyłanie legitnych pakietów z dużą prędkością. Setki pakietów tab-complete na sekundę, tysiące pakietów interakcji z blokami. Każdy pakiet sam w sobie jest poprawny, ale ich objętość przeciąża handler.

Sequence break. Wysyłanie pakietów w złej kolejności. Na przykład pakiet akcji w grze przed zakończeniem sekwencji logowania. Wiele serwerów nie sprawdza stanu połączenia i crashuje.

Konfiguracja packet limiter

Paper ma wbudowany packet limiter i trzeba go poprawnie skonfigurować:

# paper-global.yml
packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
    ServerboundMovePlayerPacket:
      interval: 1.0
      max-packet-rate: 50.0
    ServerboundContainerClickPacket:
      interval: 1.0
      max-packet-rate: 20.0
    ServerboundUseItemPacket:
      interval: 1.0
      max-packet-rate: 30.0
    ServerboundSignUpdatePacket:
      interval: 1.0
      max-packet-rate: 5.0

Limit all ustawia ogólne ograniczenie: nie więcej niż 500 pakietów przez 7 sekund od jednego gracza. Indywidualne limity dla konkretnych typów pakietów dają dokładniejszą kontrolę.

ServerboundCommandSuggestionPacket ograniczony do 15 na sekundę - to pakiet tab-complete, który często jest używany w atakach, bo obsługa autouzupełnienia komend może być zasobożerna.

Sign exploit i map exploit

Sign exploit

Tabliczki w Minecraft mogą zawierać tekst. Atak polega na wysłaniu serwerowi pakietu aktualizacji tabliczki z nadmiernie długim tekstem lub specjalnymi znakami, wywołującymi błędy przy renderowaniu.

W starych wersjach serwera pozwalało to tworzyć tabliczki z tekstem, który crashował wszystkich graczy w zasięgu widoczności. Paper to naprawił, ograniczając długość stringów i walidując zawartość:

# paper-global.yml
item-validation:
  resolve-selectors-in-books: false

Map exploit

Mapy w Minecraft trzymają dane pikseli 128x128. Exploit działa przez stworzenie ogromnej liczby map z maksymalnie złożonymi danymi i ich przymusową wysyłkę innym graczom. Klient próbuje wyrenderować dziesiątki map jednocześnie i zawisa.

Ochrona:

# paper-world-defaults.yml
environment:
  treasure-maps:
    enabled: true
    find-already-discovered:
      loot-tables: default
      villager-trade: false

Na poziomie pluginów można ograniczyć liczbę map w inwentarzu i prędkość tworzenia nowych map.

Entity cramming

Entity cramming to atak przez stworzenie ogromnej liczby encji (mobów, przedmiotów, transportu) w ograniczonej przestrzeni. Gdy obok tego miejsca pojawi się gracz, jego klient próbuje wyrenderować wszystkie encje i crashuje.

Vanilla Minecraft ma mechanikę maxEntityCramming (domyślnie 24), która zadaje obrażenia encjom przy ścisku. Ale to nie zapobiega tworzeniu dużej liczby encji, po prostu zabija je z czasem.

# server.properties
max-entity-collisions=8

# spigot.yml
world-settings:
  default:
    max-entity-collisions: 8

# paper-world-defaults.yml
entities:
  spawning:
    per-player-mob-limit: true
    max-per-chunk: 50
  behavior:
    spawner-nerfed-mobs-should-jump: false

Plugin ClearLagg lub odpowiedniki mogą okresowo usuwać zbędne encje:

/lagg clear       # usunąć wszystkie encje-przedmioty
/lagg killmobs    # usunąć zbędne moby

Czym crash-exploity różnią się od DDoS

To zasadniczo różne zagrożenia, i ochrona przed nimi też jest różna.

Parametr	DDoS	Crash-exploit
Typ ataku	Objętościowy (volumetric)	Celowany (targeted)
Źródło	Tysiące botów/źródeł	Jeden gracz
Cel	Przeciążyć łącze/CPU	Wywołać błąd w kodzie
Ruch	Gigabity	Minimalny
Wykrywanie	Anomalia ruchu	Trudno bez logów
Ochrona	Filtrowanie sieciowe	Aktualizacje, ustawienia, pluginy
Odzyskiwanie	Automatyczne po ataku	Może wymagać ręcznej interwencji

Atak DDoS zatrzymuje filtr sieciowy (jak MineGuard), który odsiewa śmieciowy ruch, zanim dotrze do serwera. Crash-exploit przechodzi przez filtr, bo technicznie to legitne połączenie od legitnego gracza. Jeden pakiet, jedno zapytanie.

Dlatego ochrona przed crash-exploitami leży na poziomie oprogramowania serwerowego. Aktualizacje Paper, poprawne ustawienia, pluginy.

Pluginy ochronne

PacketLimiter

Paper ma wbudowany packet limiter, ale do bardziej subtelnej kontroli jest plugin PacketLimiter. Pozwala konfigurować limity dla każdego typu pakietów osobno i logować podejrzaną aktywność.

ExploitFixer / AntiCrash

Pluginy typu ExploitFixer zamykają wiele znanych exploitów jednym rozwiązaniem. Sprawdzają dane NBT, rozmiary pakietów, walidują zawartość ksiąg i tabliczek.

Typowe funkcje:

• Sprawdzanie rozmiaru NBT przy każdej interakcji z inwentarzem
• Blokada ksiąg z nadmierną liczbą stron
• Ograniczenie długości tekstu na tabliczkach
• Sprawdzanie poprawności współrzędnych w pakietach ruchu
• Limity na interakcję z kontenerami

ViaVersion

Jeśli twój serwer wspiera kilka wersji przez ViaVersion, ważne jest trzymanie go w aktualnym stanie. Wiele crash-exploitów działa przez niezgodność wersji protokołu. ViaVersion regularnie zamyka takie podatności.

# ViaVersion config.yml
block-protocols: []  # lista zablokowanych protokołów
block-disconnect-message: "Unsupported protocol version"
suppress-metadata-errors: true

Kluczowe ustawienia server.properties

# server.properties
max-tick-time=60000
network-compression-threshold=256
rate-limit=0
prevent-proxy-connections=false
max-players=100

network-compression-threshold=256 - pakiety o rozmiarze większym niż 256 bajtów będą kompresowane. Obniża to przepustowość, ale też ogranicza możliwość wysyłania ogromnych niezkompresowanych pakietów.

max-tick-time=60000 - jeśli tick trwa dłużej niż 60 sekund, serwer jest uznawany za zawieszony. Ustawienie na -1 wyłącza watchdoga, co może być przydatne przy debugowaniu, ale groźne na produkcji.

Ustawienia paper-global.yml pod bezpieczeństwo

Zebrane w jedno ważne ustawienia:

# paper-global.yml
item-validation:
  book:
    page-max: 100
    max-page-length: 1024
  book-size:
    page-max: 2560
    total-multiplier: 0.98
  resolve-selectors-in-books: false

packet-limiter:
  kick-message: '<red>Connection terminated: packet rate exceeded'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

chunk-loading-basic:
  player-max-chunk-load-rate: -1.0
  player-max-chunk-send-rate: 75.0

player-max-chunk-send-rate: 75.0 ogranicza prędkość wysyłania chunków graczowi. Obniża to efekt ataków chunk ban, rozciągając obciążenie w czasie.

Jak odzyskać gracza po book/chunk ban

Jeśli gracz już jest "zbanowany" i nie może wejść na serwer, jest kilka sposobów, żeby go wyciągnąć.

Sposób 1: Teleport przez konsolę

Jeśli problem jest w chunk ban (gracz utknął w trującym chunku), teleportuj go w inne miejsce:

/tp PlayerName 0 100 0

Zadziała, jeśli serwer zdąży przetworzyć komendę przed wysyłką danych chunka klientowi.

Sposób 2: Czyszczenie inwentarza

Jeśli problem jest w book ban (zatruty przedmiot w inwentarzu):

/clear PlayerName

Albo, dla bardziej precyzyjnego podejścia:

/clear PlayerName minecraft:written_book
/clear PlayerName minecraft:writable_book

Sposób 3: Edycja pliku gracza

Jeśli serwer crashuje przed przetworzeniem komend, trzeba edytować dane gracza bezpośrednio.

1. Zatrzymaj serwer
2. Znajdź plik gracza: world/playerdata/<UUID>.dat
3. Użyj edytora NBT (NBTExplorer, NBT Studio), żeby otworzyć plik
4. Usuń problematyczne przedmioty z inwentarza lub zmień współrzędne spawnu
5. Zapisz i uruchom serwer

Sposób 4: Usunięcie uszkodzonego chunka

Przy chunk ban można usunąć uszkodzony chunk za pomocą MCEdit lub Chunker:

1. Określ współrzędne chunka z logu błędów
2. Otwórz świat w MCEdit
3. Usuń uszkodzony chunk
4. Serwer zregeneruje go przy następnym ładowaniu

To operacja destrukcyjna - wszystkie konstrukcje w tym chunku będą stracone.

Dlaczego aktualizacje są krytycznie ważne

Większość crash-exploitów działa na konkretnych wersjach serwera. PaperMC regularnie wydaje łatki zamykające znane podatności. Oto dlaczego ważne jest aktualizowanie oprogramowania serwerowego:

• Paper 1.20.4 zamknął szereg exploitów NBT przez zaostrzenie walidacji
• Paper 1.21.x dodał ulepszone limity na pakiety i rozmiar NBT
• Każda minor wersja Paper zawiera fixy bezpieczeństwa

Uruchomić aktualizację jest prosto:

# Backup obecnej wersji
cp paper.jar paper.jar.backup

# Pobrać nową wersję
wget -O paper.jar "https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/LATEST/downloads/paper-1.21.4-LATEST.jar"

Używaj konkretnego numeru buildu zamiast LATEST na produkcji. Sprawdzaj kompatybilność pluginów na serwerze testowym przed aktualizacją.

Więcej o ustawieniach bezpieczeństwa Paper pisaliśmy w artykule ustawienia bezpieczeństwa Paper i Spigot.

Warstwa sieciowa vs warstwa aplikacji

Crash-exploity działają na warstwie aplikacji (L7). Ochrona sieciowa (L3/L4) nie pomaga przed nimi bezpośrednio, bo atak idzie wewnątrz legitnego połączenia TCP.

Ale ochrona sieciowa i tak odgrywa rolę:

1. Filtrowanie botów na etapie łączenia. Wiele crash-exploitów jest zautomatyzowanych przez sieci botów. MineGuard filtruje boty zanim połączą się z serwerem, obniżając liczbę potencjalnych źródeł ataków.

2. Ograniczenie liczby połączeń z jednego IP. Jeśli atakujący nie może utworzyć wielu połączeń, skuteczność zautomatyzowanych exploitów gwałtownie spada.

3. Analiza ruchu. Systemy ochrony mogą wykrywać anomalne wzorce pakietów charakterystyczne dla exploitów.

Więcej o ochronie przed botami i exploitami na warstwie sieciowej przeczytasz w naszym artykule o atakach null i exploitach BungeeCord.

Checklista ochrony

Szybka checklista dla administratorów:

Oprogramowanie serwerowe:

• Paper najnowszej wersji dla twojej gałęzi MC
• ViaVersion zaktualizowany (jeśli używany)
• Plugin AntiCrash lub ExploitFixer zainstalowany

Ustawienia:

• Limity NBT ksiąg skonfigurowane w paper-global.yml
• Packet limiter włączony i skonfigurowany
• Limity encji ustawione w bukkit.yml i paper-world-defaults.yml
• max-entity-collisions ograniczony w spigot.yml

Monitoring:

• Logi serwera są sprawdzane pod kątem błędów NBT/pakietów
• Alerty na crash-restart skonfigurowane
• Backupy świata robione regularnie

Sieć:

• Ochrona DDoS aktywna
• Rate limiting połączeń skonfigurowany
• Firewall zamyka zbędne porty

Jeśli jesteś początkujący w ochronie serwerów, zacznij od naszego przewodnika po ochronie serwera Minecraft dla początkujących.

Podsumowanie

Crash-exploity nie są tak widoczne jak ataki DDoS, ale dla konkretnego gracza efekt jest ten sam: nie może grać. Book ban wybija człowieka z serwera przez zatruty przedmiot. Chunk ban zamienia fragment świata w pułapkę. Packet exploits mogą położyć cały serwer jednym połączeniem.

Ochrona jest warstwowa. Na poziomie oprogramowania: zaktualizowany Paper z poprawnymi ustawieniami i pluginami. Na poziomie sieci: filtrowanie botów i ograniczenie połączeń. Na poziomie administrowania: regularne backupy i monitoring logów.

Żadna ochrona nie jest absolutna. Nowe exploity pojawiają się z każdą aktualizacją Minecraft. Ale serwery na aktualnym Paper z poprawną konfiguracją zamykają 95% znanych ataków. Pozostałe 5% zamyka czujność administratora i szybka reakcja na incydenty.

Dodatkowe środki: co jeszcze warto zrobić

Ograniczenie kreatywu i komend

Na serwerach, gdzie graczom dostępny jest Creative Mode lub komendy /give, ryzyko crash-exploitów wielokrotnie wzrasta. W kreatywie gracz może swobodnie tworzyć przedmioty z dowolnymi tagami NBT. Otwiera to drzwi dla book ban, zatrutych shulker-boxów i przedmiotów z anomalnymi danymi.

Rozwiązanie: używaj systemu uprawnień (LuckPerms, LPX) do ścisłej kontroli dostępu do niebezpiecznych komend. Zablokuj /give dla zwykłych graczy. Jeśli Creative Mode jest niezbędny (np. na serwerze kreatywnym), zainstaluj plugin walidujący tagi NBT tworzonych przedmiotów.

# LuckPerms: blokada niebezpiecznych komend dla domyślnej grupy
# /lp group default permission set minecraft.command.give false
# /lp group default permission set minecraft.command.summon false

Logowanie i alerty

Skonfiguruj monitoring logów serwerowych pod kątem kluczowych wzorców wskazujących na próby exploitów:

# Wzorce do monitoringu w logach:
# "Tried to load a TOO LARGE NBT tag"
# "Disconnect: Packet too large"
# "Entity count exceeded limit"
# "Connection throttled"

Współczesne systemy monitoringu pozwalają skonfigurować alerty na pojawienie się takich stringów w logach. Daje ci to możliwość reagowania na ataki w czasie rzeczywistym, a nie wykrywać je po fakcie, gdy gracze narzekają na niemożność wejścia.

Backupy: ostatnia linia obrony

Regularne backupy świata są krytycznie ważne do szybkiego odzyskiwania po chunk ban i innych destrukcyjnych exploitach. Jeśli chunk jest uszkodzony, możesz go przywrócić z backupu zamiast pełnego usuwania.

Rekomendowana strategia:

• Pełny backup raz na dobę
• Inkrementalne backupy co 1-2 godziny
• Przechowywanie minimum 7 dziennych backupów
• Backupy playerdata osobno od świata (do szybkiego odzyskania inwentarzy)

# Prosty skrypt backupu przez rsync
rsync -a --delete /path/to/server/world/ /path/to/backups/world-$(date +%Y%m%d-%H%M)/

Whitelist i weryfikacja

Na serwerach z wartościowym contentem (RPG, SMP z historią) rozważ użycie whitelisty. Nie ochroni to przed atakami insiderskimi, ale całkowicie wykluczy przypadkowych grieferów z crash-klientami.

Dla publicznych serwerów, gdzie whitelista jest niemożliwa, używaj systemów weryfikacji: pluginy AntiBot, captcha na wejściu, powiązanie z kontem Discord. Im trudniej dostać się na serwer, tym mniej motywacji u atakującego, żeby marnować czas na exploity.

Realne przypadki

2b2t i kultura chunk ban

Na najstarszym serwerze anarchii 2b2t chunk ban stał się częścią kultury. Gracze tworzą "lavacasty" i pułapki chunk ban wokół swoich baz jako konstrukcje obronne. Nowicjusze eksplorujący świat regularnie wpadają w takie pułapki i tracą dostęp do swojej postaci.

Administracja 2b2t nie ingeruje, bo to serwer anarchii. Ale na zwykłym serwerze SMP podobna sytuacja jest nie do przyjęcia. Jeden toksyczny gracz z hack-klientem może "zbanować" dziesiątki innych graczy przez book ban lub chunk ban, a administrator będzie zmuszony ręcznie odzyskiwać każdego.

Packet exploits w trybach rywalizacyjnych

Na serwerach PvP i sieciach z mini-grami packet exploits są używane do uzyskania nieuczciwej przewagi. Gracze wysyłają serwerowi pakiety ruchu z niepoprawnymi współrzędnymi, co pozwala teleportować się lub poruszać z anomalną prędkością. Gorzej, niektóre exploity pozwalają wywołać crash konkretnego przeciwnika w trakcie walki PvP.

Pluginy anticheat (Vulcan, Grim, Polar) pomagają wykrywać takie manipulacje, ale całkowicie zamknąć wszystkie wektory ataków nie da się bez ograniczeń na poziomie serwera.