Một dòng trong file hosts đã làm hỏng tính năng chuyển giọng nói thành văn bản của bot AI như thế nào

Một nền tảng dịch vụ khách hàng dùng AI đã mất khả năng xử lý ghi chú thoại, hình ảnh và tài liệu trong hai ngày vào tháng Mười sau một cuộc di chuyển máy chủ thường quy. Nguyên nhân gốc rễ là một dòng được thêm vào file hosts của hệ thống, gây xung đột với một lớp bảo mật hiện có được thiết kế để ngăn chặn giả mạo yêu cầu phía máy chủ (SSRF).

Chuyện gì đã xảy ra

Đội ngũ đứng sau DOS AI, một trợ lý xử lý tương tác với khách hàng trên WhatsApp, Instagram và Telegram, gần đây đã chuyển cơ sở hạ tầng từ nhà cung cấp đám mây quản lý sang máy chủ tự host. Trong quá trình tăng cường bảo mật, một script đã sửa đổi file /etc/hosts để ghim các tên miền của họ về địa chỉ loopback 127.0.0.1. Mục tiêu là đảm bảo rằng các lệnh gọi nội bộ đến dịch vụ lưu trữ và xác thực vẫn hoạt động ngay cả khi phân giải DNS bên ngoài thất bại. Ứng dụng sẽ tự phân giải tên miền của chính nó cục bộ và dựa vào một reverse proxy để định tuyến lưu lượng truy cập chính xác bằng cách sử dụng Server Name Indication (SNI).

Tuy nhiên, thay đổi này đã kích hoạt một lỗi im lặng trong pipeline xử lý phương tiện truyền thông của ứng dụng. Khi khách hàng gửi ghi chú thoại hoặc tệp tin, gateway WhatsApp lưu chúng vào object storage và tạo ra một URL trỏ đến tên miền riêng của công ty. Trước khi tải bất kỳ nội dung nào từ URL do người dùng cung cấp hoặc URL nội bộ, ứng dụng chạy một lớp bảo vệ chống Giả mạo Yêu cầu Phía Máy chủ (SSRF). Biện pháp bảo mật này phân giải hostname và chặn các yêu cầu hướng tới địa chỉ IP riêng tư, loopback hoặc link-local nhằm ngăn kẻ tấn công truy cập vào các endpoint metadata nội bộ.

Vì file hosts giờ đây phân giải tên miền lưu trữ của công ty về 127.0.0.1, lớp bảo vệ SSRF đã nhận diện yêu cầu nội bộ hợp lệ này như một mối đe dọa bảo mật tiềm tàng và chặn nó. Hệ thống không bị sập, cũng không ghi log lỗi ở mức độ nghiêm trọng cao, vì việc chặn các URL không an toàn là hành vi dự kiến. Do đó, trợ lý AI phản hồi mọi tin nhắn thoại bằng một thông báo lỗi mặc định, yêu cầu người dùng gõ yêu cầu của họ thay thế. Trong suốt hai ngày, hệ thống đã không thể xử lý 314 trong số 339 ghi chú thoại, 241 trong số 248 bức ảnh và 92 trong số 94 tài liệu trên mười ba dự án khác nhau.

Chi tiết chính

• Sự cố xảy ra vào tháng 10 năm 2026 sau khi di chuyển từ cơ sở hạ tầng đám mây quản lý sang cơ sở hạ tầng tự host.
• Một script tăng cường bảo mật đã thêm 127.0.0.1 sb.dosai.pro dosai.pro vào file /etc/hosts để giảm sự phụ thuộc vào DNS.
• Lớp bảo vệ SSRF đã chặn các lượt tải xuống từ những tên miền này vì chúng phân giải về địa chỉ loopback 127.0.0.1.
• Lỗi diễn ra im lặng; các lượt tải xuống bị từ chối được ghi log dưới dạng cảnh báo (warning), không phải lỗi (error), làm chậm trễ việc phát hiện sự cố.
• Mất dữ liệu bao gồm 314 ghi chú thoại, 241 bức ảnh và 92 tài liệu trên 13 dự án trong vòng hai ngày.
• Giải pháp khắc phục liên quan đến việc cập nhật lớp bảo vệ SSRF để nhận diện các hostname công cộng cụ thể là an toàn trước khi kiểm tra địa chỉ IP.

Bối cảnh

Giả mạo Yêu cầu Phía Máy chủ (SSRF) là một lỗ hổng bảo mật mà kẻ tấn công lừa máy chủ thực hiện các yêu cầu tới các tài nguyên nội bộ không thể truy cập công khai. Để giảm thiểu điều này, các ứng dụng thường triển khai các lớp bảo vệ kiểm tra URL trước khi fetch chúng. Các lớp bảo vệ này thường phân giải hostname thành địa chỉ IP và từ chối bất kỳ yêu cầu nào nhắm vào dải IP riêng tư (như 127.0.0.1 hoặc 192.168.x.x). Điều này ngăn kẻ tấn công sử dụng máy chủ để thăm dò mạng nội bộ của chính nó hoặc truy cập các dịch vụ metadata cục bộ.

Trong môi trường tự host, việc ánh xạ tên miền công cộng về localhost trong file hosts là phổ biến. Điều này đảm bảo rằng các dịch vụ nội bộ có thể giao tiếp với nhau bằng tên miền công khai của chúng mà không cần dựa vào máy chủ DNS bên ngoài. Tuy nhiên, điều này tạo ra xung đột với các biện pháp bảo vệ SSRF tiêu chuẩn. Lớp bảo mật thấy một yêu cầu tới tên miền công cộng nhưng lại phân giải về IP riêng tư và cho rằng đó là một cuộc tấn công, mặc dù thực tế đó là một lệnh gọi nội bộ hợp lệ. Việc giải quyết vấn đề này đòi hỏi logic bảo mật phải phân biệt được giữa các cuộc tấn công rebinding độc hại và định tuyến cục bộ có chủ đích.

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

Đối với các đội ngũ vận hành phần mềm riêng, sự cố này nhấn mạnh sự phức tạp ẩn giấu khi kết hợp các thực hành bảo mật tốt nhất với tối ưu hóa cơ sở hạ tầng. Cả việc sửa đổi file hosts và lớp bảo vệ SSRF đều đúng đắn khi xét riêng lẻ. Mục nhập hosts cải thiện độ tin cậy bằng cách loại bỏ sự phụ thuộc vào DNS, còn lớp bảo vệ giúp phòng chống một lớp lỗ hổng nghiêm trọng. Thất bại chỉ xuất hiện từ sự tương tác giữa chúng, chứng minh rằng các biện pháp kiểm soát bảo mật phải ý thức được topo mạng cụ thể và quy ước đặt tên của môi trường mà chúng bảo vệ.

Sự im lặng của chế độ lỗi là một bài học quan trọng khác. Các công cụ bảo mật thường được cấu hình để fail closed (chặn khi nghi ngờ), nghĩa là chúng chặn hoạt động đáng ngờ thay vì cho phép đi qua. Mặc dù điều này an toàn, nó có thể dẫn đến mất dữ liệu nếu hoạt động bị chặn thực chất là lưu lượng kinh doanh hợp lệ. Nếu không có cảnh báo cụ thể cho các yêu cầu nội bộ bị chặn hoặc giám sát các chỉ số cấp độ kinh doanh (như số lượng chuyển giọng nói thành văn bản thành công), các đội ngũ có thể không biết đến vấn đề cho đến khi khách hàng phàn nàn. Trong trường hợp này, nhà sáng lập chỉ nhận ra vấn đề bằng cách quan sát sự sụt giảm trong các lead quảng cáo, chứ không phải thông qua cảnh báo hệ thống.

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

• Kiểm toán các lớp bảo vệ SSRF của bạn để đảm bảo chúng có thể phân biệt giữa tên miền công cộng của chính bạn và các mối đe dọa bên ngoài.
• Triển khai danh sách trắng hostname khớp chính xác (exact-match) trong các kiểm tra bảo mật thay vì chỉ dựa vào xác thực địa chỉ IP.
• Cấu hình cảnh báo cho các cảnh báo bảo mật (warnings), không chỉ lỗi (errors), để phát hiện khi lưu lượng hợp lệ đang bị chặn.
• Giám sát các chỉ số cấp độ kinh doanh, chẳng hạn như tải lên tệp hoặc chuyển giọng nói thành văn bản thành công, để bắt kịp các suy thoái chức năng sớm.
• Kiểm thử các bản vá bảo mật bằng cách mock phân giải DNS để trả về địa chỉ loopback cho cả host thuộc sở hữu của bạn và host bên ngoài.
• Tài liệu hóa các thay đổi cơ sở hạ tầng như sửa đổi file hosts và xem xét tác động của chúng đối với các chính sách bảo mật hiện có.