En IPsec-tilstandsdump er ikke en statusrapport, og å behandle den som én er nettopp måten nøkkelmateriale havner i en offentlig feilsporer. Noen utdata fra kjerneinspeksjon inneholder trafikknøklene kjernen bruker, sammen med adresser, selektorer og tellere som virkelig er nyttige. Den trygge vanen er å samle sammendraget først og bare gripe til den rå tilstanden når sammendraget ikke kan svare på spørsmålet. Hvis du likevel må se på den rå tilstanden, se på den lokalt og del noe smalere.

Sjekk 1: kan denne artefakten i det hele tatt forlate maskinen

En konfigurasjonsfil, en privat nøkkel, en ubegrenset pakkefangst og en rå tilstandsdump er alle hemmeligheter til det motsatte er bevist. En kommando som skriver ut nøkler blir ikke trygg av at du kjørte den for diagnostikk.

Regelen er enkel nok til å si i én setning: del observasjonen som svarer på spørsmålet, ikke maskintilstanden som frembragte den.

Sjekk 2: velg sammendragskommandoen, ikke tilstandsdumpen

For strongSwan viser swanctl --list-sas assosiasjonssammendraget: identiteter, installerte child-SA-er, tilstander og tellere. Den krever ikke den rå nøkkeldumpen, og det er det første du bør lime inn i en sak. På kjernesiden støtter iproute2 ip xfrm state list nokeys på versjoner som dokumenterer valget, noe som undertrykker nøkkelmateriale mens assosiasjonsfeltene beholdes.

Bekreft syntaksen i den lokale håndboken før du stoler på den, fordi valget ikke finnes i hver utgivelse, og en generisk tilstandsliste uten det er en annen kommando med annen utdata. Å kjøre ip xfrm state på et gammelt bygg for å se om flagget finnes er nettopp feilen denne sjekklisten handler om.

Sjekk 3: noter bare det undersøkelsen trenger

Assosiasjonsstatus, algoritmer, selektorer, tidsstempler, retning og de relevante tellerne er vanligvis nok. Kontoidentiteter, offentlige adresser og intern topologi er det ofte ikke, og de kan sladdes uten å miste diagnostisk verdi.

Sladd som standard og legg tilbake på forespørsel. Den som leser saken din, kan be om ett felt til; men han kan ikke gjøre en limt inn nøkkel usett.

Det finnes en mellomvei det er verdt å kjenne: et sammendrag kan fortsatt være følsomt. Identiteter, peer-adresser og child-navn beskriver topologien din, og i noen organisasjoner er det i seg selv begrenset informasjon. Bestem hvem publikum er før du limer inn, og foretrekk en kanal med riktig tilgangskontroll fremfor en offentlig sak. En trygg kommando er ikke det samme som en trygg destinasjon.

Sjekk 4: korrelér ett forsøk i begge ender

Ta opp klienten og gatewayen for det samme tilkoblingsforsøket, samtidig, og forsikre deg om at assosiasjonen du beskriver, er den forsøket produserte. Å blande en utdatert child-SA fra et tidligere forsøk med et ferskt rutesnapshot gir en rapport som er internt konsistent og fullstendig misvisende.

Identifiser assosiasjonen etter dens unike identifikatorer og ikke etter tunnelen, og noter retningen på feilen. Hvis symptomet er ingen trafikk i én retning, si hvilken retning og ta med en ufarlig testdestinasjon, slik at leseren kan resonnere om stien i stedet for å gjette. En teller som er null i én retning og stiger i den andre lokaliserer problemet mye bedre enn noen nøkkeldump. Hold tidsstemplene i én tidssone og si hvilken.

Sjekk 5: hva du skal gjøre hvis materialet allerede er eksponert

Å slette vedlegget beviser ikke at ingen har beholdt det, og en offentlig innliming blir kopiert raskt.

Behandle det som en hendelse og bruk operatørens utskiftingsprosess: roter de berørte nøklene eller påloggingsdetaljene, sjekk om eksponeringen innebærer et bredere kompromiss, og følg den varslingsveien som gjelder. Den tekniske opprydningen er den enkle delen; antakelsen om at ingen har lest det, er den vanskelige.

Den varige praksisen er en liten mal du fyller ut før du limer inn: hvilken ende, hvilken assosiasjonsidentifikator, hvilken retning, hvilken teller og hva som allerede er utelukket. dokumentasjonen for swanctl list-sas beskriver sammendragsfeltene, og det er det de fleste saker faktisk trenger. Alt annet er tilgjengelig på forespørsel for den som trenger det. En diagnostisk rapport bør inneholde bevis, ikke tilgang.

Relaterte artikler