Debian 安全加固方案｜适合站长

对于站长来说，服务器安全不是“可选项”，而是网站长期稳定运行的基础。无论你部署的是个人博客、企业官网、论坛社区、API 服务，还是电商系统，只要服务器暴露在公网，就一定会面临扫描、爆破、漏洞利用、恶意爬虫、DDoS、木马植入等风险。

Debian 作为稳定、可靠、生态成熟的 Linux 发行版，常被用于生产环境。但默认安装后的 Debian 并不等于“安全完成态”，它只是提供了一个干净、稳定的基础系统。真正适合站长使用的服务器，还需要从账号权限、SSH、防火墙、系统更新、Web 服务、数据库、日志审计、备份恢复等多个方面进行加固。

本文将从实战角度出发，整理一套适合站长使用的 Debian 安全加固方案。内容尽量兼顾安全性与可操作性，适用于 Debian 11、Debian 12 以及大多数基于 Debian 的服务器环境。

一、基础安全原则

在正式操作之前，站长需要先理解几个基本原则。

1. 最小权限原则

服务器上的每一个用户、每一个服务、每一个端口，都应该只拥有完成任务所需的最小权限。

例如：

• 普通运维不要长期使用 root 登录；
• Web 服务用户不应该拥有系统管理权限；
• 数据库不要开放公网访问；
• 不需要的端口必须关闭；
• 不需要的软件包尽量不要安装。

权限越多，攻击面越大。一旦某个程序被攻破，攻击者能够利用的权限也越高。

2. 默认配置不等于安全配置

很多软件为了兼容性和易用性，默认配置并不是最安全的。例如：

• SSH 默认监听 22 端口；
• 某些服务可能默认绑定所有网卡；
• PHP 可能暴露危险函数；
• 数据库可能存在弱密码或匿名用户；
• Web 目录权限可能设置过宽。

站长需要根据自己的业务场景主动调整。

3. 安全是持续过程

安全加固不是一次性任务。系统需要持续更新，日志需要定期检查，备份需要定期验证，证书需要定期续期，账号权限也需要周期性审计。

如果服务器上线后长期不维护，那么即使初始配置再安全，也可能因新漏洞而被攻破。

二、系统安装后的第一步：更新系统

新服务器创建完成后，第一件事就是更新软件源和系统包。

apt update
apt upgrade -y
apt full-upgrade -y
apt autoremove -y

建议安装常用安全工具：

apt install -y sudo vim curl wget gnupg2 ca-certificates lsb-release apt-transport-https ufw fail2ban unattended-upgrades logrotate

说明：

• sudo：用于普通用户提权执行管理命令；
• ufw：简化防火墙管理；
• fail2ban：防止 SSH、Web 登录等暴力破解；
• unattended-upgrades：自动安装安全更新；
• logrotate：日志轮转，防止日志撑满磁盘。

三、创建普通用户并限制 root 登录

很多站长习惯直接用 root 管理服务器，这虽然方便，但风险较高。推荐创建一个普通管理用户，然后通过 sudo 提权。

1. 创建普通用户

假设创建用户 adminuser：

adduser adminuser

根据提示设置密码。

2. 加入 sudo 组

usermod -aG sudo adminuser

之后可以用该用户登录服务器，并通过：

sudo command

执行管理员命令。

3. 测试 sudo 权限

切换用户：

su - adminuser

测试：

sudo whoami

如果输出：

root

说明配置成功。

四、SSH 安全加固

SSH 是服务器最重要的入口，也是被攻击最多的入口之一。站长必须重点加固 SSH。

SSH 配置文件通常位于：

/etc/ssh/sshd_config

编辑前建议备份：

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

编辑配置：

vim /etc/ssh/sshd_config

1. 禁止 root 远程登录

找到或添加：

PermitRootLogin no

这样即使攻击者猜到 root 密码，也无法直接远程登录。

2. 修改默认 SSH 端口

默认 22 端口每天都会被大量扫描。可以改为高位端口，例如：

Port 22222

注意：修改端口后，要先放行防火墙端口，再重启 SSH，避免把自己锁在外面。

3. 禁用密码登录，改用密钥登录

如果条件允许，建议使用 SSH 密钥登录。

在本地电脑生成密钥：

ssh-keygen -t ed25519 -C "your_email@example.com"

将公钥上传到服务器：

ssh-copy-id -p 22222 adminuser@your_server_ip

确认密钥登录成功后，在服务器配置中关闭密码登录：

PasswordAuthentication no
PubkeyAuthentication yes

4. 限制允许登录的用户

例如只允许 adminuser 登录：

AllowUsers adminuser

5. 关闭空密码登录

PermitEmptyPasswords no

6. 重启 SSH 服务

在 Debian 中通常使用：

systemctl restart ssh

或：

systemctl restart sshd

建议不要立刻关闭当前 SSH 窗口，而是新开一个终端测试能否登录。确认无误后再关闭旧连接。

五、配置 UFW 防火墙

防火墙的目标是：只开放业务必需端口，其他端口全部拒绝。

1. 默认策略

ufw default deny incoming
ufw default allow outgoing

2. 放行 SSH 端口

如果 SSH 使用 22222：

ufw allow 22222/tcp

3. 放行网站端口

HTTP：

ufw allow 80/tcp

HTTPS：

ufw allow 443/tcp

4. 启用 UFW

ufw enable

查看状态：

ufw status verbose

5. 常见站长端口建议

通常情况下：

如果你有固定办公 IP，可以进一步限制 SSH：

ufw allow from 你的IP to any port 22222 proto tcp

这样只有指定 IP 可以连接 SSH。

六、使用 Fail2ban 防止暴力破解

Fail2ban 可以监控日志，当发现某个 IP 多次登录失败时，自动封禁该 IP。

安装：

apt install -y fail2ban

创建本地配置文件：

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

编辑：

vim /etc/fail2ban/jail.local

针对 SSH 可配置：

[sshd]
enabled = true
port = 22222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

重启服务：

systemctl restart fail2ban
systemctl enable fail2ban

查看状态：

fail2ban-client status
fail2ban-client status sshd

Fail2ban 不是万能防护，但对低成本爆破非常有效。

七、配置自动安全更新

站长不可能每天都手动登录服务器更新系统，因此建议开启安全更新。

安装：

apt install -y unattended-upgrades apt-listchanges

启用：

dpkg-reconfigure unattended-upgrades

选择 Yes。

也可以编辑配置：

vim /etc/apt/apt.conf.d/50unattended-upgrades

确保包含 Debian 安全源，例如：

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
};

自动更新可以降低已知漏洞被利用的风险。但对核心业务服务器，建议配合监控和备份，避免极少数更新导致服务异常。

八、时间同步与系统时区

正确的系统时间对日志分析、证书校验、定时任务、数据库记录都很重要。

设置时区为上海：

timedatectl set-timezone Asia/Shanghai

启用时间同步：

timedatectl set-ntp true

查看状态：

timedatectl

九、Web 服务安全加固

大多数站长会使用 Nginx 或 Apache。这里以 Nginx 为例说明常见加固思路。

1. 隐藏版本号

编辑：

vim /etc/nginx/nginx.conf

在 http 区块中加入：

server_tokens off;

重新加载：

nginx -t
systemctl reload nginx

这样可以减少版本信息暴露。

2. 强制使用 HTTPS

建议使用 Let’s Encrypt 免费证书。

安装 Certbot：

apt install -y certbot python3-certbot-nginx

申请证书：

certbot --nginx -d example.com -d www.example.com

测试自动续期：

certbot renew --dry-run

Nginx 中可以配置 HTTP 跳转 HTTPS：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

3. 添加常见安全响应头

在 HTTPS 站点配置中加入：

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

如果你的网站已经全站 HTTPS 且确认没有混合内容，可以使用 HSTS：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

注意：HSTS 配置后，浏览器会长期强制使用 HTTPS。如果证书或 HTTPS 配置出错，用户可能无法访问网站。因此上线前要充分测试。

4. 限制上传目录执行脚本

很多网站被入侵，是因为攻击者上传了 PHP 木马。如果上传目录允许执行 PHP，就非常危险。

假设上传目录为：

/var/www/example.com/uploads

Nginx 中可以加入：

location ^~ /uploads/ {
    location ~ \.php$ {
        deny all;
    }
}

对于 WordPress、Discuz、Typecho 等程序，尤其要检查上传目录是否可执行脚本。

5. 限制敏感文件访问

location ~ /\.(?!well-known).* {
    deny all;
}

location ~* \.(env|ini|log|sql|bak|old|swp)$ {
    deny all;
}

这可以避免 .env、备份文件、日志文件、SQL 文件被直接下载。

十、PHP 安全加固

如果网站使用 PHP，需要特别注意 PHP 配置。

配置文件通常位于：

/etc/php/*/fpm/php.ini

1. 关闭危险函数

可根据业务情况禁用部分函数：

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

注意：有些程序可能依赖这些函数，禁用前应测试。

2. 关闭错误显示

生产环境不要直接显示 PHP 错误：

display_errors = Off
log_errors = On

3. 限制上传大小

upload_max_filesize = 20M
post_max_size = 20M

不要盲目设置过大，避免被恶意上传拖垮磁盘或内存。

4. 设置合理执行时间

max_execution_time = 60
max_input_time = 60
memory_limit = 256M

根据业务规模调整。

5. PHP-FPM 独立用户运行

不同网站建议使用不同系统用户运行 PHP-FPM，避免一个站点被攻破后影响其他站点。对于多站点服务器，这一点非常重要。

十一、数据库安全加固

1. 数据库禁止公网访问

MySQL/MariaDB 配置文件通常在：

/etc/mysql/mariadb.conf.d/50-server.cnf

或：

/etc/mysql/mysql.conf.d/mysqld.cnf

确保绑定本地地址：

bind-address = 127.0.0.1

重启数据库：

systemctl restart mariadb

或：

systemctl restart mysql

同时不要在 UFW 中开放 3306 端口。

2. 运行安全初始化

MariaDB/MySQL 可执行：

mysql_secure_installation

它可以帮助你：

• 设置 root 密码；
• 删除匿名用户；
• 禁止 root 远程登录；
• 删除测试数据库；
• 刷新权限表。

3. 为每个网站创建独立数据库账号

不要让所有网站共用数据库 root 用户。

示例：

CREATE DATABASE site_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site_user'@'localhost' IDENTIFIED BY '强密码';
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,INDEX,DROP ON site_db.* TO 'site_user'@'localhost';
FLUSH PRIVILEGES;

权限应按需分配，不要随意给 ALL PRIVILEGES。

十二、文件与目录权限加固

1. Web 目录不要随意 777

很多站长遇到权限问题时，习惯执行：

chmod -R 777 /var/www/html

这是非常危险的。777 意味着任何用户都可以读、写、执行，一旦某个低权限服务被利用，攻击者就可以修改网站文件。

常见建议：

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;

对于需要写入的目录，如 uploads、cache，单独赋予 Web 用户写权限。

2. 设置正确属主

以 Nginx/PHP-FPM 常见用户 www-data 为例：

chown -R www-data:www-data /var/www/example.com

但更推荐的做法是：代码文件由部署用户拥有，Web 用户只对上传和缓存目录有写权限。

例如：

chown -R deploy:deploy /var/www/example.com
chown -R www-data:www-data /var/www/example.com/uploads
chown -R www-data:www-data /var/www/example.com/cache

这样即使 Web 程序被攻击，也不容易篡改核心代码。

3. 保护配置文件

包含数据库密码、API 密钥的配置文件应限制权限：

chmod 600 /var/www/example.com/config.php

并尽量避免配置文件放在可被 Web 直接访问的目录中。

十三、日志审计与入侵排查

服务器安全加固后，还需要能发现异常。

1. 常见日志位置

2. 查看 SSH 登录失败

grep "Failed password" /var/log/auth.log

查看成功登录：

grep "Accepted" /var/log/auth.log

3. 查看近期登录用户

last

查看失败登录：

lastb

如果 lastb 不可用，可能需要安装或启用相关日志。

4. 检查监听端口

ss -tulnp

如果发现不认识的端口或进程，应立即排查。

5. 检查异常进程

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

6. 检查计划任务

攻击者常通过计划任务维持后门。

检查当前用户：

crontab -l

检查系统任务：

ls -la /etc/cron*
cat /etc/crontab

十四、安装与使用 rkhunter/chkrootkit

可以安装 rootkit 检测工具作为辅助检查。

apt install -y rkhunter chkrootkit

运行：

rkhunter --update
rkhunter --check
chkrootkit

需要注意，这类工具可能存在误报，也无法保证发现所有后门。它们适合作为辅助审计工具，而不是唯一安全手段。

十五、备份策略：安全的最后防线

很多站长重视防护，却忽视备份。但真实场景中，服务器可能因为误操作、硬盘故障、勒索病毒、程序漏洞、供应商故障而导致数据丢失。

可靠备份应遵循“3-2-1 原则”：

• 至少保留 3 份数据；
• 使用 2 种不同存储介质；
• 至少 1 份异地备份。

1. 需要备份的内容

通常包括：

• 网站程序文件；
• 上传文件；
• 数据库；
• Nginx/Apache 配置；
• SSL 证书；
• 定时任务；
• 环境变量和配置文件。

2. 数据库备份示例

mysqldump -u root -p --single-transaction --routines --triggers site_db > site_db_$(date +%F).sql

压缩：

gzip site_db_$(date +%F).sql

3. 文件备份示例

tar -czf website_$(date +%F).tar.gz /var/www/example.com

4. 异地同步

可以使用：

• rsync
• SFTP
• 对象存储
• 云厂商快照
• Restic
• BorgBackup

但要注意：备份账号也要有权限隔离。不要让生产服务器拥有删除所有远程备份的高权限，否则一旦服务器被攻破，备份也可能被删除。

5. 定期恢复演练

没有验证过的备份，不算真正可靠。建议每隔一段时间在测试环境恢复一次，确认数据库、文件和配置都可用。

十六、禁止不必要服务与软件

服务器上安装的软件越多，潜在漏洞越多。站长应定期检查已安装服务。

查看正在运行的服务：

systemctl --type=service --state=running

查看开机自启：

systemctl list-unit-files --type=service | grep enabled

对于不需要的服务，禁用：

systemctl disable 服务名
systemctl stop 服务名

查看已安装软件包：

apt list --installed

如果确认不需要，可以卸载：

apt remove 软件包名
apt autoremove

十七、Docker 环境安全建议

很多站长使用 Docker 部署网站。Docker 虽然方便，但也需要加固。

1. 不要随意使用 privileged 模式

避免：

docker run --privileged ...

--privileged 会给予容器过高权限，一旦容器被攻破，风险接近宿主机沦陷。

2. 不要把 Docker API 暴露公网

Docker API 如果未加认证暴露到公网，攻击者可以直接控制服务器。

检查：

ss -tulnp | grep docker

不要监听 0.0.0.0:2375。

3. 使用官方镜像或可信镜像

不要随意运行来源不明的镜像。镜像中可能包含后门、挖矿程序或恶意脚本。

4. 容器最小权限运行

尽量使用：

--read-only
--cap-drop=ALL

再按需增加能力。

5. 数据卷权限隔离

不要把宿主机根目录挂载进容器：

-v /:/host

这是非常危险的操作。

十八、站长常见程序的安全重点

1. WordPress

WordPress 用户量大，因此也是攻击重点。

建议：

• 保持 WordPress 核心、主题、插件更新；
• 删除不用的主题和插件；
• 使用强密码和双因素认证；
• 修改默认后台登录地址可降低扫描噪音；
• 限制 wp-admin 访问 IP；
• 禁止后台在线编辑主题插件；
• 定期扫描异常文件。

可在 wp-config.php 中加入：

define('DISALLOW_FILE_EDIT', true);

2. Typecho、Z-Blog、Discuz 等

同样需要：

• 及时升级版本；
• 删除安装目录；
• 关闭调试模式；
• 限制上传类型；
• 检查插件来源；
• 后台使用强密码；
• 管理后台尽量限制 IP 或加二次认证。

3. 自研网站

自研项目重点关注：

• SQL 注入；
• XSS；
• CSRF；
• 文件上传漏洞；
• 越权访问；
• SSRF；
• 反序列化漏洞；
• API 鉴权缺陷；
• 敏感信息泄露。

服务器加固只能降低风险，不能替代代码安全。

十九、监控与告警

安全不仅是防护，还包括及时发现问题。

建议至少监控：

• CPU 使用率；
• 内存使用率；
• 磁盘使用率；
• 网络流量；
• 进程异常；
• 网站状态码；
• SSL 证书有效期；
• 数据库连接数；
• SSH 登录行为。

可选工具：

• Prometheus + Grafana；
• Netdata；
• Zabbix；
• Uptime Kuma；
• 云厂商监控；
• 自写脚本配合邮件、企业微信、Telegram 通知。

例如检查磁盘：

df -h

如果磁盘使用率超过 80%，就应及时处理。很多网站故障并非黑客攻击，而是日志或备份文件撑满磁盘。

二十、建议的安全加固清单

下面是一份适合站长上线前检查的 Debian 安全清单：

• [ ] 系统已执行 apt update && apt upgrade
• [ ] 创建普通管理用户
• [ ] 禁止 root SSH 登录
• [ ] SSH 改为密钥登录
• [ ] 修改默认 SSH 端口
• [ ] 防火墙只开放必要端口
• [ ] 安装并启用 Fail2ban
• [ ] 开启自动安全更新
• [ ] Web 服务隐藏版本号
• [ ] 网站启用 HTTPS
• [ ] 配置安全响应头
• [ ] 上传目录禁止执行脚本
• [ ] 敏感文件禁止 Web 访问
• [ ] PHP 关闭错误显示
• [ ] PHP 禁用不必要危险函数
• [ ] 数据库禁止公网访问
• [ ] 每个网站使用独立数据库账号
• [ ] Web 目录权限合理，无 777
• [ ] 配置日志轮转
• [ ] 设置定期异地备份
• [ ] 定期恢复测试备份
• [ ] 安装监控和告警
• [ ] 定期审计用户、端口、进程和计划任务

二十一、应急处理建议

如果怀疑服务器已经被入侵，不建议盲目删除文件或重启服务。可以按以下步骤处理：

1. 立即保留现场：记录当前进程、端口、登录用户、计划任务、可疑文件；
2. 断开公网访问：必要时通过安全组或防火墙限制入口；
3. 备份证据：保存日志、恶意文件样本、异常进程信息；
4. 修改所有密码：包括服务器、数据库、网站后台、云平台、对象存储等；
5. 检查后门：包括 SSH key、计划任务、WebShell、系统服务；
6. 从干净备份恢复：如果无法确认系统完整性，重装系统通常比“修修补补”更可靠；
7. 复盘漏洞来源：是弱密码、程序漏洞、插件漏洞、配置错误，还是泄露密钥；
8. 补齐防护措施：避免同样问题再次发生。

对于严重入侵，最稳妥的方式通常是：备份必要数据、重装系统、恢复干净版本、重新部署服务、轮换所有密钥和密码。

结语

Debian 本身是一个非常适合生产环境的系统，但服务器安全不能只依赖系统稳定性。对于站长而言，真正有效的安全加固应该覆盖“入口控制、权限隔离、服务收敛、持续更新、日志审计、备份恢复、监控告警”这几个方面。

如果你的网站规模不大，至少应完成以下核心操作：禁止 root 登录、使用 SSH 密钥、防火墙只开放必要端口、开启 Fail2ban、数据库不开放公网、网站启用 HTTPS、目录权限不设 777、定期异地备份。

安全没有绝对完美，但可以通过正确的配置和持续维护，大幅降低被攻击和数据丢失的风险。对站长来说，稳定访问、数据安全和可恢复能力，才是服务器运维最重要的底线。