Biến các chỉ báo mối đe dọa của Cloudflare thành quy tắc WAF thời gian thực
Không khó để kết nối thông tin tình báo về mối đe dọa với công cụ quy tắc. Điều khó khăn là tích hợp các kết quả dương tính giả, thu hồi và phạm vi vào quy trình.
Ngay khi chỉ báo mối đe dọa xâm nhập vào hệ thống, các quy tắc sẽ bắt đầu chặn lưu lượng truy cập. Hành động này trông rất gọn gàng. Tốc độ nhanh, phản hồi nhanh và báo cáo đẹp. Nhưng một khi thứ này được đưa vào sản xuất, khó khăn thực sự không còn là biến chỉ báo thành quy tắc nữa mà là làm cho quy tắc này chống lại lưu lượng truy cập, dương tính giả và phản hồi.
Khi tôi đọc Biến các chỉ báo mối đe dọa của Cloudflare thành các quy tắc WAF thời gian thực, điều tôi nghĩ đến không phải là những từ hoa mỹ “tự động truy cập thông minh”, mà là một số hình ảnh rất thực tế: một IP được đánh dấu màu đỏ và bị chặn mười phút sau đó; ASN được đánh dấu là có rủi ro cao và kết quả là toàn bộ lối thoát chung có liên quan; một mẫu tấn công tồn tại trong thời gian ngắn vừa xâm nhập vào cơ sở quy tắc và lưu lượng tấn công đã bị cắt bỏ, để lại quy tắc cũ vẫn tiếp tục có hiệu lực. Ở đây, thời gian thực không chỉ liên quan đến tốc độ mà còn nén vòng đời quy tắc, độ tin cậy của dữ liệu và trách nhiệm xử lý vào cùng một cửa sổ.
Quy tắc có thể nhanh chóng, miễn là chúng có thể được rút lại
Khi một chỉ báo về mối đe dọa xâm nhập vào WAF, người mất kiên nhẫn đầu tiên thường không phải là kẻ tấn công mà là người đang làm nhiệm vụ. Bởi vì một khi quy tắc có hiệu lực, những gì tiếp theo không phải là “cải thiện bảo mật” trừu tượng, mà là các tổn thương do tai nạn cụ thể, kháng cáo, hủy bỏ và kiểm tra. Các chỉ báo cấp độ IP là dễ ủy quyền nhất. Chúng có đòn đánh một điểm, thời gian sống sót ngắn và chi phí hồi phục thấp. Các chỉ số như ASN, phân đoạn mạng, dấu vân tay TLS và kết hợp yêu cầu thận trọng hơn nhiều. Chúng bao phủ một diện tích lớn hơn và có nhiều tác dụng phụ khó khăn hơn khi đánh.
Phần thực sự có giá trị của điều này là các quy tắc không được viết một lần rồi thực hiện mà xuất hiện với các điều kiện TTL, nguồn, phạm vi truy cập và hoàn tác. Nếu không có các trường này, các quy tắc thời gian thực sẽ nhanh chóng biến thành một loạt các bản ghi lệnh cấm đã hết hạn. Nếu bạn chặn một cuộc tấn công hôm nay, bạn sẽ bắt đầu chặn người dùng bình thường vào ngày mai. Mùi hôi thường gặp nhất trong sản xuất là cơ sở quy tắc ngày càng dày đặc, thứ đọng lại không phải là khả năng phán đoán hiệu quả mà là những cảm xúc lịch sử.
Nên để lại một vùng đệm giữa lớp chỉ báo và lớp hành động.
Tất nhiên, chuyển trực tiếp các chỉ báo mối đe dọa sang quy tắc chặn là nhanh nhất, nhưng bước này cũng là bước dễ dàng nhất để khuếch đại các lỗi thông minh thành các tai nạn trực tuyến. Một cách tiếp cận ổn định hơn thường là để lại một lớp đệm giữa chỉ báo và hành động, cho phép cùng một tín hiệu đi qua quan sát, thử thách và giới hạn tốc độ trước, sau đó quyết định xem có thực sự chặn nó hay không. Một khi lớp đệm này bị thiếu, các chỉ báo được cập nhật càng nhanh thì các quy tắc sẽ vô tình bị hỏng càng nhanh.
Khi thực sự được triển khai, quy tắc tốt nhất không phải là một công tắc bật/tắt phẳng mà là một tập hợp các trạng thái có thể biểu thị cường độ của hành động: ghi trước, sau đó thử thách, sau đó giới hạn dòng điện và cuối cùng là đưa vào đánh chặn. Lợi ích của việc này rất đơn giản, các quy tắc có thể được nâng cao dần dần khi bằng chứng trở nên mạnh mẽ hơn và có thể nhanh chóng bị hạ cấp khi bằng chứng trở nên yếu hơn. Đối với nhóm bảo mật, điều này có thể duy trì độ tin cậy tốt hơn so với việc điền vào tất cả các quy tắc cùng một lúc; Về phía doanh nghiệp, ít nhất họ cũng có thể nhìn thấy những biến động bất thường khi mới xuất hiện, thay vì đợi đến khi chất đống phiếu chăm sóc khách hàng mới tìm hiểu xem chuyện gì đã xảy ra.
{
"action": "challenge",
"scope": "path:/login",
"ttl": "15m",
"confidence": 0.82
}
Cấu trúc này trông có vẻ đơn giản nhưng thực ra lại rất quan trọng. Khi confidence ở mức thấp, thử thách đầu tiên giống như phán đoán kỹ thuật hơn là đánh chặn trực tiếp; ttl tự động hết hạn sau khi hết hạn để tránh thông tin cũ bị treo bên cạnh; scope được giảm xuống thành một đường dẫn hoặc đoạn lưu lượng để vùng thiệt hại do tai nạn sẽ không bị mở rộng vô hạn.
Nếu không được xem xét, các quy tắc sẽ chỉ dài hơn và trông giống như một đống rác.
Nỗi sợ hãi lớn nhất của WAF thời gian thực không phải là tỷ lệ trúng thấp mà là không ai biết chuyện gì đã xảy ra sau cú đánh. Sau khi các quy tắc được đưa ra, bạn phải có thể nhìn lại ba điều: có bao nhiêu cuộc tấn công thực sự đã bị chặn, bao nhiêu yêu cầu bình thường vô tình bị giết và liệu có phương pháp bỏ qua mới sau các cú đánh hay không. Chỉ bằng cách kết nối ba điều này, quy tắc mới có thể được coi là có thể hoạt động và duy trì được; không có bất kỳ cái nào trong số chúng, cuối cùng nó sẽ trở thành một hành động quán tính “dù sao thì hãy chặn nó trước”.
Đây cũng là phần bị đánh giá thấp nhất trong quá trình tự động hóa chỉ báo mối đe dọa. Có thể có nhiều nguồn chỉ báo và cập nhật thông tin có thể thường xuyên, nhưng nếu không có vòng phản hồi ổn định, các quy tắc sẽ luôn được đẩy về phía trước. Một hệ thống thực sự trưởng thành sẽ ghi lại tỷ lệ trúng, số lần khôi phục, số lần phát hành thủ công, các cảnh báo liên quan và tổn thất kinh doanh của từng quy tắc. Tại thời điểm này, các quy tắc không còn đơn giản là cấu hình bảo mật nữa mà là xử lý các bản ghi với chuỗi bằng chứng.
Bộ công cụ này chỉ phù hợp với những đội đã có sẵn khả năng xử lý
Việc biến các chỉ báo mối đe dọa thành quy tắc WAF trong thời gian thực không phù hợp với mọi tình huống. Đối với các hệ thống có lưu lượng truy cập nhỏ, bề mặt tấn công hẹp và hoạt động thủ công đủ nhanh, việc tiếp tục dựa vào các quy tắc tĩnh và cập nhật thủ công thường sẽ rắc rối hơn. Những người thực sự cần khả năng này thường là các đội có lưu lượng truy cập lớn, mật độ tấn công cao, thay đổi quy tắc thường xuyên và đã có quy trình ghi nhật ký, đánh giá và làm nhiệm vụ.
Khi loại hệ thống này được triển khai, giá trị không chỉ là “dừng nhanh hơn”. Điều quan trọng hơn là chuyển đổi việc xử lý an toàn từ phán đoán thủ công một lần thành chuỗi thực thi có thể hủy bỏ, có thể xem xét và phân loại. Ưu điểm của một nền tảng như Cloudflare khi thực hiện điều này không chỉ là nó có thể nhận được nhiều tín hiệu đe dọa hơn mà còn có khả năng đẩy các tín hiệu đến lớp quy tắc, sau đó kết nối lớp quy tắc trở lại để giám sát, khôi phục và kiểm tra. Nếu không có chuỗi này, thời gian thực sẽ chỉ khiến lỗi xảy ra nhanh hơn; với chuỗi này, các quy tắc có thể thực sự được đưa vào sản xuất.
What to read next
Want more posts about 后端?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #AI?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home