Điều tra số Web thủ công: Săn tìm SQLi và Web Shell qua Log CLI

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Sự cố lúc 2:14 sáng: Một cái nhìn thực tế

2:14 sáng. Thiết bị báo tin reo vang. Bảng điều khiển giám sát hiển thị mức sử dụng CPU tăng vọt 95% trên cụm máy chủ web chính. Bạn SSH vào, chạy lệnh top, và thấy hàng tá tiến trình PHP-FPM đang tranh giành từng chu kỳ xử lý còn trống. Bản năng đầu tiên của bạn là do lưu lượng truy cập tăng đột biến, nhưng lệnh netstat lại tiết lộ các kết nối bất thường ra bên ngoài đến một dải IP độc hại đã biết. Đây không phải là một bài đăng gây sốt (viral). Đây là một vụ xâm nhập đang diễn ra.

Khi hệ thống SIEM của bạn chậm hơn thực tế 5 phút, một giao diện đồ họa (GUI) hào nhoáng sẽ không cứu được bạn. Bạn cần một cửa sổ dòng lệnh (terminal), lệnh grep, và các tệp access.log thô. Hãy coi điều tra số bằng CLI như việc theo dấu vết kỹ thuật số; bạn đang tìm kiếm những dấu chân trên bùn khi cơn bão vẫn đang hoành hành. Làm chủ những kỹ năng thủ công này là điều phân biệt các kỹ sư cấp cao với những người chỉ biết làm theo hướng dẫn (runbooks).

Sự thật gốc: Log thô so với Công cụ tự động

Trong quá trình điều tra, bạn thường phải chọn giữa các bộ bảo mật tự động (WAF, IDS, SIEM) và phân tích CLI thủ công.

  • Công cụ tự động (WAF/SIEM): Những công cụ này rất tuyệt vời để ngăn chặn trong thời gian thực. Chúng sử dụng các dấu hiệu (signatures) để gắn cờ các mẫu rõ ràng như <script>alert(1)</script>. Tuy nhiên, chúng có thể bị vượt qua bởi các kiểu mã hóa thông minh hoặc các mã độc zero-day tùy chỉnh.
  • Phân tích CLI thủ công: Đây là “sự thật gốc”. Bạn sử dụng các tiện ích tiêu chuẩn của Linux—grep, awk, sed, và uniq—để mổ xẻ dữ liệu. Nó nhanh, thô và chưa qua chỉnh sửa.

Một WAF như ModSecurity là tuyến phòng thủ đầu tiên, nhưng điều tra số thủ công mới là “con dao mổ” để khám nghiệm tử thi sau sự cố. Tại sao bộ lọc lại thất bại? Kẻ tấn công có sử dụng mã hóa hex để lách qua regex không? Chỉ có các log thô mới cung cấp chuỗi sự kiện chưa được lọc.

Ưu và nhược điểm của việc sử dụng Terminal

Ưu điểm

  • Tính di động: Mọi máy Linux trên hành tinh đều có grep. Bạn không cần đợi một tệp log 5GB tải lên máy chủ trung tâm trước khi bắt đầu săn lùng.
  • Độ trễ bằng không: Bạn nhìn thấy các yêu cầu ngay tại miligiây chúng được ghi xuống đĩa, bỏ qua các khoảng thời gian trễ trong quá trình nạp dữ liệu của hệ thống log.
  • Sự linh hoạt vô hạn: Bạn có thể viết các biểu thức chính quy (regular expressions) lồng nhau, phức tạp ngay tức thì để bắt được các cuộc tấn công bị che giấu mà những dấu hiệu chuẩn đã bỏ lỡ.

Nhược điểm

  • Sai số: Một lỗi đánh máy trong regex có thể dẫn đến việc bỏ lọt mã độc (false negative). Sự chính xác là tất cả.
  • Lộ trình học tập dốc: Bạn cần hiểu các mã trạng thái HTTP và cách các payload tấn công phổ biến thực sự trông như thế nào khi được mã hóa URL (URL-encoded).
  • Mỏi mắt: Nhìn vào hàng ngàn dòng văn bản trắng trên nền đen khiến bạn dễ dàng bỏ lỡ các bất thường về lưu lượng mà một biểu đồ có thể làm nổi bật ngay lập tức.

Cấu hình: Đừng để bị mù mờ thông tin

Bạn không thể săn lùng những gì bạn không ghi lại. Nếu log của Nginx hoặc Apache chỉ theo dõi địa chỉ IP và URL, bạn đang bỏ lỡ một nửa câu chuyện. Tối thiểu, hãy sử dụng định dạng log “Combined”. Tốt hơn nữa, hãy bao gồm $request_body cho các điểm cuối (endpoints) cụ thể (ngoại trừ trang đăng nhập) và đảm bảo $http_user_agent luôn được ghi lại.

Đừng để việc xoay vòng log (log rotation) làm mất đi bằng chứng của bạn. Trong một vụ xâm nhập, bạn thường cần xem lại 48 hoặc 72 giờ trước đó để tìm ra các đợt thăm dò ban đầu. Nếu máy chủ của bạn đang chịu tải nặng, hãy cân nhắc chuyển log sang một phân vùng đĩa riêng để các hoạt động điều tra số không làm cạn kiệt chu kỳ I/O của hệ điều hành.

Hướng dẫn triển khai: Săn lùng kẻ tấn công

1. Phát hiện SQL Injection (SQLi)

SQL Injection vẫn là cách hiệu quả nhất để trích xuất cơ sở dữ liệu. Kẻ tấn công tìm kiếm các tham số GET dễ bị tổn thương, nơi chúng có thể chèn các lệnh như UNION SELECT hoặc GROUP_CONCAT. Nếu bạn thấy 20 yêu cầu liên tiếp đến cùng một URL với các từ khóa SQL khác nhau một chút, bạn đã tìm thấy một đợt thăm dò.

Tìm kiếm các yêu cầu GET khả nghi bằng lệnh sau:

grep -iE "(select|union|concat|order\s+by|group_concat|information_schema)" /var/log/nginx/access.log

Những kẻ tấn công thông minh sử dụng mã hóa URL để vượt qua các bộ lọc cơ bản. Chúng hoán đổi ' thành %27 hoặc dấu cách thành %20. Sử dụng sed để giải mã các ký tự này trong chế độ xem terminal của bạn để các mẫu trở nên rõ ràng hơn:

grep -iE "(%27|%22|%3B|%2D%2D)" /var/log/nginx/access.log | sed -e 's/%27/'\''/g' -e 's/%20/ /g'

Khi bạn xác nhận một vụ injection thành công—hãy tìm các phản hồi 200 OK ở những nơi lẽ ra là 404—ưu tiên hàng đầu của bạn là thay đổi thông tin đăng nhập. Tôi sử dụng trình tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator cho các bí mật máy chủ mới. Nó chạy hoàn toàn trong trình duyệt, điều này rất quan trọng khi bạn không thể tin tưởng vào môi trường mạng của chính mình.

2. Vạch trần các Web Shell ẩn

Một web shell là một script cửa sau (backdoor) (như .php hoặc .aspx) cung cấp quyền truy cập bền bỉ cho kẻ tấn công. Chúng hiếm khi đặt tên là shell.php. Thay vào đó, nó sẽ được ngụy trang thành legacy_backup.php hoặc ẩn trong một thư mục /uploads/.

Một “dấu hiệu” phổ biến của web shell là một yêu cầu POST đến một tệp lẽ ra không nhận dữ liệu. Sử dụng awk để liệt kê các mục tiêu POST và xếp hạng chúng theo tần suất:

awk '$6 == "\"POST" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

Hãy tìm những trường hợp ngoại lệ. Nếu contact.php có 500 yêu cầu POST, điều đó là bình thường. Nếu assets/js/theme-min.php có 12 yêu cầu POST, rất có thể bạn đã tìm thấy shell của mình. Ngoài ra, hãy kiểm tra các yêu cầu có User-Agent trống hoặc chung chung như curl hoặc python-requests:

awk -F'"' '$6 == "-" {print $1, $2, $4}' /var/log/nginx/access.log

3. Sự bền bỉ và Di chuyển ra bên ngoài

Khi đã có shell, kẻ tấn công thường tải xuống các công cụ hậu khai thác (post-exploitation) như linpeas.sh. Kiểm tra log của bạn để tìm các mã trạng thái 200 liên quan đến địa chỉ IP bên ngoài. Nếu kẻ tấn công khôn ngoan, chúng sẽ xóa .bash_history của người dùng www-data ngay lập tức, vì vậy đừng hoàn toàn dựa vào nó.

Sử dụng lệnh find để xác định mọi tệp đã bị sửa đổi trong thư mục gốc web trong 24 giờ qua:

find /var/www/html -mtime -1 -ls

Đối chiếu các mốc thời gian này với log truy cập của bạn. Ai đã truy cập các tệp này ngay sau khi chúng được tạo? Họ đã truyền các tham số gì? Các bản log sẽ cho bạn câu trả lời.

Lấp đầy các lỗ hổng

Điều tra số không chỉ là tìm kẻ xâm nhập; đó là xác định cánh cửa đang mở. Nếu bạn tìm thấy một web shell, hãy xem log trong 10 phút trước khi nó được tạo. Bạn có thể sẽ thấy một yêu cầu POST đến một plugin dễ bị tổn thương hoặc một biểu mẫu tải lên không được xác thực.

Việc “đào bới” bằng CLI là một công việc cực nhọc, nhưng nó xây dựng một mô hình tư duy về những gì là “bình thường”. Điều này giúp việc phát hiện cái “bất thường” trở nên dễ dàng hơn nhiều vào lần tới khi thiết bị báo tin kêu gào lúc 2 giờ sáng. Hãy giữ cho các công cụ của bạn sắc bén, log chi tiết và mật khẩu của bạn là duy nhất.

Share: