Sự cố băng thông lúc 2 giờ sáng: Tại sao log là chưa đủ
Tháng trước, một đợt băng thông tăng vọt lên tới 850 Mbps đã đánh vào một trong những cụm production của tôi lúc 2:14 sáng. Cảnh báo chi phí từ AWS gửi đến còn trước cả khi bảng điều khiển giám sát tiêu chuẩn kịp nhấp nháy. Tôi đã mất một giờ lục lọi đống log và cố gắng chạy tcpdump trên nhiều interface khác nhau, chỉ để nhận ra mình đang mò kim đáy bể trong hàng triệu gói tin. Các công cụ tiêu chuẩn như top hay vnstat cho biết interface đã bị bão hòa, nhưng chúng không thể cho tôi biết ai đang thực hiện việc đó hay lưu lượng đang đi đâu.
Đây chính là lúc phân tích dựa trên luồng (flow-based analysis) thay đổi cuộc chơi. Thay vì xem xét từng gói tin riêng lẻ—điều này tiêu tốn tài nguyên tính toán và không thể mở rộng trên các liên kết 10Gbps+ —chúng ta sẽ nhìn vào metadata. Cách tiếp cận này cho phép bạn nhìn thấy “bức tranh toàn cảnh” trên toàn bộ hạ tầng từ một giao diện duy nhất.
So sánh phương pháp: Bắt gói tin vs. Phân tích luồng
Khi tôi thảo luận với các kỹ sư khác về khả năng hiển thị mạng, họ thường mặc định sử dụng các công cụ bắt gói tin như Wireshark hoặc tcpdump. Chúng không thể thiếu để debug các lỗi giao thức. Tuy nhiên, chúng sẽ thất bại khi bạn cần giám sát môi trường có lưu lượng truy cập cao trong thời gian dài.
Bắt gói tin (Deep Packet Inspection)
Hãy tưởng tượng việc bắt gói tin giống như mở từng chiếc phong bì trong bưu điện để đọc lá thư bên trong. Nó mang lại khả năng hiển thị 100%, bao gồm cả nội dung (payload). Tuy nhiên, nếu có 100.000 phong bì đến mỗi giây, bạn sẽ cần cả một đội quân để đọc chúng. Bạn cũng sẽ hết bộ nhớ để lưu trữ chúng gần như ngay lập tức. Đối với một liên kết 10Gbps chạy hết công suất, bạn sẽ phải ghi khoảng 1,2 GB dữ liệu vào đĩa mỗi giây. Nghĩa là hơn 4 TB dữ liệu mỗi giờ chỉ cho một interface.
Phân tích luồng (Metadata Inspection)
Phân tích luồng giống như việc nhìn vào bên ngoài phong bì. Bạn ghi lại địa chỉ người gửi, địa chỉ người nhận, dấu thời gian và trọng lượng. Bạn không biết bức thư nói gì, nhưng bạn biết chính xác ai đang nói chuyện với ai và họ đang trao đổi bao nhiêu dữ liệu. Đây là những gì NetFlow và sFlow thực hiện. Chúng tổng hợp các gói tin thành các “luồng” (flows) dựa trên bộ 5 tham số (5-tuple): IP nguồn, IP đích, Port nguồn, Port đích và Giao thức.
Làm chủ kỹ năng này là điều thiết yếu. Nó cho phép bạn duy trì một hạ tầng ổn định, hiệu suất cao mà không tốn quá nhiều chi phí cho phần cứng giám sát.
Ưu và nhược điểm: NetFlow, sFlow và IPFIX
Việc chọn đúng giao thức phụ thuộc rất nhiều vào phần cứng của bạn. Tôi đã làm việc với cả ba trong môi trường production. Dưới đây là cách chúng so sánh với nhau.
- NetFlow (v5/v9): Vốn là một giao thức độc quyền của Cisco, hiện đã được hỗ trợ rộng rãi. NetFlow có trạng thái (stateful). Router sẽ giữ một bộ nhớ đệm các luồng đang hoạt động và xuất chúng khi chúng hết hạn.
- Ưu điểm: Cực kỳ chi tiết và tuyệt vời cho việc kiểm tra bảo mật.
- Nhược điểm: Sử dụng nhiều tài nguyên. Trên một router bận rộn, bảng lưu lượng với 100.000 mục hoạt động có thể dễ dàng ngốn sạch hơn 200MB RAM.
- sFlow (Sampled Flow): Một tiêu chuẩn đa nhà cung cấp. Không giống như NetFlow, sFlow không trạng thái (stateless). Nó lấy 1 gói tin trong mỗi N gói—ví dụ: 1 trong 2.048 gói—và gửi header đến bộ thu thập (collector).
- Ưu điểm: Gần như không tốn tài nguyên trên switch. Hoàn hảo cho các liên kết xương sống 40G hoặc 100G.
- Nhược điểm: Đây là một ước tính thống kê. Bạn có thể bỏ lỡ một gói tin đơn lẻ kiểu ‘ping of death’ hoặc các luồng rất nhỏ và ngắn ngủi.
- IPFIX (IP Flow Information Export): Tiêu chuẩn IETF dựa trên NetFlow v9. Đây là phiên bản hiện đại, không phụ thuộc nhà cung cấp của NetFlow.
- Ưu điểm: Khả năng mở rộng cao. Nó có thể xuất dữ liệu không phải IP và các trường tùy chỉnh như URL HTTP hoặc kích thước cửa sổ TCP.
- Nhược điểm: Khả năng hỗ trợ khác nhau. Bạn sẽ không tìm thấy nó trên các phần cứng cũ lỗi thời.
Thiết lập: ntopng, nProbe và softflowd
Đối với một stack mã nguồn mở mạnh mẽ, tôi khuyên dùng ntopng kết hợp với nProbe hoặc softflowd. ntopng xử lý việc trực quan hóa dữ liệu. Các thành phần khác đóng vai trò là bộ xuất (exporter) hoặc bộ thu thập (collector). Bạn không cần một switch Cisco đắt tiền để bắt đầu. Bạn có thể cài đặt một bộ xuất phần mềm trên các gateway Linux để biến chúng thành các nút báo cáo luồng.
Kiến trúc
- Exporters: Các router hoặc server Linux chạy
softflowd. Chúng theo dõi lưu lượng và gửi các bản ghi luồng đến bộ thu thập. - Collector/Analyzer:
ntopng. Nó nhận các bản ghi này và lưu trữ chúng vào một cơ sở dữ liệu như ClickHouse. Sau đó, nó cung cấp một giao diện web.
Triển khai: Thiết lập ntopng trên Ubuntu
Hãy chạy thử nghiệm trên hệ thống Ubuntu. Chúng ta sẽ sử dụng ntopng cho dashboard và softflowd làm bộ xuất dữ liệu.
1. Cài đặt ntopng
Thêm kho lưu trữ ntop chính thức để có phiên bản ổn định mới nhất. Tránh các phiên bản trong kho mặc định của Ubuntu vì chúng thường cũ hơn ba năm và thiếu các tính năng hiện đại.
# Thêm repository ntop
wget http://apt.ntop.org/$(lsb_release -sc)/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
# Cập nhật và cài đặt
sudo apt update
sudo apt install ntopng nprobe
2. Cấu hình ntopng
Chỉnh sửa tệp cấu hình. Chúng ta muốn ntopng hoạt động như một bộ thu thập thay vì chỉ nghe lén một interface cục bộ.
sudo nano /etc/ntopng/ntopng.conf
Thêm các dòng sau để thu thập dữ liệu trên cổng 5555 qua ZeroMQ:
-i=view:all
-i=tcp://127.0.0.1:5555
-w=3000
-d=/var/lib/ntopng
3. Thiết lập softflowd
Nếu router của bạn không hỗ trợ NetFlow, hãy sử dụng softflowd ngay trên chính server đó. Công cụ này biến máy Linux của bạn thành một thiết bị có khả năng chạy NetFlow.
sudo apt install softflowd
# Xuất lưu lượng eth0 sang bộ thu thập trên cổng 2055
sudo softflowd -i eth0 -n 127.0.0.1:2055 -v 9
4. Cầu nối với nProbe
ntopng thường sử dụng nProbe làm proxy. nProbe thu thập NetFlow thô (cổng 2055) và chuyển tiếp tới ntopng (cổng 5555) theo định dạng mà nó hiểu hoàn hảo.
# Thu thập NetFlow trên cổng 2055 và chuyển tiếp tới ntopng trên cổng 5555
sudo nprobe --zmq "tcp://*:5555" -i none -n none --collector-port 2055
Xử lý sự cố trong thực tế
Khi bạn đăng nhập vào dashboard tại http://IP-server-cua-ban:3000, bạn sẽ thấy một lượng lớn dữ liệu. Đây là cách tôi sử dụng nó khi có sự cố xảy ra:
- Tìm kiếm ‘Top Talkers’: Sắp xếp phần Hosts theo thông lượng (throughput). Có lần tôi đã tìm thấy một script sao lưu bị cấu hình sai đang cố gắng đồng bộ 1,5 TB dữ liệu trong giờ cao điểm bằng cách này. Chỉ mất 30 giây để tìm ra.
- Phát hiện DDoS: Kiểm tra tab Flows. Nếu bạn thấy 50.000 luồng từ các IP bên ngoài duy nhất đến một IP nội bộ—tất cả đều có số byte thấp—bạn đang đối mặt với một cuộc tấn công SYN flood.
- Khả năng hiển thị ứng dụng: ntopng sử dụng nDPI để đoán ứng dụng. Nó có thể cho bạn biết lưu lượng đã mã hóa đó là bản tải lên AWS S3 hay chỉ là ai đó đang xem Netflix trong văn phòng.
Hãy để ý các cài đặt ‘Flow Expiration’. Nếu luồng hết hạn quá nhanh, biểu đồ của bạn trông sẽ rất rời rạc. Nếu chúng hoạt động quá lâu, dữ liệu ‘thời gian thực’ sẽ có cảm giác bị trễ. Hãy đặt các luồng hoạt động hết hạn sau mỗi 60 giây để có sự cân bằng tốt nhất.
Chuyển sang giám sát dựa trên luồng mang lại cho bạn cái nhìn bao quát cần thiết cho các mạng hiện đại. Trong khi việc bắt gói tin giải thích ‘cách thức’, NetFlow cho bạn biết ‘ai, cái gì và ở đâu’. Thêm cả hai vào bộ công cụ của bạn sẽ đảm bảo bạn không bị mù quáng khi đợt tăng đột biến tiếp theo ập đến.
