Véxolle afectando CVE-2019-14899? Unha lista de comprobación para o kernel

Un escáner marca CVE-2019-14899 nunha máquina que leva anos usando unha VPN, e o primeiro impulso é declarar a VPN rota. É un marco equivocado. O problema divulgado refírese a un atacante na rede local da vítima que infire información sobre certas conexións TCP, non a un sitio web que descifra o seu túnel.

Percorra as catro comprobacións seguintes en orde. Cada unha ou ben acouta o problema ou ben remata a investigación.

Comprobación 1: o aviso cobre o seu kernel

Consulte o rexistro da súa propia distribución, non o resumo da data de publicación dun blog. A páxina de seguridade de Ubuntu para esta CVE enumera o paquete linux xenérico para 18.04 LTS como vulnerable coa corrección aprazada e segue outros paquetes do kernel en filas separadas. Emparelle a súa versión en execución e o seu paquete do kernel coa fila correcta. Un número de versión que parece familiar non é unha coincidencia.

Un achado do escáner significa que o identificador se aplica a algo do seu inventario. Non significa que un dispositivo veciño explotase a máquina.

Comprobación 2: quen é o atacante no modelo

O modelo de ameaza supón un atacante adxacente que pode interactuar coa rede de acceso da vítima. É unha posición concreta, non un servizo remoto calquera ao que non lle gusta o seu nodo de saída. Se os usuarios se conectan desde unha cafetería, a suposición é realista; se están detrás dunha LAN corporativa xestionada, é outra conversa.

Manteña aberta a cuestión da confianza na rede local mesmo cando o túnel está cifrado. O cifrado responde a unha pregunta distinta da adxacencia.

Comprobación 3: en que capa confía

Un HTTPS validado correctamente achega a súa propia protección para os rexistros de aplicación, e TLS 1.3 autentica eses datos de extremo a extremo. Non promete que un atacante non poida interromper a conexión TCP subxacente. Polo tanto, unha aplicación pode ser segura de ler e aínda así interrompible, e a interrupción non é o mesmo resultado que a revelación. Separe ambas antes de valorar o risco.

Esa distinción importa para o informe. Converte unha afirmación vaga de que a VPN é insegura nunha declaración acoutada sobre o que un atacante adxacente podería observar ou interromper.

Comprobación 4: que mitigación despregou realmente

A divulgación trata mitigacións de encamiñamento e filtrado e é explícita sobre os seus límites, incluído o filtrado de ruta inversa e as rutas asimétricas. Non pegue un valor sysctl en cada servidor VPN e diga que está resolto. O filtrado de ruta inversa interactúa co encamiñamento, así que un valor que axuda a unha topoloxía pode romper outra.

A verificación é un comando, non unha caixa. sysctl net.ipv4.conf.all.rp_filter mostra o valor global, e sysctl net.ipv4.conf.tun0.rp_filter mostra o valor por interface que realmente se aplica. Lea ambos antes e despois de calquera cambio.

Use as indicacións da distribución e o seu propio deseño de encamiñamento, e despois confirme o axuste na interface que transporta o túnel, non nun ficheiro que ninguén cargou.

Que anotar

Anote a suposición do atacante adxacente, o paquete do kernel en execución, a fila do aviso coa que coincidiu, a mitigación despregada e onde se aplica, e as proteccións de aplicación existentes. Engada a data en que revisou o aviso, porque esas páxinas cambian. Esa combinación é unha avaliación defendible.

Unha data de publicación do sistema operativo e unha conexión VPN que funciona non son unha avaliación. Son dous feitos que casualmente son fáciles de recoller.