[CrowdSec] – Phần 11 – Scenarios

Scenarios trong CrowdSec là các tập hợp cấu hình được sử dụng để phát hiện các hành vi xâm nhập hoặc đe dọa trong dữ liệu log. Chúng định nghĩa các quy tắc và điều kiện để xác định khi một sự kiện cụ thể phù hợp với một hành vi xâm nhập cụ thể nào đó. Scenarios có thể phát hiện các loại tấn công hoặc hành vi đáng ngờ khác và tạo ra các cảnh báo dựa trên các mẫu và quy tắc được định nghĩa.

Mỗi kịch bản có các thành phần cấu hình như biểu thức (expression), dung lượng (capacity), tốc độ rò rỉ (leakspeed), và nhãn (labels) để xác định cách nó hoạt động. Kịch bản này sẽ xác định loại log nào nên theo dõi, cách xác định các mẫu tấn công hoặc hành vi không mong muốn, và cách tạo ra cảnh báo khi phát hiện một hành vi đáng ngờ.

Scenarios chủ yếu dựa vào việc so sánh các sự kiện log với các mẫu và quy tắc được xác định trong cấu hình của chúng. Khi một sự kiện khớp với một kịch bản, nó có thể dẫn đến việc tạo ra cảnh báo, quyết định về việc chặn hoặc đưa ra các biện pháp phòng ngừa khác.

Dưới đây là giải thích chi tiết từng phần cách kịch bản (scenario) hoạt động trong CrowdSec:

• Event và Filter: Sự kiện (event) được gửi vào Scenarios (đây là các file YAML mô tả cách phát hiện một hành vi cụ thể, thường là một cuộc tấn công) và trước hết đi qua một bước gọi là bộ lọc (filter). Bộ lọc quyết định liệu sự kiện có đủ điều kiện để “nhập” vào bucket hay không. Nếu biểu thức trong bộ lọc là đúng (true), sự kiện được chấp nhận vào bucket.
• Groupby and Segmenting: Một biểu thức tùy chọn được gọi là “groupby” cho phép phân chia dựa trên các yếu tố như source_ip (địa chỉ IP nguồn). Điều này đảm bảo mỗi địa chỉ IP nguồn có Bucket riêng của nó và được tính toán một cách chính xác.
• Distinct Expression: Biểu thức riêng biệt (distinct expression) có thể được sử dụng để loại bỏ các mục có thuộc tính trùng lặp. Ví dụ sử dụng là trong trường hợp kiểm tra các yêu cầu “bad” URI trong http-sensitive-files, nó được sử dụng để đảm bảo rằng chúng ta chỉ đếm các URI “bad” riêng biệt đang được yêu cầu.
• Leaky Bucket and Overflow: Sự kiện cuối cùng được đưa vào bucket. Bucket có hai tham số quan trọng là “capacity” và “leakspeed” quyết định khi và nếu một Overflow xảy ra. Nếu bucket đầy, nó có thể được xác nhận thông qua một bộ lọc overflow_filter.
  • Leaky Bucket nó được ví dụ như 1 cái bể để chứa nước và dưới đây là các tham số quan trọng của bể chứa nước này (Bucket Parameters):
    • Capacity (Sức chứa): Đây là dung lượng tối đa của bể. Nó quyết định được bao nhiêu sự kiện có thể được lưu trữ trong bể. Khi bể đạt đến sức chứa, nó không thể chứa thêm sự kiện nào khác và sự kiện mới sẽ không được thêm vào nữa.
    • Leak Speed (Tốc độ rò rỉ): Đây là tốc độ với mà thông tin trong bể bị mất đi theo thời gian. Nếu tốc độ rò rỉ là 0, bể sẽ không mất mát dữ liệu và sức chứa của nó sẽ bị tiêu hao bởi các sự kiện liên tục được thêm vào. Nếu tốc độ rò rỉ khác 0, các sự kiện sẽ bị loại bỏ khỏi bể sau một khoảng thời gian cố định.
  • Overflow (Tràn): Khi bể đã đạt đến sức chứa tối đa và không còn khả năng chứa thêm sự kiện nào khác, sự kiện cuối cùng cố gắng thêm vào bể sẽ gây ra một “Overflow.” Điều này xảy ra khi không còn đủ dung lượng trong bể để chứa sự kiện mới.
  • Bộ lọc tràn (Overflow Filter): Sau khi xảy ra sự kiện tràn, CrowdSec có thể sử dụng một bộ lọc để xác định xem sự kiện nào sẽ được lưu lại hoặc xử lý tiếp theo và sự kiện nào sẽ bị loại bỏ. Bộ lọc này có thể dựa trên các quy tắc cụ thể hoặc điều kiện nào đó mà bạn đã cấu hình trước đó.
• Xử lý sau khi có một hành động đã được thực thi (Postoverflows): Sau khi Overflow xảy ra, sự kiện sẽ được xử lý thông qua các bộ phân giải được đặt tên là “postoverflows”. Các bộ phân giải này thường chứa danh sách trắng bổ sung, ví dụ như việc xóa quyết định từ một tên miền cụ thể.
• Quyết định (Decision): Cuối cùng, sau khi đã xử lý, sự kiện có thể trở thành một quyết định tiềm năng được gửi cho CrowdSec để xem xét tiếp.