专栏首页散尽浮华Nginx range filter模块数字错误漏洞修复 (Nginx平滑升级) - 运维笔记

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Linux下误删除后的恢复操作(ext3/ext4)

    Linux是作为一个多用户、多任务的操作系统,文件一旦被删除是难以恢复的。尽管删除命令只是在文件节点中作删除标记,并不真正清除文件内容,但是其他用户和一些有写盘...

    洗尽了浮华
  • nginx下目录浏览及其验证功能、版本隐藏等配置记录

    工作中常常有写不能有网页下载东西的需求,在Apache下搭建完成后直接导入文件即可达到下载/显示文件的效果; 而Nginx的目录列表功能默认是关闭的,如果需要打...

    洗尽了浮华
  • linux下安装php的imagick扩展模块(附php升级脚本)

    imagick是一个PHP的扩展,是一套软件系列,用ImageMagick提供的API来进行图片的创建与修改,不过这些操作已经包装到扩展imagick中去了,最...

    洗尽了浮华
  • Bochspwn漏洞挖掘技术深究(1):Double Fetches 检测

    虽然现在技术文章很少人看,大家都喜欢聊安全八卦,但技术文章输出是一种很好的学习方式。更重要的是,专业的文章是给专业的人看的,并非为了取悦所有人。

    泉哥
  • MySQL实战二:多种查询方案

    MySQL学习仓库Up-Up-MySQL,这是一个学习MySQL从入门实战到理论完善,再到精通的一个仓库,后面会把MySQL的学习资料上传上去!欢迎大家star...

    公众号guangcity
  • OpenStack SR-IOV研究

    tanmx
  • ​CS:APP Attack Lab: 缓冲区溢出攻击

    CMU的15-213课程Introduction to Computer Systems (ICS)里面有一个实验叫attack lab,利用缓冲区溢出漏洞改变...

    王录华
  • FFmpeg使用手册 - MP4的格式解析

    视频文件转MP4 在互联网中常见的格式中,跨平台最好的,应该是MP4文件,因为MP4文件既可以在PC平台的Flashplayer中播放,又可以在...

    用户3765803
  • silverlight中用代码动态控制Storyboard(动画)属性的三种方法

    先准备一个基本的xaml页面 1<navigation:Page 2 xmlns="http://schemas.microsoft....

    菩提树下的杨过
  • ZABBIX 自定义采集触发时间范围

    周一到周五每天上午09:15-11:30 每隔5秒获取一次数据,下午13:00-15:00每隔10秒获得一次数据,其它时间段不获取数据。

    Kevin song

扫码关注云+社区

领取腾讯云代金券