Nginx range filter模块数字错误漏洞修复 (Nginx平滑升级)
对线上生产环境服务器进行漏洞扫描, 发现有两台前置机器存在Nginx range filter模块数字错误漏洞, 当使用nginx标准模块时，攻击者可以通过发送包含恶意构造range域的header 请求，来获取响应中的缓存文件头部信息。该漏洞存在于Nginx 1.13.3以下版本中, 只要Ningx开启了缓存功能, 攻击者即可发送恶意请求进行远程攻击造成信息泄露。也就是说当Nginx服务器使用代理缓存的情况下, 缓存文件头可能包含后端服务器的真实IP地址或其它敏感信息，攻击者就可以利用该漏洞拿到这些敏感信息，从而导致信息泄露。故此漏洞存在安全隐患, 需要尽快修复.
该漏洞修复方案一:
找到nginx的源码解压包, 在nginx的源码包中找到ngx_http_range_filter_module.c
[root@dtin ~]# cd /data/software/nginx-1.12.2
[root@dtin nginx-1.12.2]# vim ./src/http/modules/ngx_http_range_filter_module.c
.......
if (suffix) {
start = content_length - end;
end = content_length - 1;
}
....... 将上面ngx_http_range_filter_module.c源码文件中的"start = content_length - end;"改为“start = (end < content_length) ? content_length - end : 0;"
即改为:
[root@dtin nginx-1.12.2]# vim ./src/http/modules/ngx_http_range_filter_module.c
.......
if (suffix) {
start = (end < content_length) ? content_length - end : 0;
end = content_length - 1;
}
....... 接着重新编译nginx，并进行替换即可。
该漏洞修复方案一 (推荐这一种)
由于是生产环境, 线上业务不能停, 故需要进行Nginx平滑升级, 升级过程中服务不能中断. Nginx平滑升级原理如下介绍:
多进程模式下的请求分配方式
Nginx默认工作在多进程模式下，即主进程（master process）启动后完成配置加载和端口绑定等动作，fork出指定数量的工作进程（worker process），这些子进程会持有监听端口的文件描述符（fd），并通过在该描述符上添加监听事件来接受连接（accept）。
信号的接收和处理
Nginx主进程在启动完成后会进入等待状态，负责响应各类系统消息，如SIGCHLD、SIGHUP、SIGUSR2等。
Nginx信号
主进程支持的信号
- TERM, INT: 立刻退出
- QUIT: 等待工作进程结束后再退出
- KILL: 强制终止进程
- HUP: 重新加载配置文件，使用新的配置启动工作进程，并逐步关闭旧进程。
- USR1: 重新打开日志文件
- USR2: 启动新的主进程，实现热升级
- WINCH: 逐步关闭工作进程
工作进程支持的信号
- TERM, INT: 立刻退出
- QUIT: 等待请求处理结束后再退出
- USR1: 重新打开日志文件
=================nginx平滑升级操作记录====================
[app@web-node01 ~]# /data/nginx/sbin/nginx -v
nginx version: nginx/1.12.2 备份之前安装的nginx (其实主要备份的是sbin/nginx 和 conf配置目录, 这里我全部备份)
[app@web-node01 ~]# cp -r /data/nginx /data/nginx.old
[app@web-node01 ~]# ll /data/
total 0
drwxr-xr-x 10 app app 133 Sep 15 22:31 nginx
drwxr-xr-x 10 app app 133 Nov 15 15:21 nginx.old 下载nginx1.14.1的安装包, 解压并进行编译安装. 安装路径需与旧版一致
[app@web-node01 software]# ll nginx-1.14.1.tar.gz
-rw-rw-r-- 1 app app 1014040 Nov 15 11:04 nginx-1.14.1.tar.gz
[app@web-node01 software]# tar -zvxf nginx-1.14.1.tar.gz
[app@web-node01 software]# cd nginx-1.14.1/
[app@web-node01 nginx-1.14.1]# ./configure --prefix=/data/nginx --user=app --group=app --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream
[app@web-node01 nginx-1.14.1]# make && make install 发送USR2信号
向主进程发送USR2信号，Nginx会启动一个新版本的master进程和工作进程，和旧版一起处理请求
[app@web-node01 nginx-1.14.1]# ps -ef|grep nginx
app 1899 30168 0 15:25 pts/0 00:00:00 grep --color=auto nginx
app 19233 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19234 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19235 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19236 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19237 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19238 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19239 22333 0 Sep21 ? 00:00:05 nginx: worker process
app 19240 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19241 22333 0 Sep21 ? 00:00:27 nginx: cache manager process
root 22333 1 0 Sep15 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx [app@web-node01 nginx-1.14.1]# kill -USR2 22333 [app@web-node01 nginx-1.14.1]# ps -ef|grep nginx
root 1911 22333 0 15:26 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx
app 1912 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1913 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1914 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1915 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1916 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1917 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1918 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1919 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1920 1911 0 15:26 ? 00:00:00 nginx: cache manager process
app 1921 1911 0 15:26 ? 00:00:00 nginx: cache loader process
app 1923 30168 0 15:26 pts/0 00:00:00 grep --color=auto nginx
app 19233 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19234 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19235 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19236 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19237 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19238 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19239 22333 0 Sep21 ? 00:00:05 nginx: worker process
app 19240 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19241 22333 0 Sep21 ? 00:00:27 nginx: cache manager process
root 22333 1 0 Sep15 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx 发送WITCH信号
向原Nginx主进程发送WINCH信号，它会逐步关闭其下的工作进程（主进程不退出），这时所有请求都会由新版Nginx处理.
[app@web-node01 nginx-1.14.1]# kill -WITCH 22333 //如果这个命令报错,则可以忽略, 在最后一步直接kill掉原来Nginx主进程的pid即可. 发送HUP信号 (特别注意: 这一步是回退, 如果不回退, 则直接忽略这一步即可)
如果这时需要回退，可向原Nginx主进程发送HUP信号，它会重新启动工作进程， 仍使用旧版配置文件 。
然后可以将新版Nginx进程杀死（使用QUIT、TERM、或者KILL）
[app@web-node01 nginx-1.14.1]# kill -HUP 22333 升级完毕
如果不需要回滚，可以将原Nginx主进程杀死（使用QUIT、TERM、或者KILL），至此完成热升级。 [app@web-node01 nginx-1.14.1]# ps -ef|grep nginx
root 1911 22333 0 15:26 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx
app 1912 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1913 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1914 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1915 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1916 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1917 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1918 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1919 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1920 1911 0 15:26 ? 00:00:00 nginx: cache manager process
app 2394 30168 0 15:33 pts/0 00:00:00 grep --color=auto nginx
app 19233 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19234 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19235 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19236 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19237 22333 0 Sep21 ? 00:00:00 nginx: worker process
app 19238 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19239 22333 0 Sep21 ? 00:00:05 nginx: worker process
app 19240 22333 0 Sep21 ? 00:00:01 nginx: worker process
app 19241 22333 0 Sep21 ? 00:00:27 nginx: cache manager process
root 22333 1 0 Sep15 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx [app@web-node01 nginx-1.14.1]# sudo kill -9 19233 19234 19235 19236 19237 19238 19239 19240 19241 22333 [app@web-node01 nginx-1.14.1]# ps -ef|grep nginx
root 1911 1 0 15:26 ? 00:00:00 nginx: master process /data/nginx/sbin/nginx
app 1912 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1913 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1914 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1915 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1916 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1917 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1918 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1919 1911 0 15:26 ? 00:00:00 nginx: worker process
app 1920 1911 0 15:26 ? 00:00:00 nginx: cache manager process
app 2496 30168 0 15:35 pts/0 00:00:00 grep --color=auto nginx [app@web-node01 ~]# /data/nginx/sbin/nginx -v
nginx version: nginx/1.14.1
Nginx range filter模块数字错误漏洞修复 (Nginx平滑升级)的更多相关文章
- Nginx range filter模块数字错误漏洞修复 (Nginx平滑升级) 【转】
对线上生产环境服务器进行漏洞扫描, 发现有两台前置机器存在Nginx range filter模块数字错误漏洞, 当使用nginx标准模块时,攻击者可以通过发送包含恶意构造range域的header ...
- Linux kernel ‘lbs_debugfs_write’函数数字错误漏洞
漏洞名称: Linux kernel ‘lbs_debugfs_write’函数数字错误漏洞 CNNVD编号: CNNVD-201311-421 发布时间: 2013-11-29 更新时间: 2013 ...
- Linux kernel get_prng_bytes函数数字错误漏洞
漏洞名称: Linux kernel get_prng_bytes函数数字错误漏洞 CNNVD编号: CNNVD-201310-142 发布时间: 2013-10-11 更新时间: 2013-10-1 ...
- 高性能Web服务器Nginx的配置与部署研究（14）平滑升级你的Nginx
1.概述(可以直接跳过看第2部分) Nginx方便地帮助我们实现了平滑升级.其原理简单概括,就是: (1)在不停掉老进程的情况下,启动新进程. (2)老进程负责处理仍然没有处理完的请求,但不再接受处理 ...
- CVE-2013-2729 Adobe Reader和Acrobat 数字错误漏洞
这个洞是在论坛里看到的,感觉很有意思,来学习一下.个人感觉IE或者说是浏览器的洞和Adobe洞都是比较难调的,主要是有大量的类难以摸清之间的关系. 这个洞是一个整数溢出的洞,这个不是重点.重点是利用的 ...
- nginx gzip filter模块分析
API:http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/zlib-deflateinit2.html ...
- Web安全常见漏洞修复建议
转载地址:https://security.pingan.com/blog/17.html SQL注入 在服务器端要对所有的输入数据验证有效性. 在处理输入之前,验证所有客户端提供的数据,包括所有的参 ...
- nginx 增加 lua模块
Nginx中的stub_status模块主要用于查看Nginx的一些状态信息. 本模块默认是不会编译进Nginx的,如果你要使用该模块,则要在编译安装Nginx时指定: ./configure –wi ...
- PrestaShop 网站漏洞修复如何修复
PrestaShop网站的漏洞越来越多,该网站系统是很多外贸网站在使用的一个开源系统,从之前的1.0初始版本到现在的1.7版本,经历了多次的升级,系统使用的人也越来越多,国内使用该系统的外贸公司也很多 ...
随机推荐
- activity之间如何传递list
可以把list的内容拼成json串再去解析
- U盘或者移动银盘退出时一直显示占用中问题解决--最粗暴解决方式
问题描述: ---------------------------弹出 USB 大容量存储设备 时出问题---------------------------Windows 无法停用“通用卷”设备,原 ...
- HDU3572构造图的模型
第一次面对建模的图,也映照了我以前想的算法不是重点,问题的转化才是重点 Description: N个任务,M台机器,对于每一个任务有p,s,e表示该任务要做p个时长,要从[s,……)开始,从(……e ...
- HDU2159_二维完全背包问题
HDU2159_二维完全背包问题 输入有:经验,忍耐度,怪物种数,限制杀怪数 每一种怪物对应获得的经验值和消耗的耐久值 输出:剩下的最大忍耐度 限制:忍耐度,杀怪个数 在这里把忍耐度看成背包的容量,杀 ...
- linux-python在vim下的自动补全功能
linux-python在vim下的自动补全功能 安装配置: wget https://github.com/rkulla/pydiction/archive/master.zipunzip -q m ...
- Crontab有关
AIX下面 0,2,4,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,58 * * * * /usr/s ...
- 深入解析SQL Server高可用镜像实现原理
本文来自网易云社区 SQL Server 是windows平台.NET架构下标配数据库解决方案,与Oracle.MySQL共同构成了DB-Engines Ranking的第一阵营,在国内外企业市场中有 ...
- Android开发 - 获取Android设备的唯一标识码(Android 6.0或更高)
在我们的APP开发中,通常需要获取到设备的唯一标识.在Android6.0之前,有很多方法我们可以方便获取到硬件的唯一标识,但是在Android6.0之后,Android系统大幅限制了我们获取设备的硬 ...
- Android开发教程 - 使用Data Binding（六）RecyclerView Adapter中的使用
本系列目录 使用Data Binding(一)介绍 使用Data Binding(二)集成与配置 使用Data Binding(三)在Activity中的使用 使用Data Binding(四)在Fr ...
- UVA10829 L-Gap Substrings（后缀数组+ST表）
后缀数组+ST表. 代填的坑. \(Code\ Below:\) #include <bits/stdc++.h> #define ll long long using namespace ...