không phải cứ có lỗi là vá
trong vụ lỗi của máy chủ DNS, tôi thấy nhiều bạn cứ thắc mắc tại sao tôi nói tự vì kiểm tra là phải kiểm tra xem có người sử dụng dịch vụ của máy chủ DNS có được bảo vệ an toàn hay không, còn việc vá hay không vá là việc tính sau..
cái ý tưởng "có lỗi thì phải vá" thường xuất hiện ở một số bạn nghĩ là mình hiểu về bảo mật nhưng sự thật thì kô hiểu được bao nhiêu. bản thân tôi cũng đã phải mất một thời gian dài mới ngộ được ra vấn đề này, thôi thì hôm nay chia sẻ ở đây.
"có lỗi trong phần mềm tôi đang sử dụng, nên tôi cập nhật nó", một lý lẽ xem ra rất thuyết phục, nếu như không có các ràng buộc từ phía business.
mục tiêu cốt lõi và cuối cùng của một hệ thống không phải là để vá hết lỗi, mà là để phục vụ những yêu cầu của người sử dụng, như họ mong đợi, theo đúng thiết kế ban đầu của hệ thống.
đôi khi, chính cái ràng buộc, chính cái yêu cầu cốt lõi này, làm cho chúng ta phải chấp nhận vận hành một hệ thống, mà trong đó, chúng ta biết là có lỗi có thể bị khai thác. đối với nhiều bạn mới tìm hiểu về bảo mật, sẽ thấy luận điểm này khá là phản trực giác, chạy một hệ thống không an toàn là một điều không thể chấp nhận được đối với họ. rồi cuối cùng họ bị sa thải :-p, bởi hành động vá lỗi, mà họ nghĩ là tích cực, rốt cuộc lại làm tê liệt hoàn toàn hệ thống, làm thiệt hại hàng trăm nghìn, hàng triệu USD.
trở lại với vấn đề DNS. nếu bạn nào theo dõi kỹ sự kiện này, sẽ thấy những cảnh báo sau đây "the patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. Đây là một vấn đề không thể xem nhẹ, nhất là đối với các ISP lớn, bởi lẽ nếu DNS resolver của họ chết, thì toàn bộ cái mục tiêu cốt lõi của họ cũng sẽ đi tong.
ngoài ra, việc vá lỗi, dẫn đến source port sẽ bị ngẫu nhiên hóa, và sẽ có thể dẫn đến những thay đổi lớn trong cấu hình mạng của hệ thống. chẳng hạn như cấu hình firewall hay cấu hình của các thiết bị NAT. mà những thay đổi về cấu hình mạng đôi khi không phải cứ muốn làm là được.
hơn nữa, trong các doanh nghiệp hay ISP to, việc cập nhật phần mềm đối với một hệ thống critical như DNS không phải là việc các tay sysadmin muốn là có thể làm. tất cả những việc này đều có quy trình, và quy trình thì cần có thời gian. một số DNS resolver của AT&T cho đến nay vẫn chưa vá lỗi, bởi họ vẫn đang còn trong giai đoạn thử nghiệm, trước khi triển khai chính thức các miếng vá.
nói cách khác, biết là có lỗi, biết là có thể bị khai thác, biết là người dùng có thể bị ảnh hưởng nhưng vẫn không vá được ngay, thì tại sao phải vội vã hấp tấp vá, nếu như biết là có lỗi, nhưng không thể bị khai thác hay người dùng không bị ảnh hưởng?
đừng nghĩ tôi tự đặt ra những câu hỏi thế này. nếu bạn làm trong lĩnh vực này đủ lâu, sẽ có ngày một ông ở cấp C hỏi bạn câu hỏi này. không thể có chuyện vá chỉ để sướng :-p.
thành ra, nếu như DNS resolver của tôi có lỗi, nhưng do tôi đang forward toàn bộ recursive query đến một DNS forwarder đã vá lỗi, thì tôi chưa cần phải vá lỗi ngay tức thì, bởi lẽ người dùng của tôi vẫn an toàn, nghĩa là cái mục tiêu cốt lõi của hệ thống DNS vẫn được đáp ứng.
thực tế đây chính là một trong những giải pháp được rất nhiều chuyên gia trên thế giới đề nghị, kể cả Dan Kaminsky, và rất nhiều người đã áp dụng nó bằng cách forward các recursive query của họ đến cho OpenDNS, để có thêm thời gian đánh giá vấn đề.
điểm cốt yếu phân biệt giữa những tay nghĩ là họ làm về security với những người thực sự làm về security là mấy tay đầu luôn nghĩ security là một vấn đề kĩ thuật, có thể giải quyết bằng các giải pháp kỹ thuật; còn mấy tay sau, sau vài năm lăn lộn với đám làm business, biết rằng security là một vấn đề của business, không thể tách ra khỏi cái mục tiêu của business, chỉ có thể xem là được giải quyết thành công nếu vẫn đáp ứng được yêu cầu của business.
điều đáng buồn là đa số những người đi làm tư vấn bảo mật, và đa số các công ty tư vấn bảo mật chuyên nghiệp ở VN, mà công việc cho phép tôi gặp khá nhiều, thường chưa từng kinh qua công việc làm bảo mật cho các doanh nghiệp trước đó. mục tiêu của họ là làm sao cho hệ thống an toàn, trong khi mục tiêu cần phải đạt được của doanh nghiệp là các chỉ tiêu kinh doanh. khác mục tiêu, sẽ dẫn đến xung đột :-p.
cái ý tưởng "có lỗi thì phải vá" thường xuất hiện ở một số bạn nghĩ là mình hiểu về bảo mật nhưng sự thật thì kô hiểu được bao nhiêu. bản thân tôi cũng đã phải mất một thời gian dài mới ngộ được ra vấn đề này, thôi thì hôm nay chia sẻ ở đây.
"có lỗi trong phần mềm tôi đang sử dụng, nên tôi cập nhật nó", một lý lẽ xem ra rất thuyết phục, nếu như không có các ràng buộc từ phía business.
mục tiêu cốt lõi và cuối cùng của một hệ thống không phải là để vá hết lỗi, mà là để phục vụ những yêu cầu của người sử dụng, như họ mong đợi, theo đúng thiết kế ban đầu của hệ thống.
đôi khi, chính cái ràng buộc, chính cái yêu cầu cốt lõi này, làm cho chúng ta phải chấp nhận vận hành một hệ thống, mà trong đó, chúng ta biết là có lỗi có thể bị khai thác. đối với nhiều bạn mới tìm hiểu về bảo mật, sẽ thấy luận điểm này khá là phản trực giác, chạy một hệ thống không an toàn là một điều không thể chấp nhận được đối với họ. rồi cuối cùng họ bị sa thải :-p, bởi hành động vá lỗi, mà họ nghĩ là tích cực, rốt cuộc lại làm tê liệt hoàn toàn hệ thống, làm thiệt hại hàng trăm nghìn, hàng triệu USD.
trở lại với vấn đề DNS. nếu bạn nào theo dõi kỹ sự kiện này, sẽ thấy những cảnh báo sau đây "the patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. Đây là một vấn đề không thể xem nhẹ, nhất là đối với các ISP lớn, bởi lẽ nếu DNS resolver của họ chết, thì toàn bộ cái mục tiêu cốt lõi của họ cũng sẽ đi tong.
ngoài ra, việc vá lỗi, dẫn đến source port sẽ bị ngẫu nhiên hóa, và sẽ có thể dẫn đến những thay đổi lớn trong cấu hình mạng của hệ thống. chẳng hạn như cấu hình firewall hay cấu hình của các thiết bị NAT. mà những thay đổi về cấu hình mạng đôi khi không phải cứ muốn làm là được.
hơn nữa, trong các doanh nghiệp hay ISP to, việc cập nhật phần mềm đối với một hệ thống critical như DNS không phải là việc các tay sysadmin muốn là có thể làm. tất cả những việc này đều có quy trình, và quy trình thì cần có thời gian. một số DNS resolver của AT&T cho đến nay vẫn chưa vá lỗi, bởi họ vẫn đang còn trong giai đoạn thử nghiệm, trước khi triển khai chính thức các miếng vá.
nói cách khác, biết là có lỗi, biết là có thể bị khai thác, biết là người dùng có thể bị ảnh hưởng nhưng vẫn không vá được ngay, thì tại sao phải vội vã hấp tấp vá, nếu như biết là có lỗi, nhưng không thể bị khai thác hay người dùng không bị ảnh hưởng?
đừng nghĩ tôi tự đặt ra những câu hỏi thế này. nếu bạn làm trong lĩnh vực này đủ lâu, sẽ có ngày một ông ở cấp C hỏi bạn câu hỏi này. không thể có chuyện vá chỉ để sướng :-p.
thành ra, nếu như DNS resolver của tôi có lỗi, nhưng do tôi đang forward toàn bộ recursive query đến một DNS forwarder đã vá lỗi, thì tôi chưa cần phải vá lỗi ngay tức thì, bởi lẽ người dùng của tôi vẫn an toàn, nghĩa là cái mục tiêu cốt lõi của hệ thống DNS vẫn được đáp ứng.
thực tế đây chính là một trong những giải pháp được rất nhiều chuyên gia trên thế giới đề nghị, kể cả Dan Kaminsky, và rất nhiều người đã áp dụng nó bằng cách forward các recursive query của họ đến cho OpenDNS, để có thêm thời gian đánh giá vấn đề.
điểm cốt yếu phân biệt giữa những tay nghĩ là họ làm về security với những người thực sự làm về security là mấy tay đầu luôn nghĩ security là một vấn đề kĩ thuật, có thể giải quyết bằng các giải pháp kỹ thuật; còn mấy tay sau, sau vài năm lăn lộn với đám làm business, biết rằng security là một vấn đề của business, không thể tách ra khỏi cái mục tiêu của business, chỉ có thể xem là được giải quyết thành công nếu vẫn đáp ứng được yêu cầu của business.
điều đáng buồn là đa số những người đi làm tư vấn bảo mật, và đa số các công ty tư vấn bảo mật chuyên nghiệp ở VN, mà công việc cho phép tôi gặp khá nhiều, thường chưa từng kinh qua công việc làm bảo mật cho các doanh nghiệp trước đó. mục tiêu của họ là làm sao cho hệ thống an toàn, trong khi mục tiêu cần phải đạt được của doanh nghiệp là các chỉ tiêu kinh doanh. khác mục tiêu, sẽ dẫn đến xung đột :-p.
Comments
Thí dụ như tôi kinh doanh vận tải, tôi có 5 cái đầu kéo, và 3 trong số 5 cái đầu kéo có hệ thống thắng bị hư (nhưng vẫn còn xài được), thì tôi không chọn giải pháp đưa 3 cái đầu kéo đó vô xưởng để sửa chữa vì nó làm gián đoạn việc kéo hàng của tôi, mà việc này còn nguy hiểm hơn, vì làm chậm trễ thời gian của khách hàng - những người không quan tâm tới việc cái đầu kéo của tôi có thắng ăn hay không, hehehe...