服务器上线就被扫？一份Linux安全加固指南，14步防黑少踩80%坑

你刚买了一台云服务器，系统装好、应用跑起来，是不是觉得万事大吉了？其实从它暴露在公网那一刻起，全球的扫描器已经在疯狂敲门了。翻翻 /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 → 转发到本地SSH
• monitor.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;
    }
}

这套方案有几个好处：

1. 攻击面极小，nmap扫描只能看到443端口，SSH端口完全不可见
2. 管理域名可以加IP白名单或者套Cloudflare的Access策略，多一层认证
3. 所有管理入口都有TLS加密，不存在明文传输
4. 集中管理，加个新服务就加个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只开必要端口。另外密码策略也收紧了，所有服务器统一用密钥认证，彻底告别密码。

一份可以直接用的加固检查清单

怕你看完就忘，我把关键项整理成清单。新机器上线前过一遍：

序号	加固项	状态
1	创建普通用户，禁止root SSH登录	☐
2	SSH端口改为高位非标端口	☐
3	强制密钥认证，禁用密码登录	☐
4	安装配置fail2ban	☐
5	防火墙默认拒绝，白名单放行	☐
6	云安全组与系统防火墙双重配置	☐
7	内核参数加固（SYN防护/禁转发/反向过滤）	☐
8	检查并清理SUID/SGID文件	☐
9	/tmp挂载noexec,nosuid,nodev	☐
10	配置自动安全更新	☐
11	安装auditd，配置关键文件审计	☐
12	日志转发到远程日志服务器	☐
13	关闭不必要的服务和端口	☐
14	定期检查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加固堵住入口，防火墙控制流量，内核参数防御网络攻击，文件权限防止提权，自动更新堵住已知漏洞，审计日志提供溯源能力。每一项单独看都不复杂，但组合在一起就是一道靠谱的防线。

我见过太多“先上线再说安全”的情况，最后出了事才来亡羊补牢。补救的成本比预防高十倍不止。花半天时间做好加固，换来的是之后你能踏实睡觉，不用半夜被告警叫醒之后发现是被人搞了。

安全不是一次性的事，定期巡检、持续更新、关注漏洞公告，这些习惯要养成。

更多运维与安全实战经验，欢迎访问云栈社区交流。