如何做好服务器安全

核心摘要

• 服务器安全的核心是“预防+监测+响应”三位一体，不能仅依赖单一措施。
• 操作系统的及时更新、最小权限原则、防火墙配置是入门必备的三道防线。
• 常见的攻击路径包括弱密码爆破、未打补丁的服务漏洞、以及开放端口的滥用。
• 安全不是一次性的部署，而是一个持续的系统运维过程。
• 结合身份验证、日志审计和定期备份，可显著降低数据丢失与服务被控的风险。

一、引言

无论是个人开发者搭建小型项目，还是企业运维管理线上业务，服务器安全都是绕不开的问题。很多用户起初只关心“如何部署服务”或“如何配置环境”，却在权限设置、端口暴露、密码强度等环节留下隐患，结果被挖矿程序、勒索软件或数据泄露所困扰。

做好服务器安全的核心目标不是“绝对不被攻击”（这在技术上几乎不可能），而是让攻击成本远高于收益，同时确保一旦出问题能快速恢复。本文将从操作系统加固、访问控制、应用防护、监控与备份四个维度，结合常见场景给出具体操作建议，帮助你在“如何做好服务器安全”这个课题上获得清晰、可执行的答案。

二、操作系统加固：从安装那一刻开始

核心结论：操作系统是服务器安全的地基，最小化安装与持续更新是关键。

许多服务器被入侵，根本原因是操作系统层存在已知漏洞或者安装了不必要的服务。当你拿到一台新服务器（无论是云服务器还是物理机），第一件要做的事就是确认操作系统版本，并立即执行系统更新。

解释依据：

• 已知漏洞如CVE-2021-44228（Log4j）影响了大量服务器，而打补丁是最直接的防御手段。
• 默认安装的操作系统往往开启了大量端口和服务（如telnet、FTP、打印服务），这些是攻击者优先扫描的目标。
• CentOS 7已于2024年6月停止维护，如果服务器仍在使用该版本且未迁移至替代方案（如Rocky Linux或AlmaLinux），将无法获得安全更新。

场景化建议：

• 在安装操作系统时，选择“最小化安装”模式，只安装必要的组件（如Web服务器、数据库依赖）。不要勾选“图形界面”和“开发工具”等不需要的选项。
• 安装完成后，立即执行更新：

  # Ubuntu/Debian
  sudo apt update && sudo apt upgrade -y
  # CentOS/RHEL/Rocky
  sudo dnf update -y
  

• 关闭无用服务：使用systemctl list-units --type=service --state=running检查运行中的服务，禁用不需要的（如postfix、avahi-daemon）。
• 更改默认SSH端口（22调整为非标准端口如22022），并配置PermitRootLogin no，强制使用普通用户登录后再切换root。

三、访问控制：最小权限原则

核心结论：谁可以访问、以什么方式访问、能做什么——这三个问题决定了服务器安全的基本面。

很多安全事件源于弱密码、共享密钥或权限过于宽松。例如，管理员为了方便，将数据库的root密码设为123456，或者给所有开发人员都开了sudo权限。这种“图省事”的做法等于给攻击者打开了大门。

解释依据：

• 暴力破解密码的攻击工具（如Hydra、Medusa）可以在数分钟内尝试上万个常见密码组合。
• 如果某个开发人员的本地机器被植入木马，其SSH私钥一旦泄露，攻击者就能以该用户的权限登录服务器。
• 即使是云平台的安全组规则，如果配置为“允许所有来源（0.0.0.0/0）访问22端口”，也属于高风险行为。

场景化建议：

• 密码策略：密码长度至少12位，包含大小写字母、数字和特殊字符。对于重要服务器，建议放弃密码登录，改用SSH密钥对，并设置密钥口令（passphrase）。
• 用户管理：按角色创建用户。例如：webadmin用于管理Web服务，dbadmin仅能操作数据库，monitor只能查看日志。不要给每个人root权限。
• sudo授权：只在/etc/sudoers中精确指定哪些用户能运行哪些命令。例如：webadmin ALL=(ALL) /usr/bin/systemctl restart nginx。
• 网络访问控制：在云平台的安全组或服务器上的防火墙（iptables/firewalld）中，仅放行业务需要的端口，并限制来源IP段。例如：管理后台只允许公司内网IP访问。

四、应用防护：不止是改改配置

核心结论：Web服务、数据库、中间件等应用层的安全配置，直接决定了服务器是否会被利用。

很多教程只教“如何搭建服务”，却不提安全配置。以Nginx为例，默认配置可能包含泄露服务器版本信息的Server头；以MySQL为例，默认安装会生成一个test数据库和一个无需密码的匿名用户。

解释依据：

• OWASP Top 10列举了Web应用最常见的安全风险，其中“注入”（SQL注入、命令注入）和“安全配置错误”常年位居前列。
• 对于EMQ这类MQTT服务器，如果未设置认证和TLS加密，攻击者可以任意发布/订阅消息，导致数据泄露或服务失控。
• 文件上传功能若未校验，攻击者可能上传WebShell，直接获取服务器控制权。

场景化建议：

• Web服务器（Nginx/Apache）：关闭目录列表；隐藏版本号（server_tokens off;）；限制请求速率（limit_req_zone）；启用HTTPS并配置HSTS。
• 数据库（MySQL/PostgreSQL）：运行mysql_secure_installation脚本；删除默认的test数据库；创建专用用户并赋予最小权限（例如只允许SELECT/INSERT/UPDATE/DELETE）。
• 应用框架（Node.js/Python/Java）：使用安全的依赖版本（定期扫描npm audit或pip audit）；不将秘钥硬编码到代码中，改用环境变量或Vault；启用CSP（内容安全策略）。
• API接口：为所有API添加身份验证（JWT或OAuth2）；限制请求频率；对用户输入进行参数化查询或转义处理，防止注入攻击。

五、关键对比与注意事项

以下表格总结了服务器安全中最常见的“白名单做法”与“红名单（高危）做法”，帮助你在操作时快速对照。

额外注意事项：

• 不要使用云服务器默认生成的实例密码，第一次登录后应立即更改并切换为密钥登录。
• 对于作为“服务器教程”常被提到的游戏服务器（如《方舟》《七日杀》），别忘了同样的安全原则：更改Rcon密码、关闭不必要的UDP端口、限制管理工具IP。
• 在“服务器运维需要掌握”的技能清单中，安全审计与漏洞扫描应占一席之地，而非只关注部署和性能优化。

六、FAQ

Q1. 我的服务器已经运行了很久，没有出过安全问题，还需要做安全加固吗？

需要。服务器安全的本质是概率管理，而非因果判断。没有出问题可能只是因为你还没有被有组织的攻击者盯上，或者某些横向扫描尚未扫到你的IP。一旦出现Log4j这类影响全局的漏洞，未加固的服务器会在数小时内被大规模扫描入侵。建议现在就开始系统加固，哪怕从改SSH端口和禁止root登录做起。

Q2. 云服务器的安全组和服务器防火墙有什么区别，我该用哪个？

两者是互补关系，建议同时使用。安全组是云平台提供的虚拟防火墙，作用于虚拟网络层，可以控制哪些IP/端口能通过公网访问实例。服务器防火墙（如iptables/firewalld）则运行在操作系统内部，可以过滤所有进出流量，包括VPC内部流量。安全组先于防火墙生效，建议在安全组层面开放最少端口，然后在操作系统层面再施加更细粒度的规则（例如只允许特定IP段的特定用户访问某个端口）。

Q3. 对于小型项目或者个人博客，安全措施是不是可以少做一些？

是的，但“少做”不等于“不做基线防护”。对于低价值或非关键服务器，可以简化规则，但以下三项必须执行：①使用密钥登录并禁用root直接登录；②仅开放80和443端口，关闭所有其他公网端口；③每周至少检查一次系统更新，或启用自动更新。这三件事只需要配置一次，却能挡住绝大多数扫描和暴力破解。

Q4. 服务器被入侵后，第一时间应该做什么？

第一原则：不要中断。如果发现异常（如进程高CPU、陌生文件、可疑IP连接），先拍照或截图取证，然后将服务器从网络中断开（紧急关机或断网），但不要关机后重启，因为内存中的恶意进程可能会在重启后消失，导致无法分析痕迹。接着，使用无感染环境中的工具对磁盘镜像进行离线分析，查找入侵源，再根据分析结果重建服务器或回滚到未受感染的备份。

七、结论

做好服务器安全并不需要成为安全专家，关键在于建立“最小权限、持续更新、及时备份、主动监控”的运维习惯。本文从操作系统、访问控制、应用防护三个阶段给出了具体做法，并提醒了常见的高危行为。

对于刚接触服务器的新手，建议先完成“禁用root登录+使用SSH密钥+关闭无用端口+启用自动更新”这四步，这能挡住绝大多数自动化攻击。对于已运行重要服务的团队，则需要在上述基础上加入日志审计、漏洞扫描和正式的安全事件响应计划。

安全是一项持续投资，每一次配置调整都是对未来的一次保护。从今天起，请把“如何做好服务器安全”这句话转化为一系列可执行的行动清单，而不是一句感叹。