Conntrack NEW á ACK-pakka: hvað það sannar ekki

Í eldveggjarskrá er ein lína sem þú bjóst ekki við: ACK-pakki, conntrack-staða NEW, upprunavistfang sem er ekki þitt, áfangahöfn opin. Freistingin er að lesa hana sem nýja innkomna tengingu sem enginn heimilaði. Það sem línan segir í raun er þrengra: þegar sá pakki náði þessu hooki hafði rekinn enga samsvarandi stöðu, og pakkinn bar ACK. Þetta eru tvær staðreyndir um tvo mismunandi hluti, og hvorug er heil uppskrift að handabandi. Hér er röðin sem ég fer í gegnum áður en ég dreg ályktun.

Byrjaðu á pakkanum, ekki dómnum

Aðskildu athuganirnar áður en þú túlkar þær. TCP-flöggin lýsa þessum pakka, staða rekinsins lýsir því sem hann vissi við þetta hook, og upptakan þín lýsir aðeins þeim glugga sem þú tókst upp.

Að blanda þessum þremur saman er leiðin sem ACK verður að „veitandinn hleypti einhverjum inn“.

Hvað NEW þýðir í raun við hookið

iptables conntrack-samsvörun skjalfestir NEW sem pakka sem byrjar tengingu, eða pakka sem tengist tengingu sem hefur ekki enn séð umferð í báðar áttir. ESTABLISHED þýðir að rekinn hefur séð pakka í báðar áttir. Hvorug skilgreiningin segir að pakkinn hafi verið SYN, né að hann hafi komið án forsögu.

Rekinn sem byrjar að fylgjast með straumi um miðbik flokkar næsta pakka eftir því sem hann veit, og það getur verið ekkert. Þetta er fullyrðing um minni rekinsins, ekki um ætlun fjarlæga hýsisins.

Laus rekstur skýrir flest ACK-óvart

Kjarninn skjalfestir nf_conntrack_tcp_loose, sem leyfir rekjanum að taka við TCP-tengingum sem hann sá ekki hefjast. Með stillinguna á sjálfgefnu gildi má taka ACK úr miðjum straumi sem komna tengingu. Slökktu á henni og sami pakki verður líklegri til að flokkast sem INVALID í stað NEW. Báðar niðurstöður lýsa reglum rekinsins, ekki forsögu forritsins.

Skoðaðu þessa stillingu því áður en þú byggir kenningu á merkimiðann.

Útilokaðu leiðinlegu orsakirnar í þessari röð

Flest NEW-á-ACK-atvikin sem ég hef elt enduðu í einni af þessum, og allar eru ódýrar í skoðun:

• conntrack-taflan var tæmd, eða rekinn endurræstur.
• Hýsillinn var endurræstur, eða straumurinn færðist í annað namespace eða tæki.
• Ósamhverf leiðsögn sendi SYN út um slóð sem þú ert ekki að taka upp.
• NAT endurskrifaði tuple-ið, svo færslan passar ekki lengur við það sem þú lasst.
• Upptakan byrjaði seint og sá aldrei byrjunina.

Hver þeirra fjarlægir fyrri pakkana úr sýn rekinsins og lætur þá seinni ósnortna. Endurræsing eða tæming töflunnar er auðveldust að staðfesta út frá uptime og skrám. Ósamhverf leiðsögn birtist sem einstefnuupptaka. NAT er lævísasti hlutinn, því tuple-ið sem rekinn geymdi er ekki tuple-ið sem prentað er í skránni.

Skrifaðu niður hverjum þú útilokaðir og hvernig, áður en þú heldur áfram.

Lestu tuple-ið, viðmótið og hookið

Færsla í conntrack er lykluð með vistföngum, höfnum og samskiptareglum, svo hver þýðing breytir því hvaða færsla passar. Skráðu líka viðmótið og hookið, því pakki sem sést á röngu viðmóti eða eftir aðra keðju segir að slóðin sé ekki sú sem skýringarmyndin sýnir. Þegar atvikið varðar VPN, ákveddu hvort þú ert að horfa á innri pakkann eða ytri burðinn. Berðu það svo saman við það sem gáttin skráði fyrir sama fimm hluta tuple-ið.

Tvær sýnir á einum straumi sem stangast á eru upplýsandi en hvor um sig ein.

Hvenær er þess virði að eskalera

Eskaleraðu þegar þú getur sýnt þjónustu sem er aðgengileg og ætti ekki að vera það, ásamt straumnum, stefnunni sem heimilaði hana og sönnunum frá báðum endum. Tilkynntu ekki galla hjá veitandanum á grundvelli eins stöðumerkis eða einnar hlutaupptöku, því sú tilkynning verður lokuð með skýringunni sem þú varst að lesa. Ef þjónustan er í raun opin er eigandi þess markar rétta manneskjan til að laga hana, og framselt hlutverk portkorts eða óviljandi hlustandi er líklegri orsök en villa.

Lokaðu svo sýnileikagatinu sem lét einn pakka líta út eins og heila setu.