Tailworm 패치 전에 Tailscale에서 먼저 바꾼 설정

Tailworm 보고서를 읽고 내가 운영하는 tailnet의 SSH 접근 범위와 키 만료 설정부터 다시 봤다. 패치가 나오기 전에 먼저 할 일은 내부 기기 하나가 닿을 수 있는 범위를 줄이는 것이다. 취약점을 직접 재현한 점검은 아니며, 아래 조치는 패치를 대체하지 않는다.

패치 전에 지금 할 일

먼저 Tailscale SSH의 허용 범위를 줄이고, 만료 없이 남아 있는 노드 키를 확인한다. 두 항목 모두 연구자가 임시 대응으로 권했고, 공식 문서에서 설정 방법을 확인할 수 있다.[1][6][7][8]

SSH 규칙은 어디까지 좁혀야 할까?

접속이 필요한 출발 기기·대상 서버·서버 계정만 남기고, 네트워크 접근 규칙과 정책 파일의 ssh 섹션을 함께 좁혀야 한다. 포트 22를 여는 ACL/grants만 고쳐서는 Tailscale SSH에서 어떤 계정으로 로그인할 수 있는지까지 정리되지 않는다.[6][7]

관리 콘솔의 Access controls에서 현재 정책을 따로 저장해 두고, Tailscale SSH를 켠 서버와 각 서버에 접속해야 하는 관리 기기·사용자를 적는다. 태그 하나가 여러 기기에 붙어 있다면 그 전체가 허용 대상이 되는지 먼저 살핀다.
ACL/grants에서 관리 접속에 필요한 출발지와 대상 서버의 포트 22만 남긴다. 같은 경로를 더 넓게 허용하는 다른 규칙도 함께 정리한다.
ssh 규칙의 src, dst, users를 각각 확인한다. 대상은 필요한 서버에만 부여한 태그 등 공식 문서가 허용하는 선택자로 제한하고, 사용자 전체나 역할 전체를 허용하는 넓은 규칙은 쪼갠다. root와 비밀번호 없는 sudo 권한 계정은 허용 목록에서 빼고, 필요한 일반 계정만 남긴다. autogroup:nonroot도 특정 일반 계정 하나를 뜻하지 않는다.[1][6][7]
정책의 네트워크 테스트와 sshTests로 필요한 접속은 허용되고 불필요한 접속은 거부되는지 확인한다. 별도 관리 접속 수단을 확보한 뒤 저장하고, 실제 허용·거부 결과를 다시 대조한다.[7]

나는 개발 기기에서 운영 서버로 닿는 범위 가운데 업무에 필요한 것보다 넓게 열린 부분부터 정리했다. 운영 서버는 태그로 구분하고, 필요한 관리 사용자와 대상 서버만 남겼다. 정책 테스트로 의도한 허용·거부가 나오는지 확인했고, SSH check mode의 재인증 조건은 접속 범위와 따로 점검했다. check mode는 이미 열린 세션 안의 포워딩을 막는 설정이 아니다.[1][6]

여러 경로를 막고 관리 경로 하나만 허용하는 SSH 규칙 개념 일러스트 — 필요한 관리 경로 하나만 남기고 나머지 SSH 경로는 막는 최소 권한 개념 일러스트(daily-it.com 자체 제작)

꺼 둔 노드 키 만료는 어떻게 다시 켤까?

관리 콘솔 Machines에서 해당 기기의 메뉴를 열어 Enable Key Expiry를 선택하면 된다. 만료가 꺼진 서버, 특히 태그를 붙여 처음 인증해 만료가 기본으로 꺼진 기기부터 확인한다. 연구자는 탈취된 기기 신원이 무기한 유지되지 않도록 노드 키 만료를 켜라고 권했다.[1][8]

Machines에서 대상 서버의 키 만료 상태와 현재 만료 시점을 확인한다. 등록용 auth key의 유효기간이 아니라, 이미 등록된 기기의 노드 키 만료를 보는 단계다.
담당자와 재인증 일정을 정하고 Tailscale 외의 복구 접속 수단을 확보한다. 공식 문서는 만료 시 해당 기기로 오가는 연결이 끊긴다고 설명한다. 서브넷 라우터·exit node는 경로가 남은 채 통신이 막힐 수 있으므로 가용성 구성과 함께 검토한다.[8][9][10]
만료가 꺼져 있는 대상 기기의 행 오른쪽 메뉴에서 Enable Key Expiry를 선택한다. 모든 서버를 한꺼번에 바꾸지 말고 복구할 수 있는 대상부터 진행한다.
기기별 만료 상태를 다시 확인하고 재인증 담당·일정을 운영 기록에 남긴다. 도메인의 만료 기간을 바꿔도 이미 로그인한 기기의 만료 시점이 곧바로 바뀌지는 않는다.[8]

나는 미사용 기기와 키 만료 설정을 점검하면서 접근 권한을 남겨 둘 이유가 분명하지 않은 기기를 확인했다. 이전 점검에서는 불필요한 등록을 정리하고, 남긴 기기의 만료 설정을 살펴봤다. 만료를 새로 켠 기록은 없어서 확인한 범위와 앞으로 적용할 절차를 나눠 적었다.

기기 키가 만료·갱신 관문을 거쳐 서버에 연결되는 개념 일러스트 — 기기 키에 만료·갱신 관문을 두어 신원 사용 기간을 제한하는 개념 일러스트(daily-it.com 자체 제작)

‘포워딩 끄기’는 무엇을 뜻할까?

Tailworm의 SSH 공격 맥락에서 말하는 포워딩은 SSH 세션의 TCP·Unix 소켓 포워딩이다. 서브넷 라우터나 exit node 광고를 해제하거나 운영체제의 IP 포워딩을 끄는 것과는 다르다. 보고서는 Unix 소켓 경로의 공격은 netfilter를 통과하지 않는다고도 설명한다. 그래서 라우팅 기능을 끄는 방법은 이 공격의 대책으로 적지 않았다.[1][9][10]

연구 보고서와 보도는 Tailscale 호스팅 서비스에서는 SSH 규칙별 포워딩을 거부하고, headscale v0.29.5에서는 이를 끌 수 없어 SSH 허용 범위를 더 엄격히 다루라고 권한다.[1][2] 다만 이번에 확인한 공식 SSH·정책 구문 문서에서는 그 포워딩 거부 플래그의 정확한 설정법을 찾지 못했다. 그래서 추측한 JSON 필드나 명령은 실행 절차에 넣지 않았다.[6][7]

이전 점검에서 나는 SSH 포워딩이 업무에 필요한지 살펴보고 필요 없는 허용을 걷어냈다. 이는 서브넷 광고 해제나 IP 포워딩 비활성화와는 다른 작업이다. 보고서는 이와 별도로 Serve에서 특권 Unix 소켓을 대상으로 한 포워드를 정리하고 app connector의 목적지를 제한하라고도 권한다. 이 글의 두 실행 절차와는 다른 항목이다.[1]

보고서의 전제와 배경

10월 23일 Pieter Levels는 VPS 관리 접속은 Tailscale로, 웹 트래픽은 Cloudflare Tunnel로 옮겨 직접 들어오는 포트를 닫자고 권했다.[3] 이틀 뒤 Erica Windisch는 Tailscale v1.104.2와 headscale v0.29.5를 시험한 Tailworm 보고서를 공개했다. 보고서는 SSH뿐 아니라 app connector·Serve·DERP·headscale까지 11개 항목을 다룬다.[1][2]

SSH 공격의 출발점은 이미 장악된 기기 하나다. 그 기기에서 대상 서버로 Tailscale SSH와 포워딩이 허용돼 있다는 것이 전제다. 보고서는 root 권한의 tailscaled가 일반 사용자 세션의 소켓 포워딩을 처리하는 과정과 경로 검사 경쟁 조건을 문제로 지목한다.[1][2]

The Hacker News 보도 시점에는 독립적인 공개 재현이나 실제 웜 확산 사례가 확인되지 않았다. Tailscale은 보고서를 받아 수정 중이라고 밝혔다. 다만 개별 기술 주장을 모두 확인한 상태는 아니었고, 모든 사용자에게 Tailscale SSH를 끄라고 권하지도 않았다.[2]

업데이트와 후속 점검

v1.104.2를 Tailworm 수정판으로 보면 안 된다. 공식 공지 TS-2026-013은 키가 유출된 eMudhra 중간 인증서를 명시적으로 불신하는 조치다. TS-2026-012도 별개의 libtailscale 파일 디스크립터·상대 주소 연결 버그로, 0.2.0에서 수정됐다. 일반 Tailscale 클라이언트나 tailscaled 배포본이 아니라 해당 라이브러리를 내장한 앱의 문제다.[4][5]

10월 26일 확인한 공식 보안 공지 목록에서는 Tailworm에 대응하는 수정 공지를 찾지 못했다.[4] 나는 자동 업데이트 설정과 실행 버전을 함께 대조하는 단계를 점검 절차에 넣었다. 접속 로그도 허용 정책과 맞춰 보고, 낯선 기기와 예상 밖 경로를 살피는 기준을 정리했다.

내가 바꾼 것과 다음 점검

내가 실제로 바꾼 핵심은 운영 서버의 태그 구분과 SSH 접근 범위다. 키 만료는 기존 확인 기록에 더해 재인증·복구 일정을 갖추고 적용할 항목으로 남겼다. 이는 피해 범위를 줄이려는 운영 조치이지 Tailworm 취약점을 해결하거나 공격 차단을 입증한 결과는 아니다. 공개 포트로 되돌리지 않고, 필요한 접속만 남긴 채 공식 수정 공지를 계속 확인할 생각이다.

Cloudflare Tunnel 후기: 포트포워딩 없이 개발 서버를 안전하게 열어보니