个人网站从零搭建基础安全防护体系方法

个人网站上线后的头24小时，你就能在日志里看到成百上千条扫描请求。这些不是真实的访客，而是自动化脚本在探测你的系统漏洞。它们扫描开放端口、测试默认后台地址、尝试SQL注入和文件包含。如果你不做任何防护，快则几天慢则几周，网站就会被植入恶意代码、沦为挖矿肉鸡，或者直接被篡改页面。搭建基础安全防护体系，不是大厂的专利，个人站长完全可以用一套低成本、高效果的方法把99%的常见攻击挡在门外。

无论你用云服务器还是本地虚拟机，系统装好之后第一件事不是装环境，而是加固操作系统。默认的root账户和22端口是暴力破解的头号目标。先创建一个普通用户并赋予sudo权限，然后修改SSH配置文件，禁止root远程登录，把默认端口从22改成一个高位端口比如四万以上。这不是什么安全通过隐匿的玄学，而是大幅降低自动化扫描命中你的概率。那些扫描脚本默认只扫22端口，改端口能直接过滤掉九成以上的噪音流量。

接下来配置SSH密钥登录，彻底关闭密码认证。在本地机器上生成一对密钥，把公钥传到服务器，然后在sshd_config里把PasswordAuthentication设为no。从此登录必须持有私钥，暴力破解密码这条路直接被堵死。如果你有多台设备需要登录，每台设备生成独立的密钥对，不要共用。私钥文件务必设置600权限，最好再加一层口令保护。完成这些操作后重启SSH服务，新开一个终端测试登录是否正常，确认没问题再关掉当前会话，避免把自己锁在外面。

系统防火墙是必选项。Ubuntu用ufw，CentOS用firewalld，本质上都是iptables的前端。默认策略设为拒绝所有入站流量，然后按需开放端口：你改过的SSH端口、80和443。如果网站有后台管理入口需要额外端口，也一并放行。ufw enable之后用ufw status verbose确认规则已生效。这一步做完，你的服务器在公网上就只暴露了必要的服务端口，扫描器探测到的攻击面大幅缩小。

Nginx或Apache安装完成后，默认配置存在信息泄露风险。访问一个不存在的页面，错误页底部可能直接显示服务器版本号和操作系统类型。攻击者利用这些信息可以精准选择漏洞利用脚本。在Nginx的主配置文件里，把server_tokens设为off，关闭版本号输出。自定义404和500错误页面，既提升用户体验，又隐藏了后端技术栈指纹。

HTTPS已经不是可选项而是必选项。浏览器会标记HTTP站点为不安全，而且HTTP明文传输意味着登录凭证和用户数据在链路上裸奔。申请证书推荐用Let's Encrypt配合Certbot工具，完全免费且支持自动续期。安装Certbot后执行certbot --nginx根据提示完成域名验证，证书签发后Certbot会自动修改Nginx配置并设置定时任务。关键一步是配置SSL参数，禁用过时的TLS1.0和1.1，只保留TLS1.2和1.3。弱加密套件也要剔除，推荐用Mozilla SSL Configuration Generator生成适合你服务器版本的配置片段，直接粘贴到nginx.conf里。

HTTP严格传输安全HSTS这个头信息容易被忽略但作用很大。它告诉浏览器在指定时间内只通过HTTPS访问你的域名，即使用户手动输入HTTP也会被浏览器自动升级。在Nginx的server块里添加一行add_header Strict-Transport-Security "max-age=63072000" always。63072000秒是两年，意味着浏览器两年内不会尝试HTTP连接。这个头部还能有效防御SSL剥离攻击。

个人网站用商业WAF成本太高，但开源方案完全够用。ModSecurity是目前最成熟的Web应用防火墙模块，可以嵌入Nginx或Apache。它内置了OWASP核心规则集，能拦截SQL注入、跨站脚本、命令注入等常见攻击。安装过程稍微繁琐但值得投入：先编译ModSecurity动态模块，然后在Nginx里加载，再下载OWASP CRS规则集并配置。默认规则集误报率不低，部署后需要花时间根据你的网站行为做白名单调优。如果觉得编译部署太复杂，Nginx Plus用户可以直接用内置的NGINX WAF，但个人站长更多会选择免费路线。

对于WordPress这类CMS建站的场景，应用层防火墙可以简化。Wordfence或Sucuri这类插件内置了WAF规则和恶意软件扫描，安装即用。但插件层面的防护深度有限，真正的请求在到达插件之前已经经过了Web服务器处理。更好的架构是在Nginx层面用Lua脚本做前置过滤。OpenResty集成了LuaJIT，可以编写高效的请求过滤逻辑。比如判断请求路径是否包含可疑字符串，User-Agent是否为空或伪装成常见爬虫但行为异常，Referer是否来自奇怪域名。这些规则写起来不复杂，但拦截效果立竿见影。

# OpenResty简单WAF示例片段
location / {
    access_by_lua_block {
        local uri = ngx.var.uri
        local args = ngx.var.args or ""
        -- 拦截路径遍历攻击
        if uri:match("%.%./") or uri:match("%.%.\\") then
            ngx.exit(403)
        end
        -- 拦截常见SQL注入关键词
        local sql_patterns = {"union%s+select", "select%s+from", "information_schema"}
        for _, pattern in ipairs(sql_patterns) do
            if args:lower():match(pattern) then
                ngx.log(ngx.ERR, "SQL injection attempt blocked: ", ngx.var.request_uri)
                ngx.exit(403)
            end
        end
    }
    proxy_pass http://backend;
}

安全防护不是一劳永逸的配置，持续监控才能发现新型攻击和配置疏漏。Nginx访问日志和错误日志是最基础的数据源。重点监控的状态码是403、404异常高频、以及大量来自同一IP的请求。手动翻日志不现实，用Fail2ban这个工具可以自动解析日志并联动防火墙封禁恶意IP。配置Fail2ban监控Nginx日志，设定阈值比如60秒内出现20次404就封禁该IP十分钟。对于SSH登录失败，Fail2ban默认就支持，三次失败封禁一小时。这些自动化规则能有效压制暴力破解和目录扫描行为。

更进一步的监控需要集中化日志管理。ELK三件套对个人服务器资源消耗太大，轻量级的方案是用Loki加Grafana。Loki负责收集和索引日志，Grafana做可视化面板和告警规则。设置当5分钟内403错误超过某个阈值时通过邮件或即时通讯工具发送告警。如果不想自建监控栈，国内有免费的日志服务方案可以选择，把Nginx日志通过rsyslog转发到云端，设置关键词告警即可。

如果你的网站有用户系统，密码存储是底线问题。绝对不要明文存储，也不要用MD5或SHA1这类快速哈希。用bcrypt或argon2，它们计算慢、抗暴力破解。PHP可以用password_hash函数，Python用bcrypt库，Node.js用bcryptjs。盐值自动内嵌在哈希结果里，不需要额外管理。登录接口必须做频率限制，同一个IP或同一个账号连续失败五次后锁定15分钟。这个限制在应用代码层实现，同时Nginx层也可以用limit_req模块做兜底。

文件上传是个人网站最容易出事的点。即使用户只能上传头像，攻击者也可能构造一个包含PHP代码的图片文件，利用文件包含漏洞执行。上传目录必须设置在Web根目录之外，通过脚本读取输出，禁止直接通过URL访问。文件类型校验不能只靠MIME类型或扩展名，要用文件头魔数验证真实类型。上传后的文件重命名为随机字符串，杜绝用户控制文件名。图片文件额外用ImageMagick或GD库重新编码一次，这个操作能清除文件中可能嵌入的恶意代码。

数据库默认安装后往往监听所有网络接口，这对Web服务器和数据库在同一台机器上的场景完全没必要。MySQL或PostgreSQL的配置文件里把bind-address设为127.0.0.1，只允许本地连接。应用连接数据库用的账号遵循最小权限原则，只授予对应数据库的增删改查权限，不要给DDL权限。定期备份数据库，备份文件加密后同步到异地存储。勒索攻击越来越猖獗，数据库被加密勒索的案例比比皆是，有异地备份就能在出事后快速恢复。

个人网站多少会用到第三方库和框架。一个被忽视的npm包或composer包可能成为入侵入口。定期用npm audit或composer audit检查已知漏洞，及时更新依赖版本。但更新本身也有风险，之前发生过多次上游包被投毒的事件。建议锁定依赖版本号，在测试环境验证后再上线。GitHub的Dependabot可以自动检测并提交更新PR，配合CI流水线做自动化测试，能平衡安全性和稳定性。

日常维护不要用root账户操作。应用运行用户、数据库用户、文件上传目录所有者都应该是独立的低权限账户。目录权限设置遵循一个简单原则：需要写入的目录不给执行权限，需要执行的目录不给写入权限。网站根目录的所有者应该是你的普通用户，Web服务器进程以www-data身份运行，只对需要写入的目录如缓存和上传目录开放写权限。这样即使应用层出现漏洞被上传了Webshell，攻击者也受限于www-data的权限范围，无法修改系统文件。

最后养成定期审计的习惯。每个月检查一次服务器上运行的服务和监听端口，关掉不再使用的。查看计划任务有没有异常条目，检查用户列表有没有新增可疑账户。这些操作花不了半小时，但能发现很多潜伏的后门。安全是一个持续的过程，不是一次配置就结束的任务。把上述这些措施逐一落实，你的个人网站就已经具备了相当扎实的基础防护能力，足以应对绝大多数自动化攻击和机会型入侵。