你新买了一台云服务器，装好系统、部署完应用，觉得万事大吉了。
但你打开/var/log/auth.log看一眼就知道，从你服务器暴露在公网那一刻起，全世界的扫描器已经在排队敲门了。一天几万条暴力破解记录，不是夸张，是常态。
这篇文章我把每一步加固操作写到具体命令级别。不讲道理，直接上手。
系统账户和认证这块，是重灾区
大部分入侵事件的入口就是SSH暴力破解。你去看任何一台暴露在公网的Linux机器，/var/log/auth.log或者/var/log/secure里面一定有大量失败登录记录。
禁止root直接SSH登录
这是最基础的一步，但很多人懒得改。
vim /etc/ssh/sshd_config
找到这一行，改成no：
PermitRootLogin no
然后重启sshd：
systemctl restart sshd
改之前记得先建好一个普通用户并加入sudo组，不然你改完自己也登不上去了。我见过有人改完直接断连，机房又不在身边，只能提工单让机房人员接显示器重置——这种低级错误犯一次就够了。
useradd -m -s /bin/bash devops
passwd devops
usermod -aG sudo devops # Debian/Ubuntu
# 或者
usermod -aG wheel devops # CentOS/RHEL
修改SSH默认端口
22端口是所有扫描器的第一目标。改成一个高位端口，比如58222，虽然不能完全防住定向攻击，但能过滤掉99%的自动化扫描。
# /etc/ssh/sshd_config
Port 58222
改端口之后有个坑：如果你开了firewalld或者ufw，一定要先放行新端口再重启sshd。顺序反了你又得去机房了。
# ufw的情况
ufw allow 58222/tcp
systemctl restart sshd
# firewalld的情况
firewall-cmd --permanent --add-port=58222/tcp
firewall-cmd --reload
systemctl restart sshd
强制使用密钥登录，禁用密码认证
这一步做完，暴力破解基本就废了。
本地机器上生成密钥对：
ssh-keygen -t ed25519 -C "your-server-name"
把公钥传到服务器上：
ssh-copy-id -p 58222 devops@your-server-ip
确认密钥能登录之后，再禁用密码：
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
重启sshd生效。
这里有个细节很多教程不提：如果你用的是CentOS 8或者更新的系统，sshd_config里可能有个Include /etc/ssh/sshd_config.d/*.conf，子配置文件里的设置会覆盖主文件。我就踩过这个坑，明明改了主文件，密码登录还是能用，最后发现是子配置里有一行PasswordAuthentication yes在生效。
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
检查一下有没有冲突配置。
登录失败锁定
用fail2ban来做。装完就能用，配置也简单：
apt install fail2ban # Debian/Ubuntu
yum install fail2ban # CentOS
systemctl enable fail2ban
systemctl start fail2ban
默认配置已经能防SSH暴力破解了，但我一般会调整一下参数。创建一个本地配置文件：
cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = 58222
maxretry = 3
bantime = 3600
findtime = 600
EOF
意思是：10分钟内失败3次，封禁1小时。生产环境我会把bantime调到86400（一天）甚至更长。
systemctl restart fail2ban
查看当前封禁状态：
fail2ban-client status sshd
防火墙策略：默认拒绝，按需放行
很多人的防火墙配置是反的——默认放行，然后去堵某些端口。正确做法是默认拒绝所有入站流量，只开放你确实需要的端口。
UFW（Ubuntu/Debian推荐）
ufw default deny incoming
ufw default allow outgoing
ufw allow 58222/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw enable
firewalld（CentOS/RHEL）
# 先看当前zone
firewall-cmd --get-default-zone
# 设置默认拒绝
firewall-cmd --set-default-zone=drop
# 放行需要的端口
firewall-cmd --permanent --add-port=58222/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --reload
有个地方容易踩坑：如果你的服务器在云上（AWS、阿里云之类的），云平台本身有安全组。安全组和系统防火墙是两层独立的东西，两边都要配。我遇到过的情况是：系统防火墙开了端口，安全组没开，排查半天以为是应用问题。反过来也一样。
还有一种情况，服务器需要访问外部API或者拉取更新，出站规则一般不用太限制。但如果是高安全要求的环境，出站也要白名单控制，防止反弹shell之类的情况。
进阶玩法：只暴露443，管理端口全部走Nginx域名转发
这是我目前在用的方案，比改SSH端口还彻底。思路很简单：服务器对外只开443端口，SSH、管理面板、监控这些全部藏在Nginx后面，通过不同的域名来区分和转发。扫描器扫到的只有一个HTTPS端口，连SSH端口都看不到。
具体怎么做：
防火墙只放行443：
# ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 443/tcp
ufw enable
# 如果SSH还需要保留一个应急入口（比如VPN内网段）
ufw allow from 10.0.0.0/8 to any port 22 proto tcp
Nginx配置不同域名转发到不同的后端服务。比如你有这几个管理需求：
ssh.yourdomain.com → 转发到本地SSHmonitor.yourdomain.com → 转发到Grafana（3000端口）admin.yourdomain.com → 转发到管理后台（8080端口）
SSH走Nginx Stream模块（四层转发）：
# /etc/nginx/nginx.conf 主配置中加载stream模块
stream {
map $ssl_preread_server_name $backend {
ssh.yourdomain.com 127.0.0.1:22;
}
server {
listen 8443; # 内部stream监听端口
ssl_preread on;
proxy_pass $backend;
}
}
HTTP类管理服务走正常的反向代理：
# /etc/nginx/conf.d/monitor.conf
server {
listen 443 ssl;
server_name monitor.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/monitor.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monitor.yourdomain.com/privkey.pem;
# IP白名单，只允许你的办公网络访问
allow 203.0.113.0/24;
deny all;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
这套方案有几个好处：
- 攻击面极小，nmap扫描只能看到443端口，SSH端口完全不可见
- 管理域名可以加IP白名单或者套Cloudflare的Access策略，多一层认证
- 集中管理，加个新服务就加个nginx配置文件，不用动防火墙
有个坑要注意：SSH走Nginx Stream转发的话，你本地ssh连接要改成连443端口（或者你stream监听的端口）。配置~/.ssh/config：
Host my-server
HostName ssh.yourdomain.com
Port 443
User devops
IdentityFile ~/.ssh/id_ed25519
还有就是万一Nginx挂了，你SSH也进不去了。所以建议保留一个VPN内网段能直连22端口的应急通道，或者云平台的VNC控制台得确保能用。
内核参数加固
这部分经常被忽略，但对防御网络层攻击很有效。
cat >> /etc/sysctl.conf << 'EOF'
# 防止SYN Flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
# 禁止IP转发（非路由器/网关场景）
net.ipv4.ip_forward = 0
# 忽略ICMP重定向
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
# 禁止源路由
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# 开启反向路径过滤
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# 记录可疑数据包
net.ipv4.conf.all.log_martians = 1
# 忽略ping广播
net.ipv4.icmp_echo_ignore_broadcasts = 1
EOF
sysctl -p
说个实际场景：之前有台Web服务器被SYN Flood攻击，连接队列被打满，正常用户全部超时。加了tcp_syncookies和调大tcp_max_syn_backlog之后，配合前端的负载均衡限流，扛住了后面几次同样规模的攻击。
文件权限和关键目录保护
Linux下有些文件权限设置得太松，会成为提权的跳板。
检查SUID/SGID文件
SUID位的文件会以文件所有者的权限执行。如果一个root所有的文件被设置了SUID，任何用户执行它都会获得root权限。
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
看看输出里有没有不该出现的东西。正常的SUID文件比如/usr/bin/passwd、/usr/bin/sudo这些是系统需要的。但如果你发现/tmp目录下有个SUID文件，那八成有问题了。
关键配置文件权限
chmod 600 /etc/shadow
chmod 644 /etc/passwd
chmod 700 /root
chmod 600 /etc/ssh/sshd_config
/tmp目录加固
/tmp是很多攻击的中转站，因为默认所有用户都能写。如果条件允许，给/tmp单独分区并挂载时限制执行权限：
# /etc/fstab 中对/tmp分区加参数
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0
noexec禁止执行，nosuid忽略SUID位，nodev禁止设备文件。这样即使攻击者把恶意脚本丢到/tmp，也没法直接执行。
重新挂载让配置生效：
mount -o remount /tmp
自动化安全更新
漏洞被公开之后到你打补丁之间的这段时间窗口，是最危险的。很多入侵事件利用的都是已知漏洞，补丁早就发布了但服务器没更新。
Debian/Ubuntu
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
这样系统会自动安装安全更新。配置文件在/etc/apt/apt.conf.d/50unattended-upgrades，可以精细控制只更新安全补丁还是全部更新。
我的建议是：安全补丁自动装，但功能更新和内核更新手动来。自动更新内核如果出问题可能导致重启后起不来，这个风险在生产环境承担不起。
# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
// "${distro_id}:${distro_codename}-updates"; 注释掉非安全更新
};
// 自动移除不需要的依赖
Unattended-Upgrade::Remove-Unused-Dependencies "true";
// 更新后如果需要重启，自动重启（谨慎开启）
// Unattended-Upgrade::Automatic-Reboot "true";
// Unattended-Upgrade::Automatic-Reboot-Time "04:00";
CentOS/RHEL
yum install yum-cron
systemctl enable yum-cron
编辑/etc/yum/yum-cron.conf，把apply_updates = no改成yes。
审计和日志
出了事之后要能溯源，这就依赖完整的日志。
auditd审计框架
apt install auditd # Debian/Ubuntu
yum install audit # CentOS
systemctl enable auditd
systemctl start auditd
添加一些关键审计规则：
cat > /etc/audit/rules.d/hardening.rules << 'EOF'
# 监控passwd和shadow文件的修改
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
# 监控sudoers修改
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# 监控SSH配置修改
-w /etc/ssh/sshd_config -p wa -k sshd_config
# 监控crontab修改
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
# 监控系统调用 - 可执行文件的权限修改
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -k perm_mod
EOF
# 重新加载审计规则
augenrules --load
日志集中管理
单机日志如果机器被入侵了，攻击者会清理日志。把日志实时同步到远程日志服务器是基本操作。
最简单的方式是用rsyslog转发：
# /etc/rsyslog.conf 或 /etc/rsyslog.d/remote.conf
*.* @@log-server-ip:514
@@是TCP转发，@是UDP。生产环境用TCP，不会丢日志。
条件好的话上ELK或者Loki，日志检索和告警都方便很多。
服务最小化
装完系统默认会跑一些你根本不需要的服务。每多一个监听端口就多一个攻击面。
# 查看当前监听端口
ss -tlnp
看看输出里有没有你不认识的东西。常见的可以关掉的：
# 如果不需要邮件服务
systemctl disable postfix
systemctl stop postfix
# 如果不需要打印服务
systemctl disable cups
systemctl stop cups
# 如果不需要avahi（mDNS）
systemctl disable avahi-daemon
systemctl stop avahi-daemon
还有一个点：确认/etc/hosts.allow和/etc/hosts.deny（TCP Wrappers）。虽然这玩意儿比较老了，但某些服务还在用。可以做个兜底：
# /etc/hosts.deny
ALL: ALL
# /etc/hosts.allow
sshd: 10.0.0.0/8 192.168.0.0/16
意思是默认拒绝所有TCP Wrapper管控的服务，只对内网IP放行SSH。
实战案例：一次挖矿木马的排查和清理
去年有台服务器CPU突然飙到100%，业务响应变得很慢。当时排查过程是这样的：
发现异常
监控告警CPU持续100%。登上去top看了一下，有个叫kworkerds的进程吃满了CPU。这名字伪装得挺像内核线程的，但真正的内核线程在top里显示会带方括号（比如[kworker/0:0]），没有方括号的就是冒牌货。
top -c
# 找到异常进程PID
ls -la /proc/<PID>/exe
/proc/<PID>/exe指向了/tmp/.ice-unix/下的一个二进制文件。这个路径就很经典了，挖矿木马最爱藏这里。
查找入侵路径
# 查看最近被修改的文件
find / -mtime -3 -type f 2>/dev/null | grep -v proc | head -50
# 查看定时任务
crontab -l
cat /var/spool/cron/root
ls -la /etc/cron.d/
果然在crontab里发现了一条每分钟执行的任务，从一个外部地址下载脚本并执行。/etc/cron.d/下也被塞了一个文件。
再看auth.log，发现几天前有一个IP暴力破解成功了——密码太弱了，就是一个简单的admin123。
清理过程
# 杀进程
kill -9 <PID>
# 删除恶意文件
rm -rf /tmp/.ice-unix/
rm -f /etc/cron.d/malicious_cron
# 清理crontab
crontab -r # 清空当前用户的crontab，之后重新添加合法任务
# 检查有没有其他后门
# 查看是否有异常的authorized_keys
cat /root/.ssh/authorized_keys
cat /home/*/.ssh/authorized_keys
# 检查是否被修改了系统命令
rpm -Va # CentOS，验证所有包的文件完整性
debsums -c # Debian/Ubuntu
最后发现攻击者还在/root/.ssh/authorized_keys里加了自己的公钥。如果只杀进程不检查这个，人家随时能回来。
事后加固
把这篇文章前面说的那些全做了一遍：改端口、禁密码登录、上fail2ban、firewall只开必要端口。另外密码策略也收紧了，所有服务器统一用密钥认证，彻底告别密码。
一份可以直接用的加固检查清单
怕你看完就忘，我把关键项整理成清单。新机器上线前过一遍：
| | |
|---|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| /tmp挂载noexec,nosuid,nodev | |
| | |
| | |
| | |
| | |
| 定期检查crontab和authorized_keys | |
几个容易忽略的坑
DNS配置
很多人只关注TCP端口，忘了DNS。如果你的/etc/resolv.conf里配的是公共DNS（比如8.8.8.8），而你的内网有些域名需要走内部DNS解析，搞错了会导致内网服务访问异常。而且DNS查询也是可以被劫持的，有条件就用DoH或者DoT。
NTP时间同步
日志分析和审计溯源都依赖准确的时间。如果各台服务器时间不一致，你在日志里对不上事件的先后顺序，排查的时候会很痛苦。
# 确认NTP同步状态
timedatectl status
# 或者
chronyc tracking
History命令记录
默认的bash history有大小限制，而且关了终端可能丢失。加几行配置让命令记录更完整：
cat >> /etc/profile << 'EOF'
export HISTSIZE=10000
export HISTFILESIZE=20000
export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "
shopt -s histappend
EOF
这样每条命令都有时间戳，出事了能查到谁在什么时候执行了什么。
总结
服务器安全加固这件事，说白了就是把攻击面压到最小。SSH加固堵住入口，防火墙控制流量，内核参数防御网络攻击，文件权限防止提权，自动更新堵住已知漏洞，审计日志提供溯源能力。每一项单独看都不复杂，但组合在一起就是一道靠谱的防线。
我见过太多"先上线再说安全"的情况，最后出了事才来亡羊补牢。补救的成本比预防高十倍不止。花半天时间做好加固，换来的是之后你能踏实睡觉，不用半夜被告警叫醒之后发现是被人搞了。
安全不是一次性的事，定期巡检、持续更新、关注漏洞公告，这些习惯要养成。
如果这篇文章对你有用，帮忙点个在看或者转发给你的运维同事，说不定能帮他们避开一次事故。
我是运维躬行录，一个在生产环境里踩坑踩出来的运维人。关注我，持续分享运维实战经验，少走弯路少加班。
公众号：耕云躬行录
个人博客：躬行笔记
