Conntrack NEW egy ACK-csomagon: mit nem bizonyít

A tűzfalnaplóban van egy sor, amelyre nem számítottál: egy ACK-csomag, conntrack-állapot NEW, olyan forráscím, amely nem a tiéd, nyitott célport. A kísértés az, hogy friss bejövő kapcsolatként olvasd, amelyet senki nem engedélyezett. Amit a sor valójában mond, az szűkebb: amikor az a csomag elérte ezt a hookot, a követőnek nem volt illeszkedő állapota, és a csomag ACK-t hordozott. Ez két tény két különböző dologról, és egyik sem egy kézfogás teljes átirata. Íme a sorrend, amelyen végigmegyek, mielőtt következtetést vonnék.

A csomaggal kezdd, ne az ítélettel

Válaszd szét a megfigyeléseket, mielőtt értelmezed őket. A TCP-jelzők ezt a csomagot írják le, a követő állapota azt írja le, mit tudott annál a hooknál, a rögzítésed pedig csak azt az ablakot írja le, amelyet felvettél.

E három összekeverése az, ahogy egy ACK-ból „a szolgáltató beengedett valakit” lesz.

Mit jelent a NEW valójában a hooknál

Az iptables conntrack-illesztés a NEW-et olyan csomagként dokumentálja, amely kapcsolatot indít, vagy olyanként, amely olyan kapcsolathoz tartozik, amely még nem látott forgalmat mindkét irányban. Az ESTABLISHED azt jelenti, hogy a követő mindkét irányban látott csomagokat. Egyik meghatározás sem mondja, hogy a csomag SYN volt, és azt sem, hogy előzmények nélkül érkezett.

Az a követő, amely egy folyamat közepén kezdi figyelni, a következő csomagot aszerint osztályozza, amit tud, és az semmi is lehet. Ez a követő memóriájáról szóló állítás, nem a távoli gazdagép szándékáról.

A laza követés magyarázza a legtöbb ACK-meglepetést

A kernel dokumentálja nf_conntrack_tcp_loose, ami lehetővé teszi a követőnek, hogy olyan TCP-kapcsolatokat vegyen át, amelyek kezdetét nem látta. A beállítás alapértékén egy folyamat közepéről érkező ACK elfogadható létesített folyamatként. Kapcsold ki, és ugyanaz a csomag valószínűbben lesz INVALID, mint NEW. Mindkét eredmény a követő szabályait írja le, nem az alkalmazás előzményeit.

Tehát ellenőrizd ezt a beállítást, mielőtt elméletet építenél a címkére.

Zárd ki az unalmas okokat ebben a sorrendben

A legtöbb általam követett NEW-az-ACK esemény ezek egyikével végződött, és mindegyik olcsón ellenőrizhető:

• A conntrack-tábla kiürült, vagy a követő újraindult.
• A gazdagép újraindult, vagy a folyamat másik namespace-be vagy eszközre került.
• Az aszimmetrikus útválasztás olyan útra küldte a SYN-t, amelyet nem rögzítesz.
• A NAT átírta a tuple-t, így a bejegyzés már nem egyezik azzal, amit olvastál.
• A rögzítés későn indult, és soha nem látta a kezdetet.

Mindegyikük eltávolítja a korábbi csomagokat a követő látóteréből, a későbbieket pedig érintetlenül hagyja. Az újraindítást vagy a tábla ürítését a legkönnyebb uptime és naplók alapján igazolni. Az aszimmetrikus útválasztás egyirányú rögzítésként jelenik meg. A NAT az alattomos, mert a követő által tárolt tuple nem az a tuple, amely a naplóban szerepel.

Írd fel, melyeket zártál ki és hogyan, mielőtt továbblépsz.

Olvasd el a tuple-t, az interfészt és a hookot

A conntrack-bejegyzés kulcsa a címek, portok és protokoll, ezért minden fordítás megváltoztatja, melyik bejegyzés illeszkedik. Jegyezd fel az interfészt és a hookot is, mert a rossz interfészen vagy másik lánc után látott csomag azt mondja, hogy az útvonal nem az, ami az ábrán szerepel. Amikor az esemény VPN-t érint, döntsd el, a belső csomagot vagy a külső hordozót nézed. Utána vesd össze azzal, amit az átjáró ugyanarra az ötrészes tuple-re naplózott.

Egy folyamat két egymásnak ellentmondó nézete többet mond, mint bármelyik önmagában.

Mikor érdemes eszkalálni

Akkor eszkalálj, ha meg tudsz mutatni egy elérhető szolgáltatást, amelynek nem kellene elérhetőnek lennie, a folyamattal, az azt engedélyező szabályzattal és mindkét vég bizonyítékaival. Ne jelents szolgáltatói hibát egyetlen állapotcímke vagy egyetlen részleges rögzítés alapján, mert azt a jelentést azzal a magyarázattal zárják le, amelyet épp most olvastál. Ha a szolgáltatás valóban ki van téve, annak a határnak a tulajdonosa a megfelelő személy a javításra, és a delegált porttérkép vagy egy nem szándékolt figyelő valószínűbb ok, mint egy hiba.

Utána zárd be azt a láthatósági rést, amely miatt egyetlen csomag teljes munkamenetnek tűnt.