2019 on Liangweidong's blog

CentOS 8 EOL 善后：换源 vault.centos.org、时间同步与时区设置

Sun, 15 Sep 2019 00:00:00 +0800

一、为什么 2019 年要聊 CentOS 8

CentOS 8.0 正式发布是 2019-09-24——RHEL 8.0 GA 后的 CentOS 重建版。本文写于 2019-09-15，相当于 CentOS 8 正式发布前一周。但文章真正"管用"的时间是 2022 年 1 月 31 日之后——那天 CentOS 团队把 CentOS 8 的所有包从 mirror.centos.org 移到 vault.centos.org，已经装好的 CentOS 8 跑 yum 会全部报：

1

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

时间线：

2019-09-24：CentOS 8.0 GA

2020-12-08：CentOS 宣布战略调整，CentOS 8 提前 EOL

2021-12-31：CentOS 8 EOL（生命周期结束）

2022-01-31：包从 mirror.centos.org 移到 vault.centos.org

2021-05-12：Rocky Linux 8.3 RC1 发布

2021-05-18：AlmaLinux 8.3 正式发布

新机器建议直接上 Rocky Linux 9 / AlmaLinux 9 / Oracle Linux 9——跟 CentOS 8 / 7 生态兼容，迁移成本最低。本篇只解决"已经上了 CentOS 8 又不想重装"的善后问题。

二、CentOS 8 EOL 后 yum 报错的修复

症状（2022-01-31 后）：

1
2


sudo yum update
# Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

根因：CentOS 8 已经 EOL，包从 mirror.centos.org 移走，但 /etc/yum.repos.d/CentOS-*.repo 还指向 mirror.centos.org。

2.1 一次性 sed 改源

1
2


sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-*
sudo sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-*

这两条命令做的事：

把所有 mirrorlist= 注释掉（#mirrorlist=）
把 #baseurl=http://mirror.centos.org 替换成 baseurl=http://vault.centos.org

2.2 验证

1
2
3


sudo yum clean all
sudo yum makecache
sudo yum update

如果 vault.centos.org 也访问不到（更老的版本），可以临时改 https://mirrors.aliyun.com/centos-vault/8.x.x/... 阿里云镜像，但只限能联网的服务器。

坑提醒：vault.centos.org 没有 HTTPS-only 限制，但没有签名验证——意味着如果源被劫持，包可能被替换。生产环境建议尽快迁移到 Rocky/Alma/Oracle Linux。

三、CentOS 8 的 dnf 包管理器

CentOS 8 弃用了 yum（虽然命令还能用），新工具是 dnf——兼容 yum 4.x 系列，大部分命令一致。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 装包
sudo dnf install -y <package>

# 查包
dnf search <keyword>
dnf info <package>

# 列出已装
dnf list installed

# 卸包
sudo dnf remove <package>

# 仓库管理
sudo dnf config-manager --add-repo https://example.com/repo.repo
sudo dnf config-manager --set-enabled <repo-id>
sudo dnf config-manager --set-disabled <repo-id>

CentOS 8 默认有两个主仓库：

BaseOS：核心 OS 包（kernel、systemd、bash 等）
AppStream：应用流（多个 Python / Node.js 版本可并存）

应用流（Module）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 查可用 python 模块
sudo dnf module list python

# 装 Python 3.9（默认）
sudo dnf module install python39

# 切到 Python 3.6
sudo dnf module reset python
sudo dnf module enable python36
sudo dnf install python3

坑提醒：dnf module 的"版本"切换是全系统的——切换后所有 dnf 装的 Python 都用这个版本。多 Python 版本请用 conda 或源码编译。

四、时间同步：ntpdate / chrony

CentOS 7 用 ntpdate + crontab。CentOS 8 改用 chrony（chronyd daemon），开机自启：

1
2
3
4
5


systemctl status chronyd
# Active: active (running)

chronyc sources -v
# 查 NTP 源状态

4.1 想用回 ntpdate 风格

2019-2020 那段时间国内服务器常用 wlnmp 源（https://mirrors.wlnmp.com/centos/wlnmp-release-centos.noarch.rpm）一次性装 wntp：

1
2
3


rpm -ivh https://mirrors.wlnmp.com/centos/wlnmp-release-centos.noarch.rpm
dnf install wntp
ntpdate ntp1.aliyun.com

坑提醒：wlnmp-release 包没有 GPG 签名验证——商用生产环境慎用，仅适合临时调试。

4.2 配阿里云 NTP

1
2
3
4
5
6
7
8
9


vi /etc/chrony.conf
# 注释掉默认的 pool，改成阿里云
# pool 2.centos.pool.ntp.org iburst
server ntp1.aliyun.com iburst
server ntp2.aliyun.com iburst
server ntp3.aliyun.com iburst

systemctl restart chronyd
chronyc sources -v

五、时区设置

timedatectl 是 CentOS 7+ 标准的时区工具。

5.1 看当前时区

1
2
3
4
5
6
7
8


timedatectl status
# Local time: Thu 2026-06-04 12:34:56 CST
# Universal time: Thu 2026-06-04 04:34:56 UTC
# RTC time: Thu 2026-06-04 04:34:56
# Time zone: Asia/Shanghai (CST, +0800)
# NTP enabled: yes
# NTP synchronized: yes
# RTC in local TZ: no

5.2 改时区

1
2
3


sudo timedatectl set-timezone Asia/Shanghai
date
# Thu Jun 4 12:34:56 CST 2026

5.3 列出所有时区

1
2
3
4
5
6


timedatectl list-timezones | grep Asia
# Asia/Shanghai
# Asia/Hong_Kong
# Asia/Tokyo
# Asia/Singapore
# ...

5.4 手动改时间（一般不要）

1

sudo timedatectl set-time '2026-06-04 12:34:56'

改完时间记得 hwclock --systohc 把系统时间写回硬件时钟，否则重启就丢。

六、CentOS 8 → Rocky / AlmaLinux 迁移

如果想保住 CentOS 8 的环境又不想重装，官方提供 migrate2rocky / almalinux-deploy 脚本：

1
2
3
4
5
6


# Rocky Linux 迁移
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo bash migrate2rocky.sh -r
# 重启
sudo reboot

1
2
3
4


# AlmaLinux 迁移
sudo dnf install -y almalinux-deploy
sudo almalinux-deploy
sudo reboot

坑提醒：迁移脚本会改一堆包，包括内核、grub、repo。迁移前一定要做快照（云盘 / LVM 快照），回退成本高。

七、典型坑速查

现象	原因	处理
`yum update` 报 “No URLs in mirrorlist”	CentOS 8 EOL 后 mirror.centos.org 失效	走 §2.1 sed 改源
`dnf install` 报包冲突	Module 多版本并存	`dnf module reset <mod>` 再装
`chronyc sources` 显示 `??`	NTP 服务器不可达	改 `chrony.conf` 加阿里云 NTP
时间不准	没装 chronyd / 时区不对	装 chronyd + `timedatectl set-timezone`
迁移 Rocky 失败	网络 / 仓库访问	配阿里云 Vault 源后重试

八、下一步

想从 CentOS 8 直接迁到 Rocky 9 / Alma 9 → 走 migrate2rocky 或重装（重装最稳）
想继续留 CentOS 7 → 7 已 2024-06-30 EOL，尽快迁出
想换更现代的发行版 → Ubuntu 22.04 LTS / Debian 12
想学 K8s 时间同步最佳实践 → 容器里别用宿主机的本地时间，用 NTP 或 sidecar

参考资料

2024 视角：CentOS 8 时代早已过去，Rocky / Alma 9 才是"未来"

本文写于 2019-09-15（CentOS 8 GA 前一周），2024 视角下 CentOS 8 已 EOL 3 年。本文的方法在 vault 源上仍管用，但新项目早应该迁到 Rocky / Alma 9。

一、CentOS 8 EOL 时间线回顾

2019-09-24：CentOS 8.0 GA
2020-12-08：CentOS 战略调整公告（CentOS 8 提前 EOL，CentOS 转向 Stream）
2021-12-31：CentOS 8 EOL（生命周期结束，比原计划 2029-05 提前 7.5 年）
2022-01-31：包从 mirror.centos.org 移到 vault.centos.org
2024-06-30：CentOS 8 走完 6 个月的 ELS（Extended Lifecycle Support）

2024 视角：CentOS 8 完全没有安全更新——必须迁出。

二、`vault.centos.org` 2024 状态

2024-06-30 后：vault.centos.org 仍可访问，但仅供归档查询。
生产环境仍用 CentOS 8 = 裸奔在公网。
不推荐继续用 vault.centos.org 做生产源——无 GPG 签名验证（包可能被劫持）。

三、dnf 包管理器的"2024 现状"

2019 那篇介绍了 CentOS 8 的 dnf 4.x。2024 视角：

dnf 5（2024-03 在 Fedora 40 首次 GA，RHEL 9.4+ 默认）—— 完全重写：
- 基于 libsolv（比 dnf 4 的 hawkey 快 10 倍）
- Python 3.12+ 替代 Python 3.6
- 新命令：dnf install 改成 dnf install（不变）但有 dnf5 install
- 更严格的依赖解析

1
2
3
4
5
6
7


# 2024 dnf 5 用法
dnf5 --version
# 5.1.12

dnf5 install nginx
dnf5 remove nginx
dnf5 search python

四、chrony 在 2024 仍是 NTP 默认

2019 那篇的 chrony 配置 2024 仍管用。2024 新增：

chrony 4.5+（2024-02 起）：支持 NTS（Network Time Security）—— 加密的 NTP 协议。

1
2
3
4


# /etc/chrony.conf
# 启用 NTS
ntsserver ntp1.aliyun.com
ntsserver time.cloudflare.com

NTS 比传统 NTP 更安全（防中间人篡改时间）。

五、timedatectl 的"现代"用法

2019 那篇给的 timedatectl set-timezone Asia/Shanghai 2024 仍管用。2024 增强：

NTP 同步 + RTC 同步：

1
2
3
4
5
6
7
8


# 看同步状态
timedatectl show-timesync
# SystemNTPServers=ntp1.aliyun.com
# SystemNTPSynchronized=yes
# RTCInLocalTZ=no

# 强制 RTC 用 UTC（避免时区混乱）
timedatectl set-local-rtc 0

六、CentOS Stream 8 → Rocky / Alma 8 的迁移

2019 那篇只是"保留旧系统"。2024 主流：

migrate2rocky.sh 脚本（Rocky Linux 官方）：

1
2
3
4
5
6
7
8
9


# CentOS Stream 8 → Rocky Linux 8
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo bash migrate2rocky.sh -r

# 重启
sudo reboot
uname -r
# Rocky Linux 8.x

almalinux-deploy 脚本（AlmaLinux 官方）：

1
2


sudo dnf install -y almalinux-deploy
sudo almalinux-deploy

七、CentOS Stream 的"真实价值"

2019 那篇 CentOS Stream 8 还没出。
CentOS Stream 8/9（2021+）：RHEL 的"上游开发版"—— 比 RHEL 早 1-2 个 minor 版本。
2024 视角：
- 生产环境：不用 CentOS Stream（不稳定），用 Rocky / Alma 9。
- 开发环境：CentOS Stream 9 可以体验"未来 RHEL"。
- CI/CD 测试：RHEL UBI（Universal Base Image，2020+）—— 在容器里跑 RHEL。

八、AlmaLinux / Rocky / Oracle 三选一

Rocky Linux：CIQ 公司主导，社区最活跃。
AlmaLinux：CloudLinux 公司主导，外企用得多。
Oracle Linux：Oracle 公司主导，企业级支持（UEK 内核自研）。
2024 市场份额：
- Rocky Linux ~ 35%
- AlmaLinux ~ 30%
- Oracle Linux ~ 20%
- CentOS Stream ~ 15%

九、CentOS 8 的"运维遗物"：`dnf module`

2019 那篇提到 dnf module。2024 状态：

dnf module 在 Rocky / Alma 9 仍存在（继承自 RHEL 8 AppStream）。
2024 趋势：用 pyenv / conda / uv 装 Python，不用 dnf module install python39。
应用流（Module）示例（2024 仍可用）：

1
2
3
4


# Node.js 多版本（dnf module）
dnf module list nodejs
dnf module enable nodejs:18
dnf install nodejs

十、CentOS 8 EOL 后的"实践教训"

2019 → 2024 五年间，CentOS 经历了：
- GA（2019-09）
- 战略调整（2020-12）
- 提前 EOL（2021-12）
- 完全归档（2024-06）
教训：
- 不要把生产系统"绑死"在单一发行版—— 用 Docker / 容器化
- 订阅 Red Hat 或 商业支持（Alma / Rocky / Oracle）—— 别用"免费无支持"的 CentOS
- 新项目永远用"未来 5 年有支持"的发行版
- 2024 推荐：
  - 服务器：Rocky / Alma / Oracle 9（支持到 2027-2029）
  - 桌面 / 开发：Ubuntu 24.04 LTS（支持到 2029-04）
  - 容器：Distroless / Alpine / UBI（无 OS 依赖）

Linux 用户管理与安全加固：账号管理、登录审计、chattr 防删与定时任务

Fri, 15 Mar 2019 00:00:00 +0800

一、为什么是 2019 年这一份

2019 年这个时间点前后，Linux 服务器安全进入"主动防御"阶段：

sshd 密码爆破已经是常态，单一 IP 每分钟几千次尝试
挖矿病毒大规模爆发（2017-2019 持续增长），chattr +i 防删成为应急标配
Linux 用户管理的工具集基本稳定：useradd / usermod / userdel / passwd / last / lastlog
systemd 全面接管服务管理，crontab 仍有"定时任务"位置但已被 systemd timer 部分替代

这一篇覆盖用户账号管理、登录审计、异常文件排查、chattr 防删与挖矿应急、cron 故障排查——一个系统管理员面对"被入侵后该怎么排查"的全套流程。

阅读建议：本文是"应急手册"性质——日常不需要看，但出事时第一份要翻的文档。

二、用户账号管理

2.1 查用户信息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 后面第二个冒号的值大于 1000 时，这个就是一个普通用户
cat /etc/passwd | cut -d: -f 1-3
# dell:x:1000

# 各用户最近登录
lastlog
# 用户名 端口 来自 最后登录时间
# root pts/0 <IP> 三 12月 13 08:36:29 +0800 2023
# dell pts/0 <IP> 二 12月 12 21:07:11 +0800 2023

# 更新指定用户密码
passwd dell
# 新的密码：
# 重新输入新的密码：
# passwd：已成功更新密码

2.2 删除用户

1
2
3
4
5


# 仅删除用户（保留家目录）
userdel username

# 删除用户并删除家目录
userdel -r username

2.3 切换用户不可用时

如果某个用户 SSH 进去后 su 切不到，可能是 shell 被改成 /sbin/nologin：

1
2
3
4
5
6


# 方法一
usermod -s /bin/bash root

# 方法二：直接编辑 /etc/passwd
vi /etc/passwd
# 找到要修改的用户，将 /sbin/nologin 改成 /bin/bash

三、登录审计：被入侵后的第一件事

3.1 查特权用户

1
2


# UID = 0 的都是 root 等价账号
awk -F ":" '$3==0{print $1}' /etc/passwd

3.2 查可远程登录的账号

1
2


# 密码字段是 $1（MD5）/ $5（SHA-256）/ $6（SHA-512）的都有密码
awk '/\$1|\$6/{print $1}' /etc/shadow

3.3 查当前登录用户

1
2


w
# 显示当前登录用户和他们正在执行的命令

3.4 查最近登录

1
2


last
# 显示所有用户的登录/注销信息 + 系统的启动/重启/关机事件

3.5 查登录成功的记录

1
2


# 从 /var/log/secure 提取 Accepted 行
grep "Accepted " /var/log/secure* | awk '{print $1,$2,$3,$9,$11}'

3.6 查爆破 IP

1
2
3
4
5
6
7
8


# 查 sshd 拒绝的 IP
grep refused /var/log/secure* | awk {'print $9'} | sort | uniq -c | sort -nr | more

# 查 Failed password 的 IP
grep "Failed password" /var/log/secure* | grep -E -o "(([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3}))" | uniq -c

# 查爆破 root 的 IP
grep "Failed password for root" /var/log/secure | awk '{print $11}' | sort

3.7 查爆破的用户名字典

1

grep "Failed password" /var/log/secure | awk {'print $9'} | sort | uniq -c | sort -nr

四、异常文件排查

4.1 查 cron 是否有恶意脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 检查所有 cron 文件
/var/spool/cron/*
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/*
/etc/cron.hourly/*
/etc/cron.monthly/*
/etc/cron.weekly/*
/etc/anacrontab
/var/spool/anacron/*

4.2 查最近被修改的系统文件

1
2


find /etc/ /usr/bin/ /usr/sbin/ /bin/ /usr/local/bin/ \
 -type f -mtime -T | xargs ls -la

-T 是要替换的天数。比如 -mtime -7 是 7 天内被修改的文件。

4.3 查最近被替换的命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 按时间排序
ls -alt /usr/bin /usr/sbin /bin /usr/local/bin

# 用 rpm 校验包内文件（CentOS/RHEL）
rpm -Va > rpm.log
# 重点看 S、M、5、T 标记异常的
# S - 文件大小变化
# M - 模式变化（含权限）
# 5 - MD5 校验和变化
# T - 修改时间变化

4.4 查异常开机启动项

1
2
3


cat /etc/rc.local
chkconfig --list # CentOS 6
systemctl list-unit-files --type=service # CentOS 7+

五、查杀病毒和 rootkit

工具	用途	下载
`chkrootkit`	查杀 rootkit	http://www.chkrootkit.org
`rkhunter`	查杀 rootkit	http://rkhunter.sourceforge.net
`clamav`	查杀病毒	http://www.clamav.net/download.html
`cloudwalker`	查杀 webshell	http://github.com/chaitin/cloudwalker

六、挖矿病毒应急：`chattr +i` 防删与解除

6.1 现象：文件无法删除

挖矿病毒感染后常见现象：自己生成的 SSH 公钥、cron 文件、挖矿程序二进制都"加锁"了，rm 删不掉。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 找挖矿进程
top

# 找到 exe 路径
ls -l /proc/<pid>

# 查属性（有 i / a 之类的是被锁住了）
lsattr 文件名

# 添加属性（之后 rm 删不掉）
chattr -R +i ./test*

# 删除属性（运行完下面就能删了）
chattr -R -i ./test*

6.2 全局清理流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 1. 杀进程
ps aux | grep -v grep | grep 挖矿进程名 | awk '{print $2}' | xargs kill -9
# 或
pkill -9 -f 挖矿特征

# 2. 删用户（带 -r 清空家目录）
pkill -u 挖矿用户名 && userdel -f 挖矿用户名
rm -rf /home/挖矿用户名

# 3. 查 SSH 登录的挖矿用户进程
netstat -antp | grep sshd
# 拿到 PID
ps -ef | grep ssh | grep -v grep | awk '{print $2}' | xargs kill -9

# 4. 查可登录的 shell
cat /etc/passwd | grep -v nologin | grep -v halt | grep -v shutdown | \
 awk -F":" '{ print $1"|"$3"|"$4 }' | more

# 5. 改 root 密码
passwd root

6.3 查 sshd 上的可疑连接

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 当前仍在线的
last -a | grep -i still
# root pts/0 Thu Jul 18 05:40 still logged in <IP>
# reboot system boot Sat Jul 6 07:23 still running 5.15.0-113-generic

# 用 ss / netstat
ss | grep -i ssh
# tcp ESTAB 0 64 <本机>:ssh <攻击者IP>:2316

netstat -tnpa | grep 'ESTABLISHED.*sshd'
# tcp 0 0 <本机>:22 <攻击者IP>:2316 ESTABLISHED <pid>/sshd: root@

6.4 查进程工作目录

1
2
3


ps -ef | grep ssh
pwdx <pid>
ll /proc/<pid>/cwd

七、docker stats 查容器资源占用

挖矿病毒有时会跑在容器里：

1
2
3
4
5
6
7


# 按内存排序
docker stats --no-stream --format "table {{.Name}}\t{{.Container}}\t{{.MemUsage}}" | \
 sort -k 3 -h

# 按内存逆序
docker stats --no-stream --format "table {{.Name}}\t{{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}" | \
 sed '1d' | sort -k 4 -h -r

八、定时任务不生效的排查

cron 任务"配了不跑"是常见故障，按以下顺序排查：

8.1 权限问题

1

chmod +x /home/docker/mysql/mysqlbak.sh

8.2 时区问题

1
2
3
4
5
6
7
8
9


# 看时区
date
timedatectl

# 改时区
timedatectl set-timezone Asia/Shanghai

# 同步时区文件
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

8.3 服务状态

1
2


systemctl status cron
systemctl status crond

8.4 看日志

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# /var/log/cron 不存在？打开 rsyslog 记录
vim /etc/rsyslog.d/50-default.conf
cron.* /var/log/cron.log

# 重启 rsyslog
systemctl restart rsyslog

# 看 cron 日志
less -10 /var/log/cron.log

# 重载
service cron reload

8.5 Ubuntu 的 auth.log 噪声

Ubuntu 经常有大量 CRON 噪音日志刷屏：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 打开 /etc/pam.d/common-session-noninteractive
# 找到这一行
# session required pam_unix.so
# 在上面加一行
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

# 重启 cron
/etc/init.d/cron restart

# 清空日志
cat /dev/null > /var/log/auth.log

九、用户清理（离职交接）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 列出当前所有可登录账号
cat /etc/passwd | grep -v nologin | grep -v false

# 2. 杀该用户的所有进程
pkill -u username

# 3. 删用户 + 清空家目录
userdel -r username

# 4. 验证
id username
ls -la /home/username

十、安全基线检查清单

检查项	命令
特权用户	`awk -F":" '$3==0{print $1}' /etc/passwd`
空密码账号	`awk -F: '($2 == "") {print $1}' /etc/shadow`
最近 7 天被改的文件	`find /etc /usr -mtime -7 -ls`
异常 cron	`ls -la /etc/cron.* /var/spool/cron/`
SSH 端口暴露	`ss -tnlp
防火墙	`iptables -L -n`
登录失败次数	`lastb
公开密钥	`find / -name "authorized_keys" -ls 2>/dev/null`

十一、前置知识 / 下一步

想看 iptables / ufw 防火墙配置 → 翻独立文章
想看 fail2ban 防爆破 → 翻独立文章
想看 GVM 漏洞扫描 → 翻本系列《Linux 安全：挖矿病毒与漏洞扫描》
想看日志集中分析（ELK / Loki）→ 翻独立文章
想看 SELinux / AppArmor → 翻独立文章

十二、参考资源

man useradd / man usermod / man userdel / man passwd
man last / man lastlog / man w
man chattr / man lsattr
man cron / man crontab / man at
Linux 服务器安全基线（等保 2.0）：https://www.djbh.net/ 等
ATT&CK for Linux：https://attack.mitre.org/matrices/enterprise/linux/

2024 视角：用户管理与安全加固的"现代姿势"

2019 那篇是单台服务器安全加固的速查。2024 在云原生 + 等保 2.0 + 零信任背景下，思路有几处大变化。

一、systemd 替代 crontab（“定时任务"领域）

2019 那篇大段讲 cron 故障排查。2024 主流做法是 systemd timer（journal 日志统一管理 + 资源隔离）：
迁移案例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# /etc/systemd/system/backup.service
[Unit]
Description=数据库备份
Wants=backup.timer

[Service]
Type=oneshot
User=backup
ExecStart=/home/backup/db-backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=每天 03:00 跑备份

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

1
2
3


systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers

二、`/var/log/secure` 改名 → journald

2019 那篇所有"看 secure / wtmp / btmp“的命令，在 RHEL 8/9、Ubuntu 22.04+ 都用 journald 替代：

1
2
3
4
5
6
7
8


# SSH 登录成功
journalctl -u sshd -g "Accepted publickey" --since "1 day ago"

# SSH 登录失败
journalctl -u sshd -g "Failed password" --since "1 hour ago" -o json | jq -r '.__REALTIME_TIMESTAMP as $t | .MESSAGE'

# 实时跟踪
journalctl -u sshd -f

/var/log/btmp 这种二进制日志（lastb 用）保留，但默认写到 journal，需要 journalctl --list-boots + last -f /var/log/wtmp。

三、密码爆破的"现代对抗”：fail2ban → CrowdSec

2019 那篇给的 fail2ban 仍是有效工具。
2024 主流：CrowdSec（Go 写的现代版 fail2ban）——社区共享 IP 黑名单：

1
2
3
4
5


# 装
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
# 自动接管 SSH/Nginx/Apache 防护

优势：通过 bouncer 把攻击 IP 报到中心服务器，整个社区的人都在用同一个黑名单。
fail2ban 还在用，但 2024 越来越多部署同时跑 fail2ban（老牌稳）+ CrowdSec（社区黑名单）。

四、挖矿病毒对抗 2024 升级版

2019 那篇给的"挖矿进程 → chattr +i 防删 → pkill"流程在 2024 仍管用，但挖矿病毒已经升级：

rootkit 隐藏：用 LD_PRELOAD 替换系统调用，让 top / ps 看不到。
容器逃逸：挖矿病毒跑在容器里，宿主机 top 看不到。
K8s 挖矿：用 RBAC 权限漏洞（提权到 cluster-admin），挖整个集群。

2024 升级的排查：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 查被劫持的动态库
cat /etc/ld.so.preload
ls -la /etc/ld.so.preload

# 2. 用 busybox / static 工具替代被劫持的 top/ps
# busybox top
# busybox ps

# 3. chkrootkit / rkhunter 仍管用
apt install rkhunter
rkhunter --check

# 4. 用 eBPF 工具（2020 那篇已提）查隐藏进程
bpftrace -e 'tracepoint:sched:sched_process_exec { printf("%s\n", comm); }'

# 5. K8s 场景：用 Falco（容器运行时安全）
helm install falco falcosecurity/falco

五、登录审计的"现代告警”：Sudo 审计 + PAM 增强

2019 那篇主要看 last / wtmp。2024 强化：
Sudo 审计（/var/log/audit/audit.log 或 journald）：

1
2
3
4
5
6
7
8


# 查谁 sudo 了
journalctl _AUDIT_TYPE_NAME=1100 -g "EXECVE" --since today

# 或直接 auditd
ausearch -m USER_CMD -ts today

# 实时跟踪 sudo
auditctl -w /usr/bin/sudo -p x -k sudo_audit

PAM 强制 MFA（多因素认证）：

1
2


apt install libpam-google-authenticator
google-authenticator # 给用户配置 TOTP

1
2


# /etc/pam.d/sshd 加一行
auth required pam_google_authenticator.so

六、SSH 安全基线 2024 升级版

2019 那篇提到 PasswordAuthentication no / PermitRootLogin no，2024 主流加固：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# /etc/ssh/sshd_config.d/00-hardening.conf
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*
MaxAuthTries 3
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 0
LoginGraceTime 30
AllowUsers deployer admin
AllowGroups ssh-users
# 强制只接受 ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
# 禁 DSA / RSA-SHA1
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

1
2


systemctl restart sshd
sshd -T | grep -E "hostkey|pubkey|password" # 验证

七、容器时代的安全基线

2019 那篇的所有工具针对单台物理机 / 虚拟机。
2024 大量生产环境是 Docker / K8s——chattr +i 在容器里不生效（容器没有真正的 root 权限到 host fs）。
容器化场景的安全工具：
- Trivy / Grype（镜像漏洞扫描）
- Falco（运行时入侵检测）
- OPA / Kyverno（策略引擎，限制容器能做什么）
- Cosign（镜像签名，验证镜像来源）

1
2
3
4
5


# Trivy 扫描镜像
trivy image nginx:1.25

# Falco 检测异常
kubectl apply -f https://raw.githubusercontent.com/falcosecurity/falco/master/deploy/k8s-with-helm/falco.yaml