Adresa MK: 192.168.1.1 (zapnutý DNS)
Adresa PC: 192.168.1.99
Když zapnu logování firewall-output-rules, tak se jednou za čas objeví :
UDP 192.168.1.1:53 -> 192.168.1.99:vysoký port, len 92
Dříve to nedělalo. Nevíte proč to tak je? Nemám pocit že by někomu něco nefungovalo, ale raději bych to prověřil.
V input rules je samozřejmě UDP 53 povolené (vč. pravidel "established, related") a požadavky z 192.168.1.99 tam vidím.
Díky
edit: zdá se mi, že se tak děje při větším počtu uživatelů na síti. Nemůže to mít souvislost s parametrem "DNS: max-concurrent-queries" ?
Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Source UDP53 v Output
Klient se ptá z vysokého portu na port 53.
Odpověď tedy logicky musí být obráceně, z portu 53 na vysoký.
Odpověď tedy logicky musí být obráceně, z portu 53 na vysoký.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Proč se tak ale neděje u všech odpovědí DNS, ale jen u jednotek případů?
Dívám se do zaznamenaných packetů, u INPUT DST UDP53 je asi 1,6 mil packetů, u OUTPUT SRC UDP53 je asi 50 packetů.
Procházel jsem i logy za poslední 2 týdny, dnes se to objevilo poprvé (na síti bylo více lidí než obvykle).
Pravidla jsou v tomto duchu:
INPUT DROP Invalid
INPUT ACCEPT Established, Related
INPUT ACCEPT DST UDP 53 (pouze z LAN)
OUTPUT DROP Invalid
OUTPUT ACCEPT Established, Related
OUTPUT ACCEPT DST UDP 53 (na WAN, kvůli dns google)
OUTPUT LOG SRC UDP 53 (to je těch pár záznamů z milionu)
OUTPUT DROP zbytek
Dívám se do zaznamenaných packetů, u INPUT DST UDP53 je asi 1,6 mil packetů, u OUTPUT SRC UDP53 je asi 50 packetů.
Procházel jsem i logy za poslední 2 týdny, dnes se to objevilo poprvé (na síti bylo více lidí než obvykle).
Pravidla jsou v tomto duchu:
INPUT DROP Invalid
INPUT ACCEPT Established, Related
INPUT ACCEPT DST UDP 53 (pouze z LAN)
OUTPUT DROP Invalid
OUTPUT ACCEPT Established, Related
OUTPUT ACCEPT DST UDP 53 (na WAN, kvůli dns google)
OUTPUT LOG SRC UDP 53 (to je těch pár záznamů z milionu)
OUTPUT DROP zbytek
0 x
a) nezapomínáš na to, že DNS běhá i po TCP?
b) filtrovat output mi přijde vyloženě zbytečné
c) jediná možnost je (resp. co mě napadá), že ta odpověď od serveru jde až po vypršení UDP timeoutu. Tedy už ne jako established, ale jako new.
b) filtrovat output mi přijde vyloženě zbytečné
c) jediná možnost je (resp. co mě napadá), že ta odpověď od serveru jde až po vypršení UDP timeoutu. Tedy už ne jako established, ale jako new.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
ludvik píše:a) nezapomínáš na to, že DNS běhá i po TCP?
b) filtrovat output mi přijde vyloženě zbytečné
c) jediná možnost je (resp. co mě napadá), že ta odpověď od serveru jde až po vypršení UDP timeoutu. Tedy už ne jako established, ale jako new.
a) TCP tam samozřejmě mám, jen jsem to pro zjednodušení nepsal
b) myslím že Output pravidla mají v zabezpečení svoje místo. Je dobré vědět co se v routeru děje. Občas spouštím skripty třetích stran a v output přesně určím, kam smí koukat.
c) to by mohl být ten problém. Podívám se na nastavení queues, jestli tam nemám chybu. DNS dám do priority.
Díky!
0 x
b) Myslím si, že output firewall je zbytečná paranoia. Ale to že jsi paranoidní ještě neznamená, že po tobě nejdou.
c) S Queues to nemá nic společného. Ve výchozím nastavení (/ip firewall connection tracking) je UDP timeout 10sec. Pokud jsem to správně našel, tak např. Windows mají timeout DNS 15sec (ale mikrotik má 2sec/10sec - nehýbal jsi s těmito časy?) Teoreticky může dojít k tomu, že se DNS dotaz (např. kvůli nedostupným serverům + serverům někde na druhém konci světa) vyřizuje déle než 10sec a poté se DNS odpověď posílá ve chvíli, kdy již je connection vytimeoutovaná. Pokud chceš mít ten firewall opravdu tak paranoidní, tak to tak klidně nechej (zahazovací pravidlo, které nikdy nic nezahodí je v podstatě zbytečné, že...)
c) S Queues to nemá nic společného. Ve výchozím nastavení (/ip firewall connection tracking) je UDP timeout 10sec. Pokud jsem to správně našel, tak např. Windows mají timeout DNS 15sec (ale mikrotik má 2sec/10sec - nehýbal jsi s těmito časy?) Teoreticky může dojít k tomu, že se DNS dotaz (např. kvůli nedostupným serverům + serverům někde na druhém konci světa) vyřizuje déle než 10sec a poté se DNS odpověď posílá ve chvíli, kdy již je connection vytimeoutovaná. Pokud chceš mít ten firewall opravdu tak paranoidní, tak to tak klidně nechej (zahazovací pravidlo, které nikdy nic nezahodí je v podstatě zbytečné, že...)
0 x