Quản lý Log tập trung cho Thiết bị mạng và Firewall với ELK Stack

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

Cơn ác mộng mạng lúc 2 giờ sáng

Lúc đó là 2 giờ 14 phút sáng ngày thứ Ba, một core switch trong trung tâm dữ liệu chính của chúng tôi bắt đầu bị rớt khoảng 15% gói tin. Màn hình của tôi là một biển cảnh báo đỏ rực, nhưng nguyên nhân “tại sao” vẫn nằm trong bóng tối.

Trong vòng mười phút, tôi đã mở 12 cửa sổ SSH, điên cuồng theo dõi log (tail log) trên các switch Cisco Nexus, router biên Juniper và một cặp firewall FortiGate 600F. Việc đối chiếu dấu thời gian (timestamp) từ một sự kiện ‘deny’ trên firewall với sự thay đổi spanning-tree trên switch giống như đang cố gắng giải một câu đố trong khi các mảnh ghép đang tan chảy. Hai giờ gián đoạn trôi qua trước khi tôi tự tay dùng grep lọc đủ các tệp văn bản để tìm ra vòng lặp (loop).

Đây là cái giá bạn phải trả cho việc quản lý log phân tán. Khi dữ liệu của bạn nằm trong các hệ thống riêng biệt, bạn không chỉ chậm chạp mà còn đang điều hành trong mù quáng. Việc chuyển đổi từ ứng phó sự cố bị động sang quản lý hạ tầng chủ động đòi hỏi một bước đi cụ thể: tập trung hóa mọi byte dữ liệu telemetry mà phần cứng của bạn tạo ra.

Tại sao Log phân tán lại thất bại

Vấn đề không chỉ nằm ở nơi lưu trữ log; mà là chúng rất tạm thời (ephemeral). Các thiết bị mạng nổi tiếng với việc có bộ đệm vòng (circular buffer) lưu trữ rất nhỏ. Trên một liên kết 10Gbps bận rộn, một switch có thể ghi đè log của nó sau mỗi 30 phút. Nếu bạn không nhìn vào “bằng chứng xác thực” ngay lập tức, nó sẽ biến mất mãi mãi.

Định dạng không nhất quán lại thêm một rào cản khác. Một log từ Cisco IOS hầu như không có điểm chung nào với log traffic của Palo Alto hay một mục nhập iptables trên Linux. Nếu không có cách nào để chuẩn hóa chúng thành một schema duy nhất có thể tìm kiếm được, việc đối chiếu chéo giữa các thiết bị là không thể. Bạn không thể đơn giản hỏi: “IP 10.0.5.42 đã chạm vào những thiết bị nào trong năm phút qua?” mà không đăng nhập vào từng nút (hop) trên đường truyền.

So sánh: Grep vs. Splunk vs. ELK

Tôi đã đánh giá ba hướng đi khác nhau để giải quyết vấn đề này:

  • Cách thủ công (Grep/Rsyslog): Bạn gửi mọi thứ đến một máy chủ Linux trung tâm qua Syslog. Cách này miễn phí và bắt đầu nhanh, nhưng tìm kiếm qua 100GB tệp văn bản thô là một cực hình chậm chạp. Bạn không có sự trực quan hóa và cũng không có cảnh báo tự động.
  • Cách doanh nghiệp (Splunk): Đây là tiêu chuẩn vàng vì có lý do của nó—nhanh, bóng bẩy và mạnh mẽ. Tuy nhiên, mô hình cấp phép dựa trên dung lượng. Đối với một mạng tạo ra 50GB log firewall mỗi ngày, chi phí bản quyền hàng năm có thể dễ dàng vượt quá ngân sách phần cứng của bạn.
  • Cách của dân kỹ thuật (ELK Stack): Elasticsearch, Logstash và Kibana. Thiết lập này cung cấp sức mạnh của một hệ thống SIEM chuyên nghiệp với sự linh hoạt của mã nguồn mở. Bạn sở hữu dữ liệu, bạn kiểm soát việc phân tích (parsing) và bạn có thể mở rộng cluster khi lưu lượng truy cập tăng lên.

Đối với hầu hết các đội ngũ, ELK là lựa chọn lý tưởng. Nó cung cấp khả năng hiển thị cao cấp mà không gây ra “cú sốc hóa đơn” như các công cụ độc quyền.

Xây dựng Pipeline ELK

Một chiến lược quản lý log thành công không chỉ là về lưu trữ; nó là về sự biến đổi. Chúng ta cần một pipeline để thu thập, phân tích, lập chỉ mục và trực quan hóa. Đây là kiến trúc tôi sử dụng cho các môi trường production.

1. Tinh chỉnh Elasticsearch

Elasticsearch là động cơ chính. Đối với một mạng quy mô trung bình, một node đơn lẻ có thể hoạt động, nhưng bạn phải ưu tiên bộ nhớ. Trong môi trường Linux, hãy vào /etc/elasticsearch/jvm.options để thiết lập dung lượng heap. Mục tiêu là 50% RAM hệ thống, tối đa ở mức 31GB để giữ cho các con trỏ nén (compressed pointers) hoạt động hiệu quả:

# Với VM có 8GB RAM, cấp phát 4GB cho heap
-Xms4g
-Xmx4g

2. Logstash: Trình thông dịch dữ liệu

Logstash là nơi phép màu xảy ra. Nó lắng nghe lưu lượng Syslog đến (UDP/514), chia nhỏ các chuỗi văn bản hỗn độn thành các trường sạch sẽ như src_ipaction, rồi chuyển chúng đến Elasticsearch. Hãy tạo /etc/logstash/conf.d/network-logs.conf:

input {
  syslog {
    port => 514
    type => "syslog"
  }
}

filter {
  if [type] == "syslog" {
    # Phân tích định dạng Cisco cụ thể bằng Grok pattern
    grok {
      match => { "message" => "%{CISCOFW1}" }
    }
    # Ánh xạ nguồn gốc địa lý của các IP ngoại mạng
    geoip {
      source => "src_ip"
    }
  }
} 

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "network-logs-%{+YYYY.MM.dd}"
  }
}

Tôi đặc biệt khuyên dùng filter geoip. Việc nhìn thấy một bản đồ nhiệt (heat map) về các nỗ lực kết nối bị chặn sẽ hữu ích hơn nhiều cho một báo cáo bảo mật so với một danh sách các địa chỉ IP thô từ Trung Quốc hay Nga.

3. Cấu hình thiết bị phần cứng

Cấu hình thiết bị là bước cuối cùng. Trên một switch Cisco, lệnh rất đơn giản:

logging host 192.168.1.100 transport udp port 514
logging trap informational

Đối với firewall FortiGate, hãy sử dụng CLI để kiểm soát chi tiết:

config log syslogd setting
    set status enable
    set server "192.168.1.100"
    set mode udp
    set port 514
end

Trực quan hóa với Kibana

Khi dữ liệu đã chảy về, Kibana trở thành buồng lái của bạn. Thay vì dùng grep, bạn xây dựng các dashboard trả lời các câu hỏi quan trọng ngay lập tức:

  • Các nguồn bị chặn hàng đầu: Những IP cụ thể nào đang tấn công dồn dập vào biên mạng của bạn?
  • Lưu lượng tăng đột biến: Có sự gia tăng 300% lưu lượng nội bộ không? Đó có thể là một cơn bão broadcast hoặc một quá trình đồng bộ mã hóa tống tiền (ransomware).
  • Nhật ký kiểm tra (Audit Trails): Chính xác thì admin đã chạy những lệnh gì trên core switch lúc 3 giờ chiều?

Lợi ích thực tế (ROI) thực sự xuất hiện trong tab “Discover”. Khi một người dùng báo cáo ‘kết nối chậm‘, bạn có thể lọc theo IP của họ trên mọi switch, router và firewall đồng thời. Bạn sẽ thấy gói tin đi tới core, qua router và có lẽ bị chặn bởi firewall biên—tất cả trong một dòng thời gian thống nhất.

Lời kết

Thiết lập ELK đòi hỏi sự đầu tư ban đầu về thời gian và phần cứng. Tuy nhiên, lần đầu tiên bạn giải quyết một vòng lặp định tuyến phức tạp trong ba phút thay vì ba giờ, hệ thống sẽ tự chứng minh giá trị của nó. Hãy bắt đầu nhỏ. Lập chỉ mục firewall biên trước, sau đó thêm các core switch. Khả năng hiển thị toàn diện không còn là một sự xa xỉ nữa; đối với một kỹ sư hiện đại, đó là cách duy nhất để tồn tại.

Share: