开发者仍在犯的5个常见服务器安全错误

Source: Dev.to

即使在 2025 年，服务器安全仍常被视为事后考虑。
许多开发者认为云服务商、托管面板或默认配置已经“足够安全”。事实并非如此。

在管理生产服务器和托管环境的过程中，我看到相同的安全错误一次又一次地出现——即使是有经验的开发者也不例外。下面是开发者仍在犯的 5 大常见服务器安全错误以及如何正确修复它们。

将默认服务和端口暴露

错误做法

• 在 22 端口开放 SSH
• 运行未使用的服务
• 没有防火墙规则

攻击者 24/7 扫描互联网寻找这些默认设置。

正确做法

• 禁用未使用的服务
• 限制 SSH 访问
• 使用防火墙

UFW 示例

ufw allow 2222/tcp
ufw enable

更好的做法：

• 更改 SSH 端口
• 只允许可信 IP 访问 SSH
• 使用基于密钥的认证

安全的第一步是缩小攻击面。

使用弱密码或重复使用密码（尤其是 root）

错误做法

• 在所有地方使用相同密码
• 为了方便使用简单密码
• 通过密码启用 root 登录

这些都会导致暴力破解攻击。

正确做法

• 禁用基于密码的 root 登录
• 使用 SSH 密钥
• 强制使用强密码

在 /etc/ssh/sshd_config 中：

PermitRootLogin no
PasswordAuthentication no

重启 SSH 使更改生效：

systemctl restart sshd

便利性不值得让服务器被攻破。

误以为 .htaccess 在所有环境都有效

错误做法

开发者常依赖 .htaccess 来：

• 阻止目录访问
• 限制访问
• 实现安全规则

.htaccess 在 Nginx 上不起作用。

正确做法

如果使用 Nginx，请在 Nginx 配置中加入安全规则：

location /vendor/ {
    deny all;
    return 403;
}

当 Nginx 与 Apache 同时存在时，Nginx 的规则优先。务必了解自己的 Web 服务器栈。

暴露敏感文件和目录

错误做法

公开访问以下内容：

• /vendor
• .env
• configuration.php
• 备份文件
• Git 仓库

这是一条快速泄露凭证的途径。

正确做法

• 将应用文件移出 public_html
• 在 Web 服务器层面限制访问
• 设置正确的文件权限

推荐的权限设置：

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

如果文件不需要公开，就不要让它公开。

忽视更新和安全补丁

错误做法

“我以后再更新。”
漏洞服务器会多年保持脆弱。真实的攻击往往利用：

• 旧的 PHP 版本
• 未打补丁的内核
• 过时的控制面板

正确做法

• 启用自动安全更新
• 安排定期维护窗口
• 监控 CVE

在 AlmaLinux 上：

dnf update -y

安全补丁不是可选项——它们是生产就绪的一部分。

额外错误：缺乏监控或日志审查

服务器不会在无声中被攻破。通常会留下警告：

• 登录失败尝试
• 可疑进程
• 意外的流量激增

如果没人监控，就没人发现。

修复方法：

• 启用基础监控
• 定期审查日志
• 为异常行为设置告警

最后思考

服务器安全不是偏执，而是做好准备。大多数泄露并非因为零日漏洞，而是因为从未修复的基本错误。

如果你：

• 锁定访问权限
• 了解自己的服务器栈
• 保持系统更新

那么你已经在大多数部署中领先一步。