Du limer inn en logg i en støttetråd, et svar påpeker at den inneholder din private nøkkel, og innlimingen er permanent. Den stillere feilen viser seg senere, når hver adresse har blitt X og filen ikke lenger beviser at klienten og serveren var forskjellige verter. En redigeringsrunde fjerner det som gir tilgang eller navngir en person, og beholder det som forklarer feilen. Det er en omforming med regler, ikke en sletting med et søkefelt.

Redigering er en omforming, ikke en sletting

En logg bærer struktur så vel som verdier: denne adressen snakket med den der, på dette tidspunktet, og håndtrykket stoppet ved dette trinnet. Verdiene er det som gjør filen farlig å publisere. Strukturen er det som gjør den verdt å publisere i det hele tatt.

Å slette hele linjer fjerner begge deler på en gang, og derfor svarer en trimmet logg ofte ingenting. Å slå sammen hver verdi til ett token feiler annerledes, fordi to forskjellige peers blir én enkelt aktør. Begge rundene kan se ryddige ut og likevel ødelegge beviset. Testen er om en leser som aldri har sett nettverket ditt kan følge sekvensen og nå den konklusjonen du nådde.

Først et utdrag, så strippe

Skjær ut avsnittet rundt feilen før du redigerer noe. Et mindre utdrag er lettere å granske, og det bærer mindre sannsynlig noe du hadde glemt var i filen. Oppbevar det urørte originalen i beskyttet lagring til saken er lukket. Redigering er tapende, og råfilen er den eneste måten å svare på oppfølgingsspørsmålet.

Les utdraget som ren tekst før du stoler på at en eksportkommando har strippet de private delene, fordi eksportører oppsummerer og roterer felt i stedet for å rense dem. Debug- og verbose-modus er det mest sannsynlige stedet for en nøkkelblokk eller en innebygd påloggingsdetalj. Åpne filen i en editor som viser fulle linjer, ikke i en viser som bryter og skjuler halen.

Hva som må bort, og i hvilken rekkefølge

Start med materiale som gir tilgang, fordi en mistet treff der avslutter øvelsen: blokker med private nøkler, passord, forhåndsdelte nøkler, API-tokens, gjenopprettingskoder. De er ikke bare identifiserende; de er brukbare for alle som leser tråden. En runde som fjerner alt annet og lar en av dem stå, har mislyktes.

Så identitetslaget: brukernavn, sertifikatemner og serienumre, kontoidentifikatorer og enhver sti som inneholder en persons navn. Ingenting av det er brukbart alene, men sammen navngir det en person, og det er den delen en offentlig tråd ikke trenger.

Så topologilaget, og det er der skjønnet kommer inn. Offentlige adresser, interne områder og vertsnavn kan alle erstattes når avsløringen deres ikke tjener noe diagnostisk formål, og stabile etiketter slår tomme felt. Rekkefølgen betyr noe fordi de tidligere lagene er absolutte og det siste er en beslutning. Å jobbe i den rekkefølgen hindrer deg også i å bruke en time på vertsnavn mens en nøkkelblokk står på linje førti.

Original kindReplace withKeep
Client addressCLIENT_AWhich side initiated
Server addressSERVER_BPort and protocol
UsernameUSER_1The failure that mentions it
HostnameHOST_1Resolution order

Ikke ødelegg relasjonene

Gi hver reell verdi én plassholder og bruk den på nytt hver gang verdien dukker opp. Hvis to adresser var forskjellige, må de forbli forskjellige etter runden, ellers konkluderer leseren med at klienten koblet til seg selv. Konsistens er hele mekanismen: leseren lærer koblingen ved å se en etikett komme tilbake. Én gjenbrukt token for to aktører er den raskeste måten å gjøre en logg uleselig på.

Rekkefølge og tid er en del av den samme strukturen. Hold sekvensen intakt, og hvis du flytter tidsstempler, flytt alle med samme beløp og si det på én linje. Å blande endrede og ekte tider er verre enn å fjerne dem, fordi hullene da ser ut som bevis på noe som aldri skjedde.

Porter, protokoll og retning blir som de er. En plassholder på adressen krever ikke en plassholder på porten.

Behold spørsmålet loggen må svare på

Skriv ned feltene en hjelper trenger før du begynner å redigere: den nøyaktige, ikke-hemmelige feilteksten, klient- og serverversjoner, transport og hvilken side som startet forsøket. Det er de som lar en fremmed kjenne igjen feilen. Å ha listen ved siden av seg gjør runden til en sjekk i stedet for et håp.

Når du sender filen, legg til én linje som sier hva som ble erstattet, slik at ingen bruker en time på å diagnostisere et plassholder-vertsnavn. OpenVPNs dokumentasjon om diagnostiske logger lister feltene loggene deres bærer, og det er listen du er i ferd med å endre. Spør før du sender en minnedump eller en pakkeopptak, og bruk støttekanalen du kan verifisere. Disse artefaktene inneholder langt mer enn tekstloggen, og noe av det er ikke ditt å publisere.

Les det ferdige utdraget én gang fra første til siste linje, inkludert begynnelsen og slutten. Skjermbilder fortjener mer mistanke enn tekst, fordi de bærer andre vinduer, kontonavn og menyelementer.

Relaterte artikler