Snort ved VPN-kanten: der pakkene er synlige

Følg én forespørsel fra en ekstern bærbar PC, og den krysser flere grenser før noe kan inspisere den. Den ytre tunnelen slutter i VPN-prosessen, den indre pakken vises på et grensesnitt, og HTTPS-økten innenfor fortsetter til applikasjonen. Et inspeksjonsverktøy ser bare det som er synlig på punktet der pakkene når det. Installer ett uten å bestemme dette punktet, og loggene beskriver feil lag.

Én pakke krysser flere grenser

Før VPN-terminering ser observatøren én ytre forbindelse, typisk til VPN-porten, med adresser og størrelser, men uten indre struktur. Etter termineringen er de indre adressene, portene og protokollene tilgjengelige på det behandlingspunktet som overlater dem. Applikasjonens egen TLS forblir kryptert med mindre et eget design terminerer den. Det er tre synlighetsnivåer, og et pakkenavn forteller deg ikke hvilket du kjøpte.

Tegn ruten med grensene markert, og plasser deretter sensoren på linjen der spørsmålet kan besvares, fordi plasseringen er en del av svaret. En grense du ikke kan navngi, er en grense du ikke kan teste.

Se hva som er lesbart på hvert punkt

Kontroller grensesnittet og en kort opptak før du stoler på noen beskrivelse av arkitekturen.

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

Lenkelisten viser tunnel- og fysiske grensesnitt som finnes, og opptaket viser nøyaktig hva en sensor tilkoblet der ville motta. Hvis den viser indre adresser, men ingen HTTP-forespørselslinjer, er du etter VPN-termineringen og fortsatt utenfor applikasjonens TLS. Det er det normale stedet for nettverksdeteksjon og det feil stedet for innholdsinspeksjon. Gjenta opptaket på det ytre grensesnittet for å sammenligne hva den andre grensen avslører.

Passiv deteksjon kan ikke blokkere alene

Snorts inspeksjonsdokumentasjon skiller passiv observasjon fra drift i linjen. Passiv modus kan varsle om trafikk uten å stoppe den på den ruten.

snort -T -c /etc/snort/snort.lua

Testmodus validerer konfigurasjonen uten å kjøre sensoren, noe som er det riktige første trinnet før enhver utrulling. Drift i linjen krever et kompatibelt opplegg for pakkefangst og en samsvarende håndhevelseskonfigurasjon, ikke bare et ekstra flagg. En loggoppføring er derfor ikke bevis for at en forespørsel ble forhindret, og en prosess startet med et inline-lignende alternativ beviser ikke at den faktiske videresendte strømmen går gjennom den. Bekreft hvor implementasjonen faktisk overlater pakkene.

Velg håndhevelsesmodus før utrulling

Avgjør om kravet er synlighet eller forhindring, fordi de to har ulik feilatferd. En passiv sensor som dør, lar trafikken fortsette og skaper et overvåkingshull; en enhet i linjen som dør, kan enten slippe trafikken gjennom eller stoppe den, og det valget må være bevisst. Bli enige om én tillatt strøm, én strøm som må avvises, og atferden du ønsker når sensoren svikter. Hold gjenoppretting av administrasjon atskilt fra den inspiserte ruten, slik at en feil i sensoren ikke også fjerner tilgangen din.

Registrer deretter den synlige trafikken, behandlingspunktet og håndhevelsesatferden. De tre faktaene, ikke den installerte pakken, beskriver hva utrullingen faktisk gjør.