pakety -m state --state ESTABLISHED,RELATED

9.2.2012 12:32 | Přečteno: 1879× |

Tak nějak se mi zdá, že klasifikace iptables -m state --state ESTABLISHED,RELATED občas zašvindluje.

U nás v práci máme hraniční router a v něm stovky pravidel iptables určujících, odkud kam se smí a nesmí. Někde skoro na začátku se skví tohle:

# ACCEPT ustanovene spojeni
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Očekává se od toho, že pakety patřící do již navázaného spojení (ESTABLISHED) a také pakety navazující nové spojení v rámci již běžící komplexnější komunikace (RELATED) budou bez dalšího odroutovány. Při tom do kategorie ESTABLISHED se počítají i pakety SYN-ACK odpovídající na úvodní SYN při navazování TCP soketu. Dobře, tak se to obvykle dělá. Jenže v logu routeru vidíme četné zakázané pokusy o navázání spojení iniciovaného z nějakého WWW serveru se zdrojovým portem 80, kde cílovým strojem je nějaká naše stanice vysoký port. Na první pohled to vypadá, jako kdyby WWW server byl asi kraknutý a snažil se připojit z portu 80 na pécéčko klienta.

Avšak zdání klame. Ve skutečnosti šňupání paketů pomocí tcpdump ukázalo, že nic takového se neděje, žádné SYN pakety od cizích WWW serverů neběhají. Co se tedy děje? Nejspíš to, že od stanice odejde regulérní navazující SYN a modul -m state si ho nevšimne. Následně server vrátí potvrzující paket SYN-ACK a ten je vyhodnocen jako pokus o navázání spojení zvenčí na stanici a tedy odmítnut.

Jiné vysvětlení mě nenapadá. Navazující SYN nemohl odejít jinudy, to je vyloučeno. A zakázaný paket od serveru musí mít nastavený příznak SYN, protože tam máme taky pravidlo

iptables -A FORWARD -p TCP ! --syn -m state --state NEW -j NOTSYN

Kdyby ten nečekaný paket neměl SYN, byl by chainem NOTSYN zalogován jiným způsobem, než jak se to děje. Nevidím jinou možnost, než že modul -m state občas zachybuje. Což má ovšem za následek, že spojení je odmítnuto, klient to musí zkusit znovu a uživatel pak vidí zhoršenou odezvu.

       

Komentáře

[ET]

ciste teoreticky, nemohlo by to bejt kvuli necemu takovymu - http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

tj. situace, kdy se pokousi web server kontaktovat klienta (browser), ale spojeni (na routeru) uz je zavreny - at uz kvuli timeoutu, nebo treba chybe na serveru

asi bych se kouknul na ten www server co na nem bezi, popr. analyzou logu ohledne predchozich "uspesnych" spojeni

dokazu si predstavit, ze dneska ten push pouziva nejaka ta webapp (IM) - co vim, tak minimalne se to pouziva na push-email

[krnoha]

Spíš myslím že ne. Když se na TCP spojení dlouho nic neděje, opravdu router může usoudit, že spojení není aktuální a příští paket potom bude vyhodnocen jako NEW. Ale ten příští paket nebude přece SYN? A když nebude, zamečuje pravidlo NEW_NOT_SYN a podle toho to bude zalogováno, což se ale neděje.

[vencour]

A jsou po celé cestě stejné timeouty? V linuxu by měly platit jako zde uvedené ... ?

Mimochodem, pokud je spojení vyhodnoceno jako prošlé, mělo by se o tom přes icmp či nějaký tcp/reset poslat info ...

[Jiří Veselský]

A nepřeplňuje se connection-tracking tabulka?

[krnoha]

Nevím,to bych měl vidět v logu? Log je hodně objemný, co mám grepovat? Zdá se mi to dobrá myšlenka, ale v logu nic nevidím.

[Petr]

http://pario.no/2009/10/05/iptables-connection-tracking-table-full/

[krnoha]

V logu jádra není nic, co by ukazovalo na přeplnění tabulky pro conntrack. Škoda, vypadalo to jako slibný vysvětlení.

[rastos]

Tiež mám podozrenie, že tam niečo nefunguje dobre, ale nedokážem to na želanie nasimulovať a preukázať Pozorujem to však spravidla na ssh spojení.

[maleprase]

TCPKeepAlive by nepomohlo?

[rastos]

Pochybujem. Ono to nesúvisí s tým, že by sa na tom spojení neprenášali dáta. Práve naopak.

[miro]

jenže v logu routeru vidíme četné zakázané pokusy o navázání spojení iniciovaného z nějakého WWW serveru se zdrojovým portem 80, kde cílovým strojem je nějaká naše stanice vysoký port.

Ve skutečnosti šňupání paketů pomocí tcpdump ukázalo, že nic takového se neděje, žádné SYN pakety od cizích WWW serverů neběhají.

Pokud to router zahodí, tak je snad logické, že to dál po síti neběhá, ne? Nebo kde se to přesně zakáže a kde šňupete tcpdump-em?

Jinak server nemusí poslat SYN+ACK v jednom paketu, může poslat ACK zvlášť a SYN zvlášť, a není vůbec nic proti RFC793, to říká, že ACK a SYN od serveru může být v jednom paketu. Že to tak být může, se časem nějak vytratilo z překladu, takže se na to přehnaně spoléhá, čehož využívá tzv. split handshake attack, na nějž jsou náchylné některé HW routery. Takže otázka je, jestli před iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT není ještě jiné pravidlo, které SYN od serveru (nesprávně) zahodí. Případně se může stát, že se ACK serveru ztratí (nebo zpozdí) někde po cestě k routeru a dorazí pouze SYN.

[alkoholik]

A to spousta lidi nevi takovou perlicku.

[miro]

Taky jsem neznal, pěkný

[krnoha]

Až tak ??? Řekněme že klient i server jsou MS. Něco si řeknou a pak zavřou spojení. Uživatel klikne a IE pošle rovnou HTTP request. Pakety odejdou, protože ven pouštíme všecko. Server se zaraduje a pošle odpověď. Pakety od serveru nemečujou s podmínkou

-m state --state ESTABLISHED,RELATED

protože spojení nebylo řádně navázáno. Ale nemečujou ani s podmínkou

-p TCP ! --syn -m state --state NEW 

Není to sice SYN, ale není to ani NEW, protože před chvilkou tady nějaký provoz šel. Vypadá to divně, ale když vyslechnu uživatele postižených stanic a všichni se přiznají k použití MS IE, tak by to začalo vypadat jako docela dobrá hypotéza.

[krnoha]

Šňupáme samozřejmě na routeru. SYN který není NEW propouštíme. Zahozené něco od serveru šlo na stanici, která před chvilkou s tím samým serverem normálně komunikovala. Ta chyba není fatální, uživatelé vůbec nevědí, že jim něco nefunguje. Jenom mají asi delší odezvu.

[krnoha]

Ono to jenom vypadá jako pokus o pokračování spojení ze serveru na stanici, je to ze zdrojového portu 80 na nějaký vysoký port, ale není to tak. Číslo portu stanice je jiné než ze kterého šlo předchozí spojení. Takže to není chyba conntrack a dokonce ani chyba Microsoftu, je to jen obyčejný útok. Omlouvám se za zbytečné plašení. Jako IP adresy atakujících serverů jsou fingovány adresy oblíbených webových serverů, takže vlastně každému logovanému případu předcházelo skutečné připojení na tento server v nedávné minulosti.