Jde to shodit i pres Link-Local adresy, takze je potreba nemit balicek ipv6, jinak to v jednom segmentu site porad jde pouzit.
6.45beta22 to neopravuje - https://youtu.be/TzC-JVjMK8k
https://forum.mikrotik.com/viewtopic.ph ... 48#p723977 a dal je to zatim k placi.
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
MikroTik - BEZPECNOSTNI UPOZORNENI !!! DULEZITE - zablokovane MikroTiky
Jo taky jsem koukal. Mikrotik tvrdí že to opravil a autor objevené chyby jim nahrál video že to opravené není. Řekl bych že to začíná nabírat komický rozměr 
Zbývá 10dní do zveřejnění a najednou mikrotik tlačí na pilu a snaží se. Komunikuje.
Přitom měli čas to opravit skoro rok...
Zbývá 10dní do zveřejnění a najednou mikrotik tlačí na pilu a snaží se. Komunikuje.Přitom měli čas to opravit skoro rok...
0 x
To byl ftip. Někdo z MK to tak prohlásil ... je to jen chyba, protože nemůže dojít ke kompromitaci.
A tady zase odporuji já - to není obrana. To je kapitulace.
honzam píše:Podle mě to zranitelnost je. Pokud ti někdo přes IPV6 může shodit celý router tak to je jen chyba?
Možnost obrany je - vypni IPV6 v síti a problém se tě netýká.
A tady zase odporuji já - to není obrana. To je kapitulace.
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 tady zase odporuji já - to není obrana. To je kapitulace.
Pokud nemáš IPV4 adresy tak ano, je to kapitulace
0 x
Buďme rádi, že to označují alespoň za chybu, mohlo to být i horší. Klidně to mohli prohlásit za vlastnost (IT'S NOT A BUG, IT'S A FEATURE'). Pak by jsme teprv byli opravdu v řiti.
0 x
Vysoce odborných omylů se dopouští jen specialisté.
Jednou jsem se dotkl ukazováčkem UBNT a slezl mi z něho nehet. Od té doby na UBNT nesahám.
Jednou jsem se dotkl ukazováčkem UBNT a slezl mi z něho nehet. Od té doby na UBNT nesahám.
Tak nějak přemýšlím na tím, jak tam mikrotik tlačí jako dočasné řešení omezení počtu nových konexí. To by znamenalo, že minimálně jedna část problému je vyčerpání paměti conntrack tabulkou.
A pokud to tak je, tak mají opravdu omezené možnosti, co s tím. To je problém návrhu IPv6 v kombinaci se stavovým firewallem (a tak nějak obecným stavem internetu). Prostě DoS.
Pokud chce někdo provést útok na conntrack tabulku, tak co má za možnosti? Poslat mi 65536 paketů ze své IP, pokaždé s jiným zdrojovým portem. Může zkombinovat s cílovým portem ... a brzy narazí na svoje vlastní limity (má 2^32 možností, tedy musí zvládnout 4 miliardy spojení). Musí tedy použít nějaké botnety pro DDoS.
Nojo, jenže i scriptkid má pro sebe se vší pravděpodobností 2^64 IPv6 adres (a každou s 2^32 kombinací portů). A nepotřebuje conntrack ... Čili to, co bylo trochu problematické u IPv4 je zde dost zjednodušeno. Prostě posílá pakety ze svých adres.
Pokud budeme posílat 20 paketů za vteřinu velikosti 150B (řekněme plusmínus, náhodně), vygenerujeme 24 kbit/s provozu - všimne si někdo? Ale u cíle to je 72000 nových spojení za hodinu. A teď je otázkou, jak vysoké jsou timeouty toho cíle - za pět hodin to je už 360000 spojení.
Jeden záznam v conntracku zabíral 308B v dobách 2.6 jádra na 32bitech (teď jsem to nehledal, ale pochybuji, že by to bylo méně). Za těch mých hypotetických 5 hodin máme hned 110 MB RAM v čudu ...
A to je to pořád teorie s 24 kbit provozu!
Čili možná ano: IT'S NOT A BUG, IT'S A FEATURE
A pokud to tak je, tak mají opravdu omezené možnosti, co s tím. To je problém návrhu IPv6 v kombinaci se stavovým firewallem (a tak nějak obecným stavem internetu). Prostě DoS.
Pokud chce někdo provést útok na conntrack tabulku, tak co má za možnosti? Poslat mi 65536 paketů ze své IP, pokaždé s jiným zdrojovým portem. Může zkombinovat s cílovým portem ... a brzy narazí na svoje vlastní limity (má 2^32 možností, tedy musí zvládnout 4 miliardy spojení). Musí tedy použít nějaké botnety pro DDoS.
Nojo, jenže i scriptkid má pro sebe se vší pravděpodobností 2^64 IPv6 adres (a každou s 2^32 kombinací portů). A nepotřebuje conntrack ... Čili to, co bylo trochu problematické u IPv4 je zde dost zjednodušeno. Prostě posílá pakety ze svých adres.
Pokud budeme posílat 20 paketů za vteřinu velikosti 150B (řekněme plusmínus, náhodně), vygenerujeme 24 kbit/s provozu - všimne si někdo? Ale u cíle to je 72000 nových spojení za hodinu. A teď je otázkou, jak vysoké jsou timeouty toho cíle - za pět hodin to je už 360000 spojení.
Jeden záznam v conntracku zabíral 308B v dobách 2.6 jádra na 32bitech (teď jsem to nehledal, ale pochybuji, že by to bylo méně). Za těch mých hypotetických 5 hodin máme hned 110 MB RAM v čudu ...
A to je to pořád teorie s 24 kbit provozu!
Čili možná ano: IT'S NOT A BUG, IT'S A FEATURE
1 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.
jo, jenomže tvoje teorie má kupu much.
- conn. track tabulka není omezená na 65536 záznamů
- po zaplnění tabulky dochází k přemazávání nejstarších spojení resp. nejstarších spojení s největším timeoutem
- nejde o problém firewallu ale to co je před ním tedy kvůli "špatnýmu paketu" kterej nejspíš způsobí úniky do ramky a tím přetečení do "nekontrolovanýho prostoru" až dojde k zaplnění ramky
ono když se na tim člověk zamyslí... operační systémy a kernely operačních systémů by tohle vůbec neměly dovolit a to samí platí i v jiných oblastech (spectre atd..) což nabádá k myšlence jak moc kvalitně je to všechno napsaný a co nás vůbec v budoucnu čeká za masakry který ještě přijdou a že přijdou. Prakticky by vůbec nemělo k něčemu takovému dojít jenomže napsat to správně by znamenalo větší program a větší zátěž CPU na což se každej vyprdne a pak tu máme takovýhle hezký chyby.
- conn. track tabulka není omezená na 65536 záznamů
- po zaplnění tabulky dochází k přemazávání nejstarších spojení resp. nejstarších spojení s největším timeoutem
- nejde o problém firewallu ale to co je před ním tedy kvůli "špatnýmu paketu" kterej nejspíš způsobí úniky do ramky a tím přetečení do "nekontrolovanýho prostoru" až dojde k zaplnění ramky
ono když se na tim člověk zamyslí... operační systémy a kernely operačních systémů by tohle vůbec neměly dovolit a to samí platí i v jiných oblastech (spectre atd..) což nabádá k myšlence jak moc kvalitně je to všechno napsaný a co nás vůbec v budoucnu čeká za masakry který ještě přijdou a že přijdou. Prakticky by vůbec nemělo k něčemu takovému dojít jenomže napsat to správně by znamenalo větší program a větší zátěž CPU na což se každej vyprdne a pak tu máme takovýhle hezký chyby.
2 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
No to spíš tvoje odpověď ...
Nic nepíšu o maximální počtu záznamů conntrack tabulky. Nic. Píšu o teoretickém problému se zaplněním paměti ... mimochodem kdo ví, jak je ten limit nastaven? U linuxu vím, mikrotik tento parametr neexportuje. Jen ukazuje a je 1024000. Pravděpodobně to ladí online, neboť se to liší box od boxu.
Po zaplnění conntracku se rozhodně, ale to musím zdůraznit: ROZHODNĚ nezahazují stará spojení! Odmítají se nová ...
Také říkám, že je to nejspíš jen část problému. Pokud sám mikrotik jako částečné řešení nabízí omezení počtu nových konexí za vteřinu, tak na tom něco bude. To, že je tam těch problémů víc nerozporuji. A to včetně možnosti nějakého magického paketu typu ping of death.
No a to celé mělo znamenat jen názor na to, že to je problém prostě jako problém, nikoliv jako chyba. Tato jedna část, o které mluvím. Nemluvím o ničem, co si myslíš ty.
Jednu pravdu máš. "je to divně napsaný". IPv6 je prostě moc složitý, snaží se řešit moc věcí zároveň a "na vždy". To, že snad neexistuje pořádná kompletní implementace to dokazuje. Přitom to je už kolik? Přes dvacet let ...
hapi píše:jo, jenomže tvoje teorie má kupu much.
- conn. track tabulka není omezená na 65536 záznamů
- po zaplnění tabulky dochází k přemazávání nejstarších spojení resp. nejstarších spojení s největším timeoutem
- nejde o problém firewallu ale to co je před ním tedy kvůli "špatnýmu paketu" kterej nejspíš způsobí úniky do ramky a tím přetečení do "nekontrolovanýho prostoru" až dojde k zaplnění ramky
Nic nepíšu o maximální počtu záznamů conntrack tabulky. Nic. Píšu o teoretickém problému se zaplněním paměti ... mimochodem kdo ví, jak je ten limit nastaven? U linuxu vím, mikrotik tento parametr neexportuje. Jen ukazuje a je 1024000. Pravděpodobně to ladí online, neboť se to liší box od boxu.
Po zaplnění conntracku se rozhodně, ale to musím zdůraznit: ROZHODNĚ nezahazují stará spojení! Odmítají se nová ...
Také říkám, že je to nejspíš jen část problému. Pokud sám mikrotik jako částečné řešení nabízí omezení počtu nových konexí za vteřinu, tak na tom něco bude. To, že je tam těch problémů víc nerozporuji. A to včetně možnosti nějakého magického paketu typu ping of death.
No a to celé mělo znamenat jen názor na to, že to je problém prostě jako problém, nikoliv jako chyba. Tato jedna část, o které mluvím. Nemluvím o ničem, co si myslíš ty.
Jednu pravdu máš. "je to divně napsaný". IPv6 je prostě moc složitý, snaží se řešit moc věcí zároveň a "na vždy". To, že snad neexistuje pořádná kompletní implementace to dokazuje. Přitom to je už kolik? Přes dvacet let ...
1 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.
velikost conn track tabulky je ovlivněná velikostí ramky u danýho boxu. CCRka třeba jí maji obrovskou, hap lite malinkou. Stejně tak je to u linuxu podle velikosti ramky, je tam nějakej vzoreček na přepočet.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
takový možná OT,
a) na co potřebuju v mít v boxu zaplej IPv6 conntrack?
b) jak někdo zjistí IPv6 adresu mojeho boxu?
a) na co potřebuju v mít v boxu zaplej IPv6 conntrack?
b) jak někdo zjistí IPv6 adresu mojeho boxu?
0 x
Conntrack potřebuješ pokud děláš firewall například s estab,related. Zjistí třeba tak, že u tebe běží cokoliv z krz to tečou data - traceroute.
0 x
-
Dalibor Toman
- Příspěvky: 1246
- Registrován: 11 years ago
TTcko píše:takový možná OT,
a) na co potřebuju v mít v boxu zaplej IPv6 conntrack?
no napr u IPv4 ma MT problem s fragmentovanymi packety, pokud je vypnuty conenction-tracking a zaroven pouzite jakekoliv pravidlo ve firewallu. Pokud se tedy neco nezmenilo.
Kdysi jsme si takhle nabehli, kdyz jsem chtel zvysit propustnost vypnutim connection trackingu na CPEckach. Fragmenty packetu se ztracely. Firewall je bez connection trackingu proste zahodi. Je dost mozne, ze na IPv6 se to bude chovat stejne. Zrejme kvuli tomuhle problemu je od jiste doby connection tracking defaultne nastaveny na auto a zapne se automaticky pri pouziti firewallu.
TTcko píše:b) jak někdo zjistí IPv6 adresu mojeho boxu?
to je dobra poznamka. IPv6 rozsahy jsou obvykle tak velike, ze jejich proskenovani bude na dlouhy cas. Nicmene pripomina mi to ruskou ruletu. Drive nebo pozdeji bude naboj v komore.
Utocnik muze mit na Tve siti nejaky zajem a znat nejake dalsi podrobnosti. Zajimave by urcite bylo prubnout vsechny IPv6 adresy, co najdu na seznamu IPv6 peeru v NIXu, Peering.cz (a dalsich podobnych). IPV6 adresy, ktere najdu digem u domenovych jmen. Rozsekat velke site na /48 /56 a projet prvni adresy v nich, zkusit do nich doklicovat MAC adresy z rozsahu MT a zrejme nekoho napadne jeste lepsi zpusob jak zvysit sanci zasahu.
1 x
asi nikdo z vás neviděl ani ten první screen se zapojením pro test chyby? Stačí aby paket zařízením jenom prošel, nemusí mířit na něj, stačí forward a za pár sekund je dole.
Pokud chci o něčem kecat tak si aspoň o tom něco najdu. Pak je to tu jak s tatarama co vymejšleji teorie.
Pokud chci o něčem kecat tak si aspoň o tom něco najdu. Pak je to tu jak s tatarama co vymejšleji teorie.
1 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Proti čemu máš vlastně námitky? Že se neví, co to přesně způsobuje, tak hledáme možnosti? Se nezapojuj, když víš všechno a nepotřebuješ teorie.
Mimochodem i forward se týká conntracku.
A teď jako novinka je, že je chyba i v ipv6 route cache. Té se dokonce to CVE netýká, je to něco jiného.
Mimochodem i forward se týká conntracku.
A teď jako novinka je, že je chyba i v ipv6 route cache. Té se dokonce to CVE netýká, je to něco jiného.
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.
mám námitky proti teoriím který nejsme schopni prokázat a který budou za pár dnů vypuštěný do světa. Neexistuje náhodou dokument na replikaci chyby? Na MK foru to lidi úspěšně testují a sdělují mikrotiku že jejich oprava není oprava atd. takže jakýkoliv teorizování je totálně o ničem. Stačí si to jenom přečíst. Zase to tu zasere deset stránek teorie o ničem.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků