스캐너가 수년간 VPN을 운영해 온 머신에서 CVE-2019-14899를 표시하면, 첫 반응은 VPN이 망가졌다고 말하는 것입니다. 그것은 잘못된 틀입니다. 공개된 문제는 피해자의 로컬 네트워크에 있는 공격자가 특정 TCP 연결에 대해 정보를 추론하는 것이지, 웹사이트가 당신의 터널을 복호화하는 것이 아닙니다.

아래 네 가지 점검을 순서대로 진행하십시오. 각 점검은 문제를 좁히거나 조사를 끝냅니다.

점검 1: 권고가 당신의 커널을 포함하는가

블로그의 릴리스 날짜 요약이 아니라 자신의 배포판 기록을 찾아보십시오. 이 CVE에 대한 Ubuntu 보안 페이지는 18.04 LTS용 일반 linux 패키지를 수정 지연 상태의 취약으로 나열하고, 다른 커널 패키지는 별도 행에서 추적합니다. 실행 중인 릴리스와 커널 패키지를 올바른 행과 맞추십시오. 익숙해 보이는 버전 번호는 일치가 아닙니다.

스캐너 결과는 그 식별자가 당신의 자산 목록에 있는 무언가에 적용된다는 뜻입니다. 옆 기기가 그 머신을 악용했다는 뜻은 아닙니다.

점검 2: 모델에서 공격자는 누구인가

위협 모델은 피해자의 접속 네트워크와 상호작용할 수 있는 인접 공격자를 가정합니다. 그것은 특정 위치이며, 당신의 출구 노드를 싫어하는 임의의 원격 서비스가 아닙니다. 사용자가 카페에서 접속한다면 가정은 현실적이고, 관리되는 기업 LAN 뒤에 있다면 다른 이야기입니다.

터널이 암호화되어 있어도 로컬 네트워크 신뢰 문제는 열어 두십시오. 암호화는 인접성과 다른 질문에 답합니다.

점검 3: 어느 계층에 의존하는가

올바르게 검증된 HTTPS는 애플리케이션 레코드에 자체 보호를 제공하고, TLS 1.3은 그 데이터를 종단 간 인증합니다. 그러나 공격자가 기반 TCP 연결을 방해할 수 없다고 약속하지는 않습니다. 따라서 애플리케이션은 읽기에 안전하면서도 방해받을 수 있고, 방해는 노출과 같은 결과가 아닙니다. 위험을 평가하기 전에 둘을 분리하십시오.

그 구분은 보고서에 중요합니다. VPN이 안전하지 않다는 모호한 주장을 인접 공격자가 무엇을 관찰하거나 방해할 수 있었는지에 대한 제한된 진술로 바꿉니다.

점검 4: 실제로 어떤 완화 조치를 배포했는가

공개 문서는 라우팅과 필터링 완화를 논의하고 그 한계를 명시합니다. 역경로 필터링과 비대칭 경로도 포함됩니다. 하나의 sysctl 값을 모든 VPN 호스트에 붙여 놓고 해결되었다고 말하지 마십시오. 역경로 필터링은 라우팅과 상호작용하므로 한 토폴로지에 도움이 되는 값이 다른 토폴로지를 깨뜨릴 수 있습니다.

점검은 명령이지 체크박스가 아닙니다. sysctl net.ipv4.conf.all.rp_filter는 전역 값을 보여 주고, sysctl net.ipv4.conf.tun0.rp_filter는 실제로 적용되는 인터페이스별 값을 보여 줍니다. 변경 전후에 둘 다 읽으십시오.

배포판 지침과 자신의 라우팅 설계를 사용하고, 터널을 운반하는 인터페이스에서 설정을 확인하십시오. 아무도 읽지 않은 파일이 아닙니다.

무엇을 기록할까

인접 공격자 가정, 실행 중인 커널 패키지, 일치시킨 권고 행, 배포한 완화 조치와 적용 위치, 그리고 존재하는 애플리케이션 보호를 기록하십시오. 권고를 확인한 날짜도 추가하십시오. 그 페이지는 바뀝니다. 그 조합이 방어 가능한 평가입니다.

OS 릴리스 날짜와 작동하는 VPN 연결은 평가가 아닙니다. 우연히 모으기 쉬운 두 가지 사실입니다.

관련 글