Apache服务器怎么安全加固？从版本隐藏、目录权限到访问控制实战

很多人装完Apache，配好虚拟主机、能打开网站，就觉得大功告成了。可保哥要泼盆冷水：一台默认配置直接上公网的Apache，几乎等于把大门敞开还插着钥匙。它会主动告诉别人自己的版本号、把没设首页的目录里所有文件列给陌生人看、对慢速攻击毫无招架、把.git和数据库备份大方地供人下载。这些都不是高深漏洞，纯粹是“没关的默认开关”。

这篇保哥不谈玄乎的零日漏洞，只把Apache上线前后真正该拧紧的那些螺丝逐个讲清楚：怎么藏起版本信息别主动报家底、目录权限和Options怎么收、怎么用访问控制锁住后台、给敏感目录加密码门、把.git/.env和备份文件彻底挡死、防慢速攻击和资源耗尽、禁用危险HTTP方法、要不要上WAF、HTTPS摆在什么位置，最后是那些一加就把站点配崩的真实翻车坑。这是Web服务器这一层的功夫，和登录层的加固是两码事。

为什么说Apache裸装上线等于敞着门？安全加固到底在防什么？

先把威胁说清楚，不然加固就是瞎拧螺丝。公网上的服务器，从你绑上域名那一刻起，就被全球的自动化扫描器持续探测——它们不挑目标，见IP就扫，找的是默认配置里那些已知的弱点。Apache的默认配置图的是“开箱能用”，不是“安全”，所以一堆方便调试、却不该暴露在生产环境的开关，默认是开着的。

加固防的主要是这么几类事。一是信息泄露：默认Apache会在响应头和错误页里报出自己的版本、操作系统、装了哪些模块，等于给攻击者递了一张“我有哪些已知漏洞”的清单。二是目录暴露：没设首页的目录，Apache默认会把里面的文件列表全显示出来，备份、配置、代码一览无余。三是敏感文件可下载：版本控制目录、环境变量文件、数据库备份，访客直接用URL就能拖走。四是资源耗尽型攻击：慢速连接、超大请求体能把服务器的连接数和内存吃干。

这里要先划清一条边界，免得和别的加固混为一谈：本文讲的是Apache这个Web服务器软件这一层的加固——配置怎么收紧、权限怎么管、访问怎么控。它和服务器登录层面的加固是两码事，那一层管的是SSH密钥、禁root、防暴力破解，保哥在Linux服务器登录安全加固里专门讲过。两层都要做，缺一不可：登录层挡的是“别人进你服务器”，Web层挡的是“别人通过你网站搞事”。

怎么让Apache别主动暴露自己的版本和家底？

第一个该拧的螺丝，是让Apache闭嘴，别主动报家底。默认情况下，Apache的HTTP响应头里有个Server字段，会写明类似“Apache/2.4.x (操作系统)”这样的信息；出错时的默认错误页脚也会署上版本号。这些信息对你毫无用处，却能帮攻击者快速锁定“这个版本有哪些公开漏洞可以试”。

控制它的是两条指令。ServerTokens决定响应头Server字段透露多少信息，设成Prod时只显示最简的“Apache”，不带版本和系统。ServerSignature控制错误页和目录列表页脚的署名，设成Off就不再显示版本签名。这两条应该写在主配置文件里，作用于全局。

ServerTokens Prod
ServerSignature Off

保哥提醒，这一步属于“降低被针对的概率”，不是真正堵住漏洞——藏了版本号，不等于漏洞就不存在了。它的价值在于让无差别扫描器少一个快速命中的线索，提高对方的成本。真正的安全底座，永远是及时打补丁、保持Apache和操作系统更新到位。藏版本和勤更新，要一起做，别只做前者图个心理安慰。

目录权限和Options该怎么收紧？

接下来是目录层面的收口，这块默认配置最容易出事。先说目录遍历。如果一个目录里没有索引文件（比如index.html），而该目录又开了Indexes选项，Apache会很“贴心”地把目录里的所有文件列成一个清单显示给访客。这意味着你的上传目录、备份目录、配置目录，可能整个家当被人一目了然。

关掉它很简单，在目录配置里用Options -Indexes去掉目录列表功能。同时建议收紧FollowSymLinks——如果不需要软链接跟随，关掉它能减少被符号链接绕过访问限制的风险，更稳妥的是用SymLinksIfOwnerMatch限定只跟随属主一致的软链接。

<Directory /var/www/html>
    Options -Indexes -FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

再说AllowOverride，这是个权衡。它决定目录里的.htaccess文件能覆盖哪些配置。设成None时.htaccess彻底失效，Apache也不再每次请求都去逐级翻找.htaccess文件，安全和性能都更好——官方在安全建议里就推荐用AllowOverride None从根上禁掉.htaccess覆盖。

这里多说一句性能账：开了.htaccess覆盖后，Apache处理每个请求都要从根目录一层层往下找有没有.htaccess并解析，这笔开销在高流量下不容忽视。但很多应用（包括不少CMS）依赖.htaccess做伪静态和重写，全关会破坏功能。保哥的折中是：能把规则写进主配置（vhost）里的就写进去并关掉.htaccess，确实依赖.htaccess的目录再单独按需放开，两头兼顾。

还有个根目录的防御性设置值得做。官方建议把文档根之外的整个文件系统默认设为拒绝访问（Require all denied），再对真正要对外的目录显式放开。这样哪怕配置疏漏，默认也是“拒绝”而非“放行”，符合最小权限原则。这种“默认关、按需开”的思路，是整个加固的底层逻辑。

怎么用访问控制锁住后台和敏感目录？

有些目录天生就不该对全世界开放——网站后台、管理脚本、内部工具、运维接口。把这些藏在“别人猜不到的路径”是自欺欺人，正经做法是用访问控制把它们锁死，只放行可信来源。

Apache 2.4用Require指令做访问控制，由mod_authz_host等模块支撑。最常用的是按IP或网段放行：只让公司固定IP、或者你自己的运维IP能访问后台目录，其他一律拒绝。语法很直观，支持单个IP、网段（CIDR写法）、甚至IPv6。

<Directory /var/www/html/admin>
    Require ip 203.0.113.0/24
    Require ip 198.51.100.10
</Directory>

需要组合更复杂的条件时，Apache 2.4提供了<RequireAll>、<RequireAny>、<RequireNone>三个容器，可以把多条规则用“全部满足/任一满足/全不满足”的逻辑拼起来。比如“必须来自公司网段，且不能是某个被拉黑的IP”，就能用RequireAll嵌套表达。这套逻辑比老版本（2.2时代）的Allow/Deny清晰得多，老语法已经废弃，新项目别再用。

保哥的经验是：后台路径用IP白名单锁，是性价比极高的一招。绝大多数针对后台的暴力破解和漏洞扫描，根本碰不到登录页就被Apache在门口挡掉了。如果你的运维IP不固定（比如用动态宽带），可以配合后面要讲的密码门，或者走VPN/跳板机固定出口IP再放行。

给敏感目录加一道密码门：Basic Auth怎么配才靠谱？

IP白名单解决“从哪来”，密码门解决“是不是你”。对那些不方便用固定IP锁、又必须保护的目录，Apache自带的HTTP基础认证（Basic Authentication）是最轻量的一道门：访问时弹窗要用户名密码，对不上就进不去。

配置分两步。先用htpasswd工具生成一个密码文件，把用户和加密后的密码存进去；这个密码文件务必放在文档根目录之外，别让它自己能被人通过URL下载。然后在目录配置里指定认证方式和密码文件。

# 生成密码文件（-c 仅首次创建时用，追加用户去掉 -c）
htpasswd -c /etc/apache2/.htpasswd admin

# 目录配置
<Directory /var/www/html/secure>
    AuthType Basic
    AuthName "Restricted Area"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
</Directory>

这里有几个要点。htpasswd的-c参数只在第一次创建文件时用，后续追加用户千万别再带-c，否则会覆盖整个文件、把之前的用户全清掉——这是个经典误操作。Require valid-user表示密码文件里任何有效用户都能进，也可以用Require user 用户名限定到具体某人。

Basic Auth有个天然短板必须知道：它的用户名密码是以近乎明文（仅做Base64编码，不是加密）的方式在请求里传输的。所以它必须配合HTTPS使用，否则在不加密的HTTP上，密码等于裸奔，中间人轻松截获。在已经全站HTTPS的前提下，Basic Auth给后台、预发环境、内部工具加道门是足够实用的。最佳实践是IP白名单和密码门叠加用，双重门槛。

那些不该被下载的文件（.git/.env/备份）怎么彻底挡死？

这是保哥见过最多、后果最严重、却最容易被忽略的一类问题：敏感文件直接能通过URL下载。最典型的三类——版本控制目录.git（暴露整套源码甚至提交历史里的密钥）、环境变量文件.env（数据库密码、API密钥全在里面）、还有手滑留在网站目录里的数据库备份和压缩包（backup.sql、www.zip之类）。

这些文件一旦能被下载，等于把后门、钥匙、家底一起送人。保哥真见过有外贸独立站，因为部署时把.git目录留在了网站根，被人直接git clone下整个仓库，连历史提交里写死的支付密钥都被翻了出来，损失惨重。挡它的方式是用<Files>或<FilesMatch>按文件名模式拒绝访问。

<FilesMatch "(^\.|\.(env|sql|bak|log|ini|sh|zip|tar|gz)$)">
    Require all denied
</FilesMatch>

<DirectoryMatch "/\.git">
    Require all denied
</DirectoryMatch>

上面的规则挡住了以点开头的隐藏文件、以及一批常见的危险扩展名。但保哥更想强调一条原则，比任何规则都重要：网站目录里就不该存放这些文件。备份别放在Web可访问的目录、部署别把.git带上服务器、敏感配置放到文档根之外。Apache的拦截规则是最后一道保险，而不是让你可以放心把备份扔在网站根目录的理由。源头不放，比事后拦截可靠得多。

怎么防慢速攻击和资源耗尽？

不是所有攻击都来抢数据，有一类专门来“拖死”你的服务器。最典型的是慢速攻击（Slowloris一类）：攻击者跟服务器建立连接后，故意把请求发得极慢、一点一点挤牙膏，让连接长时间不释放。Apache的并发连接数有限，这类连接堆积到一定程度，正常用户就连不进来了，表现为网站“打不开”但服务器又没明显报错。

防御的核心是给请求设置合理的时间和大小上限，让磨蹭的连接被及时掐断。mod_reqtimeout模块（默认通常已启用）能设定接收请求头和请求体的超时；Timeout指令控制各阶段的总超时；LimitRequestBody限制请求体大小，防止超大上传耗尽内存；调小KeepAliveTimeout能让空闲的保持连接更快释放。

Timeout 60
KeepAlive On
KeepAliveTimeout 5

<IfModule mod_reqtimeout.c>
    RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>

官方的安全建议里专门有一节讲拒绝服务（DoS），核心思路就是通过超时和请求限制相关的指令，加上MPM层面对连接数的合理配置，来缓解这类攻击。要注意这些值要结合业务调——比如允许大文件上传的站，LimitRequestBody不能设太小。连接数和并发承载怎么配，和性能调优是一体两面，保哥在Apache高并发调优那篇里讲了MPM选型和MaxRequestWorkers怎么按内存算，安全和性能的连接配置要放一起统筹。

禁用危险的HTTP方法和模块有必要吗？

有必要，而且成本很低。先说HTTP方法。Web服务器支持多种请求方法，日常网站用到的主要是GET、POST、HEAD。而像TRACE这类调试用的方法，正常业务几乎用不到，却可能被用于跨站追踪一类的攻击。Apache可以用TraceEnable Off直接关掉TRACE；如果想更严格地只放行必要的方法，可以在目录里用<LimitExcept>把其他方法挡掉。

TraceEnable Off

<Directory /var/www/html>
    <LimitExcept GET POST HEAD>
        Require all denied
    </LimitExcept>
</Directory>

再说模块。Apache装好后默认加载了一批模块，其中不少你的站点根本用不到。官方安全建议里明确提到，删掉用不上的模块能缩小攻击面——多一个加载的模块，就多一份潜在的漏洞暴露和资源占用。常见可以考虑关掉的有mod_status（暴露服务器状态，若要用必须配IP访问控制）、mod_info（暴露配置详情）、mod_userdir（能探测系统用户是否存在）等。

保哥的做法是：上线前把当前加载的模块列一遍，逐个问“这个站用得到吗”，用不到的就注释掉对应的LoadModule行。关模块要谨慎，关之前确认没有功能依赖它，关完充分测试。这事不用追求极致，把明显用不到又有暴露风险的几个关掉，性价比就很高了。

要不要上WAF（mod_security）？普通站点值得折腾吗？

WAF（Web应用防火墙）是更上层的防御，它检查进来的请求内容，按规则拦截SQL注入、跨站脚本、恶意扫描等攻击特征。Apache生态里最常见的是mod_security，配合OWASP核心规则集（CRS）使用，能挡掉相当一部分自动化攻击和常见漏洞利用。官方安全文档里也把ModSecurity这类应用防火墙作为加固动态内容的一种手段提及。

那普通站点值不值得上？保哥的看法分情况。如果你跑的是WordPress、Magento这类暴露面大、又是攻击重灾区的应用，或者有合规要求，上mod_security+CRS是值得的，它能在应用补丁还没打上时挡一阵子。但WAF不是装上就完事的“银弹”：规则集默认配置容易误杀正常请求（比如后台的富文本提交被当成攻击拦掉），需要花精力调白名单、调规则等级，运维成本不低。

所以保哥的建议是：小站、内容简单、维护精力有限的，先把前面那些“关默认开关”的基础加固做扎实，WAF可以缓一缓，或者直接用云厂商/CDN层提供的托管WAF（省去自己调规则的麻烦）。中大型站、高价值目标、或合规需要的，再认真上mod_security并投入精力调优。别本末倒置——基础加固没做，先上个天天误杀的WAF，那是给自己添堵。

HTTPS和传输层安全在加固里该摆在什么位置？

HTTPS是现代网站的地基，不是可选项。它解决的是传输层的机密性和完整性——数据在用户和服务器之间加密传输，防窃听、防篡改、防中间人。前面讲的Basic Auth之所以必须配HTTPS，就是这个道理。所以严格说，HTTPS是整个安全体系的前提，而不只是加固清单里的一条。

在Apache上，HTTPS靠mod_ssl承载，证书现在用Let's Encrypt一类的免费证书加自动续期工具就能搞定，成本几乎为零。配好证书后，安全层面还有几件事要做：把所有HTTP请求强制跳转到HTTPS、关掉老旧不安全的TLS协议版本（只保留TLS 1.2及以上）、选用强加密套件。这些做好，站点的TLS评级才能拿到高分。

HTTPS和HSTS的具体配置、协议版本与套件怎么选、强制跳转和HSTS preload怎么提交，保哥在HTTPS站点开启HSTS实战里讲得很细，跨Apache/Nginx/IIS都覆盖了，这里就不重复展开。本文要强调的是认知：传输层安全（HTTPS）和本文讲的Web服务器配置加固，是互补的两层。HTTPS保证“路上不被偷看”，配置加固保证“服务器本身不留破绽”，两者都到位，Apache才算真正立得住。

Apache安全加固有哪些一加就翻车的坑？

最后照例把高频翻车点拎出来，让你少走弯路。这些都是保哥或同行真实踩过的。

第一，改完配置不测试语法直接重启。Apache配置一个括号没闭合、一条指令拼错，重启就直接起不来，整站挂掉。铁律是每次改完先用apachectl configtest（或apache2ctl -t）检查语法，显示Syntax OK再重启或reload。这一步十秒钟，能避免无数次“一改就全站500”的事故。

第二，IP白名单把自己也锁外面。给后台配IP限制时，最常见的乌龙是没把自己当前的出口IP加进去，配完一保存，自己也进不去后台了。改访问控制前先确认清楚自己的公网出口IP，最好留一条SSH通道能直接改回配置，别把退路堵死。

第三，htpasswd带-c覆盖了已有用户。前面提过，追加用户时误带-c会清空整个密码文件。记牢：-c只在第一次创建时用一次。

第四，AllowOverride一刀切全关，把依赖.htaccess的应用搞瘫。很多CMS的伪静态、重定向都写在.htaccess里，全局AllowOverride None会让这些规则失效，表现为页面404或重写失灵。要么把规则迁进vhost配置，要么对相应目录按需放开，别盲目全关。

第五，文件拦截规则误伤正常资源。用FilesMatch按扩展名拦截时，正则写宽了可能把正常文件也挡了（比如把.log挡了，结果某个前端组件正好要读一个.log结尾的资源）。规则上线后要实际访问站点各功能验证一遍，别想当然。

第六，关模块关过头。把站点实际依赖的模块也注释掉，导致功能失灵又一时想不到是模块被关了。关模块前确认依赖、关后充分测试，是基本纪律。安全加固的总原则始终是：每改一处都要验证站点功能正常，安全和可用要平衡，别为了加固把站点搞挂。

常见问题解答

藏掉Apache版本号真能提升安全性吗，还是只是心理安慰？

它有用，但作用有限，必须看清它的定位。藏版本号（ServerTokens Prod、ServerSignature Off）的价值在于让无差别扫描器少一个快速命中的线索——很多自动化攻击是先识别版本、再匹配该版本的已知漏洞去打，看不到版本号会增加对方的探测成本。但它绝不等于堵住了漏洞，漏洞该在的还在，有经验的攻击者也有别的方式指纹识别。所以正确理解是：藏版本是“降低被无差别针对的概率”的低成本动作，值得做，但它只是辅助。真正的安全底座永远是及时给Apache和操作系统打补丁、保持更新。把藏版本当成主要防御、却疏于更新，才是真正的心理安慰。两件事一起做才对。

我用的是nginx不是Apache，这些加固还适用吗？

思路完全通用，具体指令不同。本文讲的几类加固——隐藏版本信息、关闭目录列表、访问控制锁后台、保护敏感文件、防慢速攻击和资源耗尽、禁用危险方法、强制HTTPS——是任何Web服务器都该做的通用功课，背后的安全原则（最小权限、默认拒绝、缩小攻击面、源头不暴露）一模一样。区别只在配置语法：nginx里隐藏版本用server_tokens off，目录列表用autoindex off，访问控制用allow/deny或geo模块，敏感文件用location块加deny all。所以如果你用nginx，把本文的原则照搬，再去查nginx对应的指令即可。理解“要防什么、为什么防”，比记某一个服务器的具体写法更重要，换了服务器照样会做。

给网站后台配了IP白名单，但我的宽带是动态IP经常变，怎么办？

有几条务实的路子。一是走固定出口：用一台固定公网IP的跳板机或VPN，运维时先连上跳板/VPN，让访问后台的请求都从那个固定IP出去，白名单只放行这个IP，既安全又不受家里宽带IP变动影响。二是用密码门替代或叠加：动态IP实在没法用白名单时，给后台配Basic Auth密码门（务必在HTTPS下），靠用户名密码而非IP来控；更稳的是IP不固定时至少保证密码门和应用本身的登录双重防护。三是临时放行：偶尔需要时手动把当前IP加进配置、用完移除，适合低频场景。保哥最推荐第一种——一个固定出口IP是运维很多安全策略的基础设施，值得投入，配好之后白名单、防火墙规则都能围绕它来做。

改了Apache安全配置后网站打不开了，怎么快速定位？

按顺序排查。第一步先看Apache是不是根本没起来：改完安全配置如果带了语法错误，服务会启动失败，用systemctl status或服务管理命令看进程状态，再用apachectl configtest看具体哪行语法错——这是最常见的原因。第二步如果服务起来了但页面报错（403/500），看Apache的错误日志（通常在/var/log里），日志会明确告诉你是哪条规则拒绝了访问或哪个配置有问题，比如AllowOverride改动导致.htaccess失效、FilesMatch误伤了正常文件、访问控制把请求挡了。第三步针对性回退：定位到是哪一处改动引发的，先把那一处改回去恢复服务，再单独研究怎么正确配。关键心法是一次只改一类配置、改完立刻configtest加测试，这样出问题能马上锁定是哪一步，而不是一口气改十处然后对着崩掉的站点抓瞎。

WAF（mod_security）和前面那些基础加固，应该先做哪个？

毫无疑问先做基础加固。隐藏版本、关目录列表、访问控制、保护敏感文件、防慢速攻击、强制HTTPS这些，成本低、副作用小、收益直接，是地基；它们把绝大多数无差别扫描和低级攻击挡在门外。WAF是更上层的精细防御，门槛和运维成本都更高——默认规则容易误杀正常请求，需要持续调白名单和规则等级，是“需要养”的东西。地基没打就先上WAF，往往是天天处理误拦、却还漏着目录列表和可下载的备份文件，本末倒置。正确顺序是：先把基础加固做扎实，再根据站点的价值和风险决定要不要上WAF；真要上，中大型站或高价值目标用mod_security加OWASP规则集并投入调优，小站可以直接用CDN或云厂商的托管WAF省去自己调规则的负担。

权威参考资料