NF_CONNTRACK

5.2.2007 23:11 | Přečteno: 5000× |

Jádro 2.6.20 přineslo plnou implementaci NATU nad sjednoceným NF_CONNTRACK rozhraním. Jak opustit zastaralý IP_CONNTRACK (fuj, kdo bych chtěl takovou vykopávku) a vejít vstříc světlým zítřkům s novým a úžasným NF_CONNTRACKEM se dozvíte právě teď.

Trocha historie

Dříve byla jaderná část Netfilteru (tzv. Corefilter) vyvíjená jen pro IPv4. Později, když se Linux naučil IPv6, začalo období hurá programování (projekt USAGI), které mělo přinést nezávislou, i když odvozenou, implementaci i pro IPv6.

Časem se ale ukázalo, že se příliš duplikuje kód, conntrack helpery se píší na dva krát a vůbec je to takové divné. Vývojáři netfilteru se nakonec zařekli a i přes hlasitý křik uživatelů dožadujících se plně stavového IPv6 firewallu, několik let přepisovali jadernou část tak, aby funkcionalita společná IPv4 a IPv6 byla oddělena od adresně-rodinně [address family] specifického kódu.

Dílo se nakonec zdařilo a dnes si můžeme užívat plodů jejich práce.

Jak na to

Rozbalíme zdrojáky jádra, zkopírujeme starý .config a spustíme náš oblíbený konfigurační nástroj (make NĚCOconfig).

V Networking → Networking options → Network packet filtering framework (Netfilter) najdeme tři podmenu: Core Netfilter Configuration, IP: Netfilter Configuration a IPv6: Netfilter Configuration.

Core Netfilter Configuration

V Core Netfilter Configuration zapneme Netfilter connection tracking support (CONFIG_NF_CONNTRACK_ENABLED) a jako Netfilter connection tracking support zvolíme Layer 3 Independent Connection tracking (CONFIG_NF_CONNTRACK_SUPPORT=y). Druhou volbu (CONFIG_IP_NF_CONNTRACK_SUPPORT) prosím ne. To je ta stará možnost, která se dosud používala a které se chceme zbavit. Pokud ručně editujete .config, tak ji zakomentujte.

Abychom využili RELATED stav spojení na nějakém pěkném aplikačním protokolu, vybereme zde conntrack helper např. pro FTP (FTP protocol support, CONFIG_NF_CONNTRACK_FTP) a pro SIP (SIP protocol support, CONFIG_NF_CONNTRACK_SIP). Právě zde v přímém přenosu vidíte důkaz výhody sjednoceného rozhraní, kdy se nemusíme starat zvlášť o IPv4 a zvlášť o IPv6.

IP: Netfilter Configuration

V IP: Netfilter Configuration zapneme IPv4 connection tracking support (required for NAT) (CONFIG_NF_CONNTRACK_IPV4) a pokud máme programy zpracovávající soubor /proc/net/ip_conntrack, zapneme také proc/sysctl compatibility with old connection tracking (CONFIG_NF_CONNTRACK_PROC_COMPAT). Kdybychom toto neudělali, museli bychom upravit své programy, aby rozuměly novému souboru /proc/net/nf_conntrack. Dále ponecháme zapnutou podporu pro iptables (IP tables support (required for filtering/masq/NAT), CONFIG_IP_NF_IPTABLES) a pozor, zlatý hřeb večera – nová implementace NATU Full NAT (CONFIG_NF_NAT).

Jedná se o dříve avizovanou novinku jádra 2.6.20. Její nepřítomnost byla posledním důvodem, proč mezi podporou IPv4 NATU a IPv6 conntrackingu byl vztah vzájemné výlučnosti. Od nynějška to již není pravda a obě funkce mohou být zakompilovány současně.

IPv6: Netfilter Configuration

Zbývá zapnout IPv6 connection tracking support (CONFIG_NF_CONNTRACK_IPV6) v podmenu IPv6: Netfilter Configuration a zcela určitě ponechat podporu IPv6 iptables IP6 tables support (required for filtering) (CONFIG_IP6_NF_IPTABLES).

Samozřejmě si můžete zakompilovat, co je libo a co uznáte za vhodné (např. netlink a zpřístupnění conntrack tabulky přes netlink. Hodí se pro nástroj conntrack, který umí conntrack tabulku prohledávat ale také i měnit a záznamy přidávat nebo odmazávat (ale o tom až někdy jindy)).

Důkaz místo slibů

Moduly

$ lsmod
Module                  Size  Used by
ipt_MASQUERADE          2496  1 
nf_conntrack_sip        8020  0 
iptable_nat             5956  1 
nf_nat                 14188  2 ipt_MASQUERADE,iptable_nat
eeprom                  5584  0 
nf_conntrack_ipv4      13068  3 iptable_nat
ipt_REJECT              3328  2 
nf_conntrack_ipv6      15836  1 
xt_state                1984  2 
xt_tcpudp               2944  22 
iptable_filter          2240  1 
iptable_mangle          2176  0 
ip6table_filter         2112  1 
ip_tables               9736  3 iptable_nat,iptable_filter,iptable_mangle
ip6_tables             10824  1 ip6table_filter
x_tables               11588  7 ipt_MASQUERADE,iptable_nat,ipt_REJECT,xt_state,xt_tcpudp,ip_tables,ip6_tables
nf_conntrack_ftp        7872  0 
nf_conntrack           48264  8 ipt_MASQUERADE,nf_conntrack_sip,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state,nf_conntrack_ftp
nfnetlink               4888  3 nf_conntrack_ipv4,nf_conntrack_ipv6,nf_conntrack
ipv6                  229984  23 nf_conntrack_ipv6

NAT

$ iptables -t nat -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Plně stavový paketový filtr

$ iptables -t filter -nL INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

$ ip6tables -t filter -nL INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all      ::/0                 ::/0               state RELATED,ESTABLISHED

$ cat /proc/net/nf_conntrack
ipv4     2 tcp      6 112 TIME_WAIT src=147.251.23.20 dst=147.251.23.19 sport=3472 dport=8118 src=147.251.23.19 dst=147.251.23.20 sport=8118 dport=3472 [ASSURED] use=1
ipv4     2 tcp      6 111 TIME_WAIT src=147.251.23.20 dst=147.251.23.19 sport=3467 dport=8118 src=147.251.23.19 dst=147.251.23.20 sport=8118 dport=3467 [ASSURED] use=1
ipv6     10 tcp      6 428207 ESTABLISHED src=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 dst=2001:06a8:3c80:0000:0203:baff:fe39:f931 sport=3406 dport=21 src=2001:06a8:3c80:0000:0203:baff:fe39:f931 dst=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 sport=21 dport=3406 [ASSURED] use=2
ipv4     2 udp      17 179 src=147.251.23.20 dst=147.251.23.19 sport=1026 dport=53 src=147.251.23.19 dst=147.251.23.20 sport=53 dport=1026 [ASSURED] use=1
ipv6     10 tcp      6 431999 ESTABLISHED src=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 dst=2002:93fb:1712:0000:0000:0000:0000:0001 sport=1693 dport=8000 src=2002:93fb:1712:0000:0000:0000:0000:0001 dst=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 sport=8000 dport=1693 [ASSURED] use=1
ipv6     10 tcp      6 431999 ESTABLISHED src=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 dst=2001:06a8:3c80:0000:0203:baff:fe39:f931 sport=4684 dport=56997 src=2001:06a8:3c80:0000:0203:baff:fe39:f931 dst=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 sport=56997 dport=4684 [ASSURED] use=1
ipv6     10 tcp      6 431707 ESTABLISHED src=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 dst=2002:93fb:1712:0000:0000:0000:0000:0001 sport=2212 dport=22 src=2002:93fb:1712:0000:0000:0000:0000:0001 dst=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 sport=22 dport=2212 [ASSURED] use=1

Práce SIP a FTP helperů

cat /proc/net/nf_conntrack_expect 
176 l3proto = 2 proto=17 src=69.90.155.70 dst=147.251.23.20 sport=0 dport=7078 
280 l3proto = 10 proto=6 src=2001:06a8:3c80:0000:0203:baff:fe39:f931 dst=2002:93fb:1712:0001:4e00:10ff:fe60:7ca6 sport=0 dport=1209

       

Komentáře

[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.)