服务器上线就被扫？一套完整的Linux安全加固方案，照着做能少踩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只开必要端口。另外密码策略也收紧了，所有服务器统一用密钥认证，彻底告别密码。

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

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

几个容易忽略的坑

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加固堵住入口，防火墙控制流量，内核参数防御网络攻击，文件权限防止提权，自动更新堵住已知漏洞，审计日志提供溯源能力。每一项单独看都不复杂，但组合在一起就是一道靠谱的防线。

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

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

如果这篇文章对你有用，帮忙点个在看或者转发给你的运维同事，说不定能帮他们避开一次事故。

我是运维躬行录，一个在生产环境里踩坑踩出来的运维人。关注我，持续分享运维实战经验，少走弯路少加班。

公众号：耕云躬行录

个人博客：躬行笔记