Bài này dành cho tình huống nặng hơn một cảnh báo đơn lẻ: có dấu hiệu cho thấy máy chủ đã bị người khác kiểm soát. Thứ tự việc ở đây khác hẳn, vì làm sai thứ tự thì mất bằng chứng, hoặc mất luôn đường vào máy.
Cảnh báo lẻ từ Endpoint Security thì xem bài “Endpoint Security báo phát hiện mối đe doạ: cần làm gì”. Bài này cho tình huống nghi bị xâm nhập thật.
1. Dấu hiệu nghi bị xâm nhập
Một dấu hiệu lẻ thường có cách giải thích bình thường. Nhiều dấu hiệu cùng lúc thì đáng xử lý theo bài này.
| Dấu hiệu | Vì sao đáng chú ý |
|---|---|
| Tài khoản người dùng lạ, hoặc tài khoản cũ đột nhiên được cấp quyền quản trị | Kẻ xâm nhập cần một đường vào ổn định |
Khoá công khai lạ trong tệp authorized_keys |
Đường vào không cần mật khẩu, tồn tại cả khi đã đổi mật khẩu |
| Tiến trình lạ chiếm CPU cao, nhất là lúc không ai dùng máy | Thường là đào tiền mã hoá hoặc máy đang bị dùng để tấn công nơi khác |
| Kết nối ra ngoài tới địa chỉ không nhận ra | Kênh điều khiển, hoặc dữ liệu đang bị gửi ra |
Tác vụ theo lịch lạ trong crontab |
Cách duy trì chỗ đứng sau khi khởi động lại |
| Nhật ký bị xoá, hoặc có khoảng trống thời gian | Việc hay làm nhất để che dấu vết |
| Tệp lạ trong thư mục website, nhất là thư mục tải tệp lên | Đường vào qua lỗ hổng ứng dụng |
| Thời gian sửa đổi của tệp hệ thống thay đổi bất thường | Tệp hệ thống bị thay bằng bản có cửa hậu |
| Máy gửi thư rác, địa chỉ bị đưa vào danh sách chặn | Hệ quả thường thấy nhất, và cũng là cách phát hiện muộn |
2. Việc đầu tiên: KHÔNG khởi động lại máy
Phản ứng tự nhiên là khởi động lại cho sạch. Đây là việc gây thiệt hại nhất trong tình huống này, vì ba lý do:
- Mất bằng chứng trong bộ nhớ. Tiến trình đang chạy, kết nối đang mở, mã độc chỉ nằm trong bộ nhớ mà không có tệp trên đĩa: tất cả biến mất khi khởi động lại.
- Không làm sạch máy. Gần như mọi mã độc đều cài cách tự khởi động lại cùng máy. Khởi động lại chỉ làm mất bằng chứng, không làm mất mã độc.
- Có loại mã độc chỉ hoạt động sau khi khởi động lại. Vài loại chờ đúng lúc đó để thay tệp hệ thống.
Cũng đừng xoá tệp lạ ngay khi vừa thấy. Chép nó ra một chỗ an toàn trước, vì nó là thứ cho biết kẻ xâm nhập vào bằng đường nào. Không biết đường vào thì dựng lại máy xong sẽ bị vào lại bằng đúng đường đó.
3. Thứ tự việc
Làm theo thứ tự này. Mỗi bước có lý do riêng và thứ tự có chủ đích.
Bước 1: Cách ly máy khỏi mạng, nhưng giữ máy chạy.
Đây là bước duy nhất nên làm ngay, trước cả việc chẩn đoán. Nó chặn việc dữ liệu tiếp tục bị gửi ra và chặn máy tấn công sang máy khác, mà vẫn giữ nguyên bằng chứng trong bộ nhớ.
Cách cách ly tuỳ môi trường. Trên Portal, có thể ngắt kết nối mạng của máy ảo. Nếu đang vào máy bằng SSH và việc ngắt mạng sẽ làm mất đường vào, hãy nhắn cho Cloudzone trước để phối hợp, vì cần giữ một đường vào qua console.
Cách thu hẹp mà vẫn giữ được đường vào, nếu phải tự làm:
# Chi cho phep SSH tu dia chi cua quy Khach hang, chan phan con lai
# THAY <dia-chi-cua-ban> truoc khi chay, va kiem lai mot lan nua
sudo iptables -I INPUT -p tcp --dport 22 -s <dia-chi-cua-ban> -j ACCEPT
sudo iptables -A INPUT -j DROP
sudo iptables -A OUTPUT -d <dia-chi-cua-ban> -j ACCEPT
sudo iptables -A OUTPUT -j DROP
⚠️ Hai lệnh DROP ở trên sẽ cắt mọi kết nối khác, kể cả của chính quý Khách hàng nếu địa chỉ khai sai. Hãy chắc chắn có đường vào qua console trước khi chạy, hoặc để Cloudzone làm phần này.
Bước 2: Ghi lại hiện trạng, trước khi đụng vào gì.
# Ghi het ra mot tep, de con doi chieu ve sau
D=/root/hien-trang-$(date +%Y%m%d-%H%M).txt
{
echo "=== Tien trinh dang chay ==="
ps auxf
echo; echo "=== Ket noi mang dang mo ==="
ss -antp
echo; echo "=== Ai dang dang nhap ==="
w; last -20
echo; echo "=== Tac vu theo lich ==="
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/[$u] /"; done
ls -la /etc/cron.* /etc/crontab 2>/dev/null
echo; echo "=== Dich vu tu khoi dong ==="
systemctl list-unit-files --state=enabled
echo; echo "=== Tai khoan co quyen cao nhat ==="
awk -F: '$3 == 0 {print}' /etc/passwd
echo; echo "=== Khoa SSH da nap ==="
find / -name authorized_keys -not -path '/proc/*' -exec echo "--- {}" \; -exec cat {} \; 2>/dev/null
echo; echo "=== Tep moi bi sua trong 7 ngay, vung he thong ==="
find /etc /usr/bin /usr/sbin /bin /sbin -type f -mtime -7 2>/dev/null
} > "$D" 2>&1
echo "da ghi: $D"
Chép tệp này ra khỏi máy ngay, vì máy đang không đáng tin:
# Chay tu may cua quy Khach hang, keo tep ve
scp <nguoi-dung>@<dia-chi-may>:/root/hien-trang-*.txt ./
Bước 3: Chụp ảnh tức thời toàn máy ảo.
Việc này giữ lại trạng thái đĩa để điều tra sau, và cũng là điều kiện để làm bước 5 mà không mất bằng chứng. Làm trên Portal, hoặc nhắn Cloudzone làm nếu không thấy chức năng này.
Bước 4: Báo cho Cloudzone.
Nhắn qua khung chat ở góc phải màn hình. Gửi đủ bảy thông tin:
- Địa chỉ IP hoặc tên máy chủ.
- Dấu hiệu nào làm quý Khách hàng nghi bị xâm nhập, theo bảng mục 1.
- Thời điểm phát hiện, và thời điểm sớm nhất thấy có dấu hiệu lạ.
- Đã làm những việc gì trên máy kể từ lúc phát hiện.
- Máy đã được cách ly chưa.
- Tệp hiện trạng ở bước 2.
- Dịch vụ nào đang chạy trên máy và có dữ liệu cá nhân của người khác không.
Thông tin thứ tư quan trọng hơn vẻ ngoài của nó. Biết quý Khách hàng đã xoá gì, khởi động lại chưa, đổi mật khẩu chưa thì bên kỹ thuật biết còn bằng chứng nào dùng được.
Thông tin thứ bảy quyết định mức độ: máy có dữ liệu cá nhân của người khác thì ngoài việc kỹ thuật còn có nghĩa vụ thông báo theo quy định pháp luật về bảo vệ dữ liệu cá nhân. Phần này nên hỏi bộ phận pháp chế của quý Khách hàng.
Bước 5: Dựng lại máy, đừng dọn máy cũ.
Đây là kết luận không ai muốn nghe, nhưng nó đúng: một máy chủ đã bị kiểm soát thì không làm sạch lại được một cách đáng tin.
Lý do: kẻ xâm nhập có quyền cao nhất đã có thể thay bất cứ tệp nào, kể cả chính các công cụ dùng để kiểm tra. Công cụ đã bị thay thì nó báo “sạch” trong khi không sạch. Không có cách nào chứng minh một máy như vậy là an toàn.
Cách làm đúng:
- Dựng máy mới từ ảnh hệ điều hành gốc.
- Cài lại phần mềm từ nguồn chính thức, không chép cấu hình từ máy cũ mà không soát.
- Chép sang chỉ dữ liệu, không chép mã nguồn hay tệp thực thi. Nếu phải chép mã nguồn, lấy từ kho mã nguồn, không lấy từ máy cũ.
- Đổi toàn bộ mật khẩu và khoá mà máy cũ biết: mật khẩu cơ sở dữ liệu, khoá truy cập dịch vụ lưu trữ, khoá API, mật khẩu tài khoản quản trị. Mọi thứ nằm trên máy đó phải coi là đã bị lấy.
- Vá lỗ hổng đã bị dùng để vào. Dựng máy mới mà giữ nguyên lỗ hổng cũ thì chỉ kéo dài thời gian.
- Cài Endpoint Security trước khi đưa máy mới ra Internet.
Bước 4 ở danh sách này là bước bị bỏ nhiều nhất, và cũng là bước làm cho việc dựng lại máy trở nên vô ích nếu bỏ qua.
4. Tìm đường vào: ba chỗ hay gặp nhất
Bước 5 ở trên phụ thuộc vào việc trả lời được “vào bằng đường nào”. Ba chỗ chiếm phần lớn các trường hợp:
a. Dò mật khẩu SSH
# Dem so lan dang nhap that bai theo dia chi
sudo grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' \
| sort | uniq -c | sort -rn | head -10
# Cac lan dang nhap THANH CONG, cho nay quan trong hon
sudo grep 'Accepted' /var/log/auth.log | tail -40
Trên AlmaLinux, Rocky, CentOS thì đổi /var/log/auth.log thành /var/log/secure.
Thấy một lượt Accepted vào giờ bất thường từ địa chỉ lạ, ngay sau một loạt Failed password, là gần như kết luận được.
b. Lỗ hổng ứng dụng web
# Tep moi xuat hien trong thu muc website, 14 ngay gan nhat
find /duong/dan/thu-muc-web -type f -mtime -14 \
\( -name '*.php' -o -name '*.jsp' -o -name '*.asp*' \) 2>/dev/null
# Cac lan goi POST vao duong dan la
grep ' "POST ' /var/log/nginx/access.log | awk '{print $7}' \
| sort | uniq -c | sort -rn | head -20
Tệp mã nguồn mới xuất hiện trong thư mục tải tệp lên gần như luôn là dấu hiệu xấu. Thư mục đó không nên chứa tệp chạy được.
c. Phần mềm chưa vá
# Cac goi co ban va bao mat dang cho
sudo apt list --upgradable 2>/dev/null | grep -i security # Ubuntu, Debian
sudo dnf updateinfo list security # AlmaLinux, Rocky
Phần mềm đối diện Internet mà chậm vá vài tháng là nguyên nhân rất thường gặp, nhất là các bộ quản lý nội dung và phần mở rộng của chúng.
5. Sau khi xong: ba việc giảm hẳn khả năng lặp lại
| Việc | Vì sao hiệu quả |
|---|---|
| Tắt đăng nhập SSH bằng mật khẩu, chỉ dùng khoá | Loại bỏ hoàn toàn nhóm nguyên nhân dò mật khẩu, là nhóm phổ biến nhất |
| Gửi nhật ký ra khỏi máy, sang hệ thống log tập trung | Nhật ký nằm trên máy bị xâm nhập thì bị xoá được. Nằm ngoài thì không |
| Đặt lịch vá định kỳ, kèm người chịu trách nhiệm | Vá bảo mật không tự chạy, và không có người phụ trách thì nó không xảy ra |
Hàng thứ hai cũng là thứ làm cho lần sau phát hiện được sớm. Nhiều vụ xâm nhập chỉ bị phát hiện sau vài tuần, và lý do thường là nhật ký trên máy đã bị xoá sạch.
6. Liên hệ
Nghi máy chủ bị xâm nhập thì nhắn qua khung chat ở góc phải màn hình, kèm bảy thông tin ở mục 3 bước 4. Chưa đủ thông tin thì cứ nhắn trước, nói rõ dấu hiệu và tình trạng hiện tại, phần còn lại bổ sung sau.
Việc đáng làm ngay, trước khi tìm hiểu gì thêm: cách ly máy khỏi mạng nhưng giữ máy chạy, và đừng khởi động lại.