DNS là dành cho con người, không phải cho hạ tầng CNTT

DNS là dành cho con người, không phải cho hạ tầng CNTT

Hệ thống tên miền (DNS - Domain Name System) tồn tại vì một lý do đơn giản: con người khó nhớ các chuỗi địa chỉ IP như 185.15.59.224 nhưng lại dễ nhớ tên miền như wikipedia.org. Đối với các dịch vụ công cộng trên internet, việc sử dụng DNS để xuất bản website hay các điểm kết nối API là hoàn toàn hợp lý, vì con người cần tương tác với chúng. Ngoài ra, tên miền còn cho phép thay đổi địa chỉ IP phía sau mà không ảnh hưởng đến người dùng cuối.

Tuy nhiên, bài viết này không phản đối việc sử dụng DNS cho các dịch vụ công cộng, mà đặt câu hỏi về việc liệu chúng ta có nên tiếp tục sử dụng DNS cho hạ tầng CNTT nội bộ (internal IT infrastructure) hay không, bất kể là môi trường đám mây (cloud) hay tại chỗ (on-prem).

"Luôn là lỗi của DNS"

Mặc dù DNS là một dịch vụ rất hữu ích, nó cũng có thể trở thành một gánh nặng. Nếu bạn muốn xây dựng một hệ thống đáng tin cậy, bạn muốn càng ít thành phần càng tốt. Mỗi thành phần thêm vào đều tiềm ẩn nguy cơ thất bại. Hơn nữa, nhiều thành phần có thể tạo ra những hành vi và tương tác không lường trước được gây ra sự cố (như sự phụ thuộc vòng tròn).

Trong giới vận hành CNTT, DNS đã nổi tiếng là một "thủ phạm" thường xuyên. Có lẽ nhiều người vẫn nhớ câu thơ haiku nổi tiếng:

Không phải DNS Không thể nào là DNS Chính là DNS

Đã có nhiều sự cố lớn liên quan đến DNS. Trong các trường hợp này, nguyên nhân gốc rễ có thể không phải là hệ thống DNS本身, nhưng vì nguyên nhân đó ảnh hưởng đến dịch vụ DNS - vốn nằm trên đường đi quan trọng của hầu hết các dịch vụ - nên tác động của sự cố trở nên khổng lồ.

Ví dụ, sự cố mất điện toàn cầu của Facebook/Meta trở nên nghiêm trọng đến mức nhân viên bị khóa ngoài tòa nhà (không thể vào được vật lý) do sự phụ thuộc vòng tròn vào việc phải có DNS mới có thể xác thực danh tính. Một lần nữa, có thể nói sự phụ thuộc vòng tròn là nguyên nhân gốc rễ, nhưng "phạm vi nổ" (blast radius) của DNS quá lớn khiến việc hình dung rủi ro trở nên khó khăn.

Lập luận chống lại việc dùng DNS cho hạ tầng nội bộ

Từ góc độ vận hành, DNS có một nhược điểm lớn: các máy khách DNS sẽ lưu trữ (cache) bản ghi DNS dựa trên TTL (Time To Live). Các triển khai máy khách DNS khác nhau có thể hoạt động khác nhau, nhưng ngay cả khi bạn có một môi trường tương đối đồng nhất, cách duy nhất để đảm bảo các máy khách (ở đây là các máy chủ khác) sử dụng địa chỉ IP đã cập nhật là kiểm soát chúng và ép buộc làm mới DNS.

Điều này khiến tôi suy nghĩ: Tại sao chúng ta lại dùng DNS cho các dịch vụ hạ tầng? Nó không cần thiết cho giao tiếp giữa máy với máy (machine-to-machine). Thay vì cấu hình các tên miền có thể không phân giải được, chúng ta hoàn toàn có thể chèn trực tiếp địa chỉ IP thích hợp vào các tệp cấu hình. Việc cấu hình hệ thống theo quy mô lớn với các công cụ như Ansible hay pyinfra là rất dễ dàng.

Đối lập lại, lập luận phản biện có thể là DevOps hay kỹ sư nền tảng cũng là con người, và việc cấu hình tên miền sẽ dễ dàng hơn để phát hiện sai sót hoặc khắc phục sự cố so với địa chỉ IP.

May mắn thay, chúng ta vẫn có /etc/hosts. Chúng ta có thể dễ dàng cung cấp tệp này. Vẫn không cần dịch vụ DNS nào cả! Cách này cho phép cấu hình tên miền và "giả vờ" dùng DNS. Tôi cũng nghi ngờ rằng các truy vấn DNS đối với /etc/hosts có phản hồi khá nhanh.

DNS là rủi ro bảo mật chung

Hiện nay, hầu hết lưu lượng mạng đều được mã hóa theo mặc định hoặc đi qua một kênh được mã hóa. DNS - theo mặc định - là ngoại lệ. Đối với hạ tầng CNTT nội bộ (cloud hay on-prem), mạng có thể được coi là môi trường an toàn. Tuy nhiên, một cuộc tấn công vào dịch vụ DNS, giả mạo gói tin, v.v., có thể gây ra sự gián đoạn rất lớn. Việc thiết lập DNSSEC có thể giảm bớt vấn đề này, nhưng nó cũng mang lại gánh nặng quản trị riêng với rủi ro cấu hình sai. Đó là một lớp phức tạp khác. Và chúng ta giả định rằng hạ tầng nội bộ hỗ trợ DNSSEC.

DNS là rủi ro trích xuất dữ liệu (Egress Exfiltration)

Vì việc lọc lưu lượng ra ngoài (egress filtering) có thể phức tạp, nó thường bị bỏ qua vì các hệ thống liên quan được coi là "đáng tin cậy". Điều này thật không may vì nó giúp cuộc sống của kẻ tấn công dễ dàng hơn. Bất kỳ tài nguyên nào cần thiết cho cuộc tấn công đều có thể được lấy trên hệ thống bị lỗi thông qua một truy vấn ra ngoài đơn giản hướng tới internet. Việc lọc lưu lượng mạng ra ngoài thích hợp có thể là sự khác biệt giữa một nỗ lực hack thành công và thất bại.

Việc thiếu lọc lưu lượng ra ngoài cũng khiến kẻ tấn công dễ dàng trích xuất dữ liệu (exfiltrate data) hơn. Và vấn đề là: bất kỳ giao thức IP nào cũng có thể được sử dụng để trích xuất dữ liệu, bao gồm cả DNS.

Cách thức hoạt động như sau: kẻ tấn công có một miền và chạy máy chủ tên ủy quyền (authoritative nameserver) có thể truy cập từ internet cho miền đó. Bây giờ, kẻ tấn công có thể thực hiện các yêu cầu DNS đến miền đó như sensitivedata.evil.domain từ hệ thống bị hack và có thể trích xuất tất cả dữ liệu từ nhật ký máy chủ DNS độc hại.

Mặc dù máy chủ bị hack có thể không thể tương tác trực tiếp với máy chủ DNS do kẻ tấn công kiểm soát, nhưng bằng cách đưa ra các yêu cầu DNS cho miền do kẻ tấn công kiểm soát, các yêu cầu này sẽ vượt qua máy chủ DNS chuyển tiếp cục bộ và được chuyển tiếp tới máy chủ DNS ủy quyền do kẻ tấn công kiểm soát. Xem thêm các công cụ như dnscat2 hoặc iodine.

Do rủi ro này, có lý do để lập luận rằng ít nhất là không cho phép hệ thống truy vấn các bản ghi DNS công cộng. Vì máy chủ có thể cần tương tác với các dịch vụ trên internet (máy chủ cập nhật, API, v.v.), quyền truy cập đó có thể được tạo điều kiện thuận lợi thông qua một máy chủ proxy sử dụng danh sách các miền được cho phép (allow-listed domains).

Đánh giá và kết luận

Cuối cùng, mọi thứ đều là sự đánh đổi, nơi mọi người phải cân bằng lợi ích và bất lợi dựa trên bối cảnh hạ tầng, khẩu vị rủi ro cụ thể của họ và thậm chí cả cấu trúc và văn hóa tổ chức.

Điều đó nói rằng, tôi nghĩ rằng việc khám phá xem liệu có thể tránh hoàn toàn DNS trong hạ tầng CNTT để tăng độ tin cậy và sự mạnh mẽ là điều hợp lý.

Hãy chia sẻ suy nghĩ và cảm xúc của bạn về vấn đề này nếu bạn muốn.

Đừng quên các dịch vụ như NTP hay ICMP.

Tôi đã chứng minh cuộc tấn công này bằng phương pháp chính xác này với một miền tôi sở hữu cho một khách hàng từng nghĩ rằng họ đã ngăn chặn đúng cách lưu lượng ra ngoài, bao gồm cả việc chặn NTP và ICMP.