nginx身份验证500报错

nginx身份验证500报错

　　长话短说，因为昨晚失眠，只知道外面雷雨交加，然后凭着茶叶的提神后劲，估计2点多才睡得着。。。现在眼皮都有点睁不开。

　　这个问题我觉得没啥人遇到，因为网上搜了两页都查不到解决方法，于是对照回以前的设置看。

 

一、需求引入

　　这个需求我觉得有点反人性。话说中心现在要求我们每周做一次安全工作报告，其中有一项是日志分析，日志分析包括系统、WAF、nginx访问日志、堡垒机等。其中WAF日志分析他们看的特别仔细，对处理方式为警告而不是直接阻断的攻击（一般为低中危）显得尤为担忧，怕影响根域名也就是首页的正常访问，于是叮嘱我跟WAF那边调整后台防护策略，之前是调高防护级别，现在又想增加个短时间内同一个IP访问某链接直接阻断的策略（最终新增的策略是：同一个IP每分钟达到30次违规行为就被封禁），当昨天增加这条策略后，连首页都被拦截了（当时吓坏了我们老板= =），返回电信特有的405拦截页面，如下图：

　　这里我真的不得不吐槽下电信的WAF，给过去的白名单经常因为新增策略或者调整防护级别而莫名消失，我印象中有3次这样的情况。现在竟然连首页都能拦截的。。。其实智能点的策略，首页如果是静态页，也就是类似文章这种，这条策略不应该适用。

　　想象一个场景，一个中大型公司，路由器固定了公网IP出去外网，如果同时有几十号人去访问这个首页地址(新闻文章类)，是可以实现同一个IP每分钟达到30次访问首页的效果，也就是这种情况是正常的。另一个场景：如果是一个仅有很少人知道的后台上传登录页面，管理权实际上掌控在2~3人手上，这条策略是没错的，即使这3人同时刷新页面，这个也有点难办到，何况这2~3人不是来自同一家公司的，出口ip不可能是一样的。

　　为什么我会提到第二个场景，因为本文这个nginx身份验证就是要加固这个后台上传登录页面。

　　上面也提到，他们对那种短时间内访问同一个URL地址的IP不进行封禁而仅仅是告警，非常敏感，觉得会影响首页访问，因为用的是同一个根域名。有种城门失火，殃及池鱼的味道~(根域名下的二级目录被攻击，影响到根域名首页内容的正常访问)

 　　老板知道这策略加了连首页都拦截，觉得岂有此理，一个无利可图的静态页还担心人家攻击你，搞到崩溃无法访问，黑客是有多无聊，还浪费资源~~ （后面是我加的，哈哈哈）。于是开回来之后叫我将这个管理后台放到我们公司域名下，即使攻击也是我们公司域名访问慢，不殃及这个静态页，我就提议再加个nginx身份验证。其实最好还是中心固定好白名单ip给我们。

 

二、需求实现和500问题

　　nginx身份验证实现这个是运维人员的基本功了，不多说，我说说为啥会返回500。当时我切到了root用户去操作，然后把auth_basic相关内容写到nginx配置文件重新加载

mkdir -p /home/{运行nginx普通用户}/app/nginx/conf/htpasswd/xxxupload/
htpasswd -c /home/{运行nginx普通用户}app/nginx/conf/htpasswd/xxupload/.htpasswd xxxupload

当我进行完nginx身份验证后，

不是直接到下一层的登录页面，而是直接返回500错误：

 

 　　看nginx错误和访问日志没有什么有价值的信息，网上查一轮说是服务器内部错误。干脆找回以前配置过的对照来看，发现问题所在了：

 

 　　我这里的环境跑的nginx是用普通用户去跑的，而不是root，配置上去nginx文件的加密文件，这个普通用户无法去读取，所以把属主属组从root改过来，问题即能解决：

chown {运行nginx普通用户}.{运行nginx普通用户所属组}/home/{运行nginx普通用户}/app/nginx/conf/htpasswd/xxupload/ -R

 　  最后强调下，有些处理过的问题，其实找回以前自己成功配置过的笔记，是最省时、还比较有效的方法，因为网上找的，很多时候跟你个人习惯或者运行环境不同，而导致解决方法失效。好比我这里查了一堆都是用root去跑的nginx，而不是普通用户。。。