Lỗi thiết kế router Netgear gây bão NTP cho Đại học Wisconsin (2003)

Vào tháng 5 năm 2003, Đại học Wisconsin-Madison phát hiện một máy chủ thời gian công cộng của trường bị "dội bom" bởi hàng trăm nghìn gói tin mỗi giây từ khắp nơi trên thế giới. Điều đáng nói là thủ phạm không phải một cuộc tấn công DDoS có chủ đích, mà là lỗi thiết kế trong hàng trăm nghìn router giá rẻ của Netgear dành cho hộ gia đình.

Câu chuyện tưởng chừng chỉ là sự cố kỹ thuật nhỏ này lại kéo dài nhiều năm, tiêu tốn tài nguyên mạng của một trường đại học danh tiếng và đặt ra câu hỏi lớn về trách nhiệm của nhà sản xuất thiết bị Internet.

Sự cố bắt đầu từ một máy chủ thời gian

Máy chủ NTP (Network Time Protocol) của UW-Madison là một trong những máy chủ thời gian công cộng lâu đời nhất trên Internet, phục vụ việc đồng bộ đồng hồ cho hàng triệu thiết bị. Đến ngày 14 tháng 5 năm 2003, lưu lượng gói tin đi vào campus bất ngờ tăng vọt từ mức bình thường khoảng 40.000 gói/giây lên mức cao chưa từng thấy.

Đến 9 giờ 40 phút sáng, lưu lượng này bắt đầu gây ảnh hưởng đến hệ thống đo lường và một số router cũ trong trường. Đến 11 giờ, đội ngũ kỹ thuật đã xác định được đích đến của luồng dữ liệu: máy chủ thời gian công cộng của trường. Họ lập tức chặn lưu lượng tại biên mạng của WiscNet - nhà cung cấp dịch vụ Internet cho campus.

Lưu lượng tấn công SNTP flood vào máy chủ NTP

Điều kỳ lạ là các gói tin này tuy đến từ rất nhiều nguồn khác nhau nhưng đều có cùng số cổng nguồn là 23457. Con số này rõ ràng được lập trình viên "chọn tay", vì nó nằm ngay sau 23456. Nhóm kỹ thuật ban đầu tưởng đây là một cuộc tấn công DDoS với địa chỉ IP giả mạo, và chỉ cần chặn cổng 23457 là xong.

Nhưng một tháng sau, lưu lượng vẫn tiếp tục và còn tăng lên mức hơn 250.000 gói/giây và 150 megabit/giây. Khi phân tích sâu hơn, họ phát hiện các gói tin này là truy vấn SNTP (Simple Network Time Protocol) phiên bản 1 hoàn toàn hợp lệ, không hề giả mạo. Điều bất thường nằm ở chỗ: nhiều client gửi tới 1 truy vấn mỗi giây - một con số vô lý đối với bất kỳ ứng dụng đồng bộ thời gian nào.

Thủ phạm: router Netgear

Sau khi liên hệ với các trường đại học khác để điều tra hai địa chỉ IP nguồn, cả hai đều xác nhận: router thương hiệu Netgear (cụ thể là model MR814) chính là nguồn phát tán. Bằng cách tải firmware của Netgear và dùng lệnh strings để phân tích, nhóm nghiên cứu tìm thấy số 23457 được hard-code trong mã nguồn, cùng địa chỉ IP máy chủ NTP 128.105.39.11 của UW-Madison.

Mã nguồn firmware Netgear chứa địa chỉ IP và cổng cố định

Lỗi thiết kế của client SNTP trên các sản phẩm Netgear bao gồm:

• Sử dụng địa chỉ IP cố định cho máy chủ NTP (128.105.39.11), không cho phép cấu hình.
• Dùng cổng nguồn UDP cố định 23457 - điều này vô tình giúp UW-Madison dễ dàng nhận diện và đếm số lượng thiết bị lỗi.
• Poll mỗi 1 giây cho đến khi nhận được phản hồi, sau đó mới chuyển sang chu kỳ dài hơn như 1 phút, 10 phút, 2 giờ hoặc 24 giờ tùy model.
• Vì các truy vấn trùng lặp không được gửi đồng bộ, số lượng thiết bị càng lớn thì mức độ "dội bom" càng khủng khiếp.

Netgear báo cáo đã sản xuất tổng cộng 707.147 sản phẩm bị ảnh hưởng tính đến ngày 30 tháng 6 năm 2003. Bài toán đơn giản: nếu 700.000 client lỗi, mỗi client gửi 1 truy vấn/giây, tổng lưu lượng có thể lên tới 700.000 gói/giây, tương đương khoảng 426 megabit/giây - đủ để làm nghẽn nhiều tuyến mạng.

Một điều trớ trêu: Netgear từng được ICSA Labs chứng nhận firewall cho dòng sản phẩm FR114P, nhưng lỗi SNTP lại nằm ngoài phạm vi kiểm định đó.

Phản ứng chậm chạp từ nhà sản xuất

Ngày 16 tháng 6 năm 2003, nhóm nghiên cứu UW-Madison gửi email cho bộ phận hỗ trợ Netgear, đồng thời liên hệ trực tiếp với một số nhân viên qua địa chỉ email thu thập được trên web. Sau nhiều ngày không có phản hồi, họ gọi điện đến trụ sở Netgear và để lại lời nhắn cho hai giám đốc điều hành.

Phải mất 23 ngày, Netgear mới phản hồi qua hệ thống hỗ trợ khách hàng tự động. Sau đó, hai bên thành lập một nhóm đánh giá gồm khoảng 15 thành viên, chia đều giữa đại diện trường đại học, Netgear và cộng đồng vận hành Internet.

Netgear sau đó đã phát hành firmware mới cho các model RP614v2, RP614, DG814 và MR814, không còn dùng máy chủ thời gian của UW-Madison và không poll quá thường xuyên. Tuy nhiên, cả Netgear lẫn UW-Madison đều thừa nhận rằng không thể trông chờ khách hàng nâng cấp firmware để khắc phục triệt để vấn đề.

Hai phương án "kết thúc" đầy tốn kém

Nhóm đánh giá cân nhắc nhiều giải pháp, nhưng tập trung vào hai hướng chính:

Phương án A - BGP anycast: Triển khai các máy chủ NTP dự phòng có độ tin cậy cao tại biên WiscNet và định tuyến các truy vấn đến địa chỉ 128.104.39.11 bằng kỹ thuật anycast. Cách này cho phép đặt nhiều máy chủ cùng địa chỉ IP tại UW-Madison, UW-Milwaukee và UW-Eau Claire - gần ba điểm trao đổi Internet hiện tại. Ưu điểm là UW-Madison giữ được quyền kiểm soát không gian địa chỉ IPv4 quý giá, chỉ tiêu tốn một địa chỉ /32.

Mô hình triển khai BGP anycast cho máy chủ NTP

Rủi ro của phương án A là trường không kiểm soát được toàn bộ đường đi end-to-end. Nhiều nguyên nhân như định tuyến bất đối xứng, chính sách firewall hay thảm họa làm đứt kết nối có thể khiến các client "zombie" không bao giờ nhận được phản hồi và tiếp tục dội truy vấn về máy chủ.

Phương án B - Hy sinh không gian địa chỉ IP: Chặn hoàn toàn các truy vấn Netgear bằng cách rút một dải địa chỉ lớn khỏi bảng định tuyến BGP toàn cầu. Vì Internet backbone chỉ tôn trọng các tuyến đủ lớn (thường từ 2.048 đến 4.096 địa chỉ liền kề, tức /21 hoặc /20), UW-Madison có thể phải hy sinh tới 4.096 địa chỉ IP trong mạng 128.105.0.0/16 - có thể kéo dài suốt vòng đời của các sản phẩm lỗi.

Chia dải mạng /16 để hy sinh một khối /20

Rủi ro của phương án B là một số phần của Internet có thể không truy cập được các địa chỉ hợp lệ nằm gần khối bị rút khỏi bảng định tuyến.

Trường hợp tương tự tại CSIRO

Trong quá trình đánh giá, nhóm cũng phát hiện Tổ chức Nghiên cứu Khoa học và Công nghiệp Khối thịnh vượng chung (CSIRO) tại Úc gặp vấn đề tương tự với khoảng 85.000 router SMC poll máy chủ thời gian của họ hai lần mỗi phút khi không nhận được phản hồi. Quy mô nhỏ hơn nhiều - khoảng 2.800 gói/giây và 1,7 megabit/giây - nhưng bản chất lỗi hoàn toàn giống nhau, cho thấy đây là vấn đề hệ thống của ngành thiết bị mạng giá rẻ.

Bài học cho ngành công nghệ

Sự cố này để lại nhiều bài học quan trọng vẫn còn nguyên giá trị:

• Hard-code địa chỉ IP và cổng là thảm họa tiềm tàng. Một quyết định "tiện cho lập trình viên" có thể gây hậu quả toàn cầu trong nhiều năm.
• Chu kỳ poll phải tuân thủ thực tiễn tốt nhất. Gửi 1 truy vấn/giây đến máy chủ công cộng là hành vi phá hoại vô tình.
• Trách nhiệm của nhà sản xuất không kết thúc khi bán hàng. Firmware cũ vẫn chạy trên hàng trăm nghìn thiết bị mà người dùng khó có thể nâng cấp.
• Các dịch vụ hạ tầng công cộng cần được bảo vệ bằng thiết kế, không chỉ bằng tường lửa. Các dự án như AS112 sau này đã chứng minh hiệu quả của mô hình anycast phân tán.

Tài liệu công bố này được xem như một nỗ lực cảnh báo cộng đồng Internet, với hy vọng giảm thiểu khả năng lặp lại sai lầm tương tự ở nơi khác. Cho đến thời điểm công bố vào tháng 8 năm 2003, UW-Madison vẫn tiếp tục phục vụ các truy vấn Netgear, trong khi đối mặt với những đợt bùng phát lưu lượng có thể lên tới 100.000 gói/giây - một cuộc chơi "roulette Nga" mà trường buộc phải tham gia cho đến khi tìm được giải pháp thỏa đáng.