Un SYN flood de cateva zeci de mii de pachete pe secunda pune la pamant un router MikroTik configurat din fabrica: CPU 100%, WinBox nu mai raspunde, iar utilizatorii suna ca "nu merge netul". Partea buna: RouterOS are tot ce-i trebuie ca sa absoarba majoritatea atacurilor de acest fel, iar configuratia completa tine in vreo 15 reguli. Partea proasta: aproape nimeni nu le pune inainte de primul incident.
Ghidul de mai jos contine exact regulile pe care le folosim pe routerele pe care le administram, in ordinea in care conteaza. Toate merg pe RouterOS 7 si se bazeaza pe mecanismele din documentatia oficiala MikroTik pentru protectie DDoS.
Ce poate opri un router MikroTik si ce nu?
Sa fim onesti de la inceput, ca aici se vand multe iluzii.
Un router MikroTik dimensionat corect opreste atacurile de protocol si de epuizare a resurselor: SYN flood, SYN-ACK flood, UDP flood pana la capacitatea procesorului, conexiuni in masa de la aceleasi surse, abuz pe serviciile routerului. Adica majoritatea incidentelor pe care le vede o companie obisnuita din Romania.
Ce nu poate opri niciun router, oricat de scump: un atac volumetric care umple banda de la furnizor. Daca ai 1 Gbps de la ISP si primesti 10 Gbps de trafic, pachetele mor pe uplink inainte sa ajunga la tine. Regula de firewall perfecta nu ajuta cu nimic cand conducta e plina. Pentru scenariul asta solutia e in amonte: filtrare la ISP, blackhole pe prefix sau un CDN in fata serviciilor publice. Restul articolului se ocupa de ce poti controla tu.
Primul pas: SYN cookies. De ce inaintea oricarei reguli?
Un SYN flood clasic nu urmareste sa umple banda, ci tabela de conexiuni: mii de handshake-uri TCP incepute si niciodata terminate, pana cand routerul nu mai are loc pentru conexiuni legitime. Mecanismul standard de aparare este descris in RFC 4987: serverul raspunde cu un cookie criptografic in loc sa aloce resurse, si aloca abia cand clientul dovedeste ca exista.
In RouterOS se activeaza cu o singura comanda:
/ip settings set tcp-syncookies=yesCam atat. Costul e zero in functionare normala si se simte doar sub atac, cand unele optiuni TCP se pierd la handshake — un pret corect pentru un router care ramane in picioare.
Cum detectezi si blochezi automat un flood?
Mecanismul recomandat de MikroTik functioneaza in doi timpi: un lant de detectie care masoara rata de pachete noi pe destinatie, si o pereche de liste de adrese din care tabela RAW arunca traficul atacatorilor inainte sa consume resurse.
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=detect-ddos
add chain=detect-ddos dst-limit=32,32,dst-address/10s action=return
add chain=detect-ddos action=add-dst-to-address-list \
address-list=ddos-targets address-list-timeout=10m
add chain=detect-ddos action=add-src-to-address-list \
address-list=ddos-attackers address-list-timeout=10m
/ip firewall raw
add chain=prerouting src-address-list=ddos-attackers \
dst-address-list=ddos-targets action=dropCheia e dst-limit=32,32,dst-address/10s: cat timp o destinatie primeste sub 32 de conexiuni noi pe secunda (cu un burst de 32), traficul trece prin action=return si nu se intampla nimic. Cine depaseste pragul ajunge in liste si e taiat 10 minute. Pragul de 32 e punctul de plecare din documentatie — pe un server web aglomerat il urci la 100-200, pe o retea de birou il poti si cobori. Merita o saptamana de observat contoarele inainte sa strangi surubul.
Perechea src plus dst din regula RAW e importanta: blochezi doar combinatia atacator-victima, nu tot traficul sursei. Un IP dintr-un NAT de operator mobil poate ascunde si atacatorul, si un client legitim.
Cum limitezi conexiunile per IP?
Complementar detectiei pe rata, connection-limit taie sursele care tin deschise sute de conexiuni simultan — tiparul tipic pentru scannere agresive si botnet-uri lenese:
/ip firewall filter
add chain=input protocol=tcp connection-limit=100,32 \
action=add-src-to-address-list address-list=blocked-addr \
address-list-timeout=1d comment="Peste 100 conexiuni simultane"
/ip firewall raw
add chain=prerouting src-address-list=blocked-addr protocol=tcp action=dropLimita de 100 pe /32 e pentru chain=input, adica pentru conexiunile catre routerul insusi — acolo n-are ce cauta nimeni cu suta de sesiuni. Pentru forward, spre serverele din spate, pragul se gandeste per serviciu: un server de mail traieste linistit cu 50 de conexiuni per sursa, un server web cu HTTP/2 poate avea nevoie de mai mult de la un singur proxy corporate.
De ce tabela RAW si nu filter?
Detaliul care desparte o configuratie care tine de una care cade frumos: unde arunci pachetele.
Regulile din filter ruleaza dupa connection tracking — routerul a cheltuit deja resurse ca sa urmareasca fiecare pachet inainte sa-l refuze. Tabela RAW ruleaza inainte de conntrack, deci drop-ul acolo costa o fractiune. La zeci de mii de pachete pe secunda, diferenta asta e diferenta dintre CPU 30% si CPU 100%. De asta ambele mecanisme de mai sus detecteaza in filter, dar executa in RAW.
Tot in RAW merita o regula pentru pachetele invalide, care n-au ce cauta in nicio retea:
/ip firewall raw
add chain=prerouting connection-state=invalid action=dropCum protejezi WinBox, SSH si DNS-ul routerului?
Multe "atacuri DDoS" raportate de clienti se dovedesc a fi altceva: routerul participa fara voie la atacul altcuiva sau e macinat de brute force. Trei inchideri obligatorii.
Serviciile de administrare nu stau deschise spre internet — sa lasi WinBox expus pe IP-ul public e curata inconstienta, oricat de lung ar fi parola:
/ip service
set winbox address=10.10.99.0/24
set ssh address=10.10.99.0/24
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yesSubnetul 10.10.99.0/24 e VLAN-ul de management — daca nu ai unul, ghidul nostru de VLAN-uri pe MikroTik il construieste pas cu pas.
A doua inchidere: DNS-ul. Un router cu allow-remote-requests=yes si portul 53 deschis spre WAN devine amplificator public pentru atacurile altora, iar banda ta se duce pe raspunsuri DNS catre victime pe care nu le cunosti:
/ip firewall filter
add chain=input in-interface-list=WAN protocol=udp dst-port=53 action=drop
add chain=input in-interface-list=WAN protocol=tcp dst-port=53 action=dropA treia: incercarile repetate de autentificare pe serviciile ramase deschise. Mecanismul de tip fail2ban, cu lanturi care escaladeaza pana la blacklist, l-am documentat separat in ghidul de detectie port scan si brute force — cele doua articole sunt gandite pereche.
Greseli care fac mai mult rau decat atacul
Prima si cea mai raspandita: logging pe regulile de drop din timpul atacului. Fiecare pachet logat costa CPU si disc, iar la 50.000 de pachete pe secunda tocmai ti-ai construit singur atacul de epuizare. Log-ul se pune temporar, pe o regula cu limit, cat diagnostichezi — apoi jos.
A doua: reguli de rate limiting puse dupa FastTrack. Conexiunile stabilite si marcate fasttrack ocolesc filter-ul aproape complet, deci regula ta vede doar o felie de trafic si contoarele mint. Regulile de detectie de mai sus lucreaza pe connection-state=new tocmai ca sa prinda traficul inainte de fasttrack — ordinea in lista conteaza mai mult decat continutul regulii.
A treia: blacklist-uri gigantice tinute in filter. O lista de tari intregi cu sute de mii de prefixe se cauta la fiecare pachet; in RAW costul e suportabil, in filter devine el insusi problema. (Si o observatie din practica, poate nesuferita: jumatate din listele "de tari" copiate de pe forumuri blocheaza si CDN-uri prin care vin clientii tai reali.)
A patra: configuratie fara backup inainte de modificari. O regula RAW gresita te poate lasa fara acces la propriul router, de la distanta, vineri seara. Export inainte, safe mode in timpul lucrului.
Intrebari frecvente despre protectia DDoS pe MikroTik
Ajunge un hEX pentru protectie DDoS sau imi trebuie CCR?
Depinde de pachete pe secunda, nu de megabiti. Un hEX duce onorabil o conexiune de birou cu regulile din acest ghid, dar un flood sustinut de zeci de mii de pps il satureaza. Pentru sedii cu servicii publicate sau linii de peste 500 Mbps, un RB5009 sau un CCR are rezerva de CPU care face diferenta sub atac.
FastTrack imi anuleaza regulile de firewall?
Partial. Conexiunile marcate fasttrack ocolesc majoritatea regulilor din filter, dar pachetele connection-state=new trec mereu prin firewall — iar detectia din acest ghid exact pe ele lucreaza. Tabela RAW nu e afectata deloc de FastTrack.
tcp-syncookies are dezavantaje?
In functionare normala, niciunul sesizabil. Sub atac, cand mecanismul devine activ, unele optiuni TCP negociate la handshake se pierd si conexiunile pot fi marginal mai lente. Fata de alternativa — router blocat — e un compromis pe care il facem pe toate routerele expuse.
Pot bloca tari intregi cu address-list?
Tehnic da, cu liste de prefixe pe tari si drop in RAW. Practic, listele mari consuma memorie, se invechesc repede si blocheaza frecvent CDN-uri si proxy-uri legitime. Pentru servicii B2B din Romania are sens uneori; ca prima linie de aparare anti-DDoS, nu.
Ce fac daca atacul imi umple banda de la ISP?
Suni furnizorul, nu reconfigurezi routerul. Filtrarea sau blackhole-ul pe prefix se face in reteaua lor, unde exista capacitate; unii operatori din Romania ofera si scrubbing contra cost. Pentru site-uri si servicii publice, un CDN sau un reverse proxy cu protectie DDoS rezolva problema inainte sa ajunga la linia ta.
Configuratia completa din acest ghid se aplica intr-o jumatate de ora, cu safe mode activ si fara intrerupere de trafic. Am vazut si varianta cealalta: prima regula scrisa la 4 dimineata, in timpul atacului, cu clientii pe telefon. Aceeasi jumatate de ora, cu totul alt puls.
Daca vrei configuratia adaptata pe reteaua ta — praguri calibrate pe traficul real, management izolat, monitorizare — echipa noastra face exact asta in cadrul serviciului de administrare retele enterprise.
