Die firewall-log het een reël wat jy nie verwag het nie: ’n ACK-pakket, conntrack-toestand NEW, ’n bronadres wat nie joune is nie, bestemmingspoort oop. Die versoeking is om dit te lees as ’n vars inkomende verbinding wat niemand gemagtig het nie. Wat die reël werklik sê, is smaller: toe daardie pakket hierdie haakpunt bereik het, het die naspoorder geen passende toestand gehad nie, en die pakket het ’n ACK gedra. Dit is twee feite oor twee verskillende dinge, en nie een daarvan is ’n transkripsie van ’n handdruk nie. Hier is die volgorde wat ek volg voordat ek ’n gevolgtrekking maak.

Begin by die pakket, nie by die uitspraak nie

Skei die waarnemings voordat jy dit interpreteer. Die TCP-vlae beskryf hierdie pakket, die naspoorder se toestand beskryf wat dit by daardie haakpunt geweet het, en jou opvang beskryf net die venster wat jy opgeneem het.

Om daardie drie te verwar, is hoe ’n ACK ontaard in “die verskaffer het iemand ingelaat”.

Wat NEW eintlik by die haakpunt beteken

Die iptables-conntrack-ooreenstemming dokumenteer NEW as ’n pakket wat ’n verbinding begin, of een wat hoort by ’n verbinding wat nog nie verkeer in albei rigtings gesien het nie. ESTABLISHED beteken die naspoorder het pakkette in albei rigtings gesien. Niks in een van die twee definisies sê die pakket was ’n SYN nie, en niks sê dit het sonder ’n geskiedenis aangekom nie.

’n Naspoorder wat ’n stroom midde-in begin waarneem, klassifiseer die volgende pakket teen wat hy ook al weet, en dit kan niks wees nie. Dit sê iets oor die naspoorder se geheue, nie oor die afgeleë gasheer se bedoeling nie.

Loose tracking verduidelik die meeste ACK-verrassings

Die kernel dokumenteer nf_conntrack_tcp_loose, wat die naspoorder toelaat om TCP-verbindings op te tel wat hy nie sien begin het nie. Met die instelling op sy verstekwaarde kan ’n midde-in-ACK as ’n gevestigde stroom aanvaar word. Skakel dit af, en dieselfde pakket word waarskynliker as INVALID eerder as NEW geklassifiseer. Albei uitkomste beskryf die naspoorder se reëls, nie die toepassing se geskiedenis nie.

Kontroleer dus daardie instelling voordat jy ’n teorie op die etiket bou.

Sluit die vervelige oorsake in hierdie volgorde uit

Die meeste NEW-op-ACK-gebeurtenisse wat ek nagespeur het, het op een van hierdie geëindig, en almal is goedkoop om na te gaan:

  • Die conntrack-tabel is skoongemaak, of die naspoorder het herbegin.
  • Die gasheer het herbegin, of die stroom het na ’n ander naamruimte of toestel geskuif.
  • Asimmetriese roetering het die SYN op ’n pad uitgestuur wat jy nie opvang nie.
  • NAT het die tuple herskryf, so die inskrywing pas nie meer by wat jy gelees het nie.
  • Die opvang het laat begin en het nooit die begin gesien nie.

Elkeen van dié verwyder die vroeëre pakkette uit die naspoorder se blik terwyl die latere pakkette ongeskonde bly. ’n Herbegin of ’n skoonmaak van die tabel is die maklikste om uit uptime en logs te bevestig. Asimmetriese roetering wys as ’n eenrigting-opvang. NAT is die verraderlike een, want die tuple wat die naspoorder gestoor het, is nie die tuple wat in die log gedruk staan nie.

Skryf neer watter van hierdie jy uitgesluit het, en hoe, voordat jy verder gaan.

Lees die tuple, die koppelvlak en die haakpunt

’n Conntrack-inskrywing word gesleutel op adresse, poorte en protokol, so enige vertaling verander watter inskrywing pas. Teken ook die koppelvlak en die haakpunt aan, want ’n pakket wat op die verkeerde koppelvlak of ná ’n ander ketting gesien word, sê die pad is nie wat die diagram beweer nie. Wanneer die gebeurtenis ’n VPN betrek, besluit of jy na die binnepakket of na die buitenste draer kyk. Vergelyk dit dan met wat die gateway vir dieselfde vyf-tuple gelog het.

Twee sienings van een stroom wat verskil, is meer insiggewend as enige van die twee alleen.

Wanneer dit werd is om te eskaleer

Eskaleer wanneer jy kan wys op ’n diens wat bereikbaar is en nie behoort te wees nie, met die stroom, die beleid wat dit toegelaat het, en bewyse van albei kante. Moenie ’n verskafferfout aanmeld op grond van een toestandsetiket of een gedeeltelike opvang nie, want daardie verslag sal gesluit word met die verduideliking wat jy pas gelees het. As die diens werklik blootgestel is, is die eienaar van daardie grens die regte persoon om dit reg te maak, en ’n gedelegeerde poorttoewysing of ’n onbedoelde luisteraar is ’n waarskynliker oorsaak as ’n fout.

Maak dan die sigbaarheidsgaping toe wat een pakket soos ’n hele sessie laat lyk het.

Verwante artikels