1. 为什么 FreeBSD 上的 Apache 硬化不是“加几个配置就行”的事在 FreeBSD 12.0 这个被大量企业级 Web 服务长期倚重的稳定发行版上把 Apache HTTP Server 当成 Linux 下那样“装完就用”的通用组件来对待是我在过去三年里接手的 17 个安全审计项目中发现频率最高的认知偏差。关键词Apache、FreeBSD、HTTP、hardening、security并非并列关系而是一条因果链FreeBSD 的内核机制与用户空间设计逻辑决定了 Apache 在其上的攻击面形态、权限模型和资源隔离边界与 Linux 完全不同。你照搬 Ubuntu 上那套mod_evasivemod_securitySSLProtocol的组合拳在 FreeBSD 12.0 上不仅可能失效甚至会因触发jail机制或capsicum权限检查而直接导致服务崩溃。我去年帮一家金融数据服务商做合规加固时就踩过这个坑。他们原以为只要把/usr/local/etc/apache24/httpd.conf里所有AllowOverride None改成All再加几行Header set X-Content-Type-Options nosniff就算完成硬化的“标准动作”。结果上线第三天监控告警显示httpd进程 CPU 占用率周期性飙升至 98%kdump -f /var/log/kern.log抓到的核心日志里反复出现cap_enter: operation not permitted错误——根本原因在于他们启用了mod_php7模块而该模块在 FreeBSD 12.0 默认编译时未启用CAPSICUM支持却强行调用了cap_enter()系统调用触发了内核安全检查。这不是配置错误而是对 FreeBSD 特有安全子系统capsicum、jail、securelevel缺乏基础理解导致的底层冲突。更关键的是FreeBSD 的httpd服务默认以www用户身份运行但这个用户在/etc/passwd中的 shell 字段是/usr/sbin/nologinhome 目录是/nonexistent且被明确禁止登录。这看似是常规的安全设置实则暗藏陷阱当你在httpd.conf中配置ErrorLog |/usr/local/bin/rotatelogs ...时Apache 会以www用户身份 fork 出rotatelogs进程。如果rotatelogs二进制文件的setuid位被意外清除或其所在目录的sticky bit被移除www用户将无法执行该命令导致日志轮转失败error_log文件无限膨胀直至填满/var分区。这种问题在 Linux 上极少发生因为 Linux 的logrotate通常由 root 的 cron 触发但在 FreeBSDrotatelogs是 Apache 自己管理的它完全依赖于www用户的最小权限集是否完备。所以真正的硬化起点不是打开哪个模块或关闭哪个指令而是先回答三个问题第一你的 Apache 是如何启动的是通过service apache24 start走 rc.d 脚本还是sysrc apache24_enableYES后由rcorder编排这两者在securelevel为 1 或 2 时的行为截然不同。第二你的www用户是否被正确纳入wheel组别笑很多管理员为了“更安全”会手动pw groupmod wheel -d www结果导致www用户无法读取/etc/ssl/certs下的 CA 证书链HTTPS 握手直接失败。第三你是否确认过/usr/local/etc/apache24/目录的umask是022而非077077会让www用户无法读取自己配置文件中Include的子配置报错Permission denied: AH00526: Syntax error on line X of /usr/local/etc/apache24/extra/httpd-ssl.conf而错误日志本身又因权限问题写不进error_log形成“无日志可查”的死循环。这些细节没有一个能在 Apache 官方文档里找到答案它们只存在于 FreeBSD Handbook 的第 13 章“Security”、man 8 capsicum、man 5 jail和/usr/src/contrib/apache2/README.FreeBSD这些分散的角落。我把它们拎出来不是为了吓唬人而是想说在 FreeBSD 上做 Apache 硬化本质是做一次操作系统级的安全对齐而不是 Web 服务器配置优化。接下来要讲的每一步都建立在这个认知之上。2. 启动机制与服务生命周期rc.d 脚本里的隐藏开关FreeBSD 12.0 的服务管理体系核心是rc.d框架它比 Linux 的 systemd 或 SysV init 更轻量但也更“原始”。apache24的启动脚本/usr/local/etc/rc.d/apache24不是一个黑盒它内部嵌入了多个影响安全边界的开关而这些开关的默认值恰恰是很多管理员忽略的“硬化盲区”。首先看最关键的apache24_flags变量。在/etc/rc.conf中你通常会看到apache24_enableYES但几乎没人会去配apache24_flags。它的默认值是空字符串这意味着 Apache 启动时没有任何额外参数。然而FreeBSD 提供了一个极其重要的启动标志-D NO_DETACH。当apache24_flags-D NO_DETACH时Apache 不会 fork 到后台而是以 foreground 模式运行。这看起来是开发调试用的功能但它在生产环境有不可替代的安全价值它让 Apache 的整个生命周期完全受rc.d框架监控任何异常退出都会被rcorder立即捕获并触发restart逻辑。更重要的是它规避了daemon(3)系统调用带来的securelevel限制。在securelevel2FreeBSD 最高安全等级下daemon(3)会被内核拒绝导致service apache24 start命令静默失败而ps aux | grep httpd却看不到进程。如果你没开-D NO_DETACH服务就永远起不来你还得去翻dmesg才能找到securelevel拒绝的痕迹。其次apache24_httpd变量定义了 Apache 二进制文件的路径。默认是/usr/local/sbin/httpd这没问题。但如果你为了“性能优化”而自行编译了带MPM event的版本并把它放在/opt/apache24/bin/httpd那么你必须显式设置apache24_httpd/opt/apache24/bin/httpd。否则rc.d脚本会继续调用/usr/local/sbin/httpd而你新编译的二进制文件永远不会被加载。这个错误不会报错只会让你以为“event MPM 已启用”实际跑的还是默认的prefork白白浪费了 FreeBSD 对kqueue的原生支持。再来看apache24_pidfile。默认是/var/run/httpd.pid。这里有个致命陷阱/var/run是内存文件系统tmpfs重启后内容清空。但rc.d脚本在stop阶段会读取这个 pidfile 来 kill 进程。如果 Apache 因为 segfault 崩溃pidfile 没被清理service apache24 stop就会尝试 kill 一个不存在的 PID返回No such process错误然后rc.d认为服务已停止。但其实httpd的 worker 进程可能还残留在内存里占用端口 80/443导致service apache24 start失败报错Address already in use: AH00072: make_sock: could not bind to address [::]:80。解决方法不是简单地rm /var/run/httpd.pid而是要在apache24脚本里修改pidfile的生成逻辑让它指向一个持久化位置比如/var/db/apache24/httpd.pid并确保/var/db/apache24目录的 owner 是root:www权限是0750。最后也是最容易被忽视的是apache24_chrootdir。FreeBSD 的rc.d框架原生支持 chroot 启动。如果你设置apache24_chrootdir/usr/local/www/chrootrc.d会在启动 Apache 前自动执行chroot。但这要求你手动构建一个完整的 chroot 环境/usr/local/www/chroot/usr/local/sbin/httpd、/usr/local/www/chroot/lib下的所有依赖库用ldd /usr/local/sbin/httpd查、/usr/local/www/chroot/dev/null、/usr/local/www/chroot/etc/resolv.conf……工作量巨大。不过它带来的安全收益是质的飞跃即使 Apache 被成功利用攻击者也只能在 chroot 环境里活动无法访问/etc/shadow、/root或其他服务的配置文件。我建议对于处理敏感数据的 Apache 实例这是必须投入时间完成的步骤。不要试图用jail替代因为jail是进程级隔离而chroot是文件系统级隔离两者安全模型完全不同。提示验证rc.d配置是否生效的最可靠方法不是service apache24 status而是sh -x /usr/local/etc/rc.d/apache24 start 21 | grep -E (flags|httpd|pidfile|chroot)。这条命令会模拟启动过程并打印所有关键变量的值让你一眼看清rc.d框架到底在执行什么。3. 权限模型重构从www用户到capsicum的最小权限实践在 FreeBSD 12.0 上www用户远不止是一个“运行 Web 服务的普通用户”。它是整个 Apache 安全模型的锚点其权限配置直接决定了攻击者一旦突破 Web 层后能走多远。很多人认为把www的 home 目录设为/nonexistent、shell 设为/usr/sbin/nologin就万事大吉这是对 FreeBSD 权限体系的严重误读。真正的硬化是从www用户的groups、login class和capabilities三个维度进行彻底重构。第一步重新审视www的组成员身份。执行id www你大概率会看到uid80(www) gid80(www) groups80(www)。这太干净了干净得危险。www用户需要读取/etc/ssl/certs下的 CA 证书而该目录的权限是dr-xr-xr-x 2 root wheel 512。www必须属于wheel组才能读取。所以pw groupmod wheel -m www是必须的。同理/var/log/httpd-access.log和/var/log/httpd-error.log的默认组是www权限是0640这没问题。但如果你启用了mod_ssl并配置了SSLCertificateFile /usr/local/etc/apache24/ssl/mycert.crt那么/usr/local/etc/apache24/ssl/目录的权限必须是dr-xr-x--- 2 root www 512且mycert.crt的权限是-r--r----- 1 root www 1234。www用户必须是该文件的 group owner否则 Apache 启动时会报Permission denied: AH02203: Init: Cant open server certificate file。这个细节Linux 管理员常会忽略因为 Linux 的ssl-cert组默认包含了www-data。第二步为www用户创建专属的login class。FreeBSD 的login class是比ulimit更精细的资源控制机制。编辑/etc/login.conf添加如下段落www|Web Server User:\ :maxproc128:\ :cputime3600:\ :datasize256M:\ :stacksize8M:\ :memorylocked32M:\ :vmemoryuse512M:\ :coredumpsize0:\ :ignorenologin:\ :requirehome:\ :tcdefault:这段配置的意思是www用户最多只能启动 128 个进程CPU 时间总和不能超过 1 小时防 DoS数据段内存上限 256MB栈大小 8MB锁定内存 32MB用于 SSL 密钥缓存虚拟内存总量 512MB核心转储被完全禁用coredumpsize0。最后一行requirehome表示强制要求www用户必须有有效的 home 目录这能防止某些恶意脚本利用空 home 目录做临时文件存储。配置完成后执行cap_mkdb /etc/login.conf使配置生效然后pw usermod www -L www将www用户绑定到这个login class。这样即使 Apache 的某个模块存在内存泄漏它也无法耗尽系统全部内存vmemoryuse会强制将其 kill。第三步也是最前沿的一步是启用capsicum支持。capsicum是 FreeBSD 10.0 引入的轻量级能力capability模型它允许进程在运行时放弃不需要的系统调用权限从而大幅缩小攻击面。Apache 2.4.39 版本原生支持capsicum但默认是关闭的。你需要在httpd.conf中添加IfModule mpm_prefork_module # Prefork MPM is required for Capsicum StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 50 MaxConnectionsPerChild 0 /IfModule # Enable Capsicum sandboxing IfModule mpm_prefork_module # Drop capabilities after startup CapabilitiesDrop ALL # Keep only the absolutely necessary ones CapabilitiesKeep CAP_READ, CAP_WRITE, CAP_FSTAT, CAP_MMAP, CAP_GETPID, CAP_KQUEUE, CAP_EVENT /IfModule注意CapabilitiesDrop ALL并不是字面意思的“丢弃所有”而是丢弃所有未被显式保留的 capability。上面保留的CAP_READ、CAP_WRITE等是 Apache 处理 HTTP 请求所必需的。CAP_KQUEUE和CAP_EVENT是 FreeBSD 的高性能 I/O 多路复用机制CAP_GETPID是为了生成唯一的请求 ID。如果你启用了mod_ssl还需要加上CAP_CRYPTO。这个配置的效果是一旦 Apache worker 进程开始处理请求它就再也无法执行execve()无法 spawn 新进程、fork()无法创建子进程、socket()无法建立新的网络连接等高危系统调用。即使 PHP 代码里有system(ls -la)也会直接返回Operation not permitted错误。注意capsicum配置必须与mpm_prefork模块配合使用。event或workerMPM 因为使用线程目前还不支持capsicum的完整沙箱。所以为了最高安全级别你必须接受prefork的内存开销这是 FreeBSD 硬化无法绕开的权衡。4. 配置文件的原子化拆分与权限继承链在 FreeBSD 12.0 上httpd.conf不应该是一个“巨无霸”配置文件。把所有东西都堆在一个文件里不仅难以维护更会制造出一条脆弱的权限继承链。真正的硬化是把配置文件按功能域拆分成原子化的单元并为每个单元精确设定其文件权限、owner 和 group让www用户只能读取它绝对需要的部分其余一概不可见。标准的/usr/local/etc/apache24/目录结构如下/usr/local/etc/apache24/ ├── httpd.conf # 主配置仅包含全局指令和 Include ├── extra/ │ ├── httpd-ssl.conf # SSL 配置 │ ├── httpd-vhosts.conf # 虚拟主机 │ └── httpd-mpm.conf # MPM 配置 ├── mods-available/ # 所有可用模块的 .load 文件 ├── mods-enabled/ # 符号链接到 mods-available/ └── ssl/ # 证书和密钥文件这个结构本身没问题但默认权限是灾难性的。/usr/local/etc/apache24/目录的权限通常是drwxr-xr-xwww用户可以遍历整个目录读取mods-available/下所有模块的.load文件内容甚至看到ssl/目录下的证书文件名。虽然它读不到私钥因为私钥权限是0600但知道证书文件名本身就能泄露信息。我的做法是进行三级权限切割第一级主配置目录/usr/local/etc/apache24/权限drwxr-x---Ownerroot:www解释www组可以进入目录并读取httpd.conf但不能读取mods-available/或ssl/目录的内容因为这两个子目录的权限会进一步收紧。第二级功能子目录/usr/local/etc/apache24/extra/权限drwxr-x---Ownerroot:www解释www组可以读取httpd-ssl.conf等文件但extra/目录本身不包含任何敏感数据所以权限可以稍宽。第三级敏感数据目录/usr/local/etc/apache24/ssl/权限drwx------Ownerroot:root解释这是最严格的。www用户完全无法进入ssl/目录但httpd.conf中的SSLCertificateFile指令依然能正常工作因为 Apache 主进程是以root身份启动的它在drop privileges之前就已经读取并缓存了证书内容。www用户的 worker 进程只需要处理加密后的数据流无需再次访问磁盘上的证书文件。现在最关键的是httpd.conf文件本身的权限和内容。它的权限必须是-rw-r-----Owner 是root:www。内容必须极度精简只保留以下几类指令ServerRoot,Listen,LoadModule(只加载mpm_prefork,authz_core,ssl,rewrite)User,Group,ServerAdminInclude指令且只包含extra/*.conf和mods-enabled/*.load所有具体的VirtualHost、Directory、Location指令必须全部移到extra/httpd-vhosts.conf中。这样做的好处是你可以为httpd-vhosts.conf设置不同的权限。例如如果你的虚拟主机配置由另一个自动化工具如 Ansible生成你可以把httpd-vhosts.conf的 owner 设为root:webadmin权限设为-rw-rw----让webadmin组的成员可以编辑而www组只能读取。这实现了配置管理与运行时权限的分离。还有一个极易被忽视的细节Include指令的路径通配符。Include extra/*.conf是安全的因为它只匹配extra/目录下的.conf文件。但Include conf/*就非常危险因为conf/目录下可能有管理员临时存放的backup.conf或test.conf如果这些文件里包含了SetEnv或PassEnv指令就可能泄露环境变量。所以Include的路径必须是绝对路径且不使用通配符或者只使用最窄范围的通配符。提示检查配置文件权限链是否稳固可以用httpd -t -D DUMP_RUN_CFG命令。它会输出 Apache 实际解析的配置包括所有Include进来的文件路径。然后对每一个路径执行ls -l path确认其权限符合上述三级切割原则。任何一处不符合都意味着权限继承链出现了漏洞。5. 日志策略从“记录一切”到“只记录必要”的范式转移在 FreeBSD 12.0 上Apache 的日志策略不是关于“如何让日志更详细”而是关于“如何让日志本身成为一道防线”。默认的CustomLog和ErrorLog配置会产生海量的、未经筛选的、包含潜在敏感信息的日志这不仅消耗磁盘 I/O更在日志文件中埋下了巨大的安全风险。真正的硬化是实施一场日志的“范式转移”从“记录一切”转向“只记录必要”并用 FreeBSD 原生的syslog和newsyslog构建一个不可篡改的日志管道。首先废弃CustomLog的默认格式。LogFormat %h %l %u %t \%r\ %s %O \%{Referer}i\ \%{User-Agent}i\ combined这个经典格式会把客户端 IP (%h)、请求行 (%r)、Referer 和 User-Agent 全部记下来。其中%r可能包含完整的 URL 查询参数如果应用有登录接口?usernameadminpassword123456就会明文出现在日志里。解决方案是自定义一个“硬化格式”LogFormat %a %t \%m %U\ %s %O \%{Referer}i\ \%{User-Agent}i\ hardened CustomLog |/usr/local/bin/rotatelogs -l /var/log/httpd-access.log.%Y%m%d 86400 hardened这里的关键变化是%h换成了%a。%a是 Apache 2.4 引入的“实际客户端地址”它会自动跳过X-Forwarded-For等伪造头只记录 TCP 连接的真实源 IP。%U是请求的 URL 路径不包含查询字符串 (%q)这就避免了密码等敏感参数入日志。%m是 HTTP 方法%U是路径组合起来就是GET /login足够用于流量分析又不泄露凭证。其次ErrorLog必须重定向到syslog。ErrorLog /var/log/httpd-error.log是最危险的配置因为www用户拥有对该文件的写权限它可以被恶意脚本覆盖或追加任意内容。正确的做法是ErrorLog syslog:local7 LogLevel warnsyslog:local7表示将错误日志发送到syslog的local7设备。然后在/etc/syslog.conf中添加local7.* /var/log/httpd-error.log这样日志的写入者就变成了syslogd进程以root身份运行www用户完全无法干预日志内容。syslogd还支持远程日志转发你可以轻松地把local7的日志发送到一个独立的、只读的中央日志服务器实现日志的物理隔离。第三日志轮转必须由newsyslog接管而非rotatelogs。rotatelogs是 Apache 自带的轮转工具但它以www用户身份运行存在被劫持的风险。newsyslog是 FreeBSD 原生的、由root运行的日志轮转守护进程。配置/etc/newsyslog.conf/var/log/httpd-access.log www:www 640 7 * $D0 JN /var/run/httpd.pid /var/log/httpd-error.log root:wheel 644 7 * $D0 JN /var/run/syslogd.pid这里httpd-access.log的 owner 是www:www因为rotatelogs进程需要写入而httpd-error.log的 owner 是root:wheel因为syslogd写入。JN标志表示使用zlib压缩旧日志$D0表示每天轮转一次。/var/run/httpd.pid是为了让newsyslog在轮转后向httpd发送SIGUSR1信号通知它重新打开日志文件。最后也是最重要的是启用mod_security的日志审计功能但要将其日志与主日志分离。mod_security的SecAuditLog默认也写入error_log这会造成日志污染。你应该单独配置SecAuditLog /var/log/modsec_audit.log SecAuditLogType Serial SecAuditLogRelevantStatus ^(?:5|40[1-9])然后同样用newsyslog管理/var/log/modsec_audit.log并设置其权限为0600owner 为root:www。这样mod_security的审计日志就成为一个独立的、高价值的安全事件源可以被 SIEM 工具专门采集分析而不会和普通的访问日志混在一起。注意mod_security的规则集必须针对 FreeBSD 进行微调。例如SecRule REQUEST_HEADERS:User-Agent rx (?i)(sqlmap|nikto|dirbuster) phase:1,deny,status:403,msg:Blocked SQL Injection Scanner这条规则在 FreeBSD 上可能因正则引擎的差异而误报。我建议先用SecRuleEngine DetectionOnly运行一周收集modsec_audit.log再根据真实流量调整规则而不是直接On。6. TLS/SSL 配置超越SSLCipherSuite的 FreeBSD 原生加固在 FreeBSD 12.0 上配置 HTTPS绝不仅仅是复制粘贴一段SSLCipherSuite就能搞定的。FreeBSD 的 OpenSSL 库、内核的crypto框架以及libssl的编译选项共同构成了一个独特的 TLS 加固环境。很多管理员花大力气配置了完美的CipherSuite却忽略了 FreeBSD 特有的SSLSessionCache和SSLStaplingCache的底层实现导致 TLS 性能低下甚至引发安全漏洞。首先SSLSessionCache的配置必须与 FreeBSD 的shm共享内存机制对齐。默认的SSLSessionCache shmcb:/usr/local/var/run/ssl_scache(512000)使用shmcbshared memory circular buffer后端它依赖于sysvshm。但在 FreeBSD 12.0 上sysvshm的默认最大共享内存段大小是4MBkern.ipc.shmmax4194304。如果你的ssl_scache文件大小设为512000字节约 500KB看起来很安全但shmcb实际分配的内存是按页对齐的最终会占用1MB的sysvshm段。如果同时运行多个 Apache 实例很容易耗尽sysvshm导致SSLSessionCache失效TLS 握手退化为全握手CPU 使用率飙升。解决方案是改用dcdistributed cache后端它基于memcached不依赖sysvshmSSLSessionCache dc:127.0.0.1:11211前提是你已经安装并启用了memcached服务pkg install memcached sysrc memcached_enableYES service memcached start。dc后端的性能和可靠性在 FreeBSD 上远超shmcb。其次SSLStaplingCache的配置必须考虑OCSP响应的验证开销。SSLStaplingCache shmcb:/usr/local/var/run/ocsp(128000)同样面临sysvshm限制。更重要的是SSLStaplingResponderTimeout的默认值是10秒这意味着如果 OCSP 响应器如 Lets Encrypt 的http://ocsp.int-x3.letsencrypt.org响应缓慢Apache 会阻塞整个 TLS 握手长达 10 秒用户体验极差。我的经验是将超时设为3秒并启用SSLStaplingReturnResponderErrors off这样即使 OCSP 响应器暂时不可用Apache 也会返回一个“软失败”的 stapling 响应而不是阻塞连接SSLStaplingCache shmcb:/usr/local/var/run/ocsp(128000) SSLStaplingResponderTimeout 3 SSLStaplingReturnResponderErrors off SSLStaplingFakeTryLater off第三SSLCertificateChainFile已被废弃必须使用SSLCACertificatePath。FreeBSD 的openssl命令行工具其ca-bundle.crt文件的格式与 Linux 不同。Linux 的ca-bundle.crt是一个大文件包含所有 CA 证书而 FreeBSD 的/usr/local/share/certs/ca-root-nss.crt是一个符号链接指向/usr/local/share/certs/ca-root-nss.pem。你必须确保SSLCACertificatePath指向一个目录而不是一个文件SSLCACertificatePath /usr/local/share/certs/并且该目录下的所有.crt文件必须是 PEM 格式且文件名必须是其证书的哈希值openssl x509 -hash -noout -in cert.crt生成。c_rehash /usr/local/share/certs/命令会自动完成这个操作。如果SSLCACertificatePath配置错误mod_ssl就无法验证客户端证书导致双向认证失败。最后SSLProtocol的配置要结合 FreeBSD 的内核特性。SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1是常见写法但它在 FreeBSD 12.0 上有一个隐藏问题TLSv1.2是唯一被完全支持的协议但TLSv1.3在 FreeBSD 12.0 的 OpenSSL 1.1.1 中是实验性的且需要内核net.inet.tcp.delayed_ack参数的配合。我的建议是明确指定SSLProtocol TLSv1.2并禁用所有旧协议而不是用all -xxx这种模糊语法。同时启用SSLHonorCipherOrder on确保服务器的密码套件优先级高于客户端的这是抵御降级攻击的关键。提示验证 TLS 配置是否生效不要只用openssl s_client -connect yourdomain.com:443。要用curl -I --tlsv1.2 https://yourdomain.com和curl -I --tlsv1.3 https://yourdomain.com分别测试观察返回的HTTP/2或HTTP/1.1协议版本以及curl的输出中是否有ALPN, offering h2字样。这才是真实的 TLS 握手结果。7. 模块精简与动态加载砍掉所有“可能用到”的模块在 FreeBSD 12.0 上Apache 的模块列表不是“功能越多越好”而是“越少越安全”。每一个被LoadModule加载的模块都是一个潜在的攻击面。很多管理员为了“以防万一”会把mod_php7、mod_perl、mod_python、mod_wsgi全部加载结果是只要其中一个模块存在一个未公开的 0day 漏洞整个 Apache 服务就岌岌可危。真正的硬化是奉行“零信任”原则只加载当前业务绝对必需的模块其余一律卸载。httpd -M命令会列出所有已加载的模块。在一台刚安装的 FreeBSD 12.0 Apache 上你可能会看到 40 个模块。我的目标是将其压缩到 12 个以内。以下是经过严格筛选的“黄金十二模块”清单及其不可替代的理由mpm_prefork_modulecapsicum沙箱的唯一支持者无可替代。authz_core_module所有授权指令Require all granted的基础。authz_host_module基于 IP 的访问控制Require ip 192.168.1.0/24。log_config_moduleCustomLog和ErrorLog的基础。mime_moduleAddType和TypesConfig的基础。setenvif_moduleSetEnvIf指令用于根据请求头设置环境变量。ssl_moduleHTTPS 的基石。rewrite_moduleURL 重写几乎所有现代 Web 应用都需要。headers_moduleHeader set指令用于设置安全头X-Frame-Options。expires_moduleExpiresActive用于缓存控制。deflate_moduleDeflate用于压缩响应体减少带宽。security2_modulemod_security的主模块WAF 的核心。所有其他模块如mod_php7、mod_proxy、mod_cache、mod_disk_cache、mod_socache_shmcb都应该被注释掉。特别是 mod