- Tôi viết bài này vì không có nhiều người phản đối việc dùng WAF. Phần lớn kết quả tìm kiếm về WAF đều do các nhà cung cấp WAF viết ra
- WAF được tạo ra từ thời kỳ đầu của Internet, chặn mọi yêu cầu HTTP và đánh giá hàng trăm biểu thức chính quy để chặn các yêu cầu tương tự như SQL, mã shell, v.v.
- Ở giai đoạn đầu của an ninh mạng, WAF có vẻ là một ý tưởng hay, nhưng ngày nay thì không còn như vậy
- Do các vấn đề về hiệu năng, khả năng bị vượt qua, rủi ro khi chính nó trở thành một vector tấn công, và tỷ lệ báo nhầm cao, hiện nay đã có những công nghệ bảo mật tốt hơn
Hiệu năng của WAF rất tệ
- WAF chạy hàng trăm biểu thức chính quy cho mọi yêu cầu, gây suy giảm hiệu năng
- Khi dùng WAF sẽ cần thêm một lượng RAM đáng kể, thời gian upload trung bình tăng, tốc độ xử lý yêu cầu chậm đi, mức sử dụng CPU tăng, và cũng xảy ra chặn nhầm
WAF dễ bị vượt qua
- Trong cuộc cạnh tranh không hồi kết giữa WAF và kẻ tấn công, kẻ tấn công đang chiếm ưu thế
- Có thể vượt qua các quy tắc WAF bằng cách dùng cú pháp phức tạp và kỹ thuật mã hóa
- Ví dụ, tấn công Log4shell không thể bị chặn bằng kiểm tra chuỗi đơn giản, và kẻ tấn công có thể dùng nhiều kỹ thuật né tránh khác nhau (Log4J Lookup)
- Ngoài ra, nếu chèn thêm khoảng 8KB ký tự vô nghĩa nhưng vô hại vào chuỗi tấn công, WAF sẽ không thể tiếp tục buffer trong RAM và bị cắt ngưỡng, khiến nó trở nên vô dụng
WAF là một vector tấn công
- Năm 2019, CapitalOne đã xảy ra sự cố làm rò rỉ 100 triệu đơn đăng ký tín dụng do lỗi cấu hình WAF
- Được biết kẻ tấn công đã đánh lừa WAF gửi yêu cầu tới dịch vụ metadata của EC2 và chuyển thông tin xác thực có thể đọc các tệp nhạy cảm từ S3
- Nói cách khác, có khả năng xảy ra sự cố bảo mật do cấu hình sai WAF
- Phần lớn WAF phức tạp và thường được viết dưới dạng mã nguồn đóng, làm tăng bề mặt tấn công
- Vì là những sản phẩm "doanh nghiệp" đắt đỏ, các công ty nhồi nhét rất nhiều tính năng không cần thiết để nổi bật hơn đối thủ
- Các nguyên tắc bảo mật cơ bản dành cho sản phẩm bảo mật thường bị bỏ qua
Tỷ lệ báo nhầm cao của WAF
- Trong 20 năm qua, các bộ quy tắc WAF mã nguồn mở đã được mở rộng đáng kể để phát hiện các kiểu tấn công mới nhất. Các WAF độc quyền có lẽ cũng làm điều tương tự
- Điều đó có nghĩa là ngày càng có nhiều chuỗi có thể khiến WAF chặn yêu cầu
- Mỗi khi có quy tắc mới xuất hiện, việc mở rộng quy tắc WAF lại làm tăng tỷ lệ báo nhầm
- Các WAF "thế hệ mới" tuyên bố giải quyết vấn đề này bằng cách kiểm tra nhiều yêu cầu hoặc sử dụng hệ thống đánh giá uy tín IP
- Chúng có thể cải thiện tỷ lệ false positive, nhưng không thể giải quyết hoàn toàn vấn đề báo nhầm
- Báo nhầm có thể khiến người dùng và đội ngũ hỗ trợ không có quy trình xử lý rõ ràng
Các lựa chọn thay thế cho WAF
- Cô lập (Isolation): Kỹ thuật giúp một phần của hệ thống dù bị xâm phạm cũng không ảnh hưởng tới phần khác
- Trình duyệt làm điều này bằng cách chạy mọi mã trong các tiến trình sandbox đặc biệt, không có quyền truy cập tùy ý vào cookie, mật khẩu đã lưu, hay các tab khác
- Microservice được thiết kế với tư duy cô lập, nhưng cũng có thể triển khai trong một khối đơn nếu dùng nhiều thư viện và ngôn ngữ khác nhau
- Tính bất biến (Immutability): Loại bỏ cả một lớp tấn công bằng hệ thống tệp chỉ đọc, trình quản lý gói yêu cầu khởi động lại, bản sao lưu chỉ cho phép ghi thêm, v.v.
- Phân tích tĩnh (Static Analysis): Dùng prepared statements để ngăn SQL injection và kiểm tra mã bằng phân tích tĩnh trong pipeline CI
- Bảo mật dựa trên năng lực (Capability-based Security): Không phải mọi API endpoint đều cần quyền truy cập không giới hạn vào cơ sở dữ liệu và hệ thống tệp; hãy áp dụng cách chỉ cấp các quyền thực sự cần thiết
5 bình luận
:+1:
Nếu dùng tổ hợp nginx + naxsi thì có vẻ sẽ không rơi vào một vài trường hợp ở trên. Bộ rule WAF cần được vận hành theo cách mà chính nhà phát triển dịch vụ đảm nhiệm. Chuyên gia bảo mật, do thiết lập các cấu hình mang tính phổ quát mà không hiểu về dịch vụ, sẽ tạo ra tỷ lệ false positive cao, rồi lại xóa từng bộ rule theo từng yêu cầu, khiến WAF mất đi chức năng vốn có của nó.
Tôi đồng ý phần nào về các vấn đề bypass và false positive, nhưng nhìn chung tôi có cảm giác bài viết đang liệt kê những thông tin chưa thật sự chắc chắn như thể đó là sự thật. Khi có thời gian chắc tôi cũng պետք xem cả nội dung gốc. Đặc biệt, việc lấy trường hợp CapitalOne làm vấn đề của WAF cho thấy tác giả bài gốc dường như còn thiếu hiểu biết khá nhiều về WAF. WAF không phải là giải pháp giảm thiểu rủi ro ở mức gốc rễ cho lỗ hổng. Lỗ hổng phát sinh trong code thì cách xử lý đúng đắn là phải giải quyết trong chính code. Nhưng thực tế lại không được như vậy, nên cần có một thứ phù hợp để kiểm tra các input đáng ngờ hoặc mang tính độc hại ở lớp phía trước. Nếu vận hành tốt thì nó thực sự là một con dao rất hữu ích, còn nếu vận hành không tốt thì lại là con dao làm chính mình bị thương. Tính hai mặt của công cụ thì lúc nào cũng tồn tại, nhưng chủ đề này có vẻ chỉ làm nổi bật quá mức mặt tiêu cực của nó.
Trong phần bình luận trên Hacker News có nhiều ý kiến và phản biện khác nhau về vấn đề này. Hãy cùng tham khảo: https://news.ycombinator.com/item?id=38255004