На якія правяральнікі ўплывае лішні каранёвы сертыфікат?
Шкодны корань, налада прыватнага CA у VPN і замацаваны адбітак трапляюць у розныя правяральнікі. Складзіце карту кожнага, перш чым лічыць працоўны тунель чыстым.
Вы знаходзіце каранёвы сертыфікат, якога там быць не павінна, і першае пытанне — чыю асобу ён можа падмяніць. Сумленны адказ залежыць ад таго, якая праграма звяртаецца да гэтага сховішча і як ваш VPN правярае свой шлюз. Браўзер, менеджар пакетаў і кліент VPN з замацаваным адбіткам не абавязкова падзяляюць адно рашэнне аб даверы. Складзіце карту правяральнікаў, перш чым вызначаць абсяг.
Корань у сістэмным сховішчы — не ўніверсальны ключ
Усталяванне караня робіць сертыфікаты, падпісаныя гэтым ключом, прымальнымі для праграм, якія выкарыстоўваюць закранутае сховішча. Яно не робіць іх аўтаматычна прымальнымі ўсюды, бо некаторыя праграмы пастаўляюцца з уласным наборам або правяраюць замацаванае значэнне. Яно таксама не даказвае, што хтосьці выканаў код на машыне; змена даверу — адна магчымасць сярод некалькіх. Разглядайце сертыфікат як знойдзены факт, які трэба абмежаваць, а не як усю інцыдэнтную падзею.
Сховішча важнае не менш за сертыфікат: набор узроўню карыстальніка і якар сістэмнага ўзроўню дасягаюць розных спажыўцоў.
Складзіце карту кожнага правяральніка і крыніцы яго даверу
Запішыце кожны кампанент, які правярае сертыфікаты для закранутых працэсаў: браўзер, менеджар пакетаў, паштовы кліент, VPN. Затым знайдзіце крыніцу даверу, якую чытае кожны з іх.
ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"Спіс каталога паказвае якары, дададзеныя лакальна ў сістэмах тыпу Debian, а спіс даверу паказвае, што сістэмнае сховішча зараз прадстаўляе. Браўзер з уласным сховішчам там не з'явіцца, а праграма на Java або Python можа выкарыстоўваць яшчэ адзін набор. Запішыце, якія запісы чакаюцца, а якія не, абапіраючыся на адбітак, а не толькі на адлюстраванае імя. Гэты спіс патрэбны спецыялісту па інцыдэнтах, перш чым нешта выдаляць.
Праверце ўласную праверку партнёра ў VPN
VPN з прыватным CA або відавочным адбіткам ацэньвае шлюз паводле ўласнай канфігурацыі. Параўнайце тое, што чакае кліент, з тым, што прадстаўляе шлюз.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subjectВывад дае адбітак SHA-256 і суб'ект сертыфіката, які прадстаўляе канчатковы пункт, і іх можна параўнаць з наладжаным значэннем. OpenVPN мае опцыю адбітка партнёра, якая выконвае гэта параўнанне для тунеля, не патрабуючы, каб сістэмнае сховішча прымала подпісвальніка. Гэтая незалежнасць карысная для тунеля і нічога не кажа пра браўзер. Яна таксама не дапаможа, калі чаканы адбітак быў скапіраваны з падазронага злучэння з самага пачатку.
Абмяжуйце інцыдэнт за межамі сертыфіката
Выкарыстоўвайце працэс уладальніка прылады, каб выдаліць несанкцыянаваныя якары і знайсці змены, якія звычайна іх суправаджаюць: новыя службы, змененыя кліенты, змененыя налады проксі. На кіраванай машыне пацвердзіце законную канфігурацыю, перш чым выдаляць матэрыял, ад якога залежыць іншае праграмнае забеспячэнне. Для кожнага правяральніка запішыце, адкуль паходзіць яго давер, якую асобу ён чакае і як вы пацвердзілі, што бягучая канфігурацыя правільная. Працоўны тунель пасля ачысткі — гэта адно назіранне, а не доказ таго, што канчатковы пункт чысты.
Затым паўторна праверце працэсы, якія выкарыстоўвалі сховішча, бо выдаленне якара можа зламаць унутраную службу, якая законна на яго спадзявалася. Аднаўленне завершана, калі чаканыя адносіны даверу працуюць, а нечаканыя — не.