Dotaz: Mikrotik DNS z WAN, REJECT vs DROP

[RadekXxX]

Ahoj, na mikrotik me z venku prichazi na blokovaci pravidlo pro DNS asi 700 pkt/s (400kbps), kdyz je DNS z venku omezene pomoci DROP, tak me ping na 8.8.8.8 odpovida mezi 800-1500ms, kdyz upravim pravidlo na REJECT, tak ping spadne na 50-60ms, kdyz pravidlo vypnu a hned zapnu, tak se navaze spousta spojeni na DNS a ping klesne na 10ms. Jak mam spravne tento provoz blokovat, myslel jsem, ze pro provoz z WAN je lepsi DROP nez REJECT.

---

---

Odpovědi

[Max]

To je nějaká divnost. Můžeš sem hodit seznam pravidel, co máš pro WAN? A verzi ROS?
Zdar Max

[Max]

Ještě mně napadá, co je to za model, toho Mikrotiku?
Zdar Max

[RadekXxX]

Je to RB760iGS hEX, je tam verze 7.16.1 stable, zkousel jsem i starsi verze. Ve vsech pripadech je zatez CPU do 5% a chova se to stejne.

[RadekXxX]

Tady je videt jak se zmeni PING, kdyz pravidlo zakazu nebo zmenim na DROP:

64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=79.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=84.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=114 time=67.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=114 time=84.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=114 time=59.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=114 time=79.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=114 time=56.1 ms

64 bytes from 8.8.8.8: icmp_seq=8 ttl=114 time=7232 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=114 time=6195 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=114 time=5178 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=114 time=6274 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=114 time=5984 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=114 time=4944 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=114 time=4055 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=114 time=3590 ms

[RadekXxX]

Pokud 4ty pravidlo od konce zakazu, tak nastane ten problem (provoz zacne DROPovat posledni pravidlo) nebo staci kdyz zmenim ACTION na DROP

add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=icmp
add action=accept chain=input in-interface-list=WAN protocol=ipsec-esp
add action=accept chain=input dst-port=1701 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=4500 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=500 in-interface-list=WAN protocol=udp
add action=reject chain=input comment="DNS z WAN" dst-port=53 in-interface-list=WAN protocol=udp reject-with=icmp-network-unreachable
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input connection-state=invalid,new,untracked in-interface-list=WAN

[Max]

Takže:

add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=icmp

# Tohle je zbytečný:
add action=accept chain=input in-interface-list=WAN protocol=ipsec-esp

# Tohle vyhodit, proč povoluješ L2TP napřímo do routeru bez šifrování?
# L2TP by mělo být zabaleno vždy v ipsecu, tj pro L2TP over IPSEC stačí mít povolené porty UDP500 a UDP4500
add action=accept chain=input dst-port=1701 in-interface-list=WAN protocol=udp

add action=accept chain=input dst-port=4500 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=500 in-interface-list=WAN protocol=udp

# zbytečný, protože dole máš drop connection new
add action=reject chain=input comment="DNS z WAN" dst-port=53 in-interface-list=WAN protocol=udp reject-with=icmp-network-unreachable
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

# měl by jsi dělat kompletní drop a ne si jen vybírat
add action=drop chain=input connection-state=invalid,new,untracked in-interface-list=WAN

Za mně bych to nastavil takto:

add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=4500 in-interface-list=WAN protocol=udp
add action=accept chain=input dst-port=500 in-interface-list=WAN protocol=udp
add action=drop chain=input in-interface-list=WAN

Zdar Max

[RadekXxX]

Ok, takze jsem tam nechal pouze toto

add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=icmp
add action=drop chain=input in-interface-list=WAN

a vysledek je stejny, kdyz posledni pravidlo zmenim z DROP na REJECT, tak je to OK

[Max]

A kolik tam máš spojení? Já jen, zda tě někdo neDDoSuje.
Jde o to, že DROP = port is open, ale zahazuje všekerá spojení. Protistrana si tedy myslí, že by to jít mělo a možná se pokouší bušit do portu.
Reject = port is closed, takže prostistrana ví, že tam nic není a nepokouší se tedy asi volat.

Příklad:

iptables -A INPUT -s 127.0.0.1 -p tcp --dport 22 -j DROP

nmap 127.0.0.1
PORT     STATE    SERVICE
22/tcp   filtered ssh

iptables -A INPUT -s 127.0.0.1 -p tcp --dport 22 -j REJECT

nmap 127.0.0.1
PORT     STATE    SERVICE
22/tcp   filtered ssh

iptables -A INPUT -s 127.0.0.1 -p tcp --dport 22 -j REJECT --reject-with tcp-reset

nmap 127.0.0.1
PORT     STATE SERVICE

Zdar Max

[Max]

A v případě UDP komunikace:

iptables -A INPUT -s 127.0.0.1 -p udp --dport 53 -j DROP

nmap -sU 127.0.0.1
PORT    STATE         SERVICE
53/udp  open|filtered domain

iptables -A INPUT -s 127.0.0.1 -p udp --dport 53 -j REJECT

nmap -sU 127.0.0.1
PORT     STATE SERVICE

Zdar Max

[xxl]

PORT    STATE         SERVICE
53/udp  open|filtered domain

Pokud se na odeslaný paket nevrátí žádná odpověď, ví odesilatel pořád ještě kulový.

V uvedeném příkladu si může myslet, že na portu třeba něco běží a příjemce mu to dropuje, protože ho nemá rád, a ono je to ve skutečnosti třeba tak, že tam nic neběží a příjemce jenom dropuje všechny příchozí pakety a nenamáhá se posíláním odpovědi.

[Max]

Pleteš se. V případě "-j DROP" se odpověď posílá. Resp. posílá se ACK nebo SYN/ACK. Proto client ví, že je port otevřený, nějaká služba tam běží a je filtrovaná, tedy "open|filtered". Client si fakt sám z prstu necucá, kde je jaký port otevřený.
Zdar Max

[xxl]

Ale no tak, Maxi. DROP prostě paket zahodí bez jakékoliv odpovědi.

[Peter Golis]

Ale nechaj ho, zas je prepracovaný.

[Max]

Pokud by tam nebyl SYN/ACK, tak jak klient ví, že je port otevřený? Prostá otázka, očekávám prostou odpověď.
Zdar Max

[xxl]

Table 5.3. How Nmap interprets responses to a UDP probe

[xxl]

Jo a ještě... UDP je bezstavový protokol. Takže tak žádné SYN/ACK není.

[Max]

Pokud by to tak bylo, proč nmap neukáže všechny porty jako open/filtered, ale jen ten, kde skutečně něco běží?
Zdar Max

[Tom K]

Protože na TCP port kde nic nečeká se zpátky posílá TCP-RESET. Pro UDP je to ICMP-PORT-UNREACHABLE.
No a protože DROP nepošle nic, nmap správně usoudí, že tam musí být filtr.
Proto pokud chci udělat filtrování správně, nastavuju buď DROP všude kde to nechci otevřené (i tam, kde nic neběží) nebo REJECT with TCP-RESET když chci vypadat jako normální stroj kde nic není.

[RadekXxX]

Jak jsem psal na zacatku, na tom pravidle REJECT/DROP UDP/53 je stabilne asi 700 pkt/s (400 kbps), chapal bych, ze mikrotik bude zahazovat packety, kdyz to nebude zvladat, ale zatizeni CPU je do 5%, takze nevim proc se to chova takhle rozdilne, kdyz je DROP nebo REJECT, u obou dvou druhu ACTION se packet rate nemeni.

[Max]

Chtěl jsem jenom ukázat, jaký je rozdíl mezi DROP a REJECT. Drop říká, že je tam služba spuštěna a je filtrována firewallem, reject říká, že port je closed / nic tam není.
Zdar Max

[X]

blokovaci pravidlo pro DNS

To je jako co konkretne? Blokujes dotazy na DNS server ktery ani neexistuje? Co ma ping spolecneho s UDP na portu 53? To bude pekny gulas..

[RadekXxX]

Na mikrotiku je spusten DNS server pro lokalni sit a ja chci blokovat pristup z WANu na DNS. UDP/53 nema s pingem spolecneho nic, je to pouze vysledek chovani, kdyz zacnu DROPovat UDP/53 z WAN a na mikrotiku spustim ping kamkoliv do internetu, tak je takova latence, je jedno jestli ten ping pustim na mikrotiku nebo kdekoliv za NATem.

[X]

Kde si vzal tech 700 pkt/s? Mohl bych videt vzorek toho provozu?

[RadekXxX]

Ve statistice u tohoto pravidla (ve WinBoxu)

add action=reject chain=input dst-port=53 in-interface-list=WAN protocol=udp reject-with=icmp-host-unreachable

nyni aktualne Rate: 325 kbps, Packet rate: 549 p/s

Kdyz zapnu logovani toho pravidla, tak mam neco takovyho:

 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 91.175.157.92:13838->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 84.205.22.53:80->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 203.190.14.123:30049->x.x.x.x:53, len 65
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 14.102.10.10:888->x.x.x.x:53, len 65
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 47.106.34.105:80->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 190.12.131.224:13988->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 47.106.177.163:80->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 195.211.27.148:12139->x.x.x.x:53, len 65
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 118.107.29.131:28645->x.x.x.x:53, len 65
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 195.211.27.148:29739->x.x.x.x:53, len 65
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 106.15.225.175:80->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 38.6.218.20:80->x.x.x.x:53, len 71
 21:02:27 firewall,info DNB BLOCK input: in:ether1 out:(unknown 0), connection-state:new src-mac 00:01:5c:97:d6:46, proto UDP, 84.205.22.53:80->x.x.x.x:53, len 71

[RadekXxX]

Příloha:

• DNS Stat.jpg (71414 bytů)

Snimek obrazovky

[X]

Pokud mas v konfiguraci:

/ip dns set allow-remote-requests=yes

Tak to posloucha na vsech rozhranich => na WAN se uplne vykasli a vsechno rovnou zahazuj. Zadny reject, zadne icmp-unreachable, nic na*rat a rovou to vsechno zahazuj. Bohuzel uz jsi se dostal do hledacku nejakeho botnetu etc. a snazi se to pres tebe amplifikovat DNS DDoS.

[X]

Respektive si to oprav na:

/ip dns set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4

[RadekXxX]

Jo allow-remote-requests nastaveno mam, na provoz nemuzu dat DROP, protoze to je celej ten problem, uplne me prestavat fungovat konektivita do internetu (viz. ten PING), kdyz dam REJECT, tak je to relativne OK. Ale nechapu, kdyz DROP zahodi celej packet a tim to konci, tak reject packet zahodi, ale odesila nejake ACK protistrane, tak proc me ten DROP takhle odstavi mikrotik ? Kdyz to DNS z venku necham otevreny, packetovy provoz je tam na stejne urovni, chapu, ze by prezeme bezel ddos na jiny DNS server, ale PING me spadne na asi 10ms a vse je OK, ten trafic se na 500Mbps odbavi bez problemu. Tak jenom souhrn:

- DROP UDP/53 znefunkcni konektivitu ven i kdyz jenom zahazuje packety

- REJECT UDP/53 je na tom o 1000% lip, ale neni to idealni a navic jeste odpovida na zahozene packety

- Povoleny DNS z venku, je naprosto bez problemu, akorat by prezeme probihal DDOS

Podle me je to chyba mikrotiku a za me jediny reseni je kontaktovat ISP, aby me ten provoz odfitroval u sebe, ale nevim s jakym uspechem, mam SELFNET->MORAVIA NET->NEJ.CZ->O2 (postup kam se muj ISP transformoval) a s O2 asi moc zadna rec nebude.

[X]

Ne = proste ne. Z venku se k tobe nema co hlasit, jen odpovedi sestavenych spojeni klientu. Tecka. => Dej tam jen drop a zacni to dal diagnostikovat. Tzn. tohle vyhod uplne:

add action=reject chain=input comment="DNS z WAN" dst-port=53 in-interface-list=WAN protocol=udp reject-with=icmp-network-unreachable

Tohle staci na vsechno:

add action=drop chain=input connection-state=invalid,new,untracked in-interface-list=WAN

Dal, vyres ten ping = budes pingat postupne vsechna zarizeni na ceste, dokud nenajdes botu -> ping lokalni gateway, ping wan interface, ping gateway providera, ping ceske ip, ping zahranicni IP. Zacni IP adresama bez DNS prekladu. Take muzes zkusit traceroute nekam ven a uvidime.

[RadekXxX]

Otestovano a problem v ceste je uz na WAN GATEWAY ISP

[MarV]

Ideálně ukázat celou konfiguraci "/export hide-sensitive". Reset do defaultu se zkoušel? Verze FW je aktuální k verzi ROS?

[RadekXxX]

Reset do defaultu jsem jeste nezkousel, ale chystam se na to, jediny co jsem zkousel, tak deaktivovat vse co neni potreba (ipsec, NATy, ...) a nechat ciste zaklad, 3 pravidla ve filter, masquarade, dhcp server, dns.

Dal jsem zkousel vzit i jiny mikrotik(stejny typ) vcetne adapteru, ale jenom jsem na nem udelal restore zalohy.

FW je aktualni verze 7.16.1 stable, zkousel jsem i 7.15, 7.1.2 a 6.49.13, stejnej vysledek.

U mikrotiku jsem uz zazil divny chovani, ze to nereagovalo na nektery zmeny v nastaveni bridge nebo VLANu, ale vzdy pomohlo nesahat na nastaveni a udelat restart.

[MarV]

A jiný kus se choval stejně? Obnova ze zálohy je ošidná, protože pokud tam je nějaká podivnost ve zbytku konfigurace, tak se zatáhne zpět. Je-li k dispozici jiný kus na pokusy, tak reset do defaultu, ručně nakonfigurovat nezbytné minimum (nenahrávat zálohu) a vyzkoušet, zda je problém stejný či ne. Jinak doufám, že si rozumíme ohledně FW (u mikrotiku tím označují něco jako BIOS a verze může být jiná, než verze instalovaného OS). Viz. zde. Řeší se to v sekci System => RouterBOARD.

[RadekXxX]

Jo chova se to uplne stejne. U FW si nejsu jistej, myslis "Firmware type" ? Jinak "upgrade firmware" je stejny. Mam tady par cistych RB750, tak zkusim nastavit uplny minimum a pak dam vedet jak se to chova a poslu nastaveni.

Nastav to zvenku na drop a nech to být. Ono je to přestane časem bavit.

[MarV]

Více o problematice FW verze zde, ale nejspíš to nebude tvůj problém. Pořád bych to tipoval na nějakou záludnou chybu ve zbytku konfigurace (bez kompletního výpisu těžko říct), která se projevuje současně s útokem.

Mimochodem fungovalo to někdy správně? Kdy to začalo? Nějaká souvislost se změnou na tvé straně (upgrade, nová zařízení v síti, ...)? Sledoval jsi i celkový provoz na WAN interface (případně ostatních), když nastává problém (tj. ne jen část mířící na port 53)? Ve skupině WAN je opravdu jen ether1? Je tam IPv6?

[RadekXxX]

Vzal jsem uplne cisty mikrotik a udelal pouze zakladni nastaveni, nic vic. Chova se to stejne, kdyz vypnu pravidlo "WAN->DNS REJECT", tak nastane problem, nebo kdyz mu zmenim ACTION=DROP

Toto je kompletni nastaveni:

# nov/23/2024 09:37:48 by RouterOS 6.48.6
# software id = XL6J-3WUP
#
# model = RB750Gr3
# serial number = HCQ08APYDF2
/interface bridge
add admin-mac=18:FD:74:2B:24:93 auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.1.100-192.168.1.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.1.1/24 interface=bridge network=192.168.1.0
add address=109.x.x.12/24 interface=ether1 network=109.x.x.0
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf dns-server=192.168.1.1 gateway=192.168.1.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=icmp
add action=reject chain=input comment="WAN->DNS REJECT" dst-port=53 in-interface-list=WAN protocol=udp reject-with=icmp-host-unreachable
add action=drop chain=input comment="ALL WAN INPUT DROP" in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=15001 in-interface-list=all protocol=tcp to-addresses=192.168.1.2 to-ports=15001
add action=src-nat chain=srcnat dst-address=192.168.1.2 dst-port=15001 protocol=tcp to-addresses=109.x.x.12
add action=dst-nat chain=dstnat dst-port=81 in-interface-list=all protocol=tcp to-addresses=192.168.1.10 to-ports=81
add action=src-nat chain=srcnat dst-address=192.168.1.10 dst-port=81 protocol=tcp to-addresses=109.x.x.12
/ip route
add distance=1 gateway=109.x.x.1
/system clock
set time-zone-name=Europe/Prague
/system identity
set name=RouterOS
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

[RadekXxX]

Jeste bych dodal, ze za mikrotikem je pripojeny kabelem pouze notebook, jinak je cela sit odpojena.

[RadekXxX]

Tak problem se vyresil, snad me neukamenujete. Ten DROP vadil kabelovymu modemu, je tam CISCO EPC3212, kdyz jsem ho vypnul a zapnul, tak muzu provoz normalne dropovat, toto by me vubec nenapadlo, protoze, kdyz jsem vypnul vsechny pravidla a nechal otevreny provoz, tak konektivita jela uplne bez problemu. Tak se vsem omlouvam za ztraceny cas a dekuji.

[X]

Ocividne bylo nejak nakopnute to Cisco.

[Tom K]

Mohlo by to byt preplnenou NAT tabulkou u toho modemu. Kdyz se udela DROP, tak se nic nevrati zpatky a modem musi drzet zaznam v tabulce az do timeoutu (klidne i 600s u UDP). Kdezto u REJECT ho muze hned zase vyhodit. Buh vi jak se bude chovat pokud se tahle tabulka preplni.

[RadekXxX]

Myslim, ze modem by nemel NATovat, mel by byt v rezimu BRIDGE, verejnou IP mam pevne nastavenou primo v mikrotiku, ale uvidim. Kazdopadne od te doby co se to rozjelo uz ma mikrotik zahozenych vice nez 2.5M packetu a porada to funguje.