Giới hạn bảo mật của Cloudflare Tunnel đối với dịch vụ tự lưu trữ

Vào ngày 12 tháng 10 năm 2026, Jeremy từ Noted đã công bố một bài phân tích về bảo mật của Cloudflare Tunnel dành cho các phòng thí nghiệm tại nhà (home lab) và môi trường tự lưu trữ. Bài viết xem xét các biện pháp bảo vệ cụ thể mà dịch vụ tunneling cung cấp và làm nổi bật những lỗ hổng nghiêm trọng mà quản trị viên phải xử lý thủ công.

Điều gì đã xảy ra

Tác giả đánh giá Cloudflare Tunnel như một phương pháp để tiếp cận các ứng dụng tự lưu trữ mà không cần mở cổng inbound trên router. Cơ chế chính liên quan đến một daemon cục bộ, cloudflared, tạo kết nối outbound tới mạng của Cloudflare. Kiến trúc này cho phép người dùng bên ngoài truy cập vào các dịch vụ nội bộ trong khi vẫn giữ bí mật địa chỉ IP công khai của máy chủ. Cách tiếp cận này loại bỏ nhu cầu chuyển tiếp cổng truyền thống, giảm bề mặt tấn công liên quan đến việc phơi bày trực tiếp trên mạng.

Tuy nhiên, bài phân tích cảnh báo rằng việc che giấu địa chỉ IP không đồng nghĩa với việc bảo mật chính ứng dụng đó. Việc công bố một dịch vụ thông qua hostname công khai khiến nó có thể truy cập bởi bất kỳ ai biết URL. Cloudflare Tunnel không áp dụng xác thực theo mặc định. Nếu quản trị viên phơi bày một dashboard Docker hoặc giao diện quản trị tương tự, trang đăng nhập vẫn sẽ công khai khả dụng. Tunnel chỉ đơn thuần vận chuyển lưu lượng; nó không kiểm tra hay hạn chế ai đang cố gắng kết nối.

Để giảm thiểu rủi ro này, tác giả khuyến nghị kết hợp Cloudflare Access lên trên tunnel. Tính năng này cho phép quản trị viên hạn chế quyền truy cập dựa trên danh tính, chẳng hạn như chỉ cho phép các địa chỉ email cụ thể được tiếp tục. Mặc dù hiệu quả đối với các giao diện web, giải pháp này có thể phá vỡ khả năng tương thích với các client desktop hoặc mobile phụ thuộc vào đồng bộ hóa API trực tiếp. Cần phải thử nghiệm để đảm bảo rằng các lớp xác thực bổ sung không làm gián đoạn chức năng hợp lệ của ứng dụng.

Chi tiết chính

• Cloudflare Tunnel sử dụng kết nối outbound qua cloudflared để che giấu địa chỉ IP công khai của máy chủ.
• Tunnel không cung cấp xác thực tự động; các hostname công khai vẫn có thể truy cập bởi bất kỳ ai có URL.
• Cloudflare Access có thể hạn chế quyền truy cập theo địa chỉ email nhưng có thể gây xung đột với các client không phải trình duyệt.
• Các lỗ hổng ứng dụng, mật khẩu yếu và cấu hình sai vẫn có thể bị khai thác bất chấp sự tồn tại của tunnel.
• Lưu lượng giữa cloudflared và ứng dụng cục bộ có thể đi qua HTTP không mã hóa nếu không được cấu hình khác.
• Việc sử dụng dịch vụ đòi hỏi phải tin tưởng Cloudflare xử lý và định tuyến tất cả lưu lượng đầu vào.

Bối cảnh

Cloudflare Tunnel là một phần của xu hướng rộng lớn hơn hướng tới truy cập mạng zero-trust trong lĩnh vực tự lưu trữ. Theo cách truyền thống, việc phơi bày một máy chủ gia đình yêu cầu cấu hình chuyển tiếp cổng trên router, ánh xạ một cổng công khai trực tiếp tới một thiết bị nội bộ. Phương pháp này phơi bày địa chỉ IP của máy chủ ra internet, khiến nó hiển thị với các scanner và kẻ tấn công tiềm năng. Tunneling đảo ngược luồng này bằng cách để máy chủ khởi tạo kết nối tới một trung gian đáng tin cậy.

Mô hình này dựa trên giả định rằng kết nối outbound an toàn hơn kết nối inbound. Tuy nhiên, nó giới thiệu một sự phụ thuộc vào nhà cung cấp trung gian. Trong trường hợp này, Cloudflare hoạt động như một reverse proxy, chấm dứt kết nối TLS từ người dùng và chuyển tiếp yêu cầu tới máy chủ gốc. Hiểu rõ luồng này là rất quan trọng để chẩn đoán các vấn đề độ trễ hoặc sự cố bảo mật, vì nhà cung cấp nằm giữa người dùng và ứng dụng.

Tại sao điều này quan trọng

Đối với các nhóm và cá nhân chạy phần mềm riêng, sự tiện lợi thường xung đột với sự chặt chẽ về bảo mật. Cloudflare Tunnel cung cấp một cách ít ma sát để chia sẻ dịch vụ từ xa, nhưng nó có thể tạo ra cảm giác an toàn giả tạo. Quản trị viên có thể cho rằng vì họ không mở cổng tường lửa, nên dịch vụ của họ an toàn. Trên thực tế, logic ứng dụng vẫn là tuyến phòng thủ chính. Nếu một giao diện web có lỗ hổng đã biết, tunnel sẽ trung thực chuyển tải lưu lượng khai thác tới nó.

Sự phân biệt giữa bảo mật mạng và bảo mật ứng dụng là cực kỳ quan trọng ở đây. Các công cụ mạng như tunnels bảo vệ chống lại việc nhắm mục tiêu IP trực tiếp và quét cổng. Chúng không bảo vệ chống lại các cuộc tấn công brute-force vào biểu mẫu đăng nhập, SQL injection hoặc cross-site scripting. Nếu một tổ chức sử dụng tunnels để phơi bày các dashboard nội bộ, họ vẫn phải duy trì lịch trình vá lỗi nghiêm ngặt và chính sách thông tin đăng nhập mạnh. Chỉ dựa vào tunnel sẽ bỏ qua các vector phổ biến nhất dẫn đến xâm phạm.

Ngoài ra, mô hình tin cậy thay đổi. Tự lưu trữ thường được chọn để duy trì chủ quyền dữ liệu. Bằng cách định tuyến lưu lượng qua Cloudflare, quản trị viên chấp nhận rằng một bên thứ ba xử lý metadata và luồng lưu lượng của họ. Đối với các công cụ nội bộ nhạy cảm, sự đánh đổi này có thể không chấp nhận được. Các nhóm phải quyết định xem sự tiện lợi của truy cập từ xa có outweigh mất mát về sự cô lập mạng hoàn toàn hay không.

Bạn có thể làm gì

• Kiểm toán tất cả các hostname đã công bố để đảm bảo chỉ những dịch vụ cần thiết mới được phơi bày ra internet công khai.
• Kích hoạt Cloudflare Access hoặc các proxy nhận thức danh tính tương tự cho các giao diện quản trị.
• Thử nghiệm kết nối API và client sau khi kích hoạt các lớp xác thực bổ sung để tránh làm hỏng quy trình làm việc.
• Đảm bảo lưu lượng cục bộ giữa cloudflared và ứng dụng của bạn sử dụng HTTPS khi có thể.
• Duy trì cập nhật phần mềm thường xuyên và mật khẩu mạnh cho tất cả các ứng dụng được phơi bày.
• Cân nhắc sử dụng VPN riêng tư cho các dịch vụ cực kỳ nhạy cảm thay vì tunnels công khai.