Sunteți afectat de CVE-2019-14899? O listă de verificare pentru nucleu

Un scanner semnalează CVE-2019-14899 pe o mașină care folosește un VPN de ani de zile, iar primul instinct este să declarăm VPN-ul stricat. Acesta este cadrul greșit. Problema divulgată privește un atacator din rețeaua locală a victimei care deduce informații despre anumite conexiuni TCP, nu un site web care vă decriptează tunelul.

Parcurgeți cele patru verificări de mai jos în ordine. Fiecare fie restrânge problema, fie încheie investigația.

Verificarea 1: avizul acoperă nucleul dumneavoastră

Căutați înregistrarea propriei distribuții, nu rezumatul unui blog despre o dată de lansare. Pagina de securitate Ubuntu pentru acest CVE listează pachetul linux generic pentru 18.04 LTS ca vulnerabil cu corectarea amânată și urmărește alte pachete de nucleu pe rânduri separate. Potriviți versiunea care rulează și pachetul de nucleu cu rândul corect. Un număr de versiune care pare familiar nu este o potrivire.

Un rezultat al scannerului înseamnă că identificatorul se aplică unui lucru din inventarul dumneavoastră. Nu înseamnă că un dispozitiv vecin a exploatat mașina.

Verificarea 2: cine este atacatorul în model

Modelul de amenințare presupune un atacator adiacent care poate interacționa cu rețeaua de acces a victimei. Aceasta este o poziție concretă, nu un serviciu la distanță oarecare căruia nu-i place nodul dumneavoastră de ieșire. Dacă utilizatorii se conectează dintr-o cafenea, presupunerea este realistă; dacă stau în spatele unei rețele locale corporative administrate, este altă discuție.

Lăsați deschisă întrebarea despre încrederea în rețeaua locală chiar și atunci când tunelul este criptat. Criptarea răspunde la o altă întrebare decât adiacența.

Verificarea 3: pe ce strat vă bazați

Un HTTPS validat corect oferă propria protecție pentru înregistrările aplicației, iar TLS 1.3 autentifică aceste date de la un capăt la altul. Însă nu promite că un atacator nu poate întrerupe conexiunea TCP de dedesubt. O aplicație poate fi deci sigură de citit și totuși întreruptibilă, iar întreruperea nu este același rezultat ca divulgarea. Separați cele două înainte de a evalua riscul.

Această distincție contează pentru raport. Transformă o afirmație vagă că VPN-ul este nesigur într-o declarație limitată despre ce ar putea observa sau întrerupe un atacator adiacent.

Verificarea 4: ce atenuare ați implementat de fapt

Divulgarea discută atenuări de rutare și filtrare și este explicită cu privire la limitele lor, inclusiv filtrarea căii inverse și rutele asimetrice. Nu lipiți o singură valoare sysctl pe fiecare gazdă VPN și nu spuneți că este rezolvat. Filtrarea căii inverse interacționează cu rutarea, așa că o valoare care ajută o topologie poate strica alta.

Verificarea este o comandă, nu o casetă de bifare. sysctl net.ipv4.conf.all.rp_filter arată valoarea globală, iar sysctl net.ipv4.conf.tun0.rp_filter arată valoarea pe interfață care se aplică efectiv. Citiți ambele înainte și după orice modificare.

Folosiți îndrumările distribuției și propriul design de rutare, apoi confirmați setarea pe interfața care transportă tunelul, nu într-un fișier pe care nimeni nu l-a încărcat.

Ce să notați

Notați presupunerea despre atacatorul adiacent, pachetul de nucleu care rulează, rândul din aviz pe care l-ați potrivit, atenuarea implementată și unde se aplică, precum și protecțiile de aplicație existente. Adăugați data la care ați verificat avizul, pentru că acele pagini se schimbă. Această combinație este o evaluare defendabilă.

O dată de lansare a sistemului de operare și o conexiune VPN funcțională nu sunt o evaluare. Sunt două fapte care, întâmplător, sunt ușor de colectat.