Snort vid VPN-kanten: där paketen är synliga

Följ en enda förfrågan från en extern bärbar dator och den korsar flera gränser innan något kan inspektera den. Den yttre tunneln slutar i VPN-processen, det inre paketet dyker upp på ett gränssnitt och HTTPS-sessionen inuti fortsätter till applikationen. Ett inspektionsverktyg ser bara det som är synligt vid den punkt där paketen når det. Installera ett utan att bestämma den punkten, och loggarna beskriver fel lager.

Ett paket korsar flera gränser

Före VPN-avslutet ser observatören en enda yttre anslutning, vanligtvis till VPN-porten, med adresser och storlekar men utan inre struktur. Efter avslutet är de inre adresserna, portarna och protokollen tillgängliga vid den bearbetningspunkt som lämnar över dem. Applikationens egen TLS förblir krypterad om inte en separat design avslutar den. Det är tre synlighetsnivåer, och ett paketnamn säger dig inte vilken du köpte.

Rita vägen med gränserna markerade och placera sedan sensorn på den linje där frågan kan besvaras, eftersom platsen är en del av svaret. En gräns du inte kan namnge är en gräns du inte kan testa.

Se vad som är läsbart vid varje punkt

Kontrollera gränssnittet och en kort inspelning innan du litar på någon beskrivning av arkitekturen.

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

Länklistan visar befintliga tunnel- och fysiska gränssnitt, och inspelningen visar exakt vad en sensor ansluten där skulle ta emot. Om den visar inre adresser men inga HTTP-förfrågningsrader är du efter VPN-avslutet och fortfarande utanför applikationens TLS. Det är den normala platsen för nätverksdetektering och fel plats för innehållsinspektion. Upprepa inspelningen på det yttre gränssnittet för att jämföra vad den andra gränsen avslöjar.

Passiv detektering kan inte blockera på egen hand

Snorts inspektionsdokumentation skiljer passiv observation från drift i linjen. Passivt läge kan varna för trafik utan att stoppa den på den vägen.

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

Testläget validerar konfigurationen utan att köra sensorn, vilket är det rätta första steget före varje utrullning. Drift i linjen kräver ett kompatibelt upplägg för paketinsamling och en matchande tillämpningskonfiguration, inte bara en extra flagga. En loggpost är därför inte bevis för att en förfrågan hindrades, och en process som startats med ett inline-liknande alternativ bevisar inte att det faktiska vidarebefordrade flödet passerar genom den. Bekräfta var implementeringen faktiskt lämnar över paketen.

Välj tillämpningsläge före utrullning

Avgör om kravet är synlighet eller förhindrande, eftersom de två har olika felbeteende. En passiv sensor som dör låter trafiken fortsätta och skapar en övervakningslucka; en enhet i linjen som dör kan antingen släppa igenom trafiken eller stoppa den, och det valet måste vara avsiktligt. Enas om ett tillåtet flöde, ett flöde som måste nekas och beteendet du vill ha när sensorn misslyckas. Håll återställning av administrationen åtskild från den inspekterade vägen, så att ett fel i sensorn inte också tar bort din åtkomst.

Registrera sedan den synliga trafiken, bearbetningspunkten och tillämpningsbeteendet. De tre fakta, inte det installerade paketet, beskriver vad utrullningen faktiskt gör.