Falco được biết đến như một công cụ của Kubernetes, và gần như mọi hướng dẫn về nó đều viết cho các cụm. Nhưng nó không gắn với cụm: nó theo dõi các lời gọi hệ thống, và trên một máy chủ thông thường có trang web thì nó hoạt động y hệt như vậy. Chỉ có điều gần như chẳng ai viết về trường hợp này.

Và nó hữu ích ở chỗ các công cụ khác im lặng. Một web shell trên trang web chẳng vi phạm quyền nào, chẳng tạo ra lần đăng nhập thất bại nào, và nếu được viết tay thì cũng chẳng khớp chữ ký nào. Nhưng nó có một hành vi bất thường đối với một máy chủ web: tiến trình PHP-FPM chạy lên một shell. Và đó chính là thứ Falco nhìn thấy.

Nó cảm nhận được gì

Các sự kiện tiêu biểu trên một máy chủ thông thường:

  • một shell sinh ra từ tiến trình của máy chủ web hay của PHP — trên thực tế là dấu hiệu không thể nhầm lẫn của web shell;
  • một chương trình được chạy từ /tmp, /dev/shm hay /var/tmp;
  • việc đọc các tệp nhạy cảm (/etc/shadow, khóa riêng) bởi một tiến trình chẳng liên quan gì tới chúng;
  • thay đổi ở các tệp nhị phân của hệ thống;
  • kết nối đi ra từ một tiến trình lẽ ra không dùng mạng.

Cài đặt

Lựa chọn then chốt nằm ở lúc cài: Falco lấy các lời gọi hệ thống bằng cách nào. Con đường hiện đại dựa trên eBPF và không cần dựng module nhân lẫn không cần header của nhân:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

Module nhân cổ điển cần header và được dựng lại sau mỗi lần cập nhật nhân — và trên một máy chủ mà bản cập nhật được cài tự động thì đó là nguyên nhân lặp đi lặp lại khiến dịch vụ chết. Nếu nhân đủ mới (5.8 trở lên) thì hãy chọn eBPF và quên vấn đề đó đi.

Để chắc chắn rằng các sự kiện thực sự đang đến:

sudo systemctl status falco
sudo journalctl -u falco -n 50

Tiếng ồn và việc dọn nó

Và đây mới là công việc chính. Bộ quy tắc chuẩn thiên về môi trường container, và trên một máy chủ thông thường thì phần đáng kể của nó hoặc không áp dụng được, hoặc kích hoạt liên tục.

Các quy tắc được cung cấp (/etc/falco/falco_rules.yaml) thì không sửa — khi cập nhật tệp sẽ bị thay. Các thay đổi của bạn đi vào /etc/falco/falco_rules.local.yaml, và các quy tắc không mong muốn cũng được tắt ở đó:

- rule: Terminal shell in container
  enabled: false

Trên một máy chủ không có container thì thường phải chỉnh những gì:

  • toàn bộ quy tắc về container — không có container thì chúng chỉ chiếm chỗ trong báo cáo;
  • «Write below etc» — kích hoạt mỗi lần cài gói và mỗi lần bạn sửa một tệp cấu hình. Nó cần ngoại lệ cho apt, dpkg và unattended-upgrades, nếu không sự kiện sẽ đổ về như lũ;
  • «Read sensitive file untrusted» — kích hoạt với các agent giám sát, công cụ sao lưu và các công cụ rà soát như Lynis;
  • việc chạy từ các thư mục tạm — có những ngoại lệ hợp lệ: việc build một ứng dụng, hoặc một trình duyệt tự động mở driver trong thư mục tạm. Những sự kiện như vậy trông đáng lo nhưng giải thích được, và tốt hơn là thêm ngay một ngoại lệ cho đường dẫn cụ thể thay vì mỗi lần lại nghĩ lại từ đầu.

Trình tự hợp lý cũng như với mọi công cụ phát hiện khác: tuần đầu chỉ quan sát và thêm ngoại lệ, rồi sau đó mới coi một sự kiện xuất hiện là tín hiệu. Và quy tắc thì đơn giản — nếu trong báo cáo thường xuyên có những sự kiện bạn không đọc thì nó chẳng làm gì cho bạn cả.

Gửi sự kiện đi đâu

Đầu ra được cấu hình trong /etc/falco/falco.yaml: một tệp, nhật ký hệ thống, hoặc luồng tới một chương trình bên ngoài. Và với một máy chủ thì một tệp kèm việc xoay vòng sau đó là đủ — đừng quên việc xoay vòng, tệp sự kiện cũng lớn lên như mọi nhật ký khác và theo mặc định chẳng ai trông chừng nó.

Và nên dùng mức ưu tiên để phân tách: các sự kiện nghiêm trọng đi tới nơi bạn thấy ngay, còn phần còn lại vào nhật ký chung để xem sau.

Falco và auditd không phải một thứ

Cả hai đều theo dõi các lời gọi hệ thống, nhưng với mục đích khác nhau. auditd ghi lại những gì đang diễn ra để về sau có thể dựng lại bức tranh: nó chẳng đánh giá gì và chẳng báo gì, nó giữ một cuốn nhật ký. Trong khi Falco áp dụng các quy tắc ngay tại thời điểm sự kiện và nói «cái này trông đáng ngờ» — tức là nó cho tín hiệu, chứ không phải bản ghi.

Và giữ cả hai là hợp lý: nhật ký để dựng lại và tín hiệu để phản ứng. Nếu phải chọn một thì auditd hữu ích hơn trên máy chủ mà việc dựng lại chuỗi sự kiện sau sự cố là quan trọng nhất; còn Falco thì ở nơi cần một tín hiệu sớm về một trình đào tiền đang chạy hay một web shell.

Nó có đáng chỗ trên một máy chủ nhỏ không

Câu trả lời trung thực: không phải lúc nào cũng vậy. Falco xử lý các lời gọi hệ thống và trên một máy bận thì ảnh hưởng của nó tới bộ xử lý là cảm nhận được. Và nếu trên máy chủ chỉ có một trang web còn bạn chưa có cả việc theo dõi tính toàn vẹn lẫn cập nhật tự động cho tử tế thì đừng bắt đầu từ nó.

Thời điểm của nó đến muộn hơn — khi những việc cơ bản đã xong và chỉ còn lại câu hỏi rằng trên máy chủ đang xảy ra chuyện gì mà nhật ký không cho thấy. Và có một loại sự kiện mà nó bao phủ tốt hơn cả những công cụ khác cộng lại: cái shell do tiến trình của máy chủ web chạy lên. Các sự kiện được tách theo mức ưu tiên và theo quy tắc trông ra sao — xem ở trang demo bên dưới.