Category Archives: Nginx

nginx上传大文件，413错误解决

在nginx里增加了配置。

我觉得，应该只用修改client_max_body_size就可以解决问题。 其它几个，设置了并未起作用。其参数意义如下： client_max_body_size 限制请求体的大小，若超过所设定的大小，返回413错误。 client_header_timeout 读取请求头的超时时间，若超过所设定的大小，返回408错误。 client_body_timeout 读取请求实体的超时时间，若超过所设定的大小，返回413错误。 proxy_connect_timeout http请求无法立即被容器(tomcat, netty等)处理，被放在nginx的待处理池中等待被处理。此参数为等待的最长时间，默认为60秒，官方推荐最长不要超过75秒。 proxy_read_timeout http请求被容器(tomcat, netty等)处理后，nginx会等待处理结果，也就是容器返回的response。此参数即为服务器响应时间，默认60秒。 proxy_send_timeout http请求被服务器处理完后，把数据传返回给Nginx的用时，默认60秒。   from:https://www.cnblogs.com/aguncn/p/11189159.html

nginx开启目录浏览

nginx 升级时 [emerg] module "/usr/lib64/nginx/modules/ngx_http_geoip_module.so" version 1010003 instead of 1016000 in /usr/share/nginx/modules/mod-http-geoip.conf:1

nginx -V

  检查/换源

  升级

[root@VM_0_15_centos ~]# nginx -V nginx version: nginx/1.16.0   检查时报错

  解决问题

  from:https://www.cnblogs.com/mingetty/p/11125391.html

verynginx-web防火墙

VeryNginx 转载：https://github.com/alexazhou/VeryNginx VeryNginx 是一个功能强大而对人类友好的 Nginx 扩展程序. 提示 v0.2 版本之后，控制台入口被移动到了 /verynginx/index.html 介绍 VeryNginx 基于 lua_nginx_module(openrestry) 开发，实现了高级的防火墙、访问统计和其他的一些功能。 集成在 Nginx 中运行，扩展了 Nginx 本身的功能，并提供了友好的 Web 交互界面。 VeryNginx在线实例 用户名 / 密码: verynginx / verynginx 详细配置说明见：VeryNginx Github WiKi Nginx 运行状态分析 每秒请求数 响应时间 网络流量 网络连接数 自定义行为 VeryNginx 包含强大的自定义功能，可以做很多事情 自定义行为包含两部分， Matcher 和 Action 。 Matcher 用来对请求进行匹配， Action 为要执行的动作 这样的优势在于把所有的前置判断整合在Matcher里一起来实现了，使复杂(组合)规则的实现变成了可能 Matcher 一个 Matcher 用来判断一个 Http 请求是否符合指定的条件， 一个 Matcher 可以包含一个或者多个约束条件，目前支持以下几种约束： Client IP Host UserAgent URI Referer Request Args 当一个请求没有违反 Matcher 中包含的全部条件时，即命中了这个 Matcher Action 每个 Action 会引用一个 Matcher ，当 Matcher 命中时， Action 会被执行 目前已经实现了以下 Action Scheme Lock 将访问协议锁定为 Https 或者 Http Redirect 对请求进行重定向 URI Rewrite 对请求的 URI […]

点击劫持漏洞:使用X-Frame-Options 解决方法（应用tomcat）

发现项目中存在 X-Frame-Options 低危漏洞： 使用 X-Frame-Options X-Frame-Options 有三个值: DENY 表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。 SAMEORIGIN 表示该页面可以在相同域名页面的 frame 中展示。 ALLOW-FROM uri 表示该页面可以在指定来源的 frame 中展示。   换一句话说，如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。 另一方面，如果设置为 SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。   配置 Apache 配置 Apache 在所有页面上发送 X-Frame-Options 响应头，需要把下面这行添加到 'site' 的配置中:

  配置 nginx 配置 nginx 发送 X-Frame-Options 响应头，把下面这行添加到 'http', 'server' 或者 'location' 的配置中:

  配置 IIS 配置 IIS 发送 X-Frame-Options 响应头，添加下面的配置到 Web.config 文件中:

  配置 TOMCAT “点击劫持：X-Frame-Options未配置” 因为项目使用的是tomcat服务器，我们不可能在每个页面去添加：  

    因此我们使用过滤器，代码如下：  

  通过以下配置，好像就没有在扫描出来该漏洞信息。   你配不上自己的野心 也辜负了所受的苦难 from:https://www.cnblogs.com/wdnnccey/p/6476518.html

upstream timed out

报错信息：

  解决办法： server { listen       80; server_name  *.xywy.com ;         large_client_header_buffers 4 16k; #客户请求头缓冲大小 nginx默认会用client_header_buffer_size这个buffer来读取header值，如果header过大，它会使用large_client_header_buffers来读取如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request求行如果超过buffer，就会报HTTP 414错误(URI Too Long)nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。         client_max_body_size 300m; #指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段. 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误. 记住,浏览器并不知道怎样显示这个错误.         client_body_buffer_size 128k; 这个指令可以指定连接请求实体的缓冲区大小。 如果连接请求超过缓存区指定的值，那么这些请求实体的整体或部分将尝试写入一个临时文件。 默认值为两个内存分页大小值，根据平台的不同，可能是8k或16k。 当请求头中的Content-Length字段小于指定的buffer size，那么Nginx将使用较小的一个，所以nginx并不总是为每一个请求分配这个buffer size大小的buffer。         proxy_connect_timeout 600; 说明 该指令设置与upstream server的连接超时时间，有必要记住，这个超时不能超过75秒。 这个不是等待后端返回页面的时间，那是由proxy_read_timeout声明的。如果你的upstream服务器起来了，但是hanging住了（例如，没有足够的线程处理请求，所以把你的请求放到请求池里稍后处理），那么这个声明是没有用的，由于与upstream服务器的连接已经建立了。         proxy_read_timeout 600; 说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间，而是两次reading操作的时间。         proxy_send_timeout 600; 说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间，而是在两次write操作期间。如果超时后，upstream没有收到新的数据，nginx会关闭连接         proxy_buffer_size 64k; 该指令设置缓冲区大小,从代理后端服务器取得的第一部分的响应内容,会放到这里. 小的响应header通常位于这部分响应内容里边. 默认来说,该缓冲区大小等于指令 proxy_buffers所设置的;但是,你可以把它设置得更小.         proxy_buffers   4 32k; 该指令设置缓冲区的大小和数量,从被代理的后端服务器取得的响应内容,会放置到这里.         proxy_busy_buffers_size 64k; 默认值: proxy_busy_buffers_size proxy_buffer_size * 2; 上下文: http, server, location, if TODO: Description. buffer工作原理 首先第一个概念是所有的这些proxy buffer参数是作用到每一个请求的。每一个请求会安按照参数的配置获得自己的buffer。proxy buffer不是global而是per request的。 proxy_buffering 是为了开启response buffering of the proxied […]

nginx 优化(突破十万并发)

一般来说nginx 配置文件中对优化比较有作用的为以下几项： worker_processes 8; nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数。 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一 个进程分配到多个cpu。 worker_rlimit_nofile 102400; 这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文 件数（ulimit -n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 use epoll; 使用epoll 的I/O 模型 worker_connections 102400; 每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。 keepalive_timeout 60; keepalive 超时时间。 client_header_buffer_size 4k; 客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求 头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE 取得。 open_file_cache max=102400 inactive=20s; 这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。 open_file_cache_valid 30s; 这个是指多长时间检查一次缓存的有效信息。 open_file_cache_min_uses 1; open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。 关于内核参数的优化： net.ipv4.tcp_max_tw_buckets = 6000 timewait 的数量，默认是180000。 net.ipv4.ip_local_port_range = 1024 65000 允许系统打开的端口范围。 net.ipv4.tcp_tw_recycle = 1 启用timewait 快速回收。 net.ipv4.tcp_tw_reuse = 1 开启重用。允许将TIME-WAIT sockets 重新用于新的TCP 连接。 […]

使用NGINX+Openresty实现WAF功能

使用NGINX+Openresty实现WAF功能 一、了解WAF 1.1 什么是WAF Web应用防护系统（也称：网站应用级入侵防御系统 。英文：Web Application Firewall，简称： WAF）。利用国际上公认的一种说法：Web应用 防火墙 是通过执行一系列针对HTTP/HTTPS的 安全策略 来专门为Web应用提供保护的一款产品。 1.2 WAF的功能 支持IP白名单和黑名单功能，直接将黑名单的IP访问拒绝。 支持URL白名单，将不需要过滤的URL进行定义。 支持User-Agent的过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持CC攻击防护，单个URL指定时间的访问次数，超过设定值，直接返回403。 支持Cookie过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持URL过滤，匹配自定义规则中的条目，如果用户请求的URL包含这些，返回403。 支持URL参数过滤，原理同上。 支持日志记录，将所有拒绝的操作，记录到日志中去 1.3 WAF的特点 异常检测协议 Web应用防火墙会对HTTP的请求进行异常检测，拒绝不符合HTTP标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。 增强的输入验证 增强输入验证，可以有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为。从而减小Web服务器被攻击的可能性。 及时补丁 修补Web安全漏洞，是Web应用开发者最头痛的问题，没人会知道下一秒有什么样的漏洞出现，会为Web应用带来什么样的危害。WAF可以为我们做这项工作了——只要有全面的漏洞信息WAF能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常完美的，并且没有安装对应的补丁本身就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。 基于规则的保护和基于异常的保护 基于规则的保护可以提供各种Web应用的安全规则，WAF生产商会维护这个规则库，并时时为其更新。用户可以按照这些规则对应用进行全方面检测。还有的产品可以基于合法应用数据建立模型，并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到，可现实中这是十分困难的一件事情。 状态管理 WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件（比如登陆失败），并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。 其他防护技术 WAF还有一些安全增强的功能，可以用来解决WEB程序员过分信任输入数据带来的问题。比如：隐藏表单域保护、抗入侵规避技术、响应监视和信息泄露保护。 1.3WAF与网络防火墙的区别 网络防火墙作为访问控制设备，主要工作在OSI模型三、四层，基于IP报文进行检测。只是对端口做限制，对TCP协议做封堵。其产品设计无需理解HTTP会话，也就决定了无法理解Web应用程序语言如HTML、SQL语言。因此，它不可能对HTTP通讯进行输入验证或攻击规则分析。针对Web网站的恶意攻击绝大部分都将封装为HTTP请求，从80或443端口顺利通过防火墙检测。 一些定位比较综合、提供丰富功能的防火墙，也具备一定程度的应用层防御能力，如能根据TCP会话异常性及攻击特征阻止网络层的攻击，通过IP分拆和组合也能判断是否有攻击隐藏在多个数据包中，但从根本上说他仍然无法理解HTTP会话，难以应对如SQL注入、跨站脚本、cookie窃取、网页篡改等应用层攻击。 web应用防火墙能在应用层理解分析HTTP会话，因此能有效的防止各类应用层攻击，同时他向下兼容，具备网络防火墙的功能。 二、使用nginx配置简单实现403和404 2.1 小试身手之rerurn 403 修改nginx配置文件在server中加入以下内容 set $block_user_agent 0; if ($http_user_agent ~ "Wget|AgentBench"){ # 注意if 和(之间要有空格，否则会报错 set $block_user_agent 1; } if ($block_user_agent = 1){ return 403; } 通过其他机器去wget，结果如下 [root@mini1 ~]# wget http://192.168.3.140 --2017-05-05 14:14:53-- http://192.168.3.140/ Connecting to 192.168.3.140:80… connected. HTTP request sent, awaiting response… 403 Forbidden 2017-05-05 14:14:53 […]

使用nginx-http-concat优化网站响应

前言： 我们在访问淘宝的时候，会看到代码中的js和css文件是通过一次请求或得的，我们知道浏览器一次请求只能并发访问数个资源，这样的处理错输在网络传输层面可以大大节省时间，这里使用的技术就是把css、js等静态资源合并为一个资源。淘宝使用的tengine是基于nginx的web服务器，从11年底开源。所使用的是mod_concat模块，合并多个文件在一个响应报文中。 http1.1下浏览器的并发访问资源数 IE6                                 2 IE7                                 2 IE8                                 6 Firefox2                          2 Firefox3                          6 Safari 3,4         […]

Centos7下nginx配置https

Centos7下nginx配置https 在互联网信息安全日益重要的今天，https协议几乎成了标配，部分浏览器如果遇到非https的服务器会拒绝访问，有的平台也要求app的服务器要用https协议（如苹果、微信小程序）。 下面是个人配置https的笔记，先完整记录下来，不然到时遇到问题又各种百度。 一、步骤1 配置nginx 假如你已经申请到了https证书，而且有nginx下的版本，通常是两个文件，一个是 .key 后缀的文件，为证书的私钥，另一个是 .crt 后缀的文件，为证书的公钥。 nginx.conf 配置如下：

  把#1所在行的 www.sever.com 改成你的域名（注意：这个域名是你申请证书时用的域名）。 把#2所在行的 ssl/bundle.crt* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 把#3所在行的 ssl/cert.key* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 如果要让用户用http协议访问时自动跳转https，则还需加上如下配置：

  就是一个url重写而已。 注意要把 www.server.com 改成你实际的主机名。 配置完后，用如下命令

  测试下配置文件有没有错误。 如果没有错误，用如下命令

  重启nginx，然后用浏览器测试下用https协议能否正常访问服务器。 如果不能访问，请确认下证书路径有没有问题，如果没有，请看下面的 步骤2。 二、步骤2 开启服务器的防火墙 需要该步骤是因为服务器的防火墙没有开通443端口。 centos7 下用的防火墙是firewalld，配置防火墙用命令firewall-cmd。 开通443端口

  确认是否开通

  如果可以看到443/tcp字样就说明开通了 重新加载下防火墙配置

  执行完该步骤，大多数服务器应该可以正常用https协议访问。 如果不能，如果你用的是阿里云服务器，请看步骤3。如果是其它服务器，请自行百度。 步骤3 在安全组规则开通443端口 需要该步骤的原因是因为云服务器的安全组规则上没有开通相关的端口。     做完步骤3，应该可以用https了。如果还不能，提交工单问技术人员吧。或者再检查下步骤1与步骤2有没有做到位。   from:https://blog.csdn.net/chunyuan314/article/details/77369110