Tóm tắt nhanh
- Nhật ký của một NAS Synology ghi nhận khoảng 42 giờ thử đăng nhập thất bại; chưa có bằng chứng kẻ tấn công đăng nhập thành công.
- Một luật chuyển tiếp cổng 80 còn sót lại sau thử nghiệm nginx đã để dịch vụ trên NAS có thể được truy cập từ Internet.
- Auto Block theo IP có giới hạn trước các lượt thử phân tán; xác thực hai yếu tố vẫn cần thiết nhưng không thay việc đóng đường truy cập thừa.
- Với NAS gia đình, cần kiểm tra cả router lẫn DSM, thay vì coi CGNAT hay việc đã cài VPN là bảo đảm không còn cổng công khai.
Một NAS Synology DS1621xs+ bị thử đăng nhập đều đặn trong khoảng 42 giờ, theo nhật ký được XDA công bố ngày 29/10. Điều đáng ngại nằm ở đường truy cập: chủ máy dùng Tailscale để vào mạng từ xa và tưởng đường truyền vẫn ở sau CGNAT, nhưng một luật chuyển tiếp cổng cũ trên router vẫn đưa dịch vụ của NAS ra Internet.
Đây là sự cố cấu hình, chưa phải bằng chứng về lỗ hổng mới trong DSM. Những lượt đăng nhập được kiểm tra đều thất bại ngay ở bước mật khẩu. Dù vậy, việc bot đã chạm tới trang đăng nhập cho thấy có một lớp bảo vệ bị bỏ sót: người dùng gia cố tài khoản nhưng chưa kiểm soát hết những đường dẫn đến tài khoản đó.
Cổng mở bị bỏ quên khiến bảo vệ tài khoản phải gánh thêm rủi ro
Một dịch vụ chỉ cần thiết cho thử nghiệm vẫn có thể để lại đường truy cập lâu dài nếu phần cấu hình mạng không được dọn cùng ứng dụng. Trong trường hợp này, luật trên router eero từng được tạo để thử nginx qua cổng 80; thử nghiệm đã kết thúc nhưng luật vẫn nằm trong mục dành địa chỉ cho NAS, nơi người dùng dễ bỏ qua khi chỉ kiểm tra danh sách dịch vụ đang chạy.
Trên mạng nội bộ, truy cập NAS qua cổng đó dẫn đến trang đăng nhập DSM. Khi kiểm tra từ điện thoại dùng LTE, địa chỉ công cộng còn trả về thông báo lỗi nginx về việc gửi HTTP đến cổng HTTPS. Bản thân thông báo lỗi không chứng minh đăng nhập được, nhưng đủ cho thấy dịch vụ vẫn trả lời bên ngoài mạng nhà.
Nhật ký do XDA công bố ghi nhận lượt đầu vào tối 26/9 và lượt cuối lúc 15 giờ 17 phút ngày 28/9, tính theo giờ miền Đông Mỹ sau khi hiệu chỉnh múi giờ NAS. Các lượt thử cách nhau khoảng 10–40 giây; trong mẫu sáu phút có 14 IP thuộc bốn dải địa chỉ. Luật chuyển tiếp được xóa khoảng 15 giờ 16 phút, còn lượt thất bại cuối xuất hiện khoảng một phút sau đó.
Diễn biến này củng cố nhận định rằng luật cũ là đường phơi bày dịch vụ. Nó không có nghĩa mọi NAS đều bị lộ qua cổng 80, cũng không có nghĩa cứ thấy nginx là máy đã bị chiếm quyền. Điều cần kiểm tra là cổng bên ngoài đang được ánh xạ đến thiết bị, cổng đích và dịch vụ nào ở phía trong, kể cả khi phần mềm dùng để thử trước đây đã bị gỡ.
Mật khẩu riêng và tài khoản quản trị không dùng tên mặc định giúp giảm khả năng đoán trúng, nhưng chúng không làm trang đăng nhập biến mất khỏi Internet. Giữ một dịch vụ không cần thiết ở trạng thái công khai đồng nghĩa hệ thống vẫn phải tiếp nhận các lượt thử, xử lý xác thực và phụ thuộc vào việc mọi lớp phần mềm liên quan luôn được cấu hình đúng.
CGNAT không phải cam kết rằng NAS luôn được che khỏi Internet
CGNAT có thể khiến một luật chuyển tiếp cổng trên router nhà chưa đủ để nhận kết nối IPv4 từ Internet, nhưng không nên dùng đặc điểm đó làm nền tảng bảo mật lâu dài. Với IP công cộng gán trực tiếp lên router, cùng một luật chuyển tiếp có thể tạo ra khả năng truy cập từ bên ngoài mà người dùng không cần sửa cấu hình NAS.
Điểm phải giữ đúng mức chắc chắn là chưa có bằng chứng xác định thời điểm đường truyền trong sự cố chuyển trạng thái. Chủ máy trước đó tin mình dùng CGNAT; lúc kiểm tra, IP công cộng quan sát từ máy tính trùng IP WAN mà eero hiển thị. Không có lịch sử đủ dài để chứng minh đường truyền đã đổi khi nào, nên không thể kết luận nhà mạng vừa âm thầm đổi IP rồi lập tức gây ra cuộc tấn công.
Đối với người dùng Việt Nam, bài học hữu ích hơn việc đoán chính sách của một nhà mạng là kiểm tra lại sau mỗi thay đổi đường truyền: thay modem, chuyển router sang chế độ khác, đăng ký IP công cộng hoặc khôi phục cấu hình cũ. Các thay đổi này có thể làm khác đường đi của kết nối; không nên suy ra mức phơi bày hiện tại từ kết quả kiểm tra nhiều tháng trước.
Cài Tailscale cũng không tự xóa các luật chuyển tiếp đã tồn tại. VPN tạo một đường vào có kiểm soát để dùng thay cho việc mở trực tiếp giao diện quản trị, còn luật cũ trên router là đường khác. Hai đường có thể cùng tồn tại, và việc người dùng luôn chọn VPN không buộc bot bên ngoài phải đi qua VPN đó.
Trong vụ việc này, tắt QuickConnect không làm các lượt thử dừng lại, còn UPnP vốn đã tắt. Vì vậy, không nên vội quy trách nhiệm cho QuickConnect hoặc cho rằng tắt UPnP sẽ dọn sạch mọi cấu hình. Luật thủ công vẫn cần được kiểm tra ở router, bao gồm cả các mục gắn với từng thiết bị.
Auto Block vẫn đáng bật, nhưng đếm theo IP có điểm mù
Chặn một IP thử sai quá nhiều lần có tác dụng với nguồn tấn công tập trung, nhưng khó bao quát chiến dịch chia lượt thử cho nhiều địa chỉ. Auto Block của DSM hoạt động theo số lần đăng nhập thất bại từ một IP trong một khoảng thời gian; khi mỗi IP chỉ xuất hiện ít lần, tổng số lượt trên toàn hệ thống có thể lớn mà từng địa chỉ vẫn chưa chạm ngưỡng chặn.
Mẫu sáu phút với 14 IP do XDA công bố phù hợp với khả năng các nguồn luân phiên giữ số lượt riêng dưới ngưỡng. Tuy nhiên, nhật ký đó không đủ để xác định hạ tầng điều khiển phía sau, cũng không chứng minh mọi cấu hình Auto Block đều bất lực trước mọi kiểu tấn công phân tán. Kết luận hợp lý là không dùng danh sách IP bị chặn làm thước đo duy nhất cho độ an toàn.
Cách gọi kiểu tấn công cũng cần thận trọng. Credential stuffing thường chỉ việc thử lại các cặp tài khoản và mật khẩu đã rò rỉ từ nơi khác, trong khi các tên chung như admin, administrator hay marketing ở đây gần với dò mật khẩu trên nhiều tài khoản hơn. Chỉ từ tên tài khoản trong nhật ký thì chưa thể xác nhận kẻ tấn công đang sở hữu bộ thông tin đăng nhập bị rò rỉ nào.
Account Protection bổ sung cách bảo vệ ở cấp tài khoản trước các máy khách không đáng tin, còn Auto Block xử lý theo địa chỉ nguồn. Hai cơ chế có thể hỗ trợ nhau nhưng không thay thế mật khẩu không dùng lại và xác thực hai yếu tố. Cần xem tổng thể lượt thất bại, tài khoản bị nhắm đến và các phiên đăng nhập thành công bất thường, thay vì chỉ chờ một IP bị đưa vào danh sách chặn.
Trong sự cố này, 2FA đã được bật nhưng những lượt được kiểm tra đều thất bại ở bước mật khẩu, nên không thể nói 2FA đã trực tiếp chặn chúng. Vai trò của nó là lớp dự phòng nếu bước mật khẩu bị vượt qua. Điều đó khác với cam kết rằng bật 2FA sẽ chống được mọi cách chiếm quyền, nhất là khi còn dịch vụ khác ngoài trang đăng nhập cần được cập nhật.
Ưu tiên đóng đường thừa trước khi đổi cổng hay siết mật khẩu
Với NAS chỉ dùng cho gia đình, giảm số nơi có thể chạm vào giao diện quản trị thường đáng làm trước việc đổi cổng để tránh bot quét mặc định. Đổi số cổng có thể giảm một phần lượt dò đơn giản nhưng không tạo thêm bước xác thực; nếu dịch vụ vẫn công khai thì đường truy cập vẫn còn đó.
Trước tiên, hãy rà danh sách chuyển tiếp trên router và mục Router Configuration trong DSM, xóa các luật đã hết mục đích sử dụng. Cần kiểm tra cả luật nằm dưới phần dành địa chỉ cho thiết bị, bởi danh sách trống trong DSM không bảo đảm router không còn luật được tạo bằng ứng dụng riêng. Nếu không dùng UPnP, tắt nó giúp giảm khả năng ứng dụng tự thêm luật mới.
Sau đó, xác định người nào thực sự cần vào DSM từ xa và cho họ dùng đường truy cập phù hợp, chẳng hạn Tailscale. Không cần giữ trang quản trị mở cho toàn Internet chỉ vì điện thoại đôi lúc cần lấy tệp. Với các dịch vụ đang được gia đình dùng, nên kiểm tra chức năng sau mỗi thay đổi thay vì tắt hàng loạt rồi không biết phần nào gây gián đoạn.
Tường lửa DSM có thể giới hạn nguồn được phép truy cập, nhưng thứ tự luật và thao tác áp dụng quyết định kết quả. Hãy tạo quyền cho mạng nội bộ và đường VPN hợp lệ trước khi đặt phần còn lại thành từ chối; đồng thời giữ một cách truy cập nội bộ để kiểm tra. Sao chép nguyên dải địa chỉ từ cấu hình của người khác mà không hiểu mạng mình có thể khiến chính chủ máy bị khóa ngoài.
Các thiết lập tài khoản vẫn cần được hoàn tất song song: có tài khoản quản trị riêng, vô hiệu hóa tài khoản admin mặc định sau khi xác nhận tài khoản thay thế hoạt động, và bắt buộc 2FA cho nhóm quản trị. Tài khoản dùng đọc, ghi tệp hằng ngày không nên có quyền quản trị chỉ để tiện đăng nhập, vì quyền càng rộng thì hậu quả của việc lộ thông tin càng lớn.
SSH và Telnet không dùng đến nên được tắt, còn cập nhật bảo mật và Security Advisor giúp rà những phần cấu hình dễ bị quên. Nếu đổi cổng DSM hoặc chuyển sang HTTPS, vẫn phải kiểm tra lại đường truy cập thực tế. HTTPS bảo vệ kết nối, không ngăn người ngoài tìm thấy trang đăng nhập và cũng không thay cho việc giới hạn ai được kết nối.
Kiểm tra từ mạng ngoài mới biết cấu hình đã có hiệu lực
Kiểm tra thành công từ Wi-Fi nhà chỉ chứng minh NAS vẫn dùng được trong mạng nội bộ, không chứng minh dịch vụ đã kín với Internet. Sau khi dọn luật, nên tắt Wi-Fi trên điện thoại, dùng dữ liệu di động kiểm tra địa chỉ và cổng mà chính mình từng công khai, rồi đối chiếu với nhật ký trên NAS.
Việc trang đăng nhập không còn hiện qua một đường truy cập cũ là tín hiệu cần thiết, nhưng không đủ để chứng minh mọi dịch vụ khác đều an toàn. Cũng cần kiểm tra các đường truy cập từ xa còn chủ động giữ lại, xác nhận người dùng hợp lệ vẫn vào được, và bật thông báo để không phải tình cờ mở Log Center mới phát hiện hàng loạt lượt thử sai.
Chứng chỉ tự ký sai có thể khiến trình duyệt cảnh báo, nhưng cảnh báo đó không chặn bot thử mật khẩu. Tương tự, một thông báo lỗi web vẫn là câu trả lời từ dịch vụ. Khi mục tiêu là không để trang quản trị nhận truy cập trực tiếp từ Internet, kết quả cần kiểm chứng là đường kết nối ấy đã bị đóng hoặc bị từ chối theo đúng chính sách, chứ không chỉ là trang trông khó sử dụng hơn.
Cuối cùng, NAS cần khả năng phục hồi độc lập với tài khoản quản trị đang bảo vệ nó. Snapshot hữu ích cho việc quay lại phiên bản dữ liệu, nhưng vẫn phụ thuộc vào hệ thống lưu trữ chứa nó; RAID cũng không thay được bản sao lưu. Một bản sao ở nơi khác, dùng thông tin truy cập riêng, giảm nguy cơ một lần mất quyền quản trị kéo theo mất cả dữ liệu lẫn điểm phục hồi.
Sự cố 42 giờ chưa ghi nhận đăng nhập thành công, nhưng nó chỉ ra việc cần kiểm tra ngay: danh sách cổng mở thực tế trên router có còn khớp với nhu cầu hiện tại hay không. Nếu một luật chỉ tồn tại vì không ai nhớ lý do tạo ra nó, hãy xác minh rồi gỡ bỏ thay vì chờ nhật ký đăng nhập nhắc lại.
Nguồn tham khảo: XDA Developers; WunderTech.
