Berörs du av CVE-2019-14899? En checklista för kärnan
Den rapporterade attacken krävde en angripare på det angränsande nätet och en specifik värdnätverkskonfiguration. Kontrollera raden i rådet, kärnpaketet och din mildring.
En skanner flaggar CVE-2019-14899 på en maskin som kört VPN i åratal, och den första impulsen är att utropa VPN:en som trasig. Det är fel ram. Det offentliggjorda problemet gäller en angripare på offrets lokala nät som drar slutsatser om vissa TCP-anslutningar, inte en webbplats som dekrypterar din tunnel.
Gå igenom de fyra kontrollerna nedan i ordning. Var och en begränsar problemet eller avslutar utredningen.
Kontroll 1: omfattar rådet din kärna
Slå upp distributionens egen registrering, inte en bloggs sammanfattning av ett releasedatum. Ubuntus säkerhetssida för denna CVE listar det generiska linux-paketet för 18.04 LTS som sårbart med rättningen uppskjuten, och följer andra kärnpaket på separata rader. Matcha din körande release och ditt kärnpaket mot rätt rad. Ett bekant utseende versionsnummer är ingen träff.
En skannerträff betyder att identifieraren gäller något i din inventering. Det betyder inte att en närliggande enhet har utnyttjat maskinen.
Kontroll 2: vem är angriparen i modellen
Hotmodellen förutsätter en angränsande angripare som kan interagera med offrets åtkomstnät. Det är en bestämd position, inte en godtycklig fjärrtjänst som ogillar din utgångsnod. Om användarna ansluter från ett kafé är antagandet realistiskt; om de sitter bakom ett hanterat företags-LAN är det ett annat samtal.
Håll frågan om förtroende för det lokala nätet öppen även när tunneln är krypterad. Kryptering besvarar en annan fråga än närhet.
Kontroll 3: vilket lager förlitar du dig på
Korrekt validerad HTTPS ger sitt eget skydd för applikationsposter, och TLS 1.3 autentiserar dessa data från ände till ände. Det lovar inte att en angripare inte kan avbryta den underliggande TCP-anslutningen. En applikation kan därför vara säker att läsa och ändå avbrytbar, och avbrott är inte samma utfall som avslöjande. Separera de två innan du bedömer risken.
Den distinktionen spelar roll för rapporten. Den förvandlar ett vagt påstående att VPN:en är osäker till ett avgränsat uttalande om vad en angränsande angripare kunde observera eller avbryta.
Kontroll 4: vilken mildring du faktiskt rullade ut
Offentliggörandet diskuterar routing- och filtreringsmildringar och är tydligt om deras gränser, inklusive omvänd stigfiltrering och asymmetriska rutter. Klistra inte ett sysctl-värde på varje VPN-värd och säg att det är löst. Omvänd stigfiltrering samverkar med routingen, så ett värde som hjälper en topologi kan förstöra en annan.
Verifiering är ett kommando, inte en kryssruta. sysctl net.ipv4.conf.all.rp_filter visar det globala värdet, och sysctl net.ipv4.conf.tun0.rp_filter visar värdet per gränssnitt som faktiskt gäller. Läs båda före och efter varje ändring.
Använd distributionens vägledning och din egen routingdesign, och bekräfta sedan inställningen på gränssnittet som bär tunneln, inte i en fil som ingen har laddat.
Vad du ska skriva ned
Anteckna antagandet om angränsande angripare, det körande kärnpaketet, den rådsrad du matchade, den utrullade mildringen och var den tillämpas, samt de applikationsskydd som finns. Lägg till datumet då du kontrollerade rådet, eftersom dessa sidor ändras. Den kombinationen är en försvarbar bedömning.
Ett OS-releasedatum och en fungerande VPN-anslutning är ingen bedömning. Det är två fakta som råkar vara lätta att samla in.