전직 Tailscale 직원이고, 지금은 한 조직에서 Tailscale을 관리하고 있음. 취약점과 GitHub에 반영 중인 수정 사항을 직접 검토해 보니, Tailscale SSH로 일반 계정 접속은 허용하되 sudo나 root 권한은 주지 않는 구성에 영향을 주는 것으로 보임. OpenSSH로 접속하는 경우와는 구분해야 함.
취약한 노드에 SSH 접근 권한이나 연결 경로가 없는 사용자에게 새로 접근 권한을 주는 취약점은 아님. 반면 취약한 tailscaled에서 일반 계정으로 SSH 접속을 허용했다면, 해당 계정의 권한을 넘어서는 권한 상승이 가능하므로 영향을 받음. 심각성을 축소하려는 건 아니지만, 누구나 공격할 수 있는 원격 코드 실행 취약점은 아님.
Tailscale 사용자 상당수는 소프트웨어 개발 전문가일 테고, SSH 접속만을 위해 사용하는 경우도 많을 것임. SSH가 곧 서버 제어로 이어진다는 점에서 영향은 여전히 크다고 봄.
tailworm이라는 이름은 발견 내용을 더 홍보하려고 불안감을 부추기는 느낌임. 웜처럼 동작하려면 tailnet 내부 장비가 특정 설정을 갖추고, 같은 설정의 다른 tailnet에도 속해 있어야 하며, 그쪽에서도 다시 조건에 맞는 다른 tailnet으로 연결되어야 함. 현실성이 떨어져 보임.
여러 기기를 NAS에 백업하면서, 각자 자기 디렉터리만 볼 수 있는 제한된 백업 계정을 사용함. 토렌트용 컴퓨터가 NAS의 root 권한을 얻는 건 당연히 원치 않음. 나는 OpenSSH를 쓰지만, 다른 사람은 Tailscale SSH를 쓸 수 있음.
Linux에 기본으로 들어 있는 OpenSSH를 계속 사용한 게 다행이라고 느낌. 수십 년간 공유기 포트 포워딩으로 원격 접속을 유지했고, 2008년에는 할머니가 입원한 병원의 제한된 Wi-Fi에서 접속하려고 SSH를 80번 포트로 열기도 했음.
OpenVPN과 Cloudflare 터널도 써 봤지만, 결국 접속 대상은 늘 키 인증만 허용하도록 보안을 강화한 OpenSSH임.
명시적으로 SSH 접속을 허용한 사용자가 해당 계정의 권한을 넘어설 수 있는 버그로 이해함. 혼자 SSH를 쓰거나, sudo 권한이 있는 사용자에게만 키를 주거나, 악용하지 않을 사람만 허용하거나, 이미 다른 취약점으로 로컬 사용자의 권한 상승이 가능하거나, Tailscale을 포트 포워딩에만 쓴다면 영향이 없다고 봄. 인터넷에 공개한 OpenSSH보다 노출이 적다고도 볼 수 있지만, 공개 운영 자체에 반대하는 건 아님.
요즘은 80·53·443번 포트의 SSH 트래픽도 바로 탐지됨. 443번 포트가 열려 있더라도, 그 위에서 SSH를 돌리면 HTTPS가 아니라는 사실을 감추기 어려움.
OpenSSH의 공격 표면과 Damien에 대한 신뢰가 내 기준에도 더 잘 맞음.
Tailscale에 서비스 인증까지 맡기는 건 좋지 않아 보임. 기존 인프라와 서비스 위에 추가 보안 계층을 제공하는 역할이어야 함.
VPN과 SSH를 동시에 맡기면 다시 단일 장애점이 생기며, SSH를 인터넷에 직접 노출하는 것과 비슷해짐.
공식적으로는 권장하지 않을지 몰라도, 나는 Tailscale SSH 비활성화를 권함. sshd 기능에 간섭하고 공격 표면을 넓히므로, SSH 키는 기존 방식으로 배포하고 Tailscale SSH는 끄는 편이 좋음.
기능과 코드가 너무 많음. 아마 OpenVPN보다도 코드가 많을 텐데, 이 정도 공격 표면과 기능 규모라면 온갖 제로데이가 있을 것 같음. 많이 사용하는 제품인 만큼, 코드 검토를 해 준다면 차라리 비용을 내고 싶음.
위험한 기능을 차단하는 잠금 모드가 있으면 좋겠음. 필요한 건 연결용 VPN뿐이고 Taildrop, Taildrive, SSH, Funnel, 서비스, DNS, 노드 공유 등은 필요 없음. 관리 콘솔에서 꺼 두어도 코드는 기기에서 실행되고, 실수로 켤 수도 있음.
Taildrop은 인증되지 않은 입력을 허용하고 ACL도 따르지 않는 것으로 아는데, 신뢰도가 낮은 기기의 악성코드가 Synology NAS에 파일을 보내면 썸네일 생성 같은 자동 색인 처리를 거쳐 코드 실행으로 이어질 수 있지 않을까? 왜 ACL을 따르지 않고, 파일이 송신 기기를 떠나기 전에 수신자의 승인을 받지 않는지 궁금함. 태그를 사용하지만 소유자는 태그가 아니라 나 자신임.
Tailscale 초기부터 이를 기반으로 여러 제품을 만든 개인 개발자로서 제품은 좋아하지만, 기능이 너무 많아졌다는 데 동의함. 매출을 위해 기업용 기능이 늘어난 영향도 있을 듯함.
가벼운 버전이 있으면 좋겠지만 지금의 복잡성을 보면 쉽지 않아 보임. Headscale은 훌륭해도 오픈소스 클라이언트에는 여전히 기능이 많음. 다만 클라이언트 소스에 기능별 스위치가 점차 추가되고 있으니, 이를 활용해 경량 버전을 만들 수는 있을 듯함. Rust로 재작성하려는 tailscale-rs도 기능과 플랫폼별 검증 범위가 워낙 넓어 단기간에 준비되기는 어려워 보임.
Tailscale과 인기 있는 대안들은 너무 많은 일을 함. 기본에 충실한 대안이 있을까? 수동 키 교환 없이 WireGuard를 쓰면서, Tailscale처럼 NAT 홀 펀칭을 지원하고 실패하면 내용을 볼 수 없는 중계 서버로 우회하는 정도면 충분함.
Taildrop은 같은 계정의 기기 사이에서만 동작함. 신뢰도가 낮은 기기와 NAS를 같은 계정에 넣지 않으면 위험을 줄일 수 있음.
Tailscale 직원임. 선택 기능을 모두 제외하도록 tailscaled를 다시 빌드할 수 있음. https://github.com/tailscale/tailscale/tree/main/feature#mod...
예를 들어 go run ./cmd/featuretags --min을 실행하면 ts_omit_ssh, ts_omit_taildrop, ts_omit_drive, ts_omit_dns 등 선택 기능을 제외하는 빌드 태그 목록을 얻을 수 있음.
대부분의 AI 기업이 Tailscale을 쓰는 듯해서, 시간이 흐르며 Cloudflare처럼 인터넷의 주요 공격 경로가 되더라도 크게 놀랍지 않을 것 같음.
Tailscale은 유일한 방어선이 아니라 추가 보안 계층으로 쓰는 게 가장 좋음. 나는 Tailscale 뒤에 둔 서비스도 공개 인터넷에 있는 것처럼 인증과 HTTPS 등을 갖춰 운영함.
따라서 Tailscale이 뚫리는 것만으로는 충분하지 않고, 실제 서비스의 취약점까지 찾아야 함. 두 계층이 동시에 뚫릴 가능성은 훨씬 낮음.
발견된 Tailscale SSH 취약점의 “대부분”이 권한 상승과 관련되고, “일부 상황에서” 이미 접속을 허가받은 사용자가 설정된 로컬 계정의 권한을 넘어설 수 있다는 표현이 걸림. 혹시 무단 접속 자체가 가능한 취약점도 조사 중이라는 뜻일까, 아니면 지나친 해석일까?
아직 조사 중이라 잘못된 안도감을 주지 않으려고 신중하게 표현한 것으로 봄. 더 자세한 분석이 나오기 전에는 확대 해석할 필요가 없어 보임.
Tailscale에 뛰어난 개발자가 있고 보안이 복잡하다는 건 알지만, 책임을 피하려는 듯한 모호한 표현이 있음. “일부 상황”이 기본 설정인지, 비밀번호 사용 시인지 구체적이지 않음. 이미 접속을 허가받았더라도 접근 범위는 제한되어 있을 수 있는데, “권한을 넘어서는 작업이 가능할 수도 있다”는 식으로 조건을 겹겹이 붙이면 실제 위험을 이해하기 어려움.
보안 연구자인 동료가 이와 관련한 인증 없는 공격 경로를 조사하고 있었거나 지금도 조사 중임. 새로 들은 소식은 없고, 발견 여부를 확신하기 전에는 Tailscale 직원 외에 정보를 공개하기 어렵다고 했음.
Tailscale은 좋아하지만 홈랩은 기본 WireGuard 구성으로 옮겼음. 부가 기능을 쓰지 않았고, 공유기에서 포트 하나를 열어도 되며 기기를 자주 바꾸지도 않기 때문임. 이런 소식을 보면 복잡성과 공격 표면을 많이 줄인 게 다행이라고 느낌.
WireGuard는 훌륭하지만 배포와 유지보수가 단순하기만 한 건 아님. 공격 표면을 없앴다기보다 직접 책임지게 된 것임.
공개된 정보만 보면 어차피 이 취약점의 영향은 받지 않았을 것으로 보임.
이동 중에는 iOS WireGuard의 DNS 이름 접속이 이상하게 동작함. T-Mobile 같은 IPv6 전용 네트워크에서 A와 AAAA 레코드가 모두 있는 이름에 접속하면 A 레코드를 선호해 464XLAT 프록시를 거치는데, 이 프록시는 일정 시간이 지나면 연결이 만료됨. 이후 휴대전화에서 연결을 다시 활성화하는 동작을 하기 전까지 접속이 죽은 것처럼 보임. Tailscale에서는 이런 현상이 없음.
공유기에 포트를 열지 말고, 집에서 공개 VPS로 연결한 뒤 외부 기기들도 그 VPS에 접속하게 하는 편이 좋음.
요즘 보안에 다들 민감하지만, 첫인상으로는 그렇게 심각해 보이지 않음. 공격자를 tailnet에 직접 추가해야 한다면 악용하기가 쉽지 않을 것임. 오히려 로컬 네트워크의 허술한 IoT 기기들을 더 걱정해야 함. 다만 Tailscale 클라이언트 자동 업데이트는 설정해 두는 게 좋음.