NF_CONNTRACK (diskuse)

[Thunder.m]

Šlo by jen jednoduše říct v čem je ta výhoda? Je tedy hlavně v tom že sjednocuje ipv4 a ipv6, nebo přináší i něco navíc pro ipv4?

[petr_p]

Pro IPv4 asi nema zadny vyznam (krom toho, ze vyvojarum ubyde prace).

Pokud ale pouzivate IPv6, jedna se o znacny posun (spousta conntrack helperu, ktere existovali jen pro IPv4, funguji nyni i pro IPv6).

Pokud pouzivate IPv4 a IPv6 soucasne, jedna se o znacne znacny posun. Muzete mit jak IPv4 NAT tak i connection tracking na IPv6 zaroven (coz je asi nejcastejsi situace). Navic par verzi zpet (pred 2.6.14) nebyl ani conntracking pro IPv6.

V zasade se nyni podarilo zrovnopravnit IPv6 s IPv4.

[Mikos]

Hurá, konečně stavový IPv6 firewall! Tohle by si zasloužilo článek (případně můžeš ještě víc popsat a rozvést co všechno nového to přináší), prosím nechceš to navrhnout redakci ABCLinuxu?

[Tyfus]

Kdyz jsem s jadrem 2.6.20 prisel o -m state (a s nim o jakekoli tcp), tak jsem cekal podobnou novinku. Na druhy pokus jsem uz uspel. :~) Mohli v oznameni o vydani trochu varovat.

Uz se tesim na clanek o utilitce conntrack.

[Michal Ludvig]

Ja bych USAGI uplne nezavrhoval. Precejen to vzniklo v dobe kdy jeste ani nebyly hotove vsechny standardy (a kdy naopak platily standardy ktere byly casem zruseny nebo zasadne prepracovany). NetBSD a diky USAGI i Linux byly ve sve dobe jedine dve temer uplne IPv6 compliant platformy. Kdyby se byvalo slo tou "spravnou" cestou podle kernelovych standardu a vsechno se delalo tak aby kod mohl byt rovnou prijat do hlavniho stromu, tak by vyvoj v rychle se rozvijejicim a menicim IPv6 svete sel prilis pomalu. Jak rikam v te dobe ani nebylo jasne ceho se ma dosahnout, tim mene jak se toho ma dosahnout

Vzpominam si jak jsme nekdy kolem roku 2002 (?) v SuSE linuxovy kernel trapili TAHI testsuitou. Po nekolika mesicich jsme dosahli skoro 100% pass rate. Ale na NetBSD jsme ani tak nemeli

[Michal Ludvig]

Nejak mi v IPv6 related nechodi. Nebo mozna ty packety nejsou related

Mam dva stroje 3ffe:ffff::129/64 a 3ffe:ffff::141/64 a na to druhym s 2.6.21-rc1 mam:

ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Jenze SSH odsud na :129 nefunguje, protoze packety z neighbour discovery (obdoba ARP pro IPv6) se do RELATED asi nepocitaji, takze je DROPnul firewall. Musel jsem tomu jeste predradit

ip6tables -I INPUT -p icmpv6 -j ACCEPT

To si nestezuju, jen konstatuju Ostatne v IPv4 iptables se ARP taky neblokuje.

(Mimochodem akceptovalo to i "ip6tables ... -p icmp" coz ale pochopitelne nefunguje - uz to jdu nareportovat)

[petr_p]

…protoze packety z neighbour discovery (obdoba ARP pro IPv6) se do RELATED asi nepocitaji, takze je DROPnul firewall. Musel jsem tomu jeste predradit

ip6tables -I INPUT -p icmpv6 -j ACCEPT

Rekl bych, ze odpovedi jsou RELATAED, jen ty prichozi dotazy jsou NEW a tudiz spravne zahazovany. ARP byl zcela nadhrazen (superseded) ICPMv6 protokolem. Souhlasim, ze je to pusobi trochu nezvykle a je to obvykle prvni chyba, se kterou se clovek firewallujici setka. Vasemu ctenemu oku doporucuji dokument Best Current Practice for Filtering ICMPv6 Messages in Firewalls.

(Mimochodem akceptovalo to i "ip6tables ... -p icmp" coz ale pochopitelne nefunguje - uz to jdu nareportovat)

icmp (1) a ipv6-icmp (58, v ip6tables tez zvany icmpv6) jsou dva ruzne protokoly. Nevidim problem, proc by neslo ten ci onen prenaset nad druhym sitovym protokolem. Ze ip6tables ma dva nazvy pro jednu vec, se lze presvedcit vypisy ip6tables -vnL a ip6tables-save.

[Michal Ludvig]

ICMP vs ICMPv6 - nemyslim ze by melo smysl pouzivat ICMP(v4) nad IPv6. Ciste technicky by to asi slo, kdyby nekdo byl dostatecne prasteny, nemel nic lepsiho na praci a udelal nejakou aplikaci ktera to bude posilat. Ale prakticke vyuziti nevidim. Prinejmensim warning ze jsem asi chtel -p icmpv6 a ne -p icmp by to chtelo.

Uz jsem to napraskal do bugzilly netfilteru tak uvidime.

[jiri.b]

moc pekne - diky. uprimne toto je jedna z veci, co me vzdy na linuxu zvedalo zaludek. ten kdo videl firewall na openbsd musi dat za pravdu...

presto diky

[lukasw]

nf_conntrack: table full . . . . . tak mi poradte jak moc to muzu zvednout abych se tohohle zbavil. . . kdyz jsem to u ip%conntrack%max prehnal, shodilo to rozhrani . . .

[petr_p]

To záleží na množství paměti... přečtěte si návod... je trochu starší, ale v zásadě platí...

Na x86 je implicitní hodnota pro počet záznamů 1/16K velikosti fyzické paměti v bajtech a velikost hashmapy osmina počtu záznamů. Navíc je to omezené ze zdola i ze shora rozumnými hodnotami. Pamatujte, že paměť vyhrazená pro conntracking je v jaderném prostoru a jako taková není swapovatelná.

Pokud máte málo paměti, doporučuji pomocí iptables cíle NOTRACK v raw tabulce vyřadit ze zkoumaní možné pakety (např. pro lokální nefirewallovanou síť nebo pro loopback). Dále snížit životnost záznamů.

V případě ojedinělých zaplnění způsobených nějakým útokem stačí zbytečné záznamy odmazat nástrojem conntrack.

Jestliže natujete rozsáhlou síť, tak vám asi nic jiného než dokoupit paměť nezbude. Vařit z čisté vody se nedá.

[Pavel Francírek]

Coz je rada na dve veci, kdy na starych iptables to funguje na 1GB a na novych je ta tabulka stale plna i s 2GB.

[petr_p]

Otázka zní, čím to je? Používá se i pro IPv4 záznamy položka schopná pojmout IPv6 adresy? Neplní se třeba tabulka očekávaných spojeních na základě práce pomocníků pro FTP apod., které jste ve starém jádře neměl? Není to prostá chyba, kdy jádru uniká paměť?

Tak či tak nikdo vás nenutí sledovat všechna spojení (a tím plýtvat pamětí). A pokud ano, pak byste si k tomu měl pořídit odpovídající železo. (I dedikované firewally od renomovaných firem jsou vybavena závratnými paměťovými kapacitami.)