Apektado ka ba ng CVE-2019-14899? Isang checklist para sa kernel

May scanner na nagmamarka ng CVE-2019-14899 sa isang makina na ilang taon nang gumagamit ng VPN, at ang unang reaksyon ay sabihing sira ang VPN. Mali ang balangkas na iyon. Ang isyung isinapubliko ay tungkol sa isang attacker sa lokal na network ng biktima na naghihinuha ng impormasyon tungkol sa ilang koneksyon ng TCP, hindi isang website na nagde-decrypt ng iyong tunnel.

Daanan ang apat na pagsusuri sa ibaba nang sunod-sunod. Bawat isa ay nagpapaliit ng problema o nagtatapos sa imbestigasyon.

Pagsusuri 1: saklaw ba ng abiso ang iyong kernel

Hanapin ang sariling rekord ng iyong distribusyon, hindi ang buod ng isang blog tungkol sa petsa ng release. Ang pahina ng seguridad ng Ubuntu para sa CVE na ito ay naglilista ng generic na linux package para sa 18.04 LTS bilang mahina sa naantalang pagwawasto, at sinusubaybayan ang iba pang kernel package sa magkakahiwalay na hilera. Itugma ang tumatakbong release at kernel package sa tamang hilera. Ang pamilyar na numero ng bersyon ay hindi tugma.

Ang resulta ng scanner ay nangangahulugang ang identifier ay naaangkop sa isang bagay sa iyong imbentaryo. Hindi ito nangangahulugang pinagsamantalahan ng katabing device ang makina.

Pagsusuri 2: sino ang attacker sa modelo

Ipinapalagay ng modelo ng banta ang isang katabing attacker na maaaring makipag-ugnayan sa access network ng biktima. Iyon ay partikular na posisyon, hindi isang arbitraryong malayong serbisyo na hindi gusto ang iyong exit node. Kung ang mga user ay kumokonekta mula sa isang cafe, makatotohanan ang palagay; kung sila ay nasa likod ng pinamamahalaang corporate LAN, ibang usapan iyon.

Iwanang bukas ang tanong tungkol sa tiwala sa lokal na network kahit naka-encrypt ang tunnel. Ang encryption ay sumasagot sa ibang tanong kaysa sa pagiging katabi.

Pagsusuri 3: aling layer ang pinagkakatiwalaan mo

Ang wastong na-validate na HTTPS ay nagbibigay ng sarili nitong proteksyon para sa mga rekord ng application, at ang TLS 1.3 ay nagpapatunay ng datos na iyon mula sa dulo hanggang sa dulo. Ngunit hindi nito ipinapangako na hindi kayang putulin ng attacker ang pinagbabatayang koneksyon ng TCP. Kaya ang isang application ay maaaring ligtas basahin at mapuputol pa rin, at ang pagputol ay hindi kaparehong resulta ng pagsisiwalat. Paghiwalayin ang dalawa bago suriin ang panganib.

Mahalaga ang pagkakaibang iyon sa ulat. Ginagawa nitong limitadong pahayag ang malabong pag-aangkin na hindi secure ang VPN tungkol sa maaaring maobserbahan o maputol ng katabing attacker.

Pagsusuri 4: anong mitigation ang aktwal mong inilagay

Tinalakay ng pagsisiwalat ang mga mitigation sa routing at filtering at malinaw ito sa kanilang mga limitasyon, kabilang ang reverse-path filtering at asymmetric na ruta. Huwag idikit ang isang halaga ng sysctl sa bawat VPN host at sabihing naayos na. Ang reverse-path filtering ay nakikipag-ugnayan sa routing, kaya ang halagang tumutulong sa isang topology ay maaaring makasira ng isa pa.

Ang pagsusuri ay isang utos, hindi isang checkbox. Ipinapakita ng sysctl net.ipv4.conf.all.rp_filter ang pandaigdigang halaga, at ipinapakita ng sysctl net.ipv4.conf.tun0.rp_filter ang halaga sa bawat interface na aktwal na nalalapat. Basahin ang dalawa bago at pagkatapos ng anumang pagbabago.

Gamitin ang gabay ng distribusyon at ang sarili mong disenyo ng routing, pagkatapos ay kumpirmahin ang setting sa interface na nagdadala ng tunnel, hindi sa file na walang nag-load.

Ano ang dapat itala

Itala ang palagay tungkol sa katabing attacker, ang tumatakbong kernel package, ang hilera ng abisong itinugma, ang inilagay na mitigation at kung saan ito nalalapat, at ang mga umiiral na proteksyon ng application. Idagdag ang petsa nang sinuri mo ang abiso, dahil nagbabago ang mga pahinang iyon. Ang kombinasyong iyon ay isang maipagtatanggol na pagtatasa.

Ang petsa ng release ng OS at gumaganang koneksyon ng VPN ay hindi pagtatasa. Ito ay dalawang katotohanang nagkataong madaling kolektahin.