Кои проверяващи компоненти засяга допълнителен коренов сертификат?

Откривате коренов сертификат, който не би трябвало да е там, и първият въпрос е какво може да се представя за него. Честният отговор зависи от това кой софтуер се обръща към това хранилище и как вашият 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 има опция за отпечатък на партньора, която извършва това сравнение за тунела, без системното хранилище да приема подписващия. Тази независимост е полезна за тунела и не казва нищо за браузъра. Тя също не помага, ако очакваният отпечатък е бил копиран от подозрителната връзка още в началото.

Определете обхвата на инцидента отвъд сертификата

Използвайте процедурата на собственика на устройството, за да премахнете неразрешени котви и да потърсите промените, които обикновено ги придружават: нови услуги, модифицирани клиенти, променени настройки на прокси. На управлявана машина потвърдете законната конфигурация, преди да изтриете материал, от който зависи друг софтуер. За всеки проверяващ компонент запишете откъде идва доверието му, каква самоличност очаква и как сте потвърдили, че текущата конфигурация е правилна. Работещ тунел след почистването е едно наблюдение, а не доказателство, че крайната точка е чиста.

След това тествайте отново работните процеси, които са използвали хранилището, защото премахването на котва може да счупи вътрешна услуга, която законно е разчитала на нея. Възстановяването е завършено, когато очакваните отношения на доверие работят, а неочакваните — не.