怎么加固软件、三处配置最容易被跳过

加固这事，最贵的不是技术，是那份耐心。装个防护插件、跑一次扫描，十分钟能干完；真正决定你这套软件会不会被人从侧面摸进来的，往往是三个没人愿意点开看的配置角落。我见过太多人把防火墙规则写得漂漂亮亮，登录页却还挂着安装时留下的示例脚本。所以这篇不聊大道理，就按顺序把「怎么加固软件」这件事拆开，说三处最容易被跳过的位置，以及改完之后你怎么确认自己不是白忙一场。

怎么加固软件，先盯这三处容易漏的

顺序上我一般这么走：先看装完之后多出来什么，再看目录谁能写谁能执行，最后看报错信息往外吐了多少东西。这三件事的共同点是——它们都不在软件的配置面板首页，也不在任何一份「安全基线」的第一条，但抽查的时候一抓一个准。别急着上工具，先手动过一遍，心里有底。

第一处：安装包留下的示例、demo 和默认账号

很多程序装完是带礼包的。install 目录、setup 目录、demo 数据、test.php、还有那个口令是 admin/admin 的初始账号。装的时候图省事直接下一步，装完就忘了它们还在。这类东西的危险不在于它本身有多强，而在于它绕过了你所有正常的鉴权逻辑——它自己就是一套入口。

做法很土：装完立刻把安装目录整个删掉，或者至少改名挪到 Web 根目录之外。默认账号第一次登录就改，改完顺手确认一遍有没有第二个隐藏账号。示例数据、演示页面、后台的密码找回测试入口，能删就删。有些程序会在 /admin 之外再挂一个不带鉴权的调试入口，翻一遍路由或者直接看目录列表，比读文档快。

这里插一句，别迷信「删了就一定干净」。有些框架的安装文件是随着更新包回来的，你上次删了，下次升级又冒出来一个。所以我习惯在升级之后重新扫一遍根目录，看有没有新面孔。

第二处：目录权限，特别是上传目录能不能被执行

权限这一块最典型的现象就是 chmod -R 777 一把梭。跑起来是真顺，出事也是真快——任何一个能写文件的地方，都变成了能放脚本的地方。而上传目录，恰恰是最容易被写文件的地方。

要看的就几条：Web 根目录本身不该可写；上传目录可写但不可执行；配置文件（带数据库口令那种）权限收窄，最好只有运行用户能读。nginx 或者 Apache 那边配一下，让上传目录里的脚本请求直接返回 403，别让它进解释器。PHP 环境里顺手看下 open_basedir 有没有设，没设的话一个目录被突破就能顺着读到别的站点。

还有个常被忽略的点：备份目录和日志目录。这两个地方经常权限放得很松，因为「反正是内部用的」。可它们里面全是数据库导出和完整路径，被人拿到一份，等于把结构图交出去了。

第三处：调试开关和错误回显

上线之后还开 debug，是我见过返工率最高的一处。开发的时候方便，报错带堆栈、带 SQL、带文件绝对路径，查问题确实快。但对外它就是一份免费的内部结构说明。同样的问题还有 display_errors 没关，异常直接打印到页面上。

改这个不难，难的是记住它在几个地方都有。应用配置文件里一个、环境变量里一个、框架的缓存配置里还留着旧的。改完不清缓存，你会以为改好了，其实线上跑的还是老值。所以我一律改完就看实际输出：故意触发一个错误，或者请求一个不存在的路径，看返回的是干净的错误页还是一大段路径信息。

日志和更新，别只当它是运维那边的事

加固不是一次性动作。日志得留着，尤其是登录失败、权限变更、上传这几类，出问题时那是唯一能倒推的线索，保留周期按你们的合规要求定，拿不准就问服务商或者看官方页面说明。更新也一样，很多被打穿的软件不是没有补丁，是补丁发了没人装。

但我不建议无脑自动更新生产环境。比较稳的做法是：测试环境先跑，确认没把业务搞挂，再上生产；更新前留一份文件和数据库快照。这话听着老套，真出事的时候能救命。

改完怎么验证没白改

改配置最怕的就是自我感觉良好。给你几个我常用的笨办法：用 curl -I 看响应头有没有泄露版本号和服务标识；用没登录的浏览器直接访问后台路径，看是不是跳到登录页而不是给你个目录列表；拿一个测试账号试着访问上传目录里的脚本文件，看是不是被拦；再把自己当外人，从外网扫一遍端口，确认没有多出来的服务。

还有一条：把这次改动记下来。谁改的、改了哪个文件、为什么改。过半年你自己都不记得当初为什么把那条规则注释掉，下一个人更不会知道。

说到底，软件加固里那些真正见效的动作，往往不酷，也不在教程的第一页。装完先删示例、权限别图省事、上线关掉调试回显，这三步做完，你就已经挡掉了相当一部分只会扫目录、试默认口令的自动化脚本。剩下的才是慢慢磨的事：日志看勤一点，补丁别拖，改完一定去验证一遍。别指望一次搞定，能守住这三处不漏，就算及格了。