服务器安全加固不是装一个防护工具就结束的事。常见问题通常出在“入口太多、权限太宽、日志没人看、恢复路径没验证”。这篇指南会教你如何把一台 Linux 服务器从默认可用状态，整理成可检查、可追踪、可回滚的安全基线。我们会从 SSH（安全外壳协议）登录、账号权限、防火墙、补丁、服务暴露、文件权限、日志审计、备份验证和内核参数这些环节逐项拆开，重点不是追求复杂，而是帮助你把常见风险先压到可控范围。
先做资产盘点：知道这台服务器到底暴露了什么
很多安全问题不是因为配置者不知道某条命令，而是服务器跑了半年后，已经没人能说清楚它开放了哪些端口、哪些账号还能登录、哪些服务是历史遗留。开始加固前，建议先做一次 30 分钟盘点，把“当前状态”记录下来，后续每次修改才有对照基线。
可以先从端口和服务入手。登录服务器后执行：
ss -tulpen
systemctl --type=service --state=running
第一条命令能看到监听端口、进程和用户；第二条命令能看到运行中的 systemd 服务。对于网站服务器，常见必需端口通常是 22、80、443，数据库端口如 3306、5432 不应默认暴露在公网。如果你使用的是 服务器配置 类场景，建议把端口清单、服务名称、用途和负责人写进运维文档，至少保留“端口 / 协议 / 访问来源 / 是否公网开放”四列。
登录入口加固：先把 SSH 风险降下来
SSH（安全外壳协议）是大多数 Linux 服务器的主要管理入口，也是最常被扫描的入口。安全加固的第一步，是减少可猜、可撞、可滥用的登录方式。先创建普通用户，再通过 sudo 做提权，不要长期使用 root 直接登录日常维护。
一组比较稳妥的基线是：
- 禁止 root 远程登录：
PermitRootLogin no - 关闭密码登录：
PasswordAuthentication no - 只允许指定用户组登录：
AllowGroups ssh-admins - 调整空闲会话时间：
ClientAliveInterval 300、ClientAliveCountMax 2 - 每次修改后用
sshd -t先做语法检查，再重启服务
对应文件通常是 /etc/ssh/sshd_config。修改前先保留一个已登录终端，避免配置错误后无法进入服务器。启用密钥登录时，私钥要放在本地安全位置，服务器端 ~/.ssh/authorized_keys 权限建议为 600，用户家目录权限不要放到所有人可写。
如果服务器承载的是业务站点，不建议只靠“改 SSH（安全外壳协议）端口”获得安全感。换端口可以减少低质量扫描日志，但不能替代密钥认证、最小权限和登录审计。对 VPS（虚拟专用服务器） 用户来说，尤其要注意云控制台、系统用户和应用后台是三套不同入口，不能只加固其中一处。
防火墙与服务暴露：只放行业务真正需要的流量
登录入口收紧后，下一步是把网络边界缩小。防火墙不是为了“挡住所有东西”，而是用明确规则表达：哪些流量必须进来，哪些流量只能从内部访问，哪些端口根本不该打开。
如果使用 UFW，可以用下面的顺序建立基础规则：
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
如果你的 SSH（安全外壳协议）端口不是 22，需要先替换对应端口再启用防火墙。数据库、缓存、消息队列等服务，优先绑定到 127.0.0.1 或内网地址，不要依赖应用层密码暴露在公网。比如 MySQL 可以检查 bind-address，Redis 要检查 protected-mode 与监听地址。
这里有一个实用判断：从服务器外部执行一次端口扫描，看到的结果应该比服务器内部 ss -tulpen 少。内部能监听不代表外部能访问；外部可访问端口才是真正边界。对于需要承载更高流量或更严格隔离的 独立服务器 场景，还可以把管理入口限制到固定办公 IP 或 VPN（虚拟专用网络）出口。
系统补丁与账号权限：把可预测风险变成例行维护
服务器安全加固不能只做一次。内核、OpenSSH、Web 服务、PHP、数据库都会持续发布安全修复，如果补丁长期不装，外部扫描器往往能通过版本特征找到已公开漏洞。更现实的做法是把补丁拆成两类：安全更新尽快执行，功能升级先测试。
在 Debian/Ubuntu 系统中，可以先查看可升级包：
apt update
apt list --upgradable
如果启用自动安全更新，要明确自动范围，而不是让所有软件包无条件升级。可以检查 unattended-upgrades 的配置，确认只包含安全仓库，并把重启策略写清楚。对生产站点，内核升级后是否重启、什么时间重启、谁确认业务可用，都应该提前约定。
账号权限同样要定期清理。建议每月检查一次 /etc/passwd、/etc/group 和 sudo 权限：
getent passwd
getent group sudo
find / -perm -4000 -type f 2>/dev/null
第三条命令会列出带 SUID 权限的文件，数量突然增加时要特别留意。对网站目录，常见原则是“应用运行用户可写上传目录，不可写核心代码目录”。比如 WordPress（内容管理系统）站点可以让上传目录具备写入权限，但主题、插件和核心文件不应全部给 777。更多网站层面的性能与安全边界，也可以结合 WordPress（内容管理系统）教程 一起规划。
应用和数据隔离：不要让一个漏洞拖垮整台机器
当登录和系统层面收紧后，还要看应用层隔离。很多入侵并不是直接拿到 root 权限，而是先通过网站漏洞写入 WebShell，再读取配置文件、连接数据库、横向访问同机其他站点。因此，应用用户、目录权限、数据库账号和密钥管理要分开处理。
一个可执行的基线是：每个站点使用独立系统用户或容器运行；数据库按应用建立独立账号；配置文件只允许应用用户和部署用户读取；备份目录不放在公网 Web 根目录下。以 Nginx + PHP-FPM 为例，可以为不同站点配置不同的 pool，并指定不同 user、group 和 listen socket。这样即使一个站点出问题，影响也不容易扩散到其他站点。
密钥和配置文件要避免进入代码仓库。.env、数据库密码、对象存储访问密钥都应加入 .gitignore，部署时通过环境变量或独立配置文件注入。你可以用下面的命令快速查找疑似敏感字段：
grep -R "password\|secret\|token\|AKIA" -n /var/www 2>/dev/null | head -50
这条命令只适合作为巡检辅助，不代表完整泄露扫描。发现明文密钥后，应先轮换密钥，再清理历史提交和部署文件，顺序不要反过来。
日志、告警和备份：让问题能被发现，也能被恢复
安全加固不只为“挡住攻击”，也要让异常能被发现、损失可恢复。日志和备份是两条底线：没有日志，事后无法判断入口；没有可恢复备份，勒索、误删、误升级都会变成业务事故。
建议至少跟踪 4 类日志：SSH（安全外壳协议）登录日志、Web 访问日志、应用错误日志、系统认证日志。常用检查命令包括：
journalctl -u ssh --since "24 hours ago"
last -a | head -30
tail -n 100 /var/log/auth.log
告警不必一开始就很复杂。你可以先定义 3 个触发条件：5 分钟内同一 IP 登录失败超过 20 次、磁盘使用率超过 85%、Web 5xx 错误持续 10 分钟。这样的阈值足够具体，团队也容易判断是否需要处理。站点速度和稳定性巡检，还可以参考 网站性能优化 中关于响应时间和资源瓶颈的排查思路。
备份要重点验证“能恢复”，而不是只确认“有文件”。对于数据库型网站，建议至少保留本机短周期备份和异地备份两层；恢复演练可以每月做一次，抽取最新备份恢复到测试环境，确认首页、登录、下单或表单提交等关键路径可用。备份文件本身也要加权限和生命周期，避免备份目录反过来成为泄露源。
内核参数与网络基线：用 sysctl 收紧默认行为
内核参数不是加固的第一步，但在前面几层完成后，可以用它补上网络层默认行为。修改前建议把 /etc/sysctl.conf 或 /etc/sysctl.d/99-hardening.conf 备份出来，并一次只改一组参数，避免排障时不知道是哪项影响了业务。
下面是一组常见的 Linux 网络基线示例：
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
写入配置后执行：
sysctl --system
sysctl net.ipv4.tcp_syncookies
这些参数主要用于减少不必要的转发、重定向和部分网络滥用风险。它们不能替代业务层安全，也不能解决弱密码和错误权限。更稳妥的理解是：内核参数收紧默认行为，防火墙控制入口，应用隔离限制影响，日志与备份负责发现和恢复。
最后按 10 项清单复查，不要只做一次性配置
完成配置后，建议把服务器安全加固固定成一张巡检表。每次新建服务器、迁移站点、上线业务或更换运维人员时，都按同一张表复查，避免不同人凭经验临场发挥。
可以按下面 10 项做交付检查：
- 端口清单已记录，公网只开放业务必需端口，例如 22、80、443
- SSH（安全外壳协议）已禁用 root 远程登录，并启用密钥认证
- 防火墙默认拒绝入站，只放行明确来源和明确端口
- 系统安全更新策略已确定，内核重启窗口已写入维护计划
- sudo 用户、SUID 文件和站点目录权限已完成复核
- 数据库、缓存、队列只监听本机或内网地址
- 应用配置文件、密钥、备份目录不在公网 Web 根目录
- 登录失败、磁盘容量、Web 5xx 已设置可执行告警阈值
- 最新备份已在测试环境完成恢复验证
- sysctl 参数已备份、应用并复查，没有影响业务连接
总结来看，服务器安全加固应该从“减少入口、降低权限、限制暴露、保留证据、验证恢复”五个方向推进。我们建议先用一台非核心服务器演练整套流程，再把清单固化到生产环境。如果你需要为新业务选择基础设施，Hostease 的主机方案可以作为参考；但无论使用哪类服务器，持续巡检、最小权限和可恢复备份，才是长期安全运营的核心。