침해된 호스트에서 킬 스위치가 무엇을 보호하는지 시험하는 방법

킬 스위치를 켜고 터널 서버를 오프라인으로 만든 뒤 기계가 여전히 무엇을 하는지 보십시오. 이 시험은, 방화벽이 실제로 강제하는 것과 여러분이 가정한 것을 분리해 주고 결과가 대부분의 제품 페이지가 암시하는 것보다 좁기 때문에, 실행할 가치가 있습니다. 킬 스위치는 네트워크 경로를 지배하며, 기기에 이미 실행 중인 소프트웨어를 지배하지는 않습니다. 저는 클라이언트가 fail-closed라고 주장하는 모든 기계에서 이 순서를 실행하며, 약 십 분이 걸립니다.

서버가 아니라 클라이언트에서 시작하십시오

강제 지점은 여러분이 앉아 있는 호스트, 곧 운영체제 방화벽, 보조 서비스, 또는 VPN 클라이언트 자체의 드라이버입니다. 이것이 중요한 이유는 스위치가 할 수 있는 모든 것이 그 계층이 보는 것으로 제한되기 때문입니다. 클라이언트가 라우팅 규칙과 표식으로 차단을 구현하면 충분한 권한을 가진 무엇이든 자기 규칙을 추가할 수 있고, 커널 방화벽 표를 사용하면 같은 권한으로 표를 편집할 수 있습니다. 암호의 강도는 이 질문에 전혀 들어오지 않습니다.

따라서 먼저 정해야 할 것은 이 기기의 정책을 누가 소유하며 무엇을 덮어쓸 수 있는가입니다. 관리되는 업무 기계에서 답은 대개 조직의 엔드포인트 에이전트이며, 개인 VPN은 터널이 어떻게 구성되어 있든 그 능력을 없애지 않습니다.

첫 단계: 보호한다고 생각하는 경로에서 차단을 확인하십시오

클라이언트가 아니라 먼 쪽 끝에서 터널을 내리십시오. 그러면 클라이언트는 여전히 연결되어 있어야 한다고 믿고, 다음으로 사람이 실제로 시도할 것을 시도합니다:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

원하는 것은 빠르고 깔끔하게 실패하는 클라이언트이며, 브라우저 시간 초과까지 매달리는 클라이언트가 아닙니다. 매달림은 보통 거부 없는 규칙이 패킷을 조용히 버린다는 뜻이며 그것은 받아들일 수 있지만, 클라이언트가 죽은 인터페이스를 향한 낡은 기본 경로를 남겼다는 뜻일 수도 있습니다. 터널이 내려간 동안 라우팅 표를 읽고, 터널 장치를 가리키는 기본 경로와 새 아웃바운드 연결만 막는 방화벽 규칙이 서로 다른 상태이며 그중 하나만 fail-closed임을 확인하십시오.

클라이언트의 allow-LAN 옵션을 켜고 끈 상태로 같은 명령을 반복하십시오. 그 토글이 대부분의 놀라움이 사는 곳이며, 정책의 나머지가 닫으려고 쓰인 경로를 다시 엽니다.

둘째 단계: DNS와 IPv6를 별도 경로로 확인하십시오

이름 확인은 질의가 시스템 리졸버가 아닌 다른 것으로 나갈 수 있기 때문에 대부분의 구현에서 살아남는 틈입니다. 리졸버 구성을 무시하는 도구로 질의하고, 그 자리에서 v6 쪽도 확인하십시오:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

터널이 내려간 상태에서 두 이름 질의 모두 빈 응답이 나오는 것이 원하는 결과입니다. 두 번째 질의가 응답하면 하드코딩된 리졸버 주소에 도달할 수 있고 터널이 기계에서 나가는 유일한 경로가 아닙니다. v6 요청만 성공하면 정책이 IPv4를 덮고 IPv6를 무시하는 것이며, 다른 주소 체계에서 같은 누출입니다.

브라우저는 이것을 밖에서 읽기 어렵게 만듭니다. DNS over HTTPS로 설정된 브라우저는 HTTPS 요청으로 질의를 해결하므로, 질의는 그 끝점으로 가는 443 포트가 막힌 만큼만 막히고, 정책이 로컬 서브넷을 허용하는 호스트에서는 그 요청이 여전히 LAN의 리졸버에 닿을 수 있습니다.

셋째 단계: 네트워크 노출과 엔드포인트 노출을 분리하십시오

이제 어떤 방화벽 규칙도 닿지 않는 부분입니다. 킬 스위치는 기계 밖으로 나가는 경로를 막지만, 기계의 소프트웨어가 암호화 전에 데이터를 읽는 것을 막지 않고 그 소프트웨어가 터널을 정당하게 쓰는 것도 막지 않습니다. 키로거, 악성 확장, 잠그지 않은 화면, 넓은 권한의 동기화 클라이언트 모두 스위치가 기꺼이 허용하는 연결로 정보를 옮깁니다.

고용주가 일부러 설치한 모니터링 소프트웨어에도 같은 말이 적용됩니다. 경로를 막아도 그것은 사라지지 않고, 노출이 터널보다 앞에 있기 때문에 새 VPN 서버를 사는 것도 수리가 아닙니다.

클라우드 계정으로 업로드하는 클립보드 관리자는 이 점을 날카롭게 보여 줍니다. 트래픽은 암호화되고 목적지는 허용되며, 킬 스위치는 내내 건강한 상태를 보고합니다.

넷째 단계: 시험이 뒷받침하는 주장을 쓰십시오

차단 시험 후에는 어떤 앱이 실패했고, 어떤 경로가 멈췄고, DNS와 IPv6가 어떻게 행동했으며, 터널이 떨어질 때 차단이 버텼는지 하는 구체적인 사실을 말할 수 있습니다. 운영체제가 깨끗하다고 말할 수는 없고, 먼 쪽 끝의 서비스가 로그인을 비공개로 지켜 준다고 말할 수도 없습니다.

두 문제를 분리하고 각각에 고유한 통제를 주십시오:

• 킬 스위치: 정의된 실패 요건이며, 클라이언트 업그레이드마다 반복하는 차단 시험으로 검증합니다.
• 기기 신뢰: 지원되는 업데이트, 신뢰할 수 있는 출처의 엔드포인트 보호, 설명되지 않는 권한과 인증 요청의 검토.
• 사건: 침해가 의심되면 플랫폼이나 조직의 절차를 따르며, 새 서버는 정리 단계가 아닙니다.
• 공개: 도움을 요청할 때는 로그와 화면 캡처가 연결과 같은 비밀을 담고 있으므로 개인 키나 전체 진단 아카이브를 붙이지 마십시오.

다음 업데이트 후에 순서를 다시 실행하십시오. 킬 스위치는 버전과 함께 움직이는 구성이고, 시험만이 여러분이 의존하는 동작이 여전히 얻는 동작임을 보여 주는 유일한 증거이기 때문입니다.