Lệnh uptime hiển thị 400 days. Hoặc 800 days. Thậm chí có thể là 1,200 ngày.

Bạn cảm thấy tự hào. Máy chủ của bạn trông thật xuất sắc.

Nhưng sự thật mà chỉ các sự cố sản xuất mới dạy bạn: uptime dài thường che giấu nhiều vấn đề hơn là giải quyết chúng.

Tôi đã thấy những máy chủ có uptime hai năm thất bại hoàn toàn sau một lần khởi động lại đơn giản. Con số cao no phải là dấu hiệu của sức khỏe. Đó là dấu hiệu rằng nobody đã nhìn kỹ trong một thời gian rất dài.

Vì vậy, hãy để tôi chia sẻ một danh sách kiểm tra sức khỏe máy chủ Linux đầy đủ. Lần tới khi bạn thấy một máy chủ uptime cao, hãy chạy qua 25 kiểm tra này. Một số nhanh. Một số khác mất một phút. Nhưng cùng nhau, chúng tiết lộ những gì thực sự đang xảy ra bên dưới bề mặt.

Lệnh uptime hiển thị 400 days. Hoặc 800 days. Thậm chí có thể là 1,200 ngày.

Bạn cảm thấy tự hào. Máy chủ của bạn trông thật xuất sắc.

Nhưng sự thật mà chỉ các sự cố sản xuất mới dạy bạn: uptime dài thường che giấu nhiều vấn đề hơn là giải quyết chúng.

Tôi đã thấy những máy chủ có uptime hai năm thất bại hoàn toàn sau một lần khởi động lại đơn giản. Con số cao no phải là dấu hiệu của sức khỏe. Đó là dấu hiệu rằng nobody đã nhìn kỹ trong một thời gian rất dài.

Vì vậy, hãy để tôi chia sẻ một danh sách kiểm tra sức khỏe máy chủ Linux đầy đủ. Lần tới khi bạn thấy một máy chủ uptime cao, hãy chạy qua 25 kiểm tra này. Một số nhanh. Một số khác mất một phút. Nhưng cùng nhau, chúng tiết lộ những gì thực sự đang xảy ra bên dưới bề mặt.

-r

-T

Phần 1: Tài nguyên hệ thống (Những điều cơ bản dối trá)

Các số liệu này trông ổn trên bề mặt. Nhưng uptime cao che giấu sự suy giảm chậm chạp bên dưới.

1. Xem load average 15 phút so với số lượng CPU

1. Xem load average 15 phút so với số lượng CPU

Chạy các lệnh sau:

uptime

nproc

Bạn sẽ thấy ba con số: 1 phút, 5 phút và 15 phút. Xu hướng tải tăng được thể hiện khi số phút 1 cao hơn số phút 15 -- tải đang tích lũy nhanh hơn mức nó được giải phóng. Ngược lại (số phút 15 cao hơn số phút 1) thực sự có nghĩa là tải đang giảm từ một đỉnh trong quá khứ.

Tuy nhiên, câu hỏi thực sự no phải là so sánh ba con số với nhau. Mà là so sánh bất kỳ con số nào trong số đó với số lõi CPU của bạn. Nếu load average 15 phút liên tục vượt quá số CPU trả về bởi nproc, hệ thống của bạn đã bão hòa và công việc đang xếp hàng nhanh hơn mức có thể xử lý.

Những gì cần kiểm tra: Nếu load 1 phút cao hơn load 15 phút, tải đang có xu hướng tăng. Nếu bất kỳ giá trị trung bình nào liên tục vượt quá số lõi CPU, bạn có vấn đề bão hòa. So sánh cả ba con số để biết xu hướng, nhưng luôn neo chúng vào số lõi của bạn.

Bài đọc liên quan:

2. Kiểm tra bộ nhớ available, no phải bộ nhớ free

Chạy lệnh sau:

free -h

Nhìn vào cột available. Bỏ qua free.

total        used        free      shared  buff/cache   available
Mem:            30Gi       8.7Gi        16Gi       1.2Gi       7.2Gi        22Gi
Swap:          975Mi          0B       975Mi

Bộ nhớ available là những gì hệ thống thực sự có thể cấp cho các tiến trình mới mà không cần swap. Nếu con số này tiếp tục giảm tuần này qua tuần khác, bạn có một rò rỉ bộ nhớ chậm.

Những gì cần kiểm tra: Ghi lại bộ nhớ available hôm nay. Kiểm tra lại sau một tuần. Nó có thấp hơn không?

3. Đếm các tiến trình zombie

Chạy các lệnh này:

top -bn1 | grep "zombie"

Hoặc kiểm tra số lượng zombie trực tiếp:

ps aux | awk '$8=="Z" {print $0}' | wc -l

Hoặc

ps -eo stat= | grep -c '^Z'

Một zombie là chuyện thường. Một vài cái là ổn. Nhưng hơn mười zombie tồn tại trong nhiều ngày? Đó là một vấn đề thực sự. Mỗi zombie chiếm một slot trong bảng tiến trình. Nếu bảng đó đầy, no có tiến trình mới nào có thể chạy. Không có phiên SSH mới. Không có kiểm tra giám sát mới. Không có gì.

Những gì cần kiểm tra: Số lượng zombie nên bằng 0 hầu hết thời gian. Một vài cái thỉnh thoảng là ổn. Zombie dai dẳng là no ổn.

Zombie quá nhiều cuối cùng có thể làm cạn kiệt available process IDs hoặc tài nguyên bảng tiến trình.

4. Xác minh sử dụng inode, no chỉ dung lượng đĩa

Chạy lệnh này:

df -i

Dung lượng đĩa được chú ý nhiều. Nhưng inode (cấu trúc dữ liệu lưu trữ thông tin tệp) có thể hết ngay cả khi bạn còn nhiều dung lượng. Khi điều đó xảy ra, bạn no thể tạo tệp mới. Nhật ký ngừng ghi. Dịch vụ sập âm thầm.

Những gì cần kiểm tra: Tìm bất kỳ phân vùng nào có IUse% trên 85%. Đó là dấu hiệu cảnh báo của bạn.

udev            4041811     635  4041176    1% /dev
tmpfs           4060692    1209  4059483    1% /run
/dev/nvme0n1p2 30433280 2949390 27483890   10% /
tmpfs           4060692     434  4060258    1% /dev/shm
tmpfs           4060692      16  4060676    1% /run/lock
efivarfs              0       0        0     - /sys/firmware/efi/efivars
/dev/nvme0n1p1        0       0        0     - /boot/efi
tmpfs            812138     268   811870    1% /run/user/1000
/dev/sda1             0       0        0     - /media/ostechnix/SK_WD_SSD
/dev/fuse        262144      40   262104    1% /etc/pve

5. Kiểm tra các tiến trình bị kẹt trong trạng thái ngủ không gián đoạn (trạng thái D)

Chạy lệnh này:

ps aux | awk '$8=="D" {print $0}'

Các tiến trình ở trạng thái D đang chờ trực tiếp trên phần cứng. Chúng no thể bị giết. Ngay cả với -9. Một vài cái là bình thường trong lúc I/O đĩa nặng. Nhưng nếu chúng tồn tại hơn vài phút, có điều gì đó rất sai với hệ thống lưu trữ của bạn.

Những gì cần kiểm tra: Mục tiêu là không có tiến trình trạng thái D bị kẹt. Các tiến trình trạng thái D dai dẳng thường chỉ ra vấn đề lưu trữ, filesystem hoặc network-mounted filesystem.

6. Tìm kiếm sự kiện OOM Killer trong nhật ký

Chạy các lệnh này:

sudo dmesg | grep -i -E "killed process|out of memory|oom"

journalctl -k | grep -iE "oom|out of memory|killed process"

OOM Killer là phương sách cuối cùng của Linux. Khi bộ nhớ cạn kiệt hoàn toàn, kernel bắt đầu giết các tiến trình để tồn tại. Đây không bao giờ là dấu hiệu tốt. Trên máy chủ uptime cao, bạn có thể tìm thấy các sự kiện OOM từ nhiều tháng trước mà bạn chưa từng noticed.

Những gì cần kiểm tra: Bất kỳ sự kiện OOM Killer nào cũng có nghĩa là bạn đã có vấn đề về bộ nhớ. Một sự kiện là cảnh báo. Nhiều sự kiện có nghĩa là bạn có một mô hình.

Phần 2: Đĩa và filesystem (Nơi mục nát xảy ra)

Các máy chủ uptime cao thường mục nát từ filesystem ra ngoài. Các kiểm tra này phát hiện mục nát sớm.

7. Tìm các tệp nhật ký lớn nhất

Chạy các lệnh này:

find /var/log -type f -size +100M -exec ls -lh {} \;

du -sh /var/log/* | sort -hr | head -10

Các tệp nhật ký phát triển mãi mãi nếu logrotate bị hỏng. Và logrotate hỏng thường xuyên hơn bạn nghĩ. Một cron job cấu hình sai hoặc thay đổi quyền từ sáu tháng trước có thể dừng tất cả logrotate một cách âm thầm.

Những gì cần kiểm tra: Bất kỳ tệp nhật ký nào trên 1GB cần được điều tra. Trên 10GB đã là một sự cố. Nói cách khác, tăng trưởng bất ngờ, bất kể kích thước, đều đáng để điều tra.

8. Xác minh logrotate thực sự hoạt động

Chạy các lệnh này:

logrotate --debug /etc/logrotate.conf 2>&1 | head -30

journalctl -u logrotate --since "30 days ago" 2>/dev/null | grep -i "error\|fail"

grep -i "logrotate" /var/log/syslog 2>/dev/null | grep -i "error\|fail" | tail -10

Log rotation có thể thất bại mà không ai noticed. Cron job chạy. Lệnh thoát. Nhưng vấn đề quyền hoặc thư mục thiếu gây ra thất bại âm thầm. Trên máy chủ uptime cao, logrotate có thể đã hỏng trong nhiều năm.

Lưu ý: logrotate no ghi vào tệp /var/log/logrotate.log riêng theo mặc định trên bất kỳ bản phân phối lớn nào. Trạng thái của nó được theo dõi trong /var/lib/logrotate/status và/hoặc /var/lib/logrotate/logrotate.status. Bất kỳ lỗi nào nó gặp phải có thể xuất hiện trong system journal hoặc syslog, đó là nơi các lệnh thứ hai và thứ ba tìm kiếm.

Những gì cần kiểm tra: Đầu ra gỡ lỗi sẽ hiển thị mỗi tệp nhật ký được xử lý mà không có lỗi. Kiểm tra /var/lib/logrotate/status và/hoặc /var/lib/logrotate/logrotate.status, tùy thuộc vào bản phân phối để xác nhận dấu thời gian xoay gần đây cho các tệp nhật ký quan trọng.

Bài đọc liên quan:

9. Kiểm tra mọi mount NFS hoặc mạng

Chạy các lệnh này:

mount | grep -E "nfs|nfs4|cifs"

for mount in $(mount | grep -E "nfs|nfs4|cifs" | awk '{print $3}'); do
timeout 5 ls $mount > /dev/null 2>&1
if [ $? -ne 0 ]; then
echo "STALE: $mount"
fi
done

Các mount NFS cũ rất nguy hiểm. Máy chủ vẫn hoạt động. Mount trông ổn. Nhưng bất kỳ tiến trình nào chạm vào mount đó sẽ treo trong 60 giây hoặc hơn. Các máy chủ uptime cao tích lũy những thứ này chậm chạp, và mỗi mount cũ thêm độ trễ vào mọi thứ kiểm tra nó.

Những gì cần kiểm tra: Mọi mount mạng nên phản hồi ls trong vòng dưới 2 giây. Treo có nghĩa là mount cũ.

Bạn cũng có thể sử dụng lệnh này:

mount | grep -E "nfs|nfs4|cifs" | while read -r line; do
mountpoint=$(echo "$line" | awk '{print $3}')
timeout 5 ls "$mountpoint" >/dev/null 2>&1
done

10. Kiểm tra thời gian chờ I/O đĩa

Chạy lệnh này:

iostat -x 1 5

Nhìn vào cột %iowait và cột await.

iowait cao có nghĩa là CPU của bạn đang dành thời gian chờ đĩa. Tuy nhiên, chỉ iowait có thể gây hiểu lầm trên hệ thống nhiều lõi -- một tiến trình I/O duy nhất trên máy 32 lõi có thể bão hòa một đĩa trong khi hầu như không đăng ký trong iowait. Luôn tương quan nó với giá trị await trên mỗi thiết bị trong iostat -x.

Cột await hiển thị thời gian trung bình tính bằng mili giây từ khi yêu cầu I/O được gửi đến khi hoàn thành. Dưới tải sản xuất, các giá trị trên 20ms trên SATA SSD hoặc trên 5ms trên ổ NVMe đáng để điều tra. Hãy nhớ rằng dưới tải nhẹ, NVMe hiện đại thường hoạt động dưới 1ms và SATA SSD dưới 2ms. Bất kỳ đột biến kéo dài nào trên các ngưỡng dưới tải này đều chỉ ra sự bão hòa thiết bị hoặc suy thoái phần cứng.

Những gì cần kiểm tra: Đừng chỉ dựa vào một con số %iowait duy nhất. Sử dụng iostat -x để kiểm tra giá trị await trên mỗi thiết bị và tìm các thiết bị đang tiến gần 100% %util. Tương quan với thời gian phản hồi ứng dụng để đánh giá xem các con số có phản ánh một nút cổ chai thực sự cho khối lượng công việc của bạn hay không.

Bài đọc liên quan:

11. Tìm các tệp có bit SUID/SGID được đặt

Chạy lệnh này:

find / -perm /6000 -type f 2>/dev/null | grep -v "^/proc"

Bit SUID và SGID cho phép chương trình chạy với đặc quyền nâng cao. Một tập hợp nhỏ là mong đợi trên bất kỳ hệ thống nào -- /bin/su, /usr/bin/passwd, /usr/bin/sudo, và /usr/bin/newgrp là các ví dụ phổ biến. Nhưng theo thời gian, những cái mới có thể xuất hiện. Phần mềm cũ có thể thêm chúng. Cấu hình sai có thể tạo ra chúng. Trên máy chủ uptime cao, những thứ này có thể tích lũy mà không ai noticed.

Lưu ý: trên các bản phân phối Linux hiện đại, một số nhị phân trước đây yêu cầu SUID (như ping) đã được chuyển sang sử dụng Linux capabilities. Nếu bạn thấy một nhị phân có SUID mà bạn no mong đợi -- ngay cả một cái quen thuộc -- thì đáng để xác nhận với gói mặc định của bản phân phối.

Những gì cần kiểm tra: Xem lại danh sách. Bất cứ điều gì không quen thuộc cần được điều tra.

12. Tìm các tệp và thư mục có thể ghi bởi mọi người

Chạy lệnh này:

find / -type f -perm -0002 -ls 2>/dev/null | grep -v "^/proc"

Các tệp có thể ghi bởi mọi người là rủi ro bảo mật. Bất kỳ người dùng nào trên hệ thống đều có thể sửa đổi chúng. Trên máy chủ bận rộn với nhiều người dùng, một tệp cấu hình có thể ghi bởi mọi người có thể dẫn đến leo thang đặc quyền.

Các thư mục có thể ghi bởi mọi người thường nguy hiểm hơn tệp. Chạy lệnh này để kiểm tra thư mục:

find / -type d -perm -0002 -ls 2>/dev/null

Những gì cần kiểm tra: Danh sách nên rất ngắn. Các tệp nhật ký hệ thống đôi khi có thể đọc bởi mọi người nhưng hiếm khi có thể ghi. Bất cứ thứ gì trong /etc hoặc /usr không bao giờ nên có thể ghi bởi mọi người.

Phần 3: Tiến trình và dịch vụ (Sự hỗn loạn đang chạy)

Một máy chủ uptime cao có thể tích lũy các tiến trình lộn xộn như tủ lạnh tích lũy thức ăn cũ.

13. Tìm các tiến trình có thời gian chạy rất dài

Chạy lệnh này:

ps -eo pid,etime,comm,args --sort=-etime | head -20

Các tiến trình đã chạy trong nhiều tháng có thể ổn. Hoặc chúng có thể bị treo, rò rỉ bộ nhớ hoặc no làm gì hữu ích. Trên máy chủ uptime cao, bạn thường tìm thấy các script cũ lẽ ra đã thoát nhưng không bao giờ làm vậy.

Những gì cần kiểm tra: Với mỗi tiến trình cũ, hãy hỏi: Cái này có nên chạy không? Nó có cần chạy không? Có thể khởi động lại sạch sẽ không?

14. Kiểm tra các cron job chồng chéo

Chạy lệnh này:

# User-level crontabs
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null
done
# System-level cron locations (these are where most production jobs actually live)
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ /etc/cron.hourly/

Một cron job mất 15 phút để chạy nhưng chạy mỗi 10 phút tạo ra các tiến trình chồng chéo. Theo thời gian, chúng chất đống. Hệ thống vẫn hoạt động, nhưng chạy tệ hơn mỗi ngày. Uptime cao che giấu những sai sót lịch trình này một cách hoàn hảo.

Trên máy chủ sản xuất, hầu hết các công việc theo lịch sống trong /etc/cron.d/, /etc/crontab, và các thư mục cron.daily/weekly/monthly/hourly -- no phải trong user crontab. Chỉ kiểm tra user crontab bỏ lỡ phần lớn công việc theo lịch trên một máy chủ điển hình.

Những gì cần kiểm tra: Tìm các công việc chạy thường xuyên hơn thời gian chúng hoàn thành. Thêm ghi nhật ký để xem thời gian chạy thực tế.

Bài đọc liên quan:

15. Xác minh trạng thái dịch vụ systemd

Chạy các lệnh này:

systemctl list-units --state=failed

systemctl list-units --state=inactive --all | grep -v "not-found"

Các dịch vụ bị lỗi là rõ ràng. Nhưng các dịch vụ đã dừng "thành công" khi lẽ ra phải chạy thì khó phát hiện hơn. Trên máy chủ uptime cao, một dịch vụ quan trọng có thể đã dừng từ nhiều tháng trước mà không ai noticed.

Những gì cần kiểm tra: Mọi dịch vụ lẽ ra phải chạy nên hiển thị active (running). Bất cứ thứ gì else đều cần lý do.

Lưu ý: Các hệ thống lớn có thể có hàng trăm unit không hoạt động có chủ đích. Chỉ xem xét các dịch vụ dự kiến hoạt động.

16. Tìm các dịch vụ liên tục khởi động lại

Chạy lệnh này:

# Find services with automatic restart counts above zero
systemctl list-units --type=service --state=running --no-pager | awk '{print $1}' | \
xargs -I{} sh -c 'count=$(systemctl show {} -p NRestarts 2>/dev/null | cut -d= -f2); \
[ "$count" -gt 0 ] 2>/dev/null && echo "NRestarts=$count {}"'
# Confirm with journal history for any service you find
journalctl -u service-name --since "7 days ago" | grep -E "Started|Stopped|Failed" | tail -20

Một số dịch vụ sập và khởi động lại liên tục. Hệ thống giữ chúng "chạy" theo một nghĩa nào đó. Nhưng khởi động lại liên tục có nghĩa là có gì đó hỏng. Trên máy chủ uptime cao, điều này có thể tiếp diễn trong nhiều tháng mà không ai xem nhật ký.

Sự khác biệt chính: systemctl list-units --state=activating chỉ hiển thị các dịch vụ hiện đang khởi động tại thời điểm bạn chạy lệnh -- nó sẽ không bao giờ hiển thị dịch vụ sập và phục hồi nhanh. Thuộc tính NRestarts là thứ thực sự ghi lại số lần systemd phải tự động khởi động lại dịch vụ và nó tồn tại qua các chu kỳ phục hồi nhanh đó.

Những gì cần kiểm tra: Bất kỳ dịch vụ nào có NRestarts trên 0 đều đáng xem. Đối chiếu với journal để xem nó thực sự sập thường xuyên như thế nào và lỗi nào nó ghi lại trước mỗi lần khởi động lại. Ngoài ra, hãy điều tra các dịch vụ có số lần khởi động lại cao bất ngờ hoặc tăng đều đặn.

17. Kiểm tra các timer bị lỗi (thay thế cron của systemd)

Chạy lệnh này:

systemctl list-timers --all

Các timer systemd có thể thất bại âm thầm. Timer chạy. Lệnh thoát với mã lỗi. Nhưng no có cảnh báo nào được kích hoạt. Qua nhiều tháng, một timer sao lưu bị lỗi có nghĩa là no có sao lưu. Một timer logrotate bị lỗi có nghĩa là đĩa đầy.

Cờ --all mà không có bộ lọc trạng thái nào là cách tiếp cận đúng. Nó hiển thị mọi timer cùng với thời gian chạy LAST và NEXT trong một chế độ xem duy nhất. Lọc theo --state=waiting hoặc --state=running có thể ẩn các timer ở trạng thái bất ngờ, đó chính xác là những gì bạn đang cố gắng tìm.

Những gì cần kiểm tra: Mọi timer nên hiển thị cột LAST có dữ liệu. Bất kỳ timer nào có cột LAST trống chưa bao giờ chạy thành công. Bất kỳ timer nào có ngày LAST xa hơn nhiều so với khoảng thời gian cấu hình của nó đã âm thầm ngừng kích hoạt.

Phần 4: Bảo mật (Sự tích lũy âm thầm)

Các vấn đề bảo mật tích lũy chậm trên máy chủ uptime cao. Các kiểm tra này tìm ra những gì kẻ tấn công yêu thích.

18. Kiểm tra các bản cập nhật bảo mật đang chờ

Chạy lệnh này (Debian/Ubuntu):

apt list --upgradable 2>/dev/null | grep -i security

Trên hệ thống Ubuntu, cũng có một lệnh chuyên dụng cho mục đích này:

ubuntu-security-status

Chạy lệnh này (RHEL/CentOS/Rocky):

dnf updateinfo list --security

Một máy chủ uptime cao thường có nghĩa là no khởi động lại. Và no khởi động lại thường có nghĩa là no cập nhật kernel. Và no cập nhật kernel có nghĩa là các lỗ hổng đã biết vẫn chưa được vá trong nhiều tháng hoặc nhiều năm.

Những gì cần kiểm tra: Các bản cập nhật bảo mật đang chờ nên được áp dụng trong vòng vài ngày, no phải vài tháng. Cập nhật kernel yêu cầu khởi động lại. Đó là sự thật khó khăn.

19. Xem xét các lần đăng nhập SSH thất bại

Chạy các lệnh này:

sudo grep "Failed password" /var/log/auth.log 2>/dev/null || sudo grep "Failed password" /var/log/secure

sudo lastb | head -20

Nhiều hệ thống hiện đại lưu trữ nhật ký xác thực SSH chỉ trong journald. Trong các hệ thống đó, bạn có thể sử dụng:

journalctl -u ssh

Hoặc,

journalctl -u sshd

Các lần SSH thất bại cho thấy các cuộc tấn công brute-force. Trên máy chủ uptime cao tiếp xúc với internet, bạn có thể thấy hàng ngàn lần thử từ khắp nơi trên thế giới. Điều này là normal. Nhưng một sự tăng đột biến hoặc đăng nhập thành công từ IP lạ là no bình thường.

Những gì cần kiểm tra: Tìm các lần đăng nhập thành công từ IP không mong đợi. Tìm các mẫu thử thất bại từ cùng một IP.

20. Kiểm tra tài khoản người dùng trái phép

Chạy các lệnh này:

grep -E "sh$|bash$" /etc/passwd

lastlog | grep -v "Never logged in"

Đối với shell khác bash, bạn có thể sử dụng lệnh này:

getent passwd | awk -F: '$7 !~ /(nologin|false)$/'

Tài khoản người dùng tích lũy theo thời gian. Nhà thầu rời đi. Quản trị viên cũ chuyển đi. Nhưng tài khoản của họ đôi khi vẫn còn. Trên máy chủ uptime cao, bạn có thể tìm thấy các tài khoản không hoạt động trong nhiều năm.

Những gì cần kiểm tra: Mọi người dùng có quyền truy cập shell đăng nhập phải được ủy quyền và hoạt động. Vô hiệu hóa hoặc xóa phần còn lại.

21. Xác minh cấu hình SSH bảo mật

Chạy lệnh này:

sshd -T | grep -E "permitrootlogin|passwordauthentication"

Đăng nhập root bằng mật khẩu rất nguy hiểm. Xác thực mật khẩu qua internet rất rủi ro. Trên máy chủ uptime cao cũ, bạn có thể tìm thấy cấu hình SSH lỗi thời chưa bao giờ được cập nhật.

Những gì cần kiểm tra: PermitRootLogin nên là prohibit-password hoặc no. PasswordAuthentication nên là no nếu bạn sử dụng khóa. Lưu ý: chỉ thị Protocol cũ đã bị xóa trong OpenSSH 7.6 (2017) vì SSHv2 là giao thức duy nhất được hỗ trợ -- bạn no cần kiểm tra nó. Các hệ thống hiện đại thực thi SSHv2 mà không cần bất kỳ chỉ thị cấu hình nào.

22. Quét các cổng mở bạn không mong đợi

Chạy các lệnh này:

ss -tulpn | grep LISTEN

nmap -sT -p- localhost 2>/dev/null

Các máy chủ uptime cao thường tích lũy dịch vụ qua nhiều năm. Ai đó đã cài đặt cơ sở dữ liệu để thử nghiệm. Ai đó đã khởi động một máy chủ web gỡ lỗi. Sau đó mọi người quên. Những dịch vụ bị lãng quên này là mục tiêu tấn công hoàn hảo.

Những gì cần kiểm tra: Mọi cổng mở nên có mục đích được ghi lại. Các cổng không xác định có nghĩa là các dịch vụ không xác định.

Tìm hiểu cách kiểm tra các cổng mở và bảo mật chúng trong Linux bằng quy tắc tường lửa và các phương pháp hay nhất trong liên kết bên dưới:

23. Kiểm tra rootkit

Cài đặt nếu chưa có (Debian/Ubuntu):

sudo apt install rkhunter chkrootkit

Cài đặt nếu chưa có (RHEL/CentOS/Rocky):

sudo dnf install rkhunter chkrootkit

Lưu ý: Gói chrootkit có sẵn tùy thuộc vào bản phân phối và kho lưu trữ được kích hoạt. Kiểm tra tài liệu chính thức của bản phân phối của bạn.

Sau đó chạy:

sudo rkhunter --check --skip-keypress

sudo chkrootkit

Rootkit rất hiếm. Nhưng trên máy chủ uptime cao chưa được kiểm tra kỹ trong nhiều năm, chúng đáng để kiểm tra.

Hiểu những công cụ này có thể và no thể làm gì trước khi tin tưởng đầu ra của chúng. Cả rkhunter và chkrootkit đều chạy bằng các nhị phân của chính hệ thống -- những nhị phân mà một rootkit tinh vi có thể đã thay thế. Một kết quả sạch là một tín hiệu yếu, no phải là một sự đảm bảo. Cả hai công cụ cũng tạo ra các dương tính giả đáng kể trên các hệ thống hiện đại, đặc biệt là rkhunter trên các bản phân phối cập nhật gói thường xuyên. Mọi cảnh báo đều yêu cầu xác minh thủ công trước khi đưa ra kết luận.

Để đảm bảo mạnh mẽ hơn, hãy xem xét một trình giám sát tính toàn vẹn tệp thích hợp như AIDE hoặc Tripwire, so sánh các tệp với một đường cơ sở mật mã được thực hiện khi hệ thống được biết là sạch.

Những gì cần kiểm tra: Bất kỳ cảnh báo nào từ rkhunter hoặc chkrootkit đều cần điều tra, nhưng hãy mong đợi dương tính giả. Xác minh từng phát hiện thủ công. Đừng coi một lần quét sạch là một giấy chứng nhận sức khỏe sạch.

Phần 5: Giám sát và xác thực (Các hệ thống theo dõi)

Bạn no thể tin tưởng vào giám sát đã im lặng trong 400 days. Các kiểm tra này xác minh chính những người theo dõi.

24. Xác minh cảnh báo giám sát của bạn thực sự hoạt động

Chạy các lệnh này:

# Check when the last alert was sent
grep "ALERT" /var/log/monitoring.log | tail -5
# Simulate a test alert
/usr/local/bin/send_test_alert.sh

Kiểm tra này rất đau. Tôi đã thấy nó quá nhiều lần. Một máy chủ hiển thị 500 days của uptime. Bảng điều khiển giám sát trông xanh. Sau đó bạn phát hiện ra script cảnh báo đã ngừng chạy 400 days trước. Đĩa đầy. CPU quá nóng. Nhưng nobody nhận được một cảnh báo nào.

Xin lưu ý rằng các đường dẫn này chỉ là ví dụ. Thay thế chúng bằng đường dẫn thực tế của bạn.

Những gì cần kiểm tra: Lần cuối cùng có cảnh báo thực sự từ máy chủ này là khi nào? Bạn có thể kích hoạt một cảnh báo thử nghiệm ngay bây giờ không? Có ai nhận được nó không?

25. Đặt câu hỏi khởi động lại (câu hỏi quan trọng nhất)

Đây no phải là một lệnh. Đây là một cuộc trò chuyện.

Hãy hỏi to: Nếu chúng ta khởi động lại máy chủ này ngay bây giờ, nó có trở lại chính xác như nó phải không?

Mọi dịch vụ có khởi động đúng không? Tất cả các mount có hiện diện không? Cấu hình mạng có đúng không? Ứng dụng có lên mà không cần can thiệp thủ công không?

Nếu câu trả lời là "có lẽ" hoặc "chúng tôi no chắc" hoặc "để tôi kiểm tra runbook," thì uptime chỉ là một con số. Nó no phải là độ tin cậy. Nó no phải là sự an toàn. Nó chỉ là may mắn.

Những gì cần kiểm tra: Kiểm tra khởi động lại trong môi trường staging. Hoặc lên lịch một lần trong cửa sổ bảo trì. Sự tự tin thực sự đến từ thực hành, no phải từ một bộ đếm.

Kết luận

Uptime dài no phải là huy hiệu danh dự. Nó là một điểm dữ liệu.

Một máy chủ với 30 days của uptime và kiểm tra sức khỏe thường xuyên an toàn hơn một máy chủ với 800 days của uptime và no có xác thực. Câu hỏi no phải là "nó đã chạy được bao lâu?" Câu hỏi là "làm thế nào chúng ta biết nó đang hoạt động chính xác?"

Chạy qua danh sách kiểm tra này mỗi tháng một lần. Không phải vì bạn mong đợi tìm thấy vấn đề. Mà bởi vì những vấn đề bạn no tìm thấy là những vấn đề cuối cùng sẽ đánh gục bạn.

Tiếp theo là gì

Bạn tìm thấy nguyên nhân gốc rễ, tiếp theo là gì? Trước khi khắc phục sự cố bất kỳ hệ thống Linux nào, hãy chạy một tập hợp nhỏ các lệnh chỉ đọc để ghi lại trạng thái hiện tại của hệ thống trước khi bất kỳ can thiệp nào làm xáo trộn bằng chứng. Chúng tôi đã tổng hợp một danh sách các lệnh khắc phục sự cố Linux được khuyến nghị trong liên kết bên dưới.

Hướng dẫn đó giải thích những gì cần kiểm tra trong hệ thống Linux trước khi bạn chạm vào bất cứ thứ gì.

Bài đọc liên quan:

Chạy các lệnh sau:

uptime

nproc

Bạn sẽ thấy ba con số: 1 phút, 5 phút và 15 phút. Xu hướng tải tăng được thể hiện khi số phút 1 cao hơn số phút 15 -- tải đang tích lũy nhanh hơn mức nó được giải phóng. Ngược lại (số phút 15 cao hơn số phút 1) thực sự có nghĩa là tải đang giảm từ một đỉnh trong quá khứ.

Tuy nhiên, câu hỏi thực sự no phải là so sánh ba con số với nhau. Mà là so sánh bất kỳ con số nào trong số đó với số lõi CPU của bạn. Nếu load average 15 phút liên tục vượt quá số CPU trả về bởi nproc, hệ thống của bạn đã bão hòa và công việc đang xếp hàng nhanh hơn mức có thể xử lý.

Những gì cần kiểm tra: Nếu load 1 phút cao hơn load 15 phút, tải đang có xu hướng tăng. Nếu bất kỳ giá trị trung bình nào liên tục vượt quá số lõi CPU, bạn có vấn đề bão hòa. So sánh cả ba con số để biết xu hướng, nhưng luôn neo chúng vào số lõi của bạn.

Bài đọc liên quan:

2. Kiểm tra bộ nhớ available, no phải bộ nhớ free

Chạy lệnh sau:

free -h

Nhìn vào cột available. Bỏ qua free.

total        used        free      shared  buff/cache   available
Mem:            30Gi       8.7Gi        16Gi       1.2Gi       7.2Gi        22Gi
Swap:          975Mi          0B       975Mi

Bộ nhớ available là những gì hệ thống thực sự có thể cấp cho các tiến trình mới mà không cần swap. Nếu con số này tiếp tục giảm tuần này qua tuần khác, bạn có một rò rỉ bộ nhớ chậm.

Những gì cần kiểm tra: Ghi lại bộ nhớ available hôm nay. Kiểm tra lại sau một tuần. Nó có thấp hơn không?

3. Đếm các tiến trình zombie

Chạy các lệnh này:

top -bn1 | grep "zombie"

Hoặc kiểm tra số lượng zombie trực tiếp:

ps aux | awk '$8=="Z" {print $0}' | wc -l

Hoặc

ps -eo stat= | grep -c '^Z'

Một zombie là chuyện thường. Một vài cái là ổn. Nhưng hơn mười zombie tồn tại trong nhiều ngày? Đó là một vấn đề thực sự. Mỗi zombie chiếm một slot trong bảng tiến trình. Nếu bảng đó đầy, no có tiến trình mới nào có thể chạy. Không có phiên SSH mới. Không có kiểm tra giám sát mới. Không có gì.

Những gì cần kiểm tra: Số lượng zombie nên bằng 0 hầu hết thời gian. Một vài cái thỉnh thoảng là ổn. Zombie dai dẳng là no ổn.

Zombie quá nhiều cuối cùng có thể làm cạn kiệt available process IDs hoặc tài nguyên bảng tiến trình.

4. Xác minh sử dụng inode, no chỉ dung lượng đĩa

Chạy lệnh này:

df -i

Dung lượng đĩa được chú ý nhiều. Nhưng inode (cấu trúc dữ liệu lưu trữ thông tin tệp) có thể hết ngay cả khi bạn còn nhiều dung lượng. Khi điều đó xảy ra, bạn no thể tạo tệp mới. Nhật ký ngừng ghi. Dịch vụ sập âm thầm.

Những gì cần kiểm tra: Tìm bất kỳ phân vùng nào có IUse% trên 85%. Đó là dấu hiệu cảnh báo của bạn.

udev            4041811     635  4041176    1% /dev
tmpfs           4060692    1209  4059483    1% /run
/dev/nvme0n1p2 30433280 2949390 27483890   10% /
tmpfs           4060692     434  4060258    1% /dev/shm
tmpfs           4060692      16  4060676    1% /run/lock
efivarfs              0       0        0     - /sys/firmware/efi/efivars
/dev/nvme0n1p1        0       0        0     - /boot/efi
tmpfs            812138     268   811870    1% /run/user/1000
/dev/sda1             0       0        0     - /media/ostechnix/SK_WD_SSD
/dev/fuse        262144      40   262104    1% /etc/pve

5. Kiểm tra các tiến trình bị kẹt trong trạng thái ngủ không gián đoạn (trạng thái D)

Chạy lệnh này:

ps aux | awk '$8=="D" {print $0}'

Các tiến trình ở trạng thái D đang chờ trực tiếp trên phần cứng. Chúng no thể bị giết. Ngay cả với -9. Một vài cái là bình thường trong lúc I/O đĩa nặng. Nhưng nếu chúng tồn tại hơn vài phút, có điều gì đó rất sai với hệ thống lưu trữ của bạn.

Những gì cần kiểm tra: Mục tiêu là không có tiến trình trạng thái D bị kẹt. Các tiến trình trạng thái D dai dẳng thường chỉ ra vấn đề lưu trữ, filesystem hoặc network-mounted filesystem.

6. Tìm kiếm sự kiện OOM Killer trong nhật ký

Chạy các lệnh này:

sudo dmesg | grep -i -E "killed process|out of memory|oom"

journalctl -k | grep -iE "oom|out of memory|killed process"

OOM Killer là phương sách cuối cùng của Linux. Khi bộ nhớ cạn kiệt hoàn toàn, kernel bắt đầu giết các tiến trình để tồn tại. Đây không bao giờ là dấu hiệu tốt. Trên máy chủ uptime cao, bạn có thể tìm thấy các sự kiện OOM từ nhiều tháng trước mà bạn chưa từng noticed.

Những gì cần kiểm tra: Bất kỳ sự kiện OOM Killer nào cũng có nghĩa là bạn đã có vấn đề về bộ nhớ. Một sự kiện là cảnh báo. Nhiều sự kiện có nghĩa là bạn có một mô hình.

Phần 2: Đĩa và filesystem (Nơi mục nát xảy ra)

Các máy chủ uptime cao thường mục nát từ filesystem ra ngoài. Các kiểm tra này phát hiện mục nát sớm.

7. Tìm các tệp nhật ký lớn nhất

Chạy các lệnh này:

find /var/log -type f -size +100M -exec ls -lh {} \;

du -sh /var/log/* | sort -hr | head -10

Các tệp nhật ký phát triển mãi mãi nếu logrotate bị hỏng. Và logrotate hỏng thường xuyên hơn bạn nghĩ. Một cron job cấu hình sai hoặc thay đổi quyền từ sáu tháng trước có thể dừng tất cả logrotate một cách âm thầm.

Những gì cần kiểm tra: Bất kỳ tệp nhật ký nào trên 1GB cần được điều tra. Trên 10GB đã là một sự cố. Nói cách khác, tăng trưởng bất ngờ, bất kể kích thước, đều đáng để điều tra.

8. Xác minh logrotate thực sự hoạt động

Chạy các lệnh này:

logrotate --debug /etc/logrotate.conf 2>&1 | head -30

journalctl -u logrotate --since "30 days ago" 2>/dev/null | grep -i "error\|fail"

grep -i "logrotate" /var/log/syslog 2>/dev/null | grep -i "error\|fail" | tail -10

Log rotation có thể thất bại mà không ai noticed. Cron job chạy. Lệnh thoát. Nhưng vấn đề quyền hoặc thư mục thiếu gây ra thất bại âm thầm. Trên máy chủ uptime cao, logrotate có thể đã hỏng trong nhiều năm.

Lưu ý: logrotate no ghi vào tệp /var/log/logrotate.log riêng theo mặc định trên bất kỳ bản phân phối lớn nào. Trạng thái của nó được theo dõi trong /var/lib/logrotate/status và/hoặc /var/lib/logrotate/logrotate.status. Bất kỳ lỗi nào nó gặp phải có thể xuất hiện trong system journal hoặc syslog, đó là nơi các lệnh thứ hai và thứ ba tìm kiếm.

Những gì cần kiểm tra: Đầu ra gỡ lỗi sẽ hiển thị mỗi tệp nhật ký được xử lý mà không có lỗi. Kiểm tra /var/lib/logrotate/status và/hoặc /var/lib/logrotate/logrotate.status, tùy thuộc vào bản phân phối để xác nhận dấu thời gian xoay gần đây cho các tệp nhật ký quan trọng.

Bài đọc liên quan:

9. Kiểm tra mọi mount NFS hoặc mạng

Chạy các lệnh này:

mount | grep -E "nfs|nfs4|cifs"

for mount in $(mount | grep -E "nfs|nfs4|cifs" | awk '{print $3}'); do
timeout 5 ls $mount > /dev/null 2>&1
if [ $? -ne 0 ]; then
echo "STALE: $mount"
fi
done

Các mount NFS cũ rất nguy hiểm. Máy chủ vẫn hoạt động. Mount trông ổn. Nhưng bất kỳ tiến trình nào chạm vào mount đó sẽ treo trong 60 giây hoặc hơn. Các máy chủ uptime cao tích lũy những thứ này chậm chạp, và mỗi mount cũ thêm độ trễ vào mọi thứ kiểm tra nó.

Những gì cần kiểm tra: Mọi mount mạng nên phản hồi ls trong vòng dưới 2 giây. Treo có nghĩa là mount cũ.

Bạn cũng có thể sử dụng lệnh này:

mount | grep -E "nfs|nfs4|cifs" | while read -r line; do
mountpoint=$(echo "$line" | awk '{print $3}')
timeout 5 ls "$mountpoint" >/dev/null 2>&1
done

10. Kiểm tra thời gian chờ I/O đĩa

Chạy lệnh này:

iostat -x 1 5

Nhìn vào cột %iowait và cột await.

iowait cao có nghĩa là CPU của bạn đang dành thời gian chờ đĩa. Tuy nhiên, chỉ iowait có thể gây hiểu lầm trên hệ thống nhiều lõi -- một tiến trình I/O duy nhất trên máy 32 lõi có thể bão hòa một đĩa trong khi hầu như không đăng ký trong iowait. Luôn tương quan nó với giá trị await trên mỗi thiết bị trong iostat -x.

Cột await hiển thị thời gian trung bình tính bằng mili giây từ khi yêu cầu I/O được gửi đến khi hoàn thành. Dưới tải sản xuất, các giá trị trên 20ms trên SATA SSD hoặc trên 5ms trên ổ NVMe đáng để điều tra. Hãy nhớ rằng dưới tải nhẹ, NVMe hiện đại thường hoạt động dưới 1ms và SATA SSD dưới 2ms. Bất kỳ đột biến kéo dài nào trên các ngưỡng dưới tải này đều chỉ ra sự bão hòa thiết bị hoặc suy thoái phần cứng.

Những gì cần kiểm tra: Đừng chỉ dựa vào một con số %iowait duy nhất. Sử dụng iostat -x để kiểm tra giá trị await trên mỗi thiết bị và tìm các thiết bị đang tiến gần 100% %util. Tương quan với thời gian phản hồi ứng dụng để đánh giá xem các con số có phản ánh một nút cổ chai thực sự cho khối lượng công việc của bạn hay không.

Bài đọc liên quan:

11. Tìm các tệp có bit SUID/SGID được đặt

Chạy lệnh này:

find / -perm /6000 -type f 2>/dev/null | grep -v "^/proc"

Bit SUID và SGID cho phép chương trình chạy với đặc quyền nâng cao. Một tập hợp nhỏ là mong đợi trên bất kỳ hệ thống nào -- /bin/su, /usr/bin/passwd, /usr/bin/sudo, và /usr/bin/newgrp là các ví dụ phổ biến. Nhưng theo thời gian, những cái mới có thể xuất hiện. Phần mềm cũ có thể thêm chúng. Cấu hình sai có thể tạo ra chúng. Trên máy chủ uptime cao, những thứ này có thể tích lũy mà không ai noticed.

Lưu ý: trên các bản phân phối Linux hiện đại, một số nhị phân trước đây yêu cầu SUID (như ping) đã được chuyển sang sử dụng Linux capabilities. Nếu bạn thấy một nhị phân có SUID mà bạn no mong đợi -- ngay cả một cái quen thuộc -- thì đáng để xác nhận với gói mặc định của bản phân phối.

Những gì cần kiểm tra: Xem lại danh sách. Bất cứ điều gì không quen thuộc cần được điều tra.

12. Tìm các tệp và thư mục có thể ghi bởi mọi người

Chạy lệnh này:

find / -type f -perm -0002 -ls 2>/dev/null | grep -v "^/proc"

Các tệp có thể ghi bởi mọi người là rủi ro bảo mật. Bất kỳ người dùng nào trên hệ thống đều có thể sửa đổi chúng. Trên máy chủ bận rộn với nhiều người dùng, một tệp cấu hình có thể ghi bởi mọi người có thể dẫn đến leo thang đặc quyền.

Các thư mục có thể ghi bởi mọi người thường nguy hiểm hơn tệp. Chạy lệnh này để kiểm tra thư mục:

find / -type d -perm -0002 -ls 2>/dev/null

Những gì cần kiểm tra: Danh sách nên rất ngắn. Các tệp nhật ký hệ thống đôi khi có thể đọc bởi mọi người nhưng hiếm khi có thể ghi. Bất cứ thứ gì trong /etc hoặc /usr không bao giờ nên có thể ghi bởi mọi người.

Phần 3: Tiến trình và dịch vụ (Sự hỗn loạn đang chạy)

Một máy chủ uptime cao có thể tích lũy các tiến trình lộn xộn như tủ lạnh tích lũy thức ăn cũ.

13. Tìm các tiến trình có thời gian chạy rất dài

Chạy lệnh này:

ps -eo pid,etime,comm,args --sort=-etime | head -20

Các tiến trình đã chạy trong nhiều tháng có thể ổn. Hoặc chúng có thể bị treo, rò rỉ bộ nhớ hoặc no làm gì hữu ích. Trên máy chủ uptime cao, bạn thường tìm thấy các script cũ lẽ ra đã thoát nhưng không bao giờ làm vậy.

Những gì cần kiểm tra: Với mỗi tiến trình cũ, hãy hỏi: Cái này có nên chạy không? Nó có cần chạy không? Có thể khởi động lại sạch sẽ không?

14. Kiểm tra các cron job chồng chéo

Chạy lệnh này:

# User-level crontabs
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null
done
# System-level cron locations (these are where most production jobs actually live)
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ /etc/cron.hourly/

Một cron job mất 15 phút để chạy nhưng chạy mỗi 10 phút tạo ra các tiến trình chồng chéo. Theo thời gian, chúng chất đống. Hệ thống vẫn hoạt động, nhưng chạy tệ hơn mỗi ngày. Uptime cao che giấu những sai sót lịch trình này một cách hoàn hảo.

Trên máy chủ sản xuất, hầu hết các công việc theo lịch sống trong /etc/cron.d/, /etc/crontab, và các thư mục cron.daily/weekly/monthly/hourly -- no phải trong user crontab. Chỉ kiểm tra user crontab bỏ lỡ phần lớn công việc theo lịch trên một máy chủ điển hình.

Những gì cần kiểm tra: Tìm các công việc chạy thường xuyên hơn thời gian chúng hoàn thành. Thêm ghi nhật ký để xem thời gian chạy thực tế.

Bài đọc liên quan:

15. Xác minh trạng thái dịch vụ systemd

Chạy các lệnh này:

systemctl list-units --state=failed

systemctl list-units --state=inactive --all | grep -v "not-found"

Các dịch vụ bị lỗi là rõ ràng. Nhưng các dịch vụ đã dừng "thành công" khi lẽ ra phải chạy thì khó phát hiện hơn. Trên máy chủ uptime cao, một dịch vụ quan trọng có thể đã dừng từ nhiều tháng trước mà không ai noticed.

Những gì cần kiểm tra: Mọi dịch vụ lẽ ra phải chạy nên hiển thị active (running). Bất cứ thứ gì else đều cần lý do.

Lưu ý: Các hệ thống lớn có thể có hàng trăm unit không hoạt động có chủ đích. Chỉ xem xét các dịch vụ dự kiến hoạt động.

16. Tìm các dịch vụ liên tục khởi động lại

Chạy lệnh này:

# Find services with automatic restart counts above zero
systemctl list-units --type=service --state=running --no-pager | awk '{print $1}' | \
xargs -I{} sh -c 'count=$(systemctl show {} -p NRestarts 2>/dev/null | cut -d= -f2); \
[ "$count" -gt 0 ] 2>/dev/null && echo "NRestarts=$count {}"'
# Confirm with journal history for any service you find
journalctl -u service-name --since "7 days ago" | grep -E "Started|Stopped|Failed" | tail -20

Một số dịch vụ sập và khởi động lại liên tục. Hệ thống giữ chúng "chạy" theo một nghĩa nào đó. Nhưng khởi động lại liên tục có nghĩa là có gì đó hỏng. Trên máy chủ uptime cao, điều này có thể tiếp diễn trong nhiều tháng mà không ai xem nhật ký.

Sự khác biệt chính: systemctl list-units --state=activating chỉ hiển thị các dịch vụ hiện đang khởi động tại thời điểm bạn chạy lệnh -- nó sẽ không bao giờ hiển thị dịch vụ sập và phục hồi nhanh. Thuộc tính NRestarts là thứ thực sự ghi lại số lần systemd phải tự động khởi động lại dịch vụ và nó tồn tại qua các chu kỳ phục hồi nhanh đó.

Những gì cần kiểm tra: Bất kỳ dịch vụ nào có NRestarts trên 0 đều đáng xem. Đối chiếu với journal để xem nó thực sự sập thường xuyên như thế nào và lỗi nào nó ghi lại trước mỗi lần khởi động lại. Ngoài ra, hãy điều tra các dịch vụ có số lần khởi động lại cao bất ngờ hoặc tăng đều đặn.

17. Kiểm tra các timer bị lỗi (thay thế cron của systemd)

Chạy lệnh này:

systemctl list-timers --all

Các timer systemd có thể thất bại âm thầm. Timer chạy. Lệnh thoát với mã lỗi. Nhưng no có cảnh báo nào được kích hoạt. Qua nhiều tháng, một timer sao lưu bị lỗi có nghĩa là no có sao lưu. Một timer logrotate bị lỗi có nghĩa là đĩa đầy.

Cờ --all mà không có bộ lọc trạng thái nào là cách tiếp cận đúng. Nó hiển thị mọi timer cùng với thời gian chạy LAST và NEXT trong một chế độ xem duy nhất. Lọc theo --state=waiting hoặc --state=running có thể ẩn các timer ở trạng thái bất ngờ, đó chính xác là những gì bạn đang cố gắng tìm.

Những gì cần kiểm tra: Mọi timer nên hiển thị cột LAST có dữ liệu. Bất kỳ timer nào có cột LAST trống chưa bao giờ chạy thành công. Bất kỳ timer nào có ngày LAST xa hơn nhiều so với khoảng thời gian cấu hình của nó đã âm thầm ngừng kích hoạt.

Phần 4: Bảo mật (Sự tích lũy âm thầm)

Các vấn đề bảo mật tích lũy chậm trên máy chủ uptime cao. Các kiểm tra này tìm ra những gì kẻ tấn công yêu thích.

18. Kiểm tra các bản cập nhật bảo mật đang chờ

Chạy lệnh này (Debian/Ubuntu):

apt list --upgradable 2>/dev/null | grep -i security

Trên hệ thống Ubuntu, cũng có một lệnh chuyên dụng cho mục đích này:

ubuntu-security-status

Chạy lệnh này (RHEL/CentOS/Rocky):

dnf updateinfo list --security

Một máy chủ uptime cao thường có nghĩa là no khởi động lại. Và no khởi động lại thường có nghĩa là no cập nhật kernel. Và no cập nhật kernel có nghĩa là các lỗ hổng đã biết vẫn chưa được vá trong nhiều tháng hoặc nhiều năm.

Những gì cần kiểm tra: Các bản cập nhật bảo mật đang chờ nên được áp dụng trong vòng vài ngày, no phải vài tháng. Cập nhật kernel yêu cầu khởi động lại. Đó là sự thật khó khăn.

19. Xem xét các lần đăng nhập SSH thất bại

Chạy các lệnh này:

sudo grep "Failed password" /var/log/auth.log 2>/dev/null || sudo grep "Failed password" /var/log/secure

sudo lastb | head -20

Nhiều hệ thống hiện đại lưu trữ nhật ký xác thực SSH chỉ trong journald. Trong các hệ thống đó, bạn có thể sử dụng:

journalctl -u ssh

Hoặc,

journalctl -u sshd

Các lần SSH thất bại cho thấy các cuộc tấn công brute-force. Trên máy chủ uptime cao tiếp xúc với internet, bạn có thể thấy hàng ngàn lần thử từ khắp nơi trên thế giới. Điều này là normal. Nhưng một sự tăng đột biến hoặc đăng nhập thành công từ IP lạ là no bình thường.

Những gì cần kiểm tra: Tìm các lần đăng nhập thành công từ IP không mong đợi. Tìm các mẫu thử thất bại từ cùng một IP.

20. Kiểm tra tài khoản người dùng trái phép

Chạy các lệnh này:

grep -E "sh$|bash$" /etc/passwd

lastlog | grep -v "Never logged in"

Đối với shell khác bash, bạn có thể sử dụng lệnh này:

getent passwd | awk -F: '$7 !~ /(nologin|false)$/'

Tài khoản người dùng tích lũy theo thời gian. Nhà thầu rời đi. Quản trị viên cũ chuyển đi. Nhưng tài khoản của họ đôi khi vẫn còn. Trên máy chủ uptime cao, bạn có thể tìm thấy các tài khoản không hoạt động trong nhiều năm.

Những gì cần kiểm tra: Mọi người dùng có quyền truy cập shell đăng nhập phải được ủy quyền và hoạt động. Vô hiệu hóa hoặc xóa phần còn lại.

21. Xác minh cấu hình SSH bảo mật

Chạy lệnh này:

sshd -T | grep -E "permitrootlogin|passwordauthentication"

Đăng nhập root bằng mật khẩu rất nguy hiểm. Xác thực mật khẩu qua internet rất rủi ro. Trên máy chủ uptime cao cũ, bạn có thể tìm thấy cấu hình SSH lỗi thời chưa bao giờ được cập nhật.

Những gì cần kiểm tra: PermitRootLogin nên là prohibit-password hoặc no. PasswordAuthentication nên là no nếu bạn sử dụng khóa. Lưu ý: chỉ thị Protocol cũ đã bị xóa trong OpenSSH 7.6 (2017) vì SSHv2 là giao thức duy nhất được hỗ trợ -- bạn no cần kiểm tra nó. Các hệ thống hiện đại thực thi SSHv2 mà không cần bất kỳ chỉ thị cấu hình nào.

22. Quét các cổng mở bạn không mong đợi

Chạy các lệnh này:

ss -tulpn | grep LISTEN

nmap -sT -p- localhost 2>/dev/null

Các máy chủ uptime cao thường tích lũy dịch vụ qua nhiều năm. Ai đó đã cài đặt cơ sở dữ liệu để thử nghiệm. Ai đó đã khởi động một máy chủ web gỡ lỗi. Sau đó mọi người quên. Những dịch vụ bị lãng quên này là mục tiêu tấn công hoàn hảo.

Những gì cần kiểm tra: Mọi cổng mở nên có mục đích được ghi lại. Các cổng không xác định có nghĩa là các dịch vụ không xác định.

Tìm hiểu cách kiểm tra các cổng mở và bảo mật chúng trong Linux bằng quy tắc tường lửa và các phương pháp hay nhất trong liên kết bên dưới:

23. Kiểm tra rootkit

Cài đặt nếu chưa có (Debian/Ubuntu):

sudo apt install rkhunter chkrootkit

Cài đặt nếu chưa có (RHEL/CentOS/Rocky):

sudo dnf install rkhunter chkrootkit

Lưu ý: Gói chrootkit có sẵn tùy thuộc vào bản phân phối và kho lưu trữ được kích hoạt. Kiểm tra tài liệu chính thức của bản phân phối của bạn.

Sau đó chạy:

sudo rkhunter --check --skip-keypress

sudo chkrootkit

Rootkit rất hiếm. Nhưng trên máy chủ uptime cao chưa được kiểm tra kỹ trong nhiều năm, chúng đáng để kiểm tra.

Hiểu những công cụ này có thể và no thể làm gì trước khi tin tưởng đầu ra của chúng. Cả rkhunter và chkrootkit đều chạy bằng các nhị phân của chính hệ thống -- những nhị phân mà một rootkit tinh vi có thể đã thay thế. Một kết quả sạch là một tín hiệu yếu, no phải là một sự đảm bảo. Cả hai công cụ cũng tạo ra các dương tính giả đáng kể trên các hệ thống hiện đại, đặc biệt là rkhunter trên các bản phân phối cập nhật gói thường xuyên. Mọi cảnh báo đều yêu cầu xác minh thủ công trước khi đưa ra kết luận.

Để đảm bảo mạnh mẽ hơn, hãy xem xét một trình giám sát tính toàn vẹn tệp thích hợp như AIDE hoặc Tripwire, so sánh các tệp với một đường cơ sở mật mã được thực hiện khi hệ thống được biết là sạch.

Những gì cần kiểm tra: Bất kỳ cảnh báo nào từ rkhunter hoặc chkrootkit đều cần điều tra, nhưng hãy mong đợi dương tính giả. Xác minh từng phát hiện thủ công. Đừng coi một lần quét sạch là một giấy chứng nhận sức khỏe sạch.

Phần 5: Giám sát và xác thực (Các hệ thống theo dõi)

Bạn no thể tin tưởng vào giám sát đã im lặng trong 400 days. Các kiểm tra này xác minh chính những người theo dõi.

24. Xác minh cảnh báo giám sát của bạn thực sự hoạt động

Chạy các lệnh này:

# Check when the last alert was sent
grep "ALERT" /var/log/monitoring.log | tail -5
# Simulate a test alert
/usr/local/bin/send_test_alert.sh

Kiểm tra này rất đau. Tôi đã thấy nó quá nhiều lần. Một máy chủ hiển thị 500 days của uptime. Bảng điều khiển giám sát trông xanh. Sau đó bạn phát hiện ra script cảnh báo đã ngừng chạy 400 days trước. Đĩa đầy. CPU quá nóng. Nhưng nobody nhận được một cảnh báo nào.

Xin lưu ý rằng các đường dẫn này chỉ là ví dụ. Thay thế chúng bằng đường dẫn thực tế của bạn.

Những gì cần kiểm tra: Lần cuối cùng có cảnh báo thực sự từ máy chủ này là khi nào? Bạn có thể kích hoạt một cảnh báo thử nghiệm ngay bây giờ không? Có ai nhận được nó không?

25. Đặt câu hỏi khởi động lại (câu hỏi quan trọng nhất)

Đây no phải là một lệnh. Đây là một cuộc trò chuyện.

Hãy hỏi to: Nếu chúng ta khởi động lại máy chủ này ngay bây giờ, nó có trở lại chính xác như nó phải không?

Mọi dịch vụ có khởi động đúng không? Tất cả các mount có hiện diện không? Cấu hình mạng có đúng không? Ứng dụng có lên mà không cần can thiệp thủ công không?

Nếu câu trả lời là "có lẽ" hoặc "chúng tôi no chắc" hoặc "để tôi kiểm tra runbook," thì uptime chỉ là một con số. Nó no phải là độ tin cậy. Nó no phải là sự an toàn. Nó chỉ là may mắn.

Những gì cần kiểm tra: Kiểm tra khởi động lại trong môi trường staging. Hoặc lên lịch một lần trong cửa sổ bảo trì. Sự tự tin thực sự đến từ thực hành, no phải từ một bộ đếm.

Kết luận

Uptime dài no phải là huy hiệu danh dự. Nó là một điểm dữ liệu.

Một máy chủ với 30 days của uptime và kiểm tra sức khỏe thường xuyên an toàn hơn một máy chủ với 800 days của uptime và no có xác thực. Câu hỏi no phải là "nó đã chạy được bao lâu?" Câu hỏi là "làm thế nào chúng ta biết nó đang hoạt động chính xác?"

Chạy qua danh sách kiểm tra này mỗi tháng một lần. Không phải vì bạn mong đợi tìm thấy vấn đề. Mà bởi vì những vấn đề bạn no tìm thấy là những vấn đề cuối cùng sẽ đánh gục bạn.

Tiếp theo là gì

Bạn tìm thấy nguyên nhân gốc rễ, tiếp theo là gì? Trước khi khắc phục sự cố bất kỳ hệ thống Linux nào, hãy chạy một tập hợp nhỏ các lệnh chỉ đọc để ghi lại trạng thái hiện tại của hệ thống trước khi bất kỳ can thiệp nào làm xáo trộn bằng chứng. Chúng tôi đã tổng hợp một danh sách các lệnh khắc phục sự cố Linux được khuyến nghị trong liên kết bên dưới.

Hướng dẫn đó giải thích những gì cần kiểm tra trong hệ thống Linux trước khi bạn chạm vào bất cứ thứ gì.

Bài đọc liên quan: