추가 루트 인증서는 어떤 검증기에 영향을 주는가?

있어서는 안 될 루트 인증서를 발견하면 첫 질문은 그것이 누구의 신원을 사칭할 수 있는가입니다. 정직한 답은 어떤 소프트웨어가 그 저장소를 참조하는지, 그리고 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의 피어 지문 옵션은 시스템 저장소가 서명자를 받아들일 것을 요구하지 않고 터널에 대해 그 비교를 수행합니다. 이 독립성은 터널에는 유용하지만 브라우저에 대해서는 아무것도 말하지 않습니다. 기대한 지문이 처음부터 의심스러운 연결에서 복사된 경우에는 도움이 되지도 않습니다.

인증서 너머로 사건의 범위를 정하십시오

기기 소유자의 절차에 따라 승인되지 않은 앵커를 제거하고 보통 그와 함께 오는 변경을 찾으십시오. 새 서비스, 수정된 클라이언트, 변경된 프록시 설정입니다. 관리되는 기기에서는 다른 소프트웨어가 의존하는 자료를 삭제하기 전에 정당한 구성을 확인하십시오. 검증기마다 신뢰가 어디서 오는지, 어떤 신원을 기대하는지, 현재 구성이 올바르다고 어떻게 확인했는지 기록하십시오. 정리 후 작동하는 터널은 하나의 관찰이며, 엔드포인트가 깨끗하다는 증거가 아닙니다.

그다음 저장소를 사용한 워크플로를 다시 테스트하십시오. 앵커를 제거하면 그것에 정당하게 의존하던 내부 서비스가 깨질 수 있기 때문입니다. 기대한 신뢰 관계가 작동하고 예상하지 못한 관계가 작동하지 않을 때 복구가 완료됩니다.