Útoky na stroj: čo robíme my a čo môžeš ty

Slovo „útok“ znie rovnako v dvoch úplne odlišných situáciách: keď je tvoj kanál zaplavený odpadovou prevádzkou a keď niekoľko stoviek požiadaviek za sekundu zloží tvoju aplikáciu. Riešia sa inak a prvé, čo treba urobiť, je zistiť, s ktorou z nich máš dočinenia.

Ako ich rozlíšiť

Pozri si grafy procesora, pamäte a prevádzky v „Prehľade“ na /hosting/vds/m/<id> za posledných 24 hodín. Ak je prevádzka normálna, ale procesor je na strope, ide o záťaž aplikácie a musíš ju riešiť na svojej strane.

Čo môžeš urobiť

Obmedzenie počtu požiadaviek v nginx:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Obmedzenie počtu spojení vo firewalle:

ufw limit 22/tcp

Flexibilnejšie pravidlá nájdeš v článku nftables: tam môžeš tiež obmedziť počet nových spojení a viesť zoznam zablokovaných adries s časom platnosti.

Nájdi zdroj v logoch:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Jednorazové zablokovanie adresy alebo siete:

ufw deny from 203.0.113.0/24

fail2ban dokáže blokovanie na základe logov zautomatizovať.

Čo robíme my

Naša infraštruktúra filtruje odpadovú prevádzku na ceste k uzlu — skôr, než spotrebuje tvoju šírku pásma. Funguje to proti objemovým útokom na kanál a nevyžaduje od teba žiadnu konfiguráciu.

Čo ochrana na úrovni uzla nerobí: neanalyzuje logiku tvojej aplikácie. Požiadavky, ktoré navonok vyzerajú normálne, sa dostanú až k tvojmu stroju a proti nim ťa ochráni len tvoja vlastná konfigurácia.

Ak sa tvoj stroj stane zdrojom útoku — napríklad bol kompromitovaný a zúčastňuje sa na cudzej spamovej kampani — prístup bude obmedzený podľa zásad prijateľného používania. Skontroluj svoj stroj podľa príznakov kompromitácie.

Cachovanie a statické súbory

Najúčinnejšia technika proti záplave požiadaviek je nepočítať to isté dvakrát:

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Ťažké stránky cachuj na strane aplikácie. Požiadavka obslúžená z cache stojí stokrát menej.

Časté chyby

• Nastavenie limit_req bez burst — bežní používatelia, ktorých stránka ťahá dva tucty súborov, dostanú odrezané.
• Ručné blokovanie adries jednu po druhej počas distribuovaného útoku: sú ich tisíce a nestíhaš.
• Úplné zablokovanie ICMP — rozbije vyjednávanie veľkosti paketov, pozri MTU.
• Zámena vlastnej chyby za útok: slučka v kóde, vyhľadávací bot prehľadávajúci adresár, ktorý si zabudol vylúčiť, nekonečné opakovania na strane klienta.

Nastav si limity vopred, na pokojnom stroji. Počas záplavy požiadaviek nebudeš môcť ladit hodnoty rate a burst: budeš upravovať konfiguráciu naslepo a po kúskoch.