Ứng phó Tailworm: tăng cường bảo mật mạng Tailscale mà không làm gián đoạn hệ thống production

Cách chúng tôi rà soát mạng Tailscale theo các phát hiện của Tailworm, loại bỏ rủi ro từ Tailscale SSH và giữ mọi tác vụ production hoạt động liên tục.

Tóm tắt

Ngày 25 tháng 10 năm 2026, một nhà nghiên cứu bảo mật đã công bố “Tailworm”: 11 phát hiện liên quan đến Tailscale và headscale, được công bố mà không qua quy trình công bố phối hợp (coordinated disclosure). Tại thời điểm viết bài, Tailscale chưa phát hành bản sửa lỗi. Ngay tối hôm đó, chúng tôi đã đối chiếu mạng Tailscale của mình với từng phát hiện. Chúng tôi loại bỏ điểm phơi nhiễm duy nhất áp dụng với mình, siết chặt quyền truy cập, và giữ mọi tác vụ production chạy liên tục trong suốt quá trình.

Bài viết này trình bày những gì chúng tôi đã kiểm tra, những gì đã thay đổi, cách chúng tôi tránh gián đoạn dịch vụ và những bài học rút ra. Đây không phải là một bản xác minh độc lập đối với báo cáo.

Tóm lược nội dung báo cáo Tailworm

11 phát hiện có thể chia thành một vài nhóm:

• Tailscale SSH (nghiêm trọng nhất). Một phiên SSH đã được cấp quyền có thể leo thang thành root trên máy đích. Trong môi trường thử nghiệm của nhà nghiên cứu, cuộc tấn công sau đó lan từ máy này sang máy khác.
• App connectors. Đích đến (destination) không được kiểm tra hợp lệ.
• Cạn kiệt bộ nhớ, ở cả máy chủ điều khiển và phía client.
• Các trường hợp biên của Serve và Funnel.

Mọi phát hiện đều đòi hỏi kẻ tấn công đã có sẵn chỗ đứng trong hệ thống. Không phát hiện nào là tấn công từ xa trực tiếp qua internet. Một số chuyên gia bảo mật cho rằng cách trình bày đã phóng đại rủi ro, nhưng điểm phơi nhiễm chính là Tailscale SSH thì có thật và dễ loại bỏ.

Bước 1: Kiểm tra trước khi thay đổi

Chúng tôi bắt đầu bằng các bước kiểm tra chỉ đọc và ghi lại kết quả trước khi động vào bất cứ thứ gì:

• các phiên bản Tailscale client đang sử dụng
• những tính năng thực sự đang được bật
• nhật ký phiên SSH trong 60 ngày, để xem ai kết nối từ đâu và có ai dùng chuyển tiếp cổng hoặc socket hay không
• danh sách thiết bị, bao gồm cả những thiết bị đã nhiều tháng không xuất hiện

Kết quả:

• Tailscale SSH đang được bật ở một phần môi trường của chúng tôi, nên các phát hiện F1–F3 và F5 có liên quan.
• Các tính năng mà những phát hiện còn lại phụ thuộc vào đều không được sử dụng, nên phần lớn không áp dụng.
• Nhật ký SSH không cho thấy nguồn kết nối bất thường nào và không có yêu cầu chuyển tiếp nào.

Bước 2: Loại bỏ điểm phơi nhiễm mà không gây gián đoạn

Cách khắc phục hiển nhiên là tắt Tailscale SSH và chuyển sang xác thực bằng khóa OpenSSH tiêu chuẩn. Nhưng bước kiểm tra trước đã phát hiện một cái bẫy.

Tailscale SSH xác thực bằng danh tính tailnet, không phải bằng khóa SSH. Các script tự động hóa của chúng tôi có truyền một khóa SSH trên dòng lệnh, nhưng khóa đó được bảo vệ bằng passphrase và không bao giờ có thể hoạt động khi chạy tự động không người giám sát. Các tác vụ vẫn chạy được chỉ vì Tailscale SSH không hề kiểm tra khóa. Nếu chúng tôi chỉ đơn giản tắt Tailscale SSH, mọi tác vụ tự động sẽ dừng lại.

Vì vậy, chúng tôi chuyển đổi theo thứ tự sau:

1. Tạo một khóa riêng cho tự động hóa, chỉ cho phép từ một máy nguồn duy nhất, và tắt chuyển tiếp.
2. Kiểm thử đường kết nối mới trước khi chuyển đổi. Chúng tôi mở một cổng OpenSSH tạm thời, chỉ truy cập được bên trong tailnet, và kết nối từ một môi trường giống với môi trường chạy tác vụ (không có SSH agent, không có terminal), theo mọi cách mà script của chúng tôi gọi SSH.
3. Chạy kiểm thử phủ định. Khóa mới bị từ chối khi dùng từ ngoài nguồn được phép, và các yêu cầu chuyển tiếp bị từ chối.
4. Thiết lập khôi phục tự động trước. Trước khi tắt Tailscale SSH, chúng tôi đặt một bộ hẹn giờ để tự động bật lại nó. Đường khôi phục này không phụ thuộc vào việc SSH có hoạt động hay không.
5. Chuyển đổi, rồi kiểm tra mọi tác vụ tự động bằng kết nối mới. Mỗi tác vụ đều hoàn thành một lần chạy thực tế. Chúng tôi không coi một phiên đã mở sẵn là bằng chứng.
6. Gỡ bỏ các thành phần tạm thời — cổng bổ sung, quy tắc tường lửa và bộ hẹn giờ khôi phục — rồi xác minh thêm một lần nữa.

Bước 3: Siết chặt phần còn lại

• Làm trống chính sách Tailscale SSH. Chính sách mặc định cho phép bất kỳ thiết bị nào của một người dùng mở phiên SSH tới các thiết bị khác của chính họ, kể cả với quyền root, chỉ cần phê duyệt lại trên trình duyệt mỗi tuần. Chúng tôi đã làm trống chính sách này, nên nếu vô tình bật lại Tailscale SSH thì cũng không còn cấp quyền truy cập.
• Đóng SSH từ internet. Trước khi đóng, chúng tôi xác nhận rằng đăng nhập qua console ngoài băng (out-of-band) hoạt động, để không tự khóa mình ở ngoài. Sau đó, chúng tôi xác minh từ một mạng bên ngoài rằng SSH không còn phản hồi.
• Bắt buộc phê duyệt thiết bị. Thiết bị mới phải được quản trị viên phê duyệt mới có thể tham gia.
• Kiểm tra các khóa đăng ký. Không có khóa nào cần thu hồi.
• Xác nhận MFA trên tài khoản quản trị viên. Bất kỳ ai chiếm được thông tin đăng nhập quản trị đều có thể đảo ngược các biện pháp kiểm soát ở tầng mạng.
• Bắt đầu quan sát lưu lượng thực tế giữa các thiết bị, để bước tiếp theo — thu hẹp thiết bị nào được phép kết nối tới dịch vụ nào — dựa trên bằng chứng chứ không phải phỏng đoán.

Tailnet Lock và phê duyệt thiết bị đều bảo vệ trước việc một thiết bị lạ tham gia mạng, nhưng không thể dùng cùng lúc, vì vậy hãy cân nhắc và chủ động chọn một.

Bước 4: Sửa cả runbook, không chỉ máy chủ

Quy trình khôi phục cũ của chúng tôi yêu cầu kết nối lại máy chủ với Tailscale SSH được bật. Nếu làm theo sau thay đổi này, tính năng rủi ro kia sẽ lặng lẽ quay trở lại. Chúng tôi đã viết lại quy trình:

• Chẩn đoán trước. Kết nối mạng bị mất, hay vấn đề nằm ở chính SSH (khóa, cấu hình, tường lửa)? Hai trường hợp có cách khắc phục khác nhau.
• Kết nối lại mà không thay đổi cài đặt. Không dùng thêm cờ nào, lưu cài đặt của node trước khi kết nối lại và so sánh sau đó.
• Chỉ mở truy cập khẩn cấp kèm bộ hẹn giờ. Xin phê duyệt trước, đặt lịch tự động đóng trước khi mở, giới hạn nguồn và kiểm tra cả IPv4 lẫn IPv6.
• Không bật lại Tailscale SSH, kể cả trong tình huống khẩn cấp. Thay đổi chính sách truy cập mà nó cần không thể được khôi phục tự động.

Bài học rút ra

1. Hãy hiểu một tính năng bảo mật thực sự xác thực cái gì trước khi gỡ bỏ nó. Khóa mà script của chúng tôi chỉ định chưa từng được sử dụng.
2. Kiểm thử chính đường kết nối bạn sắp chuyển sang, trong cùng môi trường mà tác vụ của bạn chạy, trước khi chuyển đổi.
3. Thiết lập cơ chế khôi phục không phụ thuộc vào thứ bạn đang thay đổi. Một bộ hẹn giờ, chứ không phải “rồi mình SSH vào sửa lại”.
4. Kiểm tra đường truy cập khôi phục trước khi đóng một cánh cửa. Chúng tôi đã xác nhận truy cập console trước khi đóng SSH từ internet.
5. Cập nhật runbook trong cùng một lần thay đổi. Một bước khôi phục cũ có thể vô hiệu hóa một bản vá bảo mật nhiều tháng sau đó.
6. Đọc kỹ các chính sách mặc định. “Cho phép các thiết bị của chính bạn, kể cả root” là cấu hình mặc định mà chúng tôi bắt đầu.
7. Tách bạch “thay đổi đã thành công” với “lỗ hổng đã được xử lý”. Chúng tôi không còn bị ảnh hưởng bởi các phát hiện liên quan đến Tailscale SSH, nhưng Tailworm nói chung chưa được khép lại cho đến khi có bản sửa từ upstream. Chúng tôi sẽ cập nhật client khi bản sửa được phát hành.
8. Đo lường trước, thu hẹp sau. Có dữ liệu lưu lượng quan sát được và danh sách phụ thuộc thực tế trước khi siết chặt quy tắc truy cập, để việc tăng cường bảo mật không làm gián đoạn hoạt động kinh doanh.

Bước tiếp theo

Chúng tôi đang thu hẹp quyền truy cập mạng giữa các thiết bị xuống mức tối thiểu mà mỗi dịch vụ cần, dựa trên lưu lượng quan sát được. Chúng tôi sẽ cài đặt các bản sửa lỗi của Tailscale ngay khi chúng được phát hành.

Tài liệu tham khảo: báo cáo Tailworm (tailworm.com) và tài liệu của Tailscale về Tailnet Lock.