网站安全建设从基础配置做起

网站安全建设最容易犯的错误，就是把所有精力都放在应用层漏洞修补和攻击事后响应上，却忽略了服务器、中间件、数据库和权限体系这些基础配置带来的结构性风险。实际上大量入侵事件并不是因为攻击者使用了多高级的0day，而是基础配置里留下了太多本可以提前关闭的口子。安全建设从基础配置做起，意味着在系统上线前就消除默认口令、多余服务、错误权限和明文传输等低级但致命的问题。

操作系统是网站运行的最底层环境，如果这一层配置不当，上层应用做得再安全也形同虚设。首先要检查的是默认账户和弱口令，很多Linux发行版和Windows Server在初始安装后会保留guest账户、默认管理账户，甚至某些云镜像会内置统一的初始密码。上线前必须删除或禁用非必要账户，强制所有管理员账户使用高强度密码或密钥登录。对于Linux服务器，应当禁用root直接远程登录，改为普通用户通过sudo提权，这样即使攻击者获取了普通账户密码，也无法直接拿到最高权限。

其次是远程管理入口的收敛。SSH和RDP端口不要使用默认值，虽然改端口不能阻止定向扫描，但能过滤掉大量自动化蠕虫和批量扫描流量。更关键的是配置来源IP白名单，只允许办公网或跳板机地址访问管理端口。防火墙策略应当遵循默认拒绝原则，只放行业务必需的端口，比如80、443，其余一律关闭。很多管理员图省事直接关闭防火墙，这等于把数据库、缓存、消息队列等内部服务全部暴露在公网上。

系统补丁管理同样属于基础配置的一部分。需要建立定期检查更新机制，尤其是内核提权类漏洞，这类漏洞一旦被利用，攻击者可以从普通用户直接提升到root或SYSTEM权限，后续任何应用层防护都会失效。对于无法立即重启的生产环境，至少要评估风险并采取临时缓解措施，而不是无限期拖延。

Nginx和Apache是网站最常用的Web服务器，它们的默认配置往往偏向兼容性而非安全性。一个常见问题是目录浏览功能未关闭，攻击者可以直接列出网站目录结构，从中发现备份文件、源码压缩包或配置文件。应当在服务器配置中明确关闭autoindex，并确保每个站点根目录下没有遗留的测试文件和备份文件。

另一个容易被忽略的问题是Web服务器版本信息泄露。默认错误页面和响应头中会暴露服务器软件及版本号，攻击者可以据此快速匹配已知漏洞。应修改错误页面模板，并在配置中关闭server_tokens或ServerTokens，减少不必要的信息输出。同时要限制HTTP请求方法，如果业务只用到GET和POST，就应当在配置中拒绝PUT、DELETE、TRACE等方法，防止通过WebDAV或TRACE方式探测和利用漏洞。

对于PHP-FPM、Tomcat、Node.js等应用中间件，关键是限制运行权限和资源隔离。PHP进程不应以root身份运行，而应创建独立的低权限系统用户，并设置open_basedir限制文件访问范围。Tomcat的管理后台如果不需要使用，应直接删除或重命名manager和host-manager应用，而不是只修改密码。Node.js应用要确保不以root启动，并通过进程管理器限制内存和CPU使用，防止应用被攻击后成为挖矿或DDoS的跳板。

数据库往往是攻击者最想拿到的目标，因为里面存放着用户数据和业务核心信息。MySQL、PostgreSQL、Redis等数据库在默认安装后，很多版本允许本地免密登录或使用空密码，这是必须第一时间修改的。数据库账户体系要遵循最小权限原则，应用程序连接数据库的账户只授予对应库的增删改查权限，不要使用root或管理员账户作为业务连接账户。

Redis的安全问题尤为突出，默认配置下Redis绑定在0.0.0.0且没有密码认证，攻击者可以直接连接并写入公钥、修改持久化文件甚至执行系统命令。如果业务确实需要Redis对外提供服务，必须设置强密码、修改默认端口、禁用高危命令如CONFIG、FLUSHALL、EVAL，并通过防火墙限制访问来源。更推荐的做法是让Redis只监听内网地址，仅允许应用服务器访问。

数据库的远程访问策略也需要严格收紧。MySQL和PostgreSQL不应直接对公网开放3306或5432端口，所有数据库连接都应走内网或通过SSH隧道。如果必须跨机房或跨云访问，应使用专线或VPN组网，而不是把数据库端口暴露在公网上。同时要定期检查数据库中是否存在匿名账户、无密码账户或过期未删除的临时账户，这些账户常常成为攻击者横向渗透的入口。

网站传输层安全的基础就是全站启用HTTPS，并且要配置正确。很多网站虽然部署了SSL证书，但仍然允许HTTP访问，或者存在混合内容问题，导致部分数据明文传输。正确做法是在Web服务器层配置301跳转，将所有HTTP请求强制跳转到HTTPS，同时在应用代码中统一使用相对路径或HTTPS绝对路径加载资源。

证书配置本身也有讲究。私钥文件权限必须严格限制为仅root或Web服务器启动用户可读，防止其他进程或用户读取。证书链要配置完整，避免部分浏览器或客户端出现证书不受信任的警告。对于多域名或子域名业务，建议使用通配符证书或SAN证书统一管理，减少因证书过期或配置遗漏导致的安全事件。

TLS协议版本和加密套件的选择同样重要。应禁用SSLv2、SSLv3、TLSv1.0和TLSv1.1这些已被证明存在漏洞的旧版本，只保留TLSv1.2和TLSv1.3。加密套件要优先选择支持前向保密的ECDHE系列，避免使用RC4、3DES等弱算法。可以通过定期扫描工具检测站点的TLS配置评分，确保没有降级攻击和已知漏洞风险。

网站目录和文件的权限配置直接决定了攻击者入侵后能造成多大破坏。一个基本原则是：Web服务器进程对网站文件只应有读取权限，只有需要写入的目录如上传目录、缓存目录、日志目录才开放写权限。而且写入目录应禁止执行脚本，防止攻击者上传WebShell后直接运行。在Nginx和Apache中可以通过location规则对上传目录单独设置，禁止PHP、JSP等脚本解析。

文件上传功能是网站安全的重灾区。除了限制上传目录的执行权限外，还应在应用层做严格的文件类型校验，不能只依赖客户端JavaScript验证，也不能只检查Content-Type头，因为这些都可以被伪造。应结合文件扩展名白名单、文件头魔数检测和文件内容分析多重验证。上传后的文件应重命名为随机字符串，避免保留原始文件名，防止路径穿越和XSS攻击。

对于配置文件、数据库连接文件、日志文件等敏感文件，要确保它们不在Web可访问目录下。很多框架的配置文件如果放在站点根目录，攻击者通过猜测路径就可能直接下载源码或配置信息。应将配置文件放在Web根目录之外，通过应用层引用。同时要定期检查网站目录中是否存在.bak、.sql、.tar.gz等备份文件，这些文件往往是开发或运维人员临时放置后忘记删除的，包含大量敏感信息。

安全建设不能只靠事前配置，事中监控和事后审计同样属于基础配置的一部分。Web服务器、数据库、系统认证都需要开启日志记录，并且日志内容要足够详细，能够支撑安全事件回溯。Nginx和Apache应记录访问来源IP、请求时间、请求方法、URL、状态码、User-Agent和Referer，数据库应开启慢查询日志和错误日志，系统层面要记录所有用户登录和提权操作。

日志的保存和保护也很关键。攻击者入侵后往往会清理日志以掩盖痕迹，因此日志应实时同步到独立的日志服务器或集中式日志平台，避免只保存在被攻击的服务器本地。日志保留周期至少满足安全合规要求，通常建议保存六个月以上。对于关键操作日志，如后台登录、权限变更、数据导出等，应设置告警规则，发现异常行为及时通知管理员。

文件完整性监控是另一个容易被忽视的基础配置。通过对网站核心文件、系统关键目录建立哈希基线，可以及时发现被篡改的文件。无论是攻击者植入WebShell、修改系统命令还是替换动态链接库，文件哈希值都会发生变化。可以使用开源工具如Tripwire、AIDE或商业EDR产品实现这一功能，定期比对并生成报告。

很多网站直到被勒索软件加密或数据被删除后才意识到备份的重要性。备份策略属于安全建设的基础环节，必须提前规划。备份应遵循3-2-1原则，即至少保留三份数据副本，存储在两种不同介质上，其中一份存放在异地。备份内容不仅包括数据库，还要覆盖网站源码、配置文件、证书私钥和系统镜像。

备份的自动化执行和恢复验证同样重要。很多团队配置了定时备份任务，但从未测试过恢复流程，等到真正需要恢复时才发现备份文件损坏或恢复步骤不完整。应定期进行恢复演练，模拟数据丢失场景，验证备份的可用性和恢复时间目标。同时备份文件本身也要加密存储，防止备份泄露导致数据外泄。

应急响应预案是基础配置的最后一环。在安全事件发生前就明确谁负责什么、按照什么步骤处理、如何与业务方沟通，能大幅缩短响应时间。预案中应包含常见攻击类型的处理流程，如WebShell植入、数据库拖库、DDoS攻击、勒索软件等，并准备必要的取证工具和联系方式。预案不是写完就束之高阁，需要定期更新和演练。

网站安全建设从来不是一劳永逸的事情，但把基础配置做扎实，能消除绝大多数自动化攻击和机会型攻击的生存空间。与其在入侵发生后花费大量精力溯源和修复，不如在系统上线前就把账户、权限、端口、传输、日志这些基础项逐条落实。安全防护的强度不取决于你做了多少高级措施，而取决于最薄弱的那一环是否被堵住。