TCP Normalizáció – a kétélű fegyver

Nem egy új funkció, elsőként a Cisco ASA (PIX) 7.0-ás szoftver verziójában találkozhattunk jótékony, vagy éppen bosszantó hatásával. Biztonsági szempontból funkciójának szükségessége nem vitatható, de elég sok fejfájást tud okozni, ha hatása kiterjed az egyébként jogos, de az elvárt szempontoknak nem megfelelő összetételű forgalomra (false positive). Nincs “túldokumentálva”, ezért gondoltam, hogy hasznos lenne írni róla, mondjuk üzemeltetői vagy rendszertámogatói szemszögből.

A TCP normalizáció egy L4-es szinten működő védelmi funkció, melynek célja a TCP kommunikáció vizsgálata, szükség esetén ennek „cenzúrázása”, ezáltal bizonyos támadások megakadályozása. Valójában nem más, mint egy szűrő, melyen keresztül a TCP adatfolyam áthalad és „megtisztul”.


A dokumentáció két fajta szűrőt említ:

  • fix beállítású beépített szűrők (melyek garantáltan csak a „rosszindulatú” szegmenseket büntetik)
  • a felhasználó által konfigurálható szűrők

A TCP normalizáció „fragment reassembly”-t is végez, tehát bevárja és összerakja a több szegmensben érkező darabolt adatot és összerakva továbbítja az adatfolyamot pl. az eszközben lévő IPS modulnak analizálásra. A TCP normalizáció alapértelmezetten be van kapcsolva és pl. ASA és IPS esetében nem lehet kikapcsolni.
Az alábbi táblázatban összeszedtem a konfigurálható szűrők egyes verzióra vetített alapértelmezett beállításait:

ScreenHunter_10 Jul. 31 21.13

A TCP state bypass funkció a 8.2-es szoftver verzióban debütált, célja az aszimmetrikus TCP forgalom támogatása. Direkt módon nincs köze a TCP normalizációhoz, de fontos tudni, hogy a két funkció kölcsönösen kizárja egymást (“workaround” lehetőség a TCP normalizáció kikapcsolására).

Két szűrőt emelnék ki, melyek alapértelmezett beállítása problémát szokott okozni:

  • exceed-mss: a szűrő, mely az MSS (Maximum Segment Size) értékeket figyeli és ha a kommunikációban ennél magasabbat értéket észlel, a beállításnak megfelelően eldobja, vagy továbbítja a csomagot. A fenti táblázatban látható, hogy a korai fázisban (7.0-1) az alapértelmezett érték „drop” volt (a nagy számban jelentkező hibák és megoldásai bővebben), majd 7.2-től „allow”-ra változott, kihúzva ezáltal a probléma méregfogát.
  • queue-limit: a szűrő, mely beállítja azon (a TCP kommunikáció szerinti) sorrendvesztett csomagok számát, melyek a sorrendbe rakás céljából a pufferben tárolhatók és (7.2-től kezdődően) azt az időintervallumot, melyet ezen csomagok (szegmensek) a pufferben maradhatnak. Mivel az alapértelmezett érték “0”, beavatkozás nélkül gyakorlatilag minden sorrendvesztett csomag eldobódik (kivételt képeznek a policy-ban inspect paranccsal kiemelt alkalmazások, valamint ips és a TCP check-retransmission parancsok hatóköréhez tartozó forgalom).

Queue-limit szűrő:
Ez utóbbi szűrő által okozott problémával gondolom már sokan találkoztak, jómagam többször is beleestem abba a hibába, hogy új problémaként kezeltem és csak később csaptam a fejemre, amikor a “deja-vu” effektust észleltem

Tünetek:

  • bizonyos alkalmazások kapcsolatai időszakosan megszakadnak
  • lassú a kommunikáció

A TCP normalizáció alattomossága abban nyilvánul meg, hogy a queue-limit drop eseményről nincs explicit log üzenet!

Hogyan lehet a problémát diagnosztizálni?

A „show asp drop” parancs segítségével nézzük meg az ASP (Accelerated Security Path) által eldobott csomagok statisztikáit (igény esetén törölhetjük “clear asp drop”-pal), a kijelölt sorok mutatják a queue-limit által eldobott csomagok számát:

ScreenHunter_04 Jul. 31 20.40

Queue-limit konfiguráció:

A legtöbb esetben a queue-limit 3 megoldotta a problémát, de néhány esetben ennél nagyobb értékre lehet szükség.

Konfiguráció (esetünkben minden https forgalomra vonatkozóan):

ScreenHunter_05 Jul. 31 20.41

Finomhangolás:

A legutóbbi hibánál több mint egy hétig tartott a finomhangolási időszak, majd reménytelennek nyilvánítottuk az esetet. Gyakorlatilag naponta 2-3 alkalommal figyeltük a queue-limit által eldobott szegmenseket és ennek megfelelően módosítottuk a beállításokat („OoO no buffer drops” esetén a puffer méretét, „OoO buffer timeout drops” esetén pedig pufferben tölthető időintervallumot).

ScreenHunter_07 Jul. 31 20.53

Tanulságok:

A felhasználói visszajelzéseket elemezve („ugyan kevesebb a megszakadás, de az alkalmazás lényegesen belassult”), nem érdemes túl sok energiát pazarolni a finomhangolásra, a sorrendvesztett csomagok extrém méretű kitéréseit (pl. >3, a konkrét esetben 100-as puffer méret és 20 sec timeout fölött is volt hiba) nem lehet következmény nélkül korrigálni. Célszerű megtalálni a hibaforrást (a “root cause”-t), mely nagy valószínűséggel az adatfolyamban résztvevő valamely hálózati eszköz (switch, router vagy hálózati kártya) nem megfelelő működésének tulajdonítható (a QoS beállítások elvileg nem okozhatnak TCP session-ön belüli csomag (szegmens) sorrendváltozást). Amennyiben a hibát okozó eszköz “honos” hálózaton kívül található (pl. az Interneten), célszerű bejelenteni a hibát a szolgáltatónál. Sajnos tapasztaltam már olyat is, hogy az Internet szolgáltató a csomagok továbbítási sorrendjének ily módú megváltoztatását nem tekintette hibás működésnek.

TCP normalizációval (az ASA-n kívül) még az alábbi eszközök, szoftverek esetében találkozhatunk:

Cimkék: , ,

Kertész Viktor 2014. december 16.

  • Sziasztok!

    Jó cikk! Egy állítással vitatkoznék:
    “a QoS beállítások elvileg nem okozhatnak TCP session-ön belüli csomag (szegmens) sorrendváltozást”

    Sajnos, amennyiben az útvonalon van olyan router, amely például különböző queue-ba sorolja az out of contract csomagokat, akkor előfordulhat, hogy emiatt a csomagok nem sorrendben érkeznek meg a különböző queue-k eldobási stratégiájától függően. Ez tipikusan szolgáltatóknál fordulhat elő, ahol az ügyfél QoS beállításai okoznak ilyen problémát.

    Üdv,
    Viktor

Hozzászólás írása

Hiba az űrlap kitöltése során!

* A csillaggal jelölt mezők kitöltése kötelező

*
*
*
*