怎么从Nginx底层存储架构出发归纳Master进程与Worker进程在现代化项目中的全部防御策略

Master进程不处理请求，仅负责管理Worker、加载配置、绑定端口及平滑重启；Worker进程才是实际响应HTTP请求的执行单元，二者必须严格权限分离：Master以root完成初始化后立即降权，Worker以专用低权限用户运行。

Master进程本身不处理请求，只负责管理Worker进程、加载配置、绑定端口、平滑重启等特权操作；Worker进程才是真正响应HTTP请求的执行单元。防御策略必须围绕“主从分离”这一底层设计展开，核心是让Master保持最小必要权限，Worker严格受限于业务所需范围。

Master进程的权限收敛与启动加固

Master必须以root运行，但仅限完成初始化动作：绑定80/443端口、读取SSL私钥、加载模块、创建监听套接字。之后立即降权移交控制权——这不是可选项，而是Nginx架构强制约定。

• 禁止在配置中写user root root或留空user指令，否则Worker可能退化为nobody或产生不可控行为
• SSL证书私钥文件权限必须为600且属主为root，确保Master能读、Worker完全不可读
• 配置文件（nginx.conf）和include路径应设为644，属主root，避免Worker意外修改或泄露内容
• 启用master_process on（默认），禁用后将失去热重载、优雅退出等关键能力，不适用于生产

Worker进程的运行身份与文件系统隔离

Worker必须以专用低权限用户运行，如nginx或www-data，且该用户不能登录、无shell、无家目录。

• 创建命令示例：useradd -r -s /sbin/nologin -d /var/www nginx
• Web根目录（如/var/www/html）属主设为root，属组设为nginx，权限755；启用setgid保证新文件继承组
• 日志目录（/var/log/nginx）需赋予nginx组写权限，静态资源文件统一设为644，可执行脚本（如CGI）必须显式限制
• 检查所有proxy_pass目标、fastcgi_pass路径、include的模板文件，确保Worker对该路径有且仅有必要访问权

基于共享内存的协同防御机制

Nginx通过共享内存区（zone）实现Master与Worker间状态同步，这是限流、封禁、缓存统计等功能的底层支撑，也是攻击面集中区。

• limit_req_zone和limit_conn_zone必须定义在http块，使用$binary_remote_addr而非$remote_addr防伪造
• zone大小要合理：10MB zone约支持16万IP状态，过小会导致哈希冲突频发，过大浪费内存
• 配合fail2ban时，应监听Nginx错误日志中limit_*触发记录，而非依赖Worker进程自身判断
• 自定义模块若使用共享内存，需确认其清理逻辑是否兼容Master reload流程，避免内存泄漏或状态错乱

操作系统级纵深协同控制

仅靠Nginx配置无法闭环防御，必须与SELinux、AppArmor、内核参数联动。

• RHEL/CentOS启用SELinux时，确保Nginx运行在httpd_t域；自定义路径需用semanage fcontext标记并restorecon
• Ubuntu启用AppArmor后，更新/etc/apparmor.d/usr.sbin.nginx，显式声明允许读取的证书路径、日志路径、临时上传目录
• 调整内核参数：net.core.somaxconn匹配listen ... backlog=值；net.ipv4.tcp_fin_timeout缩短连接回收时间
• 设置worker_rlimit_nofile并与ulimit -n一致，防止因文件描述符耗尽导致accept失败却无日志提示