趁这几天还比较闲，提前修复，到时等做等保三级也不用整改那么多嘛~~~能无脑地按照提示做就按加固建议做，着实坑了我，哈哈哈（幸好这环境还没用起来，阶段性修复我也有快照备份）~~专门惩罚我这种不动脑子的，所以呀，做运维要严谨，严谨，严谨，为自己的设置负责，至少要知道设置是干嘛的
一、nginx重定向到404页面
有一项是关于访问控制的：
当通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；身份鉴别 描述 1.设置客户端连接保持活动的超时时间 2.设置客户端请求头读取超时时间 3.设置客户端请求主体读取超时时间 4.设置响应客户端的超时时间 5.应设置客户端下载的连接并发数（每个IP的连接并发数） 检查提示 加固建议 编辑nginx.conf文件 具体设置如下: 1.keepalive_timeout 5 5; 2.client_header_timeout 10; 3.client_body_timeout 10; 4.send_timeout 10; 5.location / { limit_conn one 1; #限制每个ip只能发起一个并发连接,one为变量需在http段配置的limit_conn_zone对应的变量 limit_rate 20k; #限制每个连接的限制速度为20K，IP的下载速度为连接数*限制速度 } 提示:limit_conn_zone配置项可在官方文档中查看，与limit_conn相互依赖，http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
于是我就在nginx虚拟主机配置文件配了个：limit_conn 和 limit_rate（我昨晚弄的），觉得没啥不妥，直接复制黏贴
今早打开发现突然有问题，因为下午要给人做漏扫，恢复访问要紧。
1、问题现象：
一开始我找的开发，以为他改了啥，然后他说没有，给了这个截图我：
以为又是天翼的锅（人一开始从不会从自身找原因滴，都会先觉得是别人的问题），毕竟有前科【https://www.cnblogs.com/windysai/p/16545559.html】。话说可能他们也查不到，所以一天也没回我，我纯粹想着人多好办事，当然也在努力查原因。
一开始没头绪，恢复了昨天修复漏洞前的快照，竟然正常了，然后一个个排雷。。。弄死了继续恢复快照就行
首先以为是nginx虚拟主机配置文件中的location外面的404配置搞鬼，后来以为是审计（audit、rsyslog，毕竟昨天我加了这个配置）。
location外面的404配置：
如下图注释，因为上图很明显给我跳到404页面，话说这个404也奇怪，在location 里面配置才跳，location外面这个404竟然不起效，所以备注了“这个不起效”，实际问题未解决前，是没注释掉的，反正也不碍眼，但是现在确实是这里搞鬼，页面的url全部跳到404，先注释了，竟然好了
然后我开回来，网站竟然还是好的，没有重定向。。反反复复多次试验，被我找到原因了。
问题解决：
是nginx限流限速的配置，因为我无脑抄上去（觉得20k其实也还ok，实际上我低估了，一堆文件访问下来都超过20k【理解成下载】）。
这个啥意思呢（网上找的，不是我的原图）
limit_conn one 10; #限制并发连接数 limit_rate 200k; #限制最高下载速度
在想用这个参数会不会更好呢（待验证）：
limit_rate_after 1000k; #下载到指定的文件大小之后开始限速
特意观察下恢复好的网站，设置20K，肯定完蛋啦！！！
干脆直接去掉了，这个跟用户网络存在极大的关系，不能乱设置，先不搞，都开起来。
还有一个注意点：
这个配置有时注释重新加载nginx还不起效 (因为我反复试了几次，开了关，关了开，查问题原因嘛)，异常顽固，所以必要时刻，把整个nginx进程干掉，重新开起来
二、nginx账号锁定
老实说，这问题我没解决~~~干脆摆烂不干 = =
属于“阿里云标准-Nginx安全基线检查”，关于nginx身份鉴别的。
我比较好奇为啥会有这个锁定账号的策略，所谓存在即合理，查了下原因【参考：https://blog.csdn.net/Arlingtonroad/article/details/120346118】。
我的总结如下（如有不对，欢迎大家指出）
（1）首先绝对不能用root去跑的，权限太大
（2）能将服务运行情况隔离开来，保证不会因为服务器程序的问题而让服务器程序成了黑客的直接操作源。
浅显地说，这个运行nginx的用户即使被破解被利用，也不会危害系统其他用户的服务/文件/数据等
所以建议用一个不能登录的账号，一个特殊用途的用户 ID（linux的专用ID）
检查是否配置Nginx账号锁定策略。身份鉴别 描述 1.执行系统命令passwd -S nginx来查看锁定状态 出现Password locked证明锁定成功 如：nginx LK ..... (Password locked.)或nginx L .... 2.默认符合，修改后才有（默认已符合） 3.执行系统命令passwd -l nginx进行锁定 检查提示 -- 加固建议 配置Nginx账号登录锁定策略： Nginx服务建议使用非root用户(如nginx，nobody)启动，并且确保启动用户的状态为锁定状态。可执行passwd -l <Nginx启动用户> 如passwd -l nginx 来锁定Nginx服务的启动用户。命令 passwd -S <用户> 如passwd -S nginx可查看用户状态。 修改配置文件中的nginx启动用户修改为nginx或nobody 如： user nobody; 操作时建议做好记录或备份
因为安装nginx的时候，我用的是服务器新建的一个能登陆的普通用户去编译安装。明显跟策略需求相悖的
1、先测试锁定用户（感觉特别新奇），我找了那个既运行nginx，也是系统的登录账号去测（我一开始是抗拒用nobody这种不能登录的用户进行整改的），假设账号名叫：ljyhaha
passwd -S ljyhaha
passwd -l ljyhaha
直接远程连接不上！！！锁定之后就登不上服务器了
解锁就让登：passwd -u ljyhaha ，真是危险的操作 = =
2、修改nginx运行用户
1、添加 nginx 用户 useradd nginx -s /sbin/nologin -M 2、修改配置文件nginx运行用户 vim nginx.conf ——》user nginx nginx;
哪怕修改了目录权限，属主属组，都无果
sudo chown nginx.nginx /home/{ljyhaha}/app/nginx/ -R
sudo chmod 777 /home/{ljyhaha}/app/nginx/ -R
所以最终结果就是：从普通系统登录用户：ljyhaha，改成不能登录的用户：nginx，去运行nginx服务，这个完全没问题。但网站403的问题（也就是location匹配那块），暂时不知道怎么解决
有人说，是由于启动用户和nginx工作用户不一致所致，我的一个是nginx，一个是root，有空再测测
洗洗睡，找亲爱的周公约会 ^___^