Názory k článku
Chrome bude blokovat porty 554 a 10080 kvůli zranitelnosti NAT Slipstreaming

Ja mel za to, ze na bezne NAT krabicce se pamatuje z jakeho hostu a portu dotaz prisel.. aby bylo mozne na nej provazat odpovedi. Jak tedy funguje ta komunikace kamkoliv?

Za prvním odkazem ve zprávičce je docela jasná animace, která to vysvětluje :-)

Hole punching predpokladá, resp. využíva, že to tak nie je. Preto nefunguje tam, kde NAT robí to, čo píšete.

Přesně. Proto je důležité si všimnout poznámky "This attack requires the NAT/firewall to support ALG (Application Level Gateways),".
Takže stačí vypnout ALG, který stejně dělá jen neplechu a je klid.

Ono je těch předpokladů trochu víc. Nejen že by příslušný conntrack helper musel být natažený, pokud není povolený automatic helper assignment (volba existuje od 3.5 a od 4.7 je defaultně vypnutá), budou muset být navíc nastavená odpovídající pravidla, aby ten helper příslušné pakety opravdu zpracovával a nastavoval expectations.

S těmi fragmenty to také není tak jednoduché, protože pokud je aktivní connection tracking (a na tom ten útok závisí), fragmentovaný paket se pro netfilter složí (u IPv4 skutečně, u IPv6 virtuálně) a netfilter tak pracuje s celým paketem, ne s jednotlivými fragmenty. Takže tvrzení z toho článku, že porty se kontrolují jen u prvního fragmentu, už docela dlouho neplatí.

Takze to nekdo preoptimalizoval a pak to tak dopada.. viz pristup tohoto pana:

https://forum.root.cz/index.php?topic=24461.0

Samozrejme mu tam radim, at otestuje veskere hlavicky - ten NAT slipstreaming mi prijde prave jako bug tohoto druhu.

Já o něčem podobném četl před tak 10 lety, ale když jsem to pak později hledal už jsem nenašel ani zmínku a skoro jsem si říkal, že jsem si to jen vymyslel vzhledem k mé tehdejší neznalosti problematiky a vida, je tu rok 2021 a je to tady, dokonce tam má odkaz na článek z roku 2010, takže příjemné shledání po mnoha létech;)