뒤로

2026/10/27

Tailworm 대응: 운영 환경을 멈추지 않고 Tailscale 네트워크를 강화한 방법

Tailworm 발견 사항을 기준으로 자사 Tailscale 네트워크를 점검하고, Tailscale SSH 노출을 제거하면서 모든 운영 작업을 계속 실행한 과정을 소개합니다.

요약

2026년 10월 25일, 한 보안 연구자가 “Tailworm”을 공개했습니다. Tailscale과 headscale에 대한 11건의 발견 사항으로, 조율된 공개(coordinated disclosure) 절차 없이 발표되었습니다. 이 글을 쓰는 시점까지 Tailscale은 수정 사항을 내놓지 않았습니다. 저희는 같은 날 저녁, 자사 Tailscale 네트워크를 각 발견 사항에 비추어 점검했습니다. 해당되는 노출 한 가지를 제거하고 접근 권한을 강화했으며, 그동안 모든 운영 작업은 계속 실행되었습니다.

이 글에서는 무엇을 확인했고, 무엇을 바꿨으며, 어떻게 장애를 피했는지, 그리고 무엇을 배웠는지 정리합니다. 이 글은 보고서 내용을 독립적으로 검증한 것이 아닙니다.

Tailworm이 보고한 내용 요약

11건의 발견 사항은 몇 가지 그룹으로 나눌 수 있습니다.

  • Tailscale SSH(가장 심각). 허가된 SSH 세션에서 대상 머신의 root 권한으로 상승할 수 있습니다. 연구자의 실험 환경에서는 이후 머신에서 머신으로 확산되었습니다.
  • App connectors. 목적지(destination)가 검증되지 않습니다.
  • 메모리 고갈. 컨트롤 서버와 클라이언트 양쪽에서 발생합니다.
  • Serve 및 Funnel의 엣지 케이스.

모든 발견 사항은 공격자가 이미 발판을 확보하고 있어야 성립합니다. 인터넷에서 바로 가능한 원격 공격은 없습니다. 일부 보안 전문가는 위험이 과장되었다고 보지만, 주요 노출 지점인 Tailscale SSH는 실제 문제이며 제거하기도 쉽습니다.

1단계: 바꾸기 전에 확인하기

먼저 읽기 전용 점검부터 시작했고, 무엇이든 건드리기 전에 결과를 기록했습니다.

  • 사용 중인 Tailscale 클라이언트 버전
  • 실제로 켜져 있는 기능
  • 60일간의 SSH 세션 로그: 누가 어디서 접속했는지, 포트나 소켓 포워딩을 사용했는지
  • 몇 달 동안 접속 기록이 없는 기기를 포함한 기기 목록

점검 결과:

  • 환경 일부에서 Tailscale SSH가 활성화되어 있었기 때문에 발견 사항 F1–F3과 F5가 저희에게 해당되었습니다.
  • 나머지 발견 사항이 전제로 하는 기능은 사용하지 않았기 때문에 대부분은 해당되지 않았습니다.
  • SSH 로그에는 예상치 못한 접속 출처나 포워딩 요청이 없었습니다.

2단계: 장애 없이 노출 제거하기

가장 간단한 해결책은 Tailscale SSH를 끄고 표준 OpenSSH 키 인증을 사용하는 것이었습니다. 그런데 사전 점검에서 함정이 발견되었습니다.

Tailscale SSH는 SSH 키가 아니라 tailnet 신원으로 인증합니다. 자동화 스크립트는 명령줄에서 SSH 키를 지정했지만, 그 키는 암호문(passphrase)으로 보호되어 있어 무인 실행에서는 처음부터 작동할 수 없었습니다. 작업이 실행된 것은 Tailscale SSH가 키를 전혀 확인하지 않았기 때문입니다. Tailscale SSH를 그냥 껐다면 모든 자동화 작업이 멈췄을 것입니다.

그래서 다음 순서로 전환했습니다.

  1. 자동화 전용 키를 만들었습니다. 접속 출처를 한 대의 머신으로 제한하고 포워딩을 비활성화했습니다.
  2. 전환 전에 새 경로를 테스트했습니다. tailnet 내부에서만 접근 가능한 임시 OpenSSH 포트를 열고, 작업이 실행되는 것과 같은 환경(SSH 에이전트 없음, 터미널 없음)에서 스크립트가 SSH를 호출하는 모든 방식으로 접속해 보았습니다.
  3. 부정 테스트를 실행했습니다. 허용된 출처 밖에서는 새 키가 거부되고, 포워딩 요청도 거부되는 것을 확인했습니다.
  4. 자동 롤백을 먼저 준비했습니다. Tailscale SSH를 끄기 전에 이를 자동으로 다시 켜는 타이머를 예약했습니다. 이 복구 경로는 SSH 작동 여부에 의존하지 않았습니다.
  5. 전환한 뒤 모든 자동화 작업을 새 연결로 확인했습니다. 각 작업이 실제 실행을 한 번씩 완료했습니다. 이미 열려 있던 세션은 증거로 인정하지 않았습니다.
  6. 임시 구성 요소를 제거했습니다. 추가 포트, 방화벽 규칙, 롤백 타이머를 제거한 뒤 한 번 더 검증했습니다.

3단계: 남은 부분 강화하기

  • Tailscale SSH 정책을 비웠습니다. 기본 정책은 사용자가 자신의 어떤 기기에서든 자신의 다른 기기로 root를 포함해 SSH 세션을 열 수 있게 했고, 필요한 것은 주 1회 브라우저 재승인뿐이었습니다. 정책을 비웠기 때문에 실수로 Tailscale SSH를 다시 켜더라도 더 이상 접근이 허용되지 않습니다.
  • 인터넷에서의 SSH 접근을 차단했습니다. 차단하기 전에 대역 외(out-of-band) 콘솔 로그인이 가능한지 확인해 스스로 갇히는 일이 없도록 했습니다. 차단 후에는 외부 네트워크에서 SSH가 더 이상 응답하지 않는 것을 확인했습니다.
  • 기기 승인을 필수로 설정했습니다. 새 기기는 관리자의 승인을 받아야 참여할 수 있습니다.
  • 등록 키를 점검했습니다. 폐기할 키는 없었습니다.
  • 관리자 계정에 MFA가 적용되어 있는지 확인했습니다. 관리자 로그인을 탈취한 사람은 누구든 네트워크 수준의 통제를 되돌릴 수 있기 때문입니다.
  • 기기 간 실제 트래픽 관찰을 시작했습니다. 다음 단계인 어떤 기기가 어떤 서비스와 통신할 수 있는지 좁히는 작업을 추측이 아닌 근거에 기반해 진행하기 위해서입니다.

Tailnet Lock과 기기 승인은 모두 허가되지 않은 기기의 참여를 막아 주지만 함께 사용할 수는 없으므로, 의도적으로 하나를 선택하십시오.

4단계: 서버만이 아니라 런북도 고치기

기존 복구 절차에는 Tailscale SSH를 켠 상태로 서버를 다시 연결하라고 되어 있었습니다. 이번 변경 후에 그 절차를 따랐다면 위험한 기능이 조용히 되살아났을 것입니다. 그래서 절차를 다시 작성했습니다.

  • 먼저 진단합니다. 네트워크 연결이 끊긴 것인지, SSH 자체(키, 구성, 방화벽)의 문제인지 확인합니다. 두 경우는 해결 방법이 다릅니다.
  • 설정을 바꾸지 않고 다시 연결합니다. 추가 플래그를 사용하지 않고, 다시 연결하기 전에 노드 설정을 저장한 뒤 연결 후에 비교합니다.
  • 긴급 접근은 타이머를 걸고서만 엽니다. 먼저 승인을 받고, 열기 전에 자동으로 닫히도록 예약하고, 접속 출처를 제한하며, IPv4와 IPv6를 모두 확인합니다.
  • 긴급 상황에서도 Tailscale SSH를 다시 켜지 않습니다. 이를 위해 필요한 접근 정책 변경은 자동으로 롤백할 수 없습니다.

배운 점

  1. 보안 기능을 제거하기 전에 그것이 실제로 무엇을 인증하는지 파악해야 합니다. 스크립트에 지정된 키는 한 번도 사용된 적이 없었습니다.
  2. 옮겨 갈 경로 그대로를 테스트해야 합니다. 작업이 실행되는 것과 같은 환경에서, 전환하기 전에 테스트합니다.
  3. 변경 대상에 의존하지 않는 롤백을 마련해야 합니다. “SSH로 다시 들어가서 고치면 된다”가 아니라 타이머입니다.
  4. 문을 닫기 전에 복구용 접근 경로를 확인해야 합니다. 저희는 인터넷에서의 SSH를 차단하기 전에 콘솔 접근을 확인했습니다.
  5. 런북을 같은 변경에서 함께 갱신해야 합니다. 오래된 복구 단계가 몇 달 뒤 보안 조치를 되돌릴 수 있습니다.
  6. 기본 정책을 읽어 보아야 합니다. “root를 포함해 자신의 기기 간 접속 허용”이 저희가 출발한 기본 설정이었습니다.
  7. “변경이 성공했다”와 “취약점이 해결되었다”를 구분해야 합니다. 저희는 더 이상 Tailscale SSH 관련 발견 사항에 노출되어 있지 않지만, 업스트림 수정이 나오기 전까지 Tailworm 전체는 해결된 것이 아닙니다. 수정이 나오면 클라이언트를 업데이트할 것입니다.
  8. 먼저 측정하고, 그다음 좁혀야 합니다. 관찰된 트래픽과 실제 의존성 목록을 먼저 확보한 뒤 접근 규칙을 강화해야 보안 강화가 업무를 멈추지 않습니다.

다음 계획

관찰된 트래픽을 바탕으로 기기 간 네트워크 접근을 각 서비스에 필요한 최소한으로 좁히고 있습니다. Tailscale의 수정 사항이 공개되면 즉시 설치할 예정입니다.

참고 자료: Tailworm 보고서(tailworm.com) 및 Tailscale의 Tailnet Lock 문서