Conntrack NEW på ett ACK-paket: vad det inte bevisar

I brandväggsloggen finns en rad du inte väntade dig: ett ACK-paket, conntrack-tillstånd NEW, en källadress som inte är din, målporten öppen. Frestelsen är att läsa det som en ny inkommande anslutning som ingen har auktoriserat. Vad raden faktiskt säger är snävare: när det paketet nådde den här hooken hade spåraren inget matchande tillstånd, och paketet bar en ACK. Det är två fakta om två olika saker, och ingen av dem är en fullständig transkription av ett handskak. Här är ordningen jag går igenom innan jag drar en slutsats.

Börja med paketet, inte med domen

Separera observationerna innan du tolkar dem. TCP-flaggorna beskriver det här paketet, spårarens tillstånd beskriver vad den visste vid den hooken, och din inspelning beskriver bara det fönster du registrerade.

Att blanda de tre är hur ett ACK blir ”leverantören släppte in någon”.

Vad NEW egentligen betyder vid hooken

Den iptables-conntrack-matchningen dokumenterar NEW som ett paket som inleder en anslutning, eller ett som hör till en anslutning som ännu inte sett trafik i båda riktningarna. ESTABLISHED betyder att spåraren har sett paket båda vägarna. Ingen av definitionerna säger att paketet var en SYN, och ingen säger att det kom utan historik.

En spårare som börjar observera ett flöde mitt i klassificerar nästa paket efter vad den vet, och det kan vara ingenting. Det är ett påstående om spårarens minne, inte om den avlägsna värden avsikt.

Löst spårning förklarar de flesta ACK-överraskningarna

Kärnan dokumenterar nf_conntrack_tcp_loose, vilket låter spåraren plocka upp TCP-anslutningar som den inte såg början av. Med inställningen på sitt standardvärde kan ett ACK mitt i ett flöde antas som ett etablerat flöde. Stäng av den och samma paket klassificeras troligare som INVALID i stället för NEW. Båda utfallen beskriver spårarens regler, inte applikationens historik.

Kontrollera alltså den inställningen innan du bygger en teori på etiketten.

Uteslut de tråkiga orsakerna i den här ordningen

De flesta NEW-på-ACK-händelser jag har jagat slutade i en av dessa, och alla är billiga att kontrollera:

• Conntrack-tabellen tömdes, eller spåraren startades om.
• Värden startades om, eller flödet flyttade till en annan namespace eller enhet.
• Asymmetrisk routning skickade ut SYN:n på en väg du inte fångar.
• NAT skrev om tuple:n, så posten matchar inte längre det du läste.
• Inspelningen började sent och såg aldrig början.

Var och en av dessa tar bort de tidigare paketen från spårarens synfält och lämnar de senare intakta. En omstart eller en tömning av tabellen är lättast att bekräfta från uptime och loggar. Asymmetrisk routning visar sig som en enkelriktad inspelning. NAT är den lömska, eftersom tuple:n som spåraren sparade inte är tuple:n som tryckts i loggen.

Skriv ned vilka av dessa du uteslöt, och hur, innan du går vidare.

Läs tuple:n, gränssnittet och hooken

En conntrack-post är nycklad på adresser, portar och protokoll, så varje översättning ändrar vilken post som matchar. Anteckna också gränssnittet och hooken, eftersom ett paket sett på fel gränssnitt eller efter en annan kedja säger att vägen inte är den i diagrammet. När händelsen gäller en VPN, avgör om du tittar på det inre paketet eller den yttre bäraren. Jämför sedan med vad gatewayen loggade för samma femdelade tuple.

Två vyer av ett flöde som inte stämmer överens är mer informativa än någon av dem ensam.

När det är värt att eskalera

Eskalera när du kan visa en tjänst som är nåbar och inte borde vara det, med flödet, policyn som tillät det och bevis från båda ändar. Rapportera inte ett leverantörsfel på grundval av en enda tillståndsetikett eller en enda partiell inspelning, eftersom den rapporten kommer att stängas med förklaringen du just läste. Om tjänsten verkligen är exponerad är ägaren till den gränsen rätt person att åtgärda det, och en delegerad portmappning eller en oavsiktlig lyssnare är en troligare orsak än en bugg.

Åtgärda sedan det synlighetsgap som lät ett paket se ut som en hel session.