1. 项目概述为什么需要一份专项加固指南在当前的数字化环境中Web应用和数据服务是绝大多数业务的核心。Nginx作为最流行的Web服务器和反向代理MySQL作为最广泛使用的关系型数据库它们的组合几乎构成了互联网服务的“标准底座”。然而这个底座的稳固性直接决定了上层业务的安全水位。我见过太多项目业务逻辑写得天花乱坠前端界面炫酷无比但一扒开Nginx配置和MySQL参数安全配置几乎处于“裸奔”状态——默认安装、空密码或弱密码、日志不开启、权限混乱。这就像把金库建在纸糊的墙上。“等保”即网络安全等级保护它不是一份简单的检查清单而是一套系统化的安全建设和管理框架。等保测评会从物理、网络、主机、应用、数据等多个层面进行审查。对于Nginx和MySQL而言其配置直接关系到“应用安全”和“数据安全”这两个核心层面的合规性。很多团队在应对等保测评时往往临时抱佛脚四处搜索零散的加固命令头痛医头脚痛医脚缺乏体系化的理解和可落地的操作指南导致整改过程反复、效率低下甚至引入新的风险。这份指南的目的就是基于我多年在运维和安全合规一线的实战经验将等保2.0尤其是二级和三级要求中与Nginx、MySQL强相关的安全控制点转化为具体、可逐项核对、可直接操作的配置指令和加固步骤。它不是理论空谈而是能让你“抄作业”的实战手册。无论你是运维工程师、开发负责人还是安全专员通过系统性地实施本指南你不仅能有效满足等保测评的硬性要求更能实实在在地提升服务自身的安全免疫能力防患于未然。2. 等保视角下的安全加固核心思路拆解在动手修改任何一个配置文件之前我们必须先建立正确的安全观。等保测评不是“找茬”而是引导我们建立“持续保护”的思维。针对Nginx和MySQL的加固我们可以从以下几个核心维度来构建防御体系2.1 最小权限原则收紧每一个入口这是安全的第一铁律。对于Nginx这意味着不以root权限运行工作进程配置文件、日志目录的权限严格控制隐藏不必要的版本信息限制HTTP方法如禁止TRACE、DELETE为不同的虚拟主机或应用分配仅够用的权限。对于MySQL则体现在为每个应用创建独立的数据库和专属用户并授予其完成业务所必需的最小权限SELECT, INSERT, UPDATE, DELETE坚决杜绝使用root账户或拥有ALL PRIVILEGES的账户进行日常业务连接。2.2 纵深防御不把鸡蛋放在一个篮子里安全不能只靠一层防护。Nginx层面我们可以通过配置实现Web应用防火墙WAF的部分功能如限制请求速率、过滤恶意User-Agent、防止SQL注入和XSS攻击的常见特征。同时Nginx作为反向代理其本身应与后端应用服务器如Tomcat、uWSGI以及数据库服务器在网络层面进行隔离通常部署在不同的安全域或通过内网防火墙策略控制访问。MySQL则应该仅监听在内网地址上并通过防火墙严格限制访问源IP只有特定的应用服务器才能连接。2.3 可审计性留下完整的“脚印”“雁过留声人过留痕”。所有重要的操作和行为都必须有据可查。Nginx的访问日志和错误日志是分析攻击行为、排查问题的关键。我们需要确保日志完整开启、格式包含足够的信息如客户端IP、请求时间、方法、URI、状态码、响应大小、Referer、User-Agent等并妥善管理日志轮转和长期存储。MySQL的审计更为关键必须开启通用查询日志general_log或慢查询日志slow_query_log用于行为审计同时二进制日志binlog不仅是数据恢复的基础也记录了所有数据变更是数据安全审计的重要依据。等保明确要求审计覆盖到每个用户的重要行为。2.4 配置安全与漏洞防范堵住已知的“破窗”使用稳定的官方版本并及时更新安全补丁。禁用存在安全隐患的旧协议、弱加密算法如SSLv2, SSLv3, TLS 1.0 MySQL的旧式密码认证。对Nginx要小心处理文件路径解析防止目录遍历对MySQL要移除测试数据库、匿名用户等默认安装的“赠品”。这些看似细微的配置往往是攻击者最先尝试的突破口。基于以上思路我们的加固工作将分为Nginx和MySQL两条主线每条主线都遵循“身份认证与授权 - 通信安全 - 日志审计 - 配置与漏洞”的流程来展开确保覆盖全面逻辑清晰。3. Nginx专项安全加固配置实操Nginx的安全加固主要围绕其配置文件通常是nginx.conf及其包含的conf.d/*.conf或sites-enabled/*展开。在修改任何配置前务必先备份原文件。3.1 运行权限与进程隔离默认情况下Nginx主进程以root启动以便绑定1024以下端口如80、443但工作进程worker processes必须以非特权用户运行。操作步骤创建一个专用的系统用户和组例如nginx。groupadd nginx useradd -g nginx -s /sbin/nologin -M nginx修改nginx.conf主配置文件中的user指令。# 在main上下文events块之前修改 user nginx nginx; worker_processes auto; # 根据CPU核心数自动设置修改Nginx相关目录的权限确保nginx用户有必要的读写权限。chown -R root:nginx /etc/nginx/ # 配置文件所有权归root组为nginx chmod -R 750 /etc/nginx/ # root可读写执行nginx组可读执行其他无权限 chown -R nginx:nginx /var/log/nginx /var/cache/nginx # 日志和缓存目录归nginx用户注意事项如果网站需要上传功能上传目录的所有权应设置为运行后端应用的用户如www-data或php-fpm用户而不是nginx用户并结合client_body_temp_path设置合适的临时目录权限防止通过上传漏洞获取nginx权限。3.2 隐藏敏感信息与减少攻击面泄露软件版本和操作系统信息会为攻击者提供便利。隐藏Nginx版本号在http块或server块中配置。server_tokens off;自定义错误页面避免在4xx、5xx错误页面中暴露默认信息。可以设置统一的友好错误页。error_page 404 /404.html; error_page 500 502 503 504 /50x.html; # 并确保这些html文件存在且内容无害限制HTTP方法通常只允许GET, HEAD, POST。location / { limit_except GET HEAD POST { # 限制除了GET/HEAD/POST之外的方法 deny all; } # ... 其他配置 }禁用非必要模块在编译安装Nginx时使用--without-http_autoindex_module禁用自动目录列表除非业务确实需要。3.3 传输安全与SSL/TLS强化如果提供HTTPS服务SSL/TLS配置是重中之重。仅使用强加密协议和套件禁用SSLv2、SSLv3、TLS 1.0甚至TLS 1.1。优先使用TLS 1.2/1.3。ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE; ssl_prefer_server_ciphers on;启用HSTS强制浏览器使用HTTPS连接。add_header Strict-Transport-Security max-age63072000; includeSubDomains; preload always;注意includeSubDomains和preload要谨慎使用确认所有子域名都支持HTTPS后再添加。安全的Cookie设置proxy_cookie_path / /; secure; HttpOnly; SameSiteStrict;这会在通过Nginx反向代理设置Cookie时自动添加安全属性。3.4 访问控制与请求限制限制客户端连接和请求速率防止CC攻击和暴力扫描。http { limit_conn_zone $binary_remote_addr zoneperip:10m; limit_conn_zone $server_name zoneperserver:10m; limit_req_zone $binary_remote_addr zonereqlimit:10m rate10r/s; # 每秒10个请求 server { limit_conn perip 10; # 每个IP同时最多10个连接 limit_conn perserver 100; # 整个server同时最多100个连接 location /api/ { limit_req zonereqlimit burst20 nodelay; # 突发处理20个请求 proxy_pass http://backend; } } }基于IP的访问控制对于管理后台等敏感接口应限制访问IP。location /admin/ { allow 192.168.1.0/24; # 允许内网网段 allow 10.10.10.100; # 允许特定管理IP deny all; # 拒绝其他所有 # ... 代理配置 }3.5 日志配置与安全管理确保日志开启且格式完整http { log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; # 日志级别设为warn避免debug信息过多 }日志轮转与保护使用系统的logrotate工具定期切割、压缩并保留一定天数的日志。确保日志文件权限正确如640属主root属组adm或nginx防止被篡改。监控关键错误定期检查error.log中出现的permission denied、connection reset by peer以及大量4xx/5xx状态码的请求这些可能是攻击尝试或配置问题的信号。4. MySQL专项安全加固配置实操MySQL的加固主要通过SQL命令修改全局变量、调整配置文件(my.cnf或my.ini)以及执行安全审计操作来完成。操作前请务必在测试环境验证并对生产数据库进行完整备份。4.1 初始化安全与账户权限加固这是最基础也最重要的一步。运行mysql_secure_installation如果是全新安装首先运行这个脚本。它会引导你设置root密码。移除匿名用户。禁止root账户远程登录极其重要。移除测试数据库test。创建专属应用账户遵循最小权限原则-- 首先为每个应用创建独立的数据库 CREATE DATABASE app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建仅能访问该数据库的用户并限制其来源IP例如仅允许应用服务器IP 192.168.1.100访问 CREATE USER app_user192.168.1.100 IDENTIFIED BY StrongPassword123!; -- 授予该用户对app_db数据库的必要权限通常不包括GRANT, FILE, PROCESS, SUPER等管理权限 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, EXECUTE ON app_db.* TO app_user192.168.1.100; -- 立即刷新权限 FLUSH PRIVILEGES;检查并清理多余用户和权限SELECT User, Host, authentication_string FROM mysql.user; -- 删除任何非必要的用户特别是Host为%任意主机的root或高权限用户 DROP USER root%; -- 如果存在务必删除4.2 网络与连接安全配置绑定内网地址禁止公网监听在[mysqld]配置段中修改。[mysqld] bind-address 192.168.1.10 # 改为你的内网IP切勿使用 0.0.0.0修改默认端口可选但推荐将默认的3306端口改为其他端口可以减少自动化扫描工具的发现概率。port 33066注意修改后所有客户端连接都需要指定新端口。配置连接数限制和超时防止资源耗尽。max_connections 500 # 根据服务器资源设置 connect_timeout 10 wait_timeout 600 # 非交互连接超时时间 interactive_timeout 600 # 交互连接超时时间4.3 审计日志与安全监控等保对审计日志有明确要求必须开启。开启通用查询日志用于全量审计此日志记录所有连接和语句对性能影响较大通常用于短期排查或安全事件调查不建议在生产环境长期全量开启。如需满足等保可考虑使用第三方审计插件或MariaDB的审计功能。SET GLOBAL general_log ON; SET GLOBAL general_log_file /var/log/mysql/general.log;或在配置文件中永久设置general_log 1 general_log_file /var/log/mysql/general.log开启慢查询日志用于性能与异常分析记录执行时间超过阈值的查询有助于发现性能问题和潜在的恶意慢查询。slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 2 # 单位秒超过2秒的查询被记录 log_queries_not_using_indexes 1 # 记录未使用索引的查询谨慎开启可能日志量巨大确保二进制日志开启用于数据恢复与复制Binlog是数据安全的关键必须开启。log_bin /var/log/mysql/mysql-bin.log expire_logs_days 30 # 自动清理30天前的binlog server_id 1 # 在复制环境中需唯一日志文件权限管理确保日志文件不被未授权访问。chown mysql:adm /var/log/mysql/ chmod 750 /var/log/mysql/4.4 密码策略与加密强化启用密码复杂度策略MySQL 5.7 / MariaDB 10.3-- 安装密码验证组件MySQL 5.7/8.0 INSTALL COMPONENT file://component_validate_password; -- 然后设置策略 SET GLOBAL validate_password.policy MEDIUM; -- 或 STRONG SET GLOBAL validate_password.length 12; SET GLOBAL validate_password.number_count 2; SET GLOBAL validate_password.special_char_count 1;在配置文件中永久生效[mysqld] plugin-load-add validate_password.so validate_password.policy MEDIUM validate_password.length 12确保使用安全的密码哈希算法MySQL 8.0默认使用caching_sha2_password比旧的mysql_native_password更安全。如果使用5.7应确保用户不使用旧的、不安全的哈希方式。-- 查看用户认证插件 SELECT user, host, plugin FROM mysql.user; -- 修改用户插件例如root用户 ALTER USER rootlocalhost IDENTIFIED WITH caching_sha2_password BY YourNewStrongPassword;4.5 其他关键安全配置禁用LOCAL INFILE防止客户端通过LOAD DATA LOCAL INFILE读取服务器上的任意文件。local_infile 0禁用符号链接防止通过数据库表符号链接到系统文件。symbolic_links 0设置安全的umask确保MySQL创建的文件和目录有安全的默认权限。[mysqld] umask 0027 # 创建的文件权限为640目录为7505. 加固后的验证与持续监控配置修改完成后绝不能一改了之必须进行严格的验证。5.1 配置验证清单Nginx验证语法检查nginx -t重载配置systemctl reload nginx(确保服务不中断)检查进程运行用户ps aux | grep nginx确认worker进程以nginx用户运行。测试信息隐藏访问一个不存在的页面查看错误响应头是否包含Server: nginx。测试HTTPS使用openssl s_client -connect yourdomain.com:443 -tls1_2或在线工具如SSL Labs检查SSL/TLS配置是否安全。测试访问控制尝试从非授权IP访问管理后台应被拒绝。MySQL验证重启或重载MySQL服务systemctl restart mysql(或mysqld)使用应用账户从指定IP登录测试mysql -u app_user -p -h 192.168.1.10 -P 33066尝试远程用root登录mysql -u root -p -h 公网IP应该被拒绝。检查日志是否正常生成查看/var/log/mysql/error.log,general.log(如果开启)slow.log。运行安全审计脚本MySQL自带mysql_secure_installation也可以使用像mysqltuner.pl这样的第三方脚本进行安全检查和建议。5.2 持续监控与应急响应安全加固是一个持续的过程不是一次性的任务。日志监控使用ELK Stack、Graylog或LokiPromtailGrafana等工具集中收集、分析Nginx和MySQL的日志。设置告警规则例如Nginx短时间内同一IP产生大量5xx或4xx错误。MySQL出现大量失败的登录尝试、Access denied错误、或执行时间极长的慢查询。定期漏洞扫描与配置复查定期使用Nessus、OpenVAS等工具对服务器进行漏洞扫描。每季度或发生重大变更后重新对照本指南的检查项进行配置复查。备份与恢复演练确保MySQL的备份策略物理备份逻辑备份binlog有效并定期进行恢复演练。Nginx的配置也应纳入版本控制系统如Git进行管理。建立变更管理流程任何对生产环境Nginx/MySQL配置的修改都必须经过申请、评审、测试、实施的流程并记录在案。6. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种“坑”。这里记录了几个典型问题和我的解决思路。6.1 Nginx配置错误导致服务不可用问题修改配置后nginx -t测试通过但systemctl reload nginx后网站无法访问systemctl status nginx显示服务是active (running)。排查检查错误日志第一时间查看error.log(tail -f /var/log/nginx/error.log)这里通常有最直接的错误信息。检查端口监听netstat -tlnp | grep nginx或ss -tlnp | grep nginx。确认Nginx是否成功监听了80/443端口。如果没有可能是与旧进程冲突或权限问题。检查SELinux/AppArmor在RHEL/CentOS或Ubuntu等高安全发行版上安全模块可能会阻止Nginx绑定端口或访问日志文件。可以暂时将其设为宽容模式测试setenforce 0(SELinux) 或sudo aa-complain /usr/sbin/nginx(AppArmor)。如果问题解决则需要添加正确的安全上下文或策略而不是永久关闭它。回滚与二分法如果以上都无果最有效的方法是回滚到上一个可用的配置。如果修改点很多采用“二分法”注释掉一半修改重载测试逐步定位问题配置行。6.2 MySQL无法远程连接或权限错误问题应用服务器无法连接到MySQL数据库报错 “Host ‘xxx.xxx.xxx.xxx’ is not allowed to connect”。排查确认用户权限在MySQL服务器上登录执行SELECT user, host FROM mysql.user WHERE userapp_user;。确保host字段精确匹配应用服务器的IP地址或通配符%不推荐。localhost和127.0.0.1在MySQL中是不同的。检查绑定地址确认my.cnf中的bind-address不是127.0.0.1并且服务器防火墙如firewalld, iptables允许了从应用服务器IP到MySQL端口默认3306或自定义端口的流量。检查密码插件MySQL 8.0的caching_sha2_password插件可能被一些老的客户端如某些PHP版本不支持。可以尝试将用户认证插件改回mysql_native_password但这会降低安全性。更好的方案是升级客户端或驱动。ALTER USER app_user192.168.1.100 IDENTIFIED WITH mysql_native_password BY password;6.3 开启日志后磁盘空间暴涨问题开启了MySQL的general_log或slow_log或者Nginx访问量巨大导致日志文件迅速占满磁盘。应对立即清理或轮转Nginx:logrotate -f /etc/logrotate.d/nginx或手动清空access.log(echo /var/log/nginx/access.log)。MySQL: 对于通用日志可以临时关闭SET GLOBAL general_log OFF;然后安全地删除或移动旧日志文件。切勿直接删除正在被MySQL写入的日志文件。调整日志策略Nginx: 在log_format中考虑精简字段对于静态资源请求可以在location块中使用access_log off;来关闭日志。MySQL:general_log仅用于临时调试切勿长期开启。slow_query_log的long_query_time可以适当调大如从2秒调到5秒并谨慎开启log_queries_not_using_indexes。设置监控告警对/var/log和/等关键分区设置磁盘使用率告警如 80%这是运维的基本功。6.4 性能与安全的平衡点安全配置往往会带来一定的性能开销需要找到平衡。Nginx的limit_req/limit_conn限制过于严格会误伤正常用户过于宽松则失去防护意义。需要根据业务实际QPS和用户行为模式通过监控日志来调整rate和burst参数。对于API可以设置得严格一些对于首页等静态资源可以放宽或不做限制。MySQL的密码验证插件validate_password的STRONG策略会要求非常复杂的密码可能增加用户管理难度。对于内部系统MEDIUM策略通常已足够。关键在于杜绝弱密码和默认密码。SSL/TLS加密会消耗CPU资源。对于性能敏感的内网服务如果网络环境完全可信可以考虑不使用TLS。但对于任何经过公网或涉及敏感数据的传输TLS是必须的性能开销可以通过硬件加速如支持AES-NI的CPU来缓解。安全加固没有一劳永逸的银弹。它始于一套严谨的配置成于持续的监控、审计和应急响应。这份指南为你提供了满足等保要求和提升实战安全性的具体路径但真正的安全源于对这套体系和其中每一个配置项背后原理的深刻理解以及将其融入日常运维血液中的习惯。每次变更前多问一句“这安全吗”每次告警后多查一步“根本原因是什么”你的系统就会在攻防的拉锯中变得越来越稳固。
》)
一键保存高清图表到本地（附完整参数详解）)