Conntrack NEW ant ACK paketo: ko tai neįrodo

Ugniasienės žurnale yra viena eilutė, kurios nesitikėjote: ACK paketas, conntrack būsena NEW, šaltinio adresas ne jūsų, paskirties prievadas atidarytas. Pagunda tai perskaityti kaip naują įeinančią jungtį, kurios niekas neleido. Ką eilutė iš tikrųjų sako, yra siauriau: kai tas paketas pasiekė šį hook, sekiklis neturėjo atitinkančios būsenos, o paketas nešė ACK. Tai du faktai apie du skirtingus dalykus, ir nė vienas nėra visas rankos paspaudimo įrašas. Štai tvarka, kurią pereinu prieš darydamas išvadą.

Pradėkite nuo paketo, o ne nuo nuosprendžio

Atskirkite stebėjimus prieš juos aiškindami. TCP vėliavėlės apibūdina šį paketą, sekiklio būsena apibūdina, ką jis žinojo tame hook, o jūsų fiksavimas apibūdina tik tą langą, kurį įrašėte.

Šių trijų sumaišymas yra būdas, kuriuo ACK virsta „tiekėjas ką nors įleido“.

Ką NEW iš tikrųjų reiškia hook

iptables conntrack atitikmuo dokumentuoja NEW kaip paketą, kuris pradeda jungtį, arba paketą, susietą su jungtimi, kuri dar nematė srauto abiem kryptimis. ESTABLISHED reiškia, kad sekiklis matė paketus abiem kryptimis. Nė vienas apibrėžimas nesako, kad paketas buvo SYN, nei kad jis atėjo be istorijos.

Sekiklis, kuris pradeda stebėti srautą nuo vidurio, klasifikuoja kitą paketą pagal tai, ką žino, ir tai gali būti nieko. Tai teiginys apie sekiklio atmintį, o ne apie nuotolinio mazgo ketinimą.

Laisvas sekimas paaiškina daugumą ACK netikėtumų

Branduolys dokumentuoja nf_conntrack_tcp_loose, kas leidžia sekikliui perimti TCP jungtis, kurių pradžios jis nematė. Esant numatytajai nuostatai, ACK iš srauto vidurio gali būti priimtas kaip nusistovėjęs srautas. Išjunkite ją, ir tas pats paketas labiau linkęs būti klasifikuojamas kaip INVALID, o ne NEW. Abu rezultatai apibūdina sekiklio taisykles, o ne programos istoriją.

Todėl patikrinkite tą nuostatą prieš kurdami teoriją apie etiketę.

Pašalinkite nuobodžias priežastis šia tvarka

Dauguma NEW-ant-ACK įvykių, kuriuos sekiau, baigėsi viena iš šių priežasčių, ir visas jas patikrinti pigu:

• Conntrack lentelė buvo išvalyta arba sekiklis paleistas iš naujo.
• Mazgas buvo perkrautas arba srautas persikėlė į kitą namespace ar įrenginį.
• Asimetrinis maršrutizavimas išleido SYN keliu, kurio nefiksuojate.
• NAT perrašė tuple, todėl įrašas nebeatitinka to, ką perskaitėte.
• Fiksavimas prasidėjo vėlai ir niekada nematė pradžios.

Kiekviena jų pašalina ankstesnius paketus iš sekiklio regos lauko, o vėlesnius palieka nepažeistus. Perkrovimą ar lentelės išvalymą lengviausia patvirtinti iš uptime ir žurnalų. Asimetrinis maršrutizavimas pasirodo kaip vienkryptis fiksavimas. NAT yra klastingas, nes tuple, kurį sekiklis išsaugojo, nėra tas tuple, kuris atspausdintas žurnale.

Užsirašykite, kurias iš jų pašalinote ir kaip, prieš eidami toliau.

Skaitykite tuple, sąsają ir hook

Conntrack įrašo raktas yra adresai, prievadai ir protokolas, todėl bet koks vertimas keičia, kuris įrašas atitinka. Užsirašykite ir sąsają bei hook, nes paketas, matytas netinkamoje sąsajoje ar po kitos grandinės, sako, kad kelias ne toks, kaip schemoje. Kai įvykis susijęs su VPN, nuspręskite, ar žiūrite į vidinį paketą, ar į išorinį nešiklį. Tada palyginkite su tuo, ką šliuzas užregistravo tam pačiam penkių dalių tuple.

Du prieštaringi vieno srauto vaizdai yra informatyvesni nei bet kuris iš jų atskirai.

Kada verta eskaluoti

Eskaluokite, kai galite parodyti pasiekiamą paslaugą, kuri neturėtų būti pasiekiama, kartu su srautu, ją leidusią politika ir įrodymais iš abiejų galų. Nepraneškite apie tiekėjo defektą remdamiesi viena būsenos etikete ar vienu daliniu fiksavimu, nes ta ataskaita bus uždaryta būtent tuo paaiškinimu, kurį ką tik perskaitėte. Jei paslauga tikrai atvira, tos ribos savininkas yra tinkamas žmogus ją sutvarkyti, ir deleguotas prievadų susiejimas ar netyčinis klausytojas yra labiau tikėtina priežastis nei klaida.

Tada uždarykite matomumo spragą, dėl kurios vienas paketas atrodė kaip visa sesija.