Us afecta CVE-2019-14899? Una llista de comprovació per al nucli
L’atac descrit requeria un atacant a la xarxa adjacent i una configuració de xarxa de l’amfitrió concreta. Reviseu la fila de l’avís, el paquet del nucli i la vostra mitigació.
Un escàner marca CVE-2019-14899 en una màquina que fa anys que utilitza una VPN, i el primer instint és declarar la VPN trencada. És un marc equivocat. El problema publicat afecta un atacant a la xarxa local de la víctima que dedueix informació sobre certes connexions TCP, no un lloc web que desxifra el vostre túnel.
Feu les quatre comprovacions següents en ordre. Cadascuna o bé estreny el problema o bé acaba la investigació.
Comprovació 1: l’avís cobreix el vostre nucli
Consulteu el registre de la vostra distribució, no el resum d’una data de publicació d’un blog. La pàgina de seguretat d’Ubuntu per a aquesta CVE llista el paquet linux genèric per a 18.04 LTS com a vulnerable amb la correcció ajornada, i fa el seguiment d’altres paquets del nucli en files separades. Feu coincidir la versió que executeu i el paquet del nucli amb la fila correcta. Un número de versió que sembla familiar no és una coincidència.
Un resultat de l’escàner vol dir que l’identificador s’aplica a alguna cosa del vostre inventari. No vol dir que un dispositiu veí hagi explotat la màquina.
Comprovació 2: qui és l’atacant al model
El model d’amenaces assumeix un atacant adjacent que pot interactuar amb la xarxa d’accés de la víctima. És una posició concreta, no un servei remot qualsevol a qui no agrada el vostre node de sortida. Si els usuaris es connecten des d’un cafè, la suposició és realista; si són darrere d’una LAN corporativa gestionada, és una altra conversa.
Mantingueu oberta la qüestió de la confiança en la xarxa local fins i tot quan el túnel està xifrat. El xifratge respon una pregunta diferent de l’adjacència.
Comprovació 3: en quina capa confieu
Un HTTPS validat correctament aporta la seva pròpia protecció per als registres d’aplicació, i TLS 1.3 autentica aquestes dades d’extrem a extrem. No promet que un atacant no pugui interrompre la connexió TCP subjacent. Per tant, una aplicació pot ser segura de llegir i alhora interrompible, i la interrupció no és el mateix resultat que la revelació. Separeu les dues coses abans de valorar el risc.
Aquesta distinció importa per a l’informe. Converteix una afirmació vaga que la VPN és insegura en una declaració limitada sobre què podria observar o interrompre un atacant adjacent.
Comprovació 4: quina mitigació heu desplegat realment
La divulgació tracta mitigacions d’encaminament i filtratge i és explícita sobre els seus límits, inclòs el filtratge de ruta inversa i les rutes asimètriques. No enganxeu un valor sysctl a cada amfitrió VPN i digueu que està resolt. El filtratge de ruta inversa interactua amb l’encaminament, així que un valor que ajuda una topologia en pot trencar una altra.
La verificació és una ordre, no una casella. sysctl net.ipv4.conf.all.rp_filter mostra el valor global, i sysctl net.ipv4.conf.tun0.rp_filter mostra el valor per interfície que realment s’aplica. Llegiu tots dos abans i després de qualsevol canvi.
Feu servir les indicacions de la distribució i el vostre propi disseny d’encaminament, i després confirmeu el paràmetre a la interfície que porta el túnel, no en un fitxer que ningú no ha carregat.
Què cal anotar
Anoteu la suposició de l’atacant adjacent, el paquet del nucli en execució, la fila de l’avís que heu fet coincidir, la mitigació desplegada i on s’aplica, i les proteccions d’aplicació presents. Afegiu la data en què vau revisar l’avís, perquè aquestes pàgines canvien. Aquesta combinació és una avaluació defensable.
Una data de publicació del sistema operatiu i una connexió VPN que funciona no són una avaluació. Són dos fets que casualment són fàcils de recollir.