Finn forkastede VPN-pakker uten å fange innholdet deres

En brannmurteller øker når en pakke samsvarer med en regel, og den gjør det uten å beholde pakken. Det er nok til å svare på det første spørsmålet i de fleste drop-undersøkelser: nådde strømmen i det hele tatt denne regelen. Innfanging av nyttelasten svarer på et annet spørsmål, og den samler alt annet som krysser grensesnittet mens den kjører. Start med telleren, og gå over til metadata-logging bare når telleren er tvetydig.

Tellere svarer på det første spørsmålet

Hver regel som kan samsvare har en teller, og å lese den før og etter en test forteller om trafikken kom frem. Det er en sammenligning av to tall og ikke et arkiv, og det koster ingenting i lagring eller eksponering.

Les tellerne med verktøyet som eier reglene:

iptables -L FORWARD -v -n --line-numbers
nft list ruleset

Deltaet er beviset. En regel der telleren ikke beveger seg har aldri sett strømmen, noe som peker på en tidligere grense: feil grensesnitt, feil tabell eller en rute som aldri sendte pakken dit. En regel der telleren beveger seg og likevel forkaster, forteller at policyen gjør det den ble skrevet for.

Hva en teller ikke kan fortelle deg

En teller gir deg et tall, ikke en grunn. Den kan ikke skille en pakke som samsvarte på adresse fra en som samsvarte på port, og den kan ikke si hvilken av to like regler som fanget strømmen. Den kan heller ikke si om pakken ble forkastet, avvist eller godtatt og deretter tapt, med mindre du leser regelen som eier telleren.

Det er her metadata-logging kommer inn, og omfanget er hele poenget. Logg grensesnitt, retning, adresser, protokoll og avgjørelse for en bestemt teststrøm. De feltene lokaliserer en mislykket grense uten å registrere hva brukeren gjorde.

Logging av nyttelast svarer på et annet spørsmål, og den svarer på det om alle på grensesnittet.

Metadata-logging med et smalt omfang

Skriv en regel som bare samsvarer med teststrømmen din, gi den et tydelig prefiks, og begrens hastigheten under plattformens egne kontroller slik at et vanlig nytt forsøk ikke oversvømmer lagringen. Prefikset er det som lar deg finne oppføringene dine blant alt annet enheten logger.

Unngå å slå på logging av nyttelast eller ubegrenset pakkelogging bare fordi funksjonen finnes. En avkortet innfanging er heller ikke automatisk fri for nyttelast, siden headere og pakkelayout varierer, så en snaplengde som ser liten ut kan fortsatt bære applikasjonsbytes.

Hvis du må fange, fang én strøm, i en begrenset tid, med den minste snaplengden som svarer på spørsmålet ditt.

Match én ny forespørsel

Generer ufarlig trafikk som følger den faktiske klientruten, og sammenlign deretter de relevante tellerne før og etter. En lokal test på gatewayen kan helt overse en videresendingsregel, fordi pakken aldri tar videresendingsveien. En etablert sesjon kan også samsvare med en annen tilstandshåndtering enn en ny tilkobling, så en langvarig strøm erstatter ikke en ny.

Tidsbegrens vinduet og skriv det ned. Mellom to bestemte minutter, fra denne klientadressen, til denne destinasjonen på denne protokollen er en diagnose. En gang i morges er et søk.

Én strøm, ett vindu, én grense er enheten for fremgang her.

Rydd opp og behold bare utdraget

Fjern den midlertidige diagnostikkregelen gjennom den eide konfigurasjonen når undersøkelsen er over. En smal loggingsregel som blir stående blir et utilsiktet registersystem, og ingen husker hvorfor den finnes seks måneder senere.

Hold originale opptegnelser private når policyen krever det, og del et gjennomgått minimalt utdrag i stedet for hele innfangingen. Adresser, kontoidentifikatorer og intern topologi er sensitive selv når det ikke finnes nyttelast. Behandle utdraget som et dokument med en eier. Sladd alt diagnosen ikke trenger.

Målet er en bestemt mislykket grense for en bestemt forespørsel. Alt som produserer et fullstendig arkiv over alle som bruker VPN, har overskredet diagnosen og startet et annet prosjekt. Sjekk plattformens loggdokumentasjon for hva den registrerer som standard før du legger til noe.