知新_RL

这个屌丝很懒，什么也没留下！

热门标签

Nginx常用安全加固措施+限速模块_nginx安全加固

作者：知新_RL | 2024-08-08 11:49:14

踩

nginx安全加固

安全加固

1、禁止目录浏览/隐藏版本信息

编辑nginx.conf配置文件，HTTP模块添加如下一行内容，并重启：


autoindex off;      #禁止目录浏览
server_tokens off;       #隐藏版本信息

2、限制http请求方法


if ($request_method !~ ^(GET|HEAD|POST)$ ) {
  return444; 
}

3、限制IP访问


location / { 
  deny 192.168.1.1; #拒绝IP
  allow 192.168.1.0/24; #允许IP 
  allow 10.1.1.0/16; #允许IP 
  deny all; #拒绝其他所有IP 
}

4、限制并发和速度


limit_zone one $binary_remote_addr 10m; 
server {      
  listen   80;      
  server_name www.test.com;      
  index index.html index.htm index.php;      
  root  /usr/local/www;      #Zone limit;      
  location / {          
    limit_conn one 1;          
    limit_rate 20k;      
  } 
  ……… 
}

5、控制超时时间


client_body_timeout 10;  #设置客户端请求主体读取超时时间 
client_header_timeout 10;  #设置客户端请求头读取超时时间 
keepalive_timeout 55;  #第一个参数指定客户端连接保持活动的超时时间，第二个参数是可选的，它指定了消息头保持活动的有效时间 
send_timeout10;  #指定响应客户端的超时时间

6、nginx降权

user nobody;

7、配置防盗链


location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip)$ {     
  valid_referers none blocked server_names *.test.com http://localhost baidu.com;
  if ($invalid_referer) {         
    rewrite ^/ [img]http://www.XXX.com/images/default/logo.gif[/img];         
    # return403;     
  } 
}

8、针对SSL 策略进行加固（需ngnix版本支持）


server { 
 ssl_protocols TLSv1.2,TLSv1.3;
}

9、确保NGINX配置文件权限为644


修改Nginx配置文件权限： 
执行chmod 644 <conf_path>来限制Nginx配置文件的权限；(<conf_path>为配置文件的路径，
如默认/安装目录/conf/nginx.conf或者/etc/nginx/nginx.conf，或用户自定义，请 自行查找)

10、更改源码隐藏软件名称及版本号


在nginx编译安装之前，先更改，之后再编译安装
 
1.更改版本号
 
修改nginx-1.6.4/src/core/nginx.h
nginx-1.6.2/src/core# 
sed -n '13,17p' nginx.h
#修改为需要的版本号
#将nginx修改为其他名称

11、Nginx后端服务指定的Header隐藏状态

当nginx作为反向代理时,会配置很多站点，为了不想泄露后端webserver主机信息，可以在http全局下配置隐藏Nginx后端服务X-Powered-By头。

隐藏Nginx后端服务X-Powered-By头


1、打开conf/nginx.conf配置文件； 
2、在http下配置proxy_hide_header项； 
     增加或修改为 proxy_hide_header X-Powered-By; proxy_hide_header Server;
 
http {
       .....
       proxy_hide_header X-Powered-By; 
       proxy_hide_header Server;
       ....
}

12、Nginx解决跨域问题

复杂跨域的条件是：

①、非GET、HEAD、POST请求。

②、POST请求的Content-Type不是application/x-www-form-urlencoded, multipart/form-data, 或text/plain。

③、添加了自定义header，例如Token。

跨域请求浏览器会在Headers中添加Origin，通常情况下不允许用户修改其值。


在编辑状态下，在http节点下添加三条命令就行了，命令如下：
 
add_headerAccess-Control-Allow-Origin*;
add_headerAccess-Control-Allow-MethodsGET,POST,OPTIONS;
add_headerAccess-Control-Allow-HeadersX-Requested-With;

1、首先查看http头部有无origin字段；
2、如果没有，或者不允许，直接当成普通人请求处理，结束；
3、如果有并且是允许的，那么再看是否是preflight(method=OPTIONS)；
4、如果是preflight，就返回Allow-Headers、Allow-Methods等，内容为空；
5、如果不是preflight，就返回Allow-Origin、Allow-Credentials等，并返回正常内容。


  1 location /pub/(.+) {
  2     if ($http_origin ~ <允许的域（正则匹配）>) {
  3         add_header 'Access-Control-Allow-Origin' "$http_origin";
  4         add_header 'Access-Control-Allow-Credentials' "true";
  5         if ($request_method = "OPTIONS") {
  6             add_header 'Access-Control-Max-Age' 86400;
  7             add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE';
  8             add_header 'Access-Control-Allow-Headers' 'reqid, nid, host, x-real-ip, x-forwarded-ip, event-type, event-id, accept, content-type';
  9             add_header 'Content-Length' 0;
 10             add_header 'Content-Type' 'text/plain, charset=utf-8';
 11             return 204;
 12         }
 13     }
 14     # 正常nginx配置
 15     ......
 16 }

方案1 *：通配符，全部允许，存在安全隐患(不推荐)。

一旦启用本方法，表示任何域名皆可直接跨域请求：


  1     server {
  2         ...
  3         location / {
  4             # 允许 所有头部 所有域 所有方法
  5             add_header 'Access-Control-Allow-Origin' '*';
  6             add_header 'Access-Control-Allow-Headers' '*';
  7             add_header 'Access-Control-Allow-Methods' '*';
  8             # OPTIONS 直接返回204
  9             if ($request_method = 'OPTIONS') {
 10                 return 204;
 11             }
 12         }
 13         ...
 14     }

方案2：多域名配置(推荐)

配置多个域名在map中只有配置过的允许跨域：


  1  map $http_origin $corsHost {
  2         default 0;
  3         "~https://zzzmh.cn" https://zzzmh.cn;
  4         "~https://chrome.zzzmh.cn" https://chrome.zzzmh.cn;
  5         "~https://bz.zzzmh.cn" https://bz.zzzmh.cn;
  6     }
  7     server {
  8         ...
  9         location / {
 10             # 允许 所有头部 所有$corsHost域 所有方法
 11             add_header 'Access-Control-Allow-Origin' $corsHost;
 12             add_header 'Access-Control-Allow-Headers' '*';
 13             add_header 'Access-Control-Allow-Methods' '*';
 14             # OPTIONS 直接返回204
 15             if ($request_method = 'OPTIONS') {
 16                 return 204;
 17             }
 18         }
 19         ...
 20     }

Nginx限速模块

Nginx限流使用的是leaky bucket算法，如对算法感兴趣，可移步维基百科先行阅读。不过不了解此算法，不影响阅读本文。

空桶

我们从最简单的限流配置开始：


limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=ip_limit;
        proxy_pass http://login_upstream;
    }
}

$binary_remote_addr 针对客户端ip限流；
zone=ip_limit:10m 限流规则名称为ip_limit，允许使用10MB的内存空间来记录ip对应的限流状态；
rate=10r/s 限流速度为每秒10次请求
location /login/ 对登录进行限流

限流速度为每秒10次请求，如果有10次请求同时到达一个空闲的nginx，他们都能得到执行吗？

漏桶漏出请求是匀速的。10r/s是怎样匀速的呢？每100ms漏出一个请求。

在这样的配置下，桶是空的，所有不能实时漏出的请求，都会被拒绝掉。

所以如果10次请求同时到达，那么只有一个请求能够得到执行，其它的，都会被拒绝。

这不太友好，大部分业务场景下我们希望这10个请求都能得到执行。

Burst

我们把配置改一下，解决上一节的问题


limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=ip_limit burst=12;
        proxy_pass http://login_upstream;
    }
}

burst=12 漏桶的大小设置为12

逻辑上叫漏桶，实现起来是FIFO队列，把得不到执行的请求暂时缓存起来。

这样漏出的速度仍然是100ms一个请求，但并发而来，暂时得不到执行的请求，可以先缓存起来。只有当队列满了的时候，才会拒绝接受新请求。

这样漏桶在限流的同时，也起到了削峰填谷的作用。

在这样的配置下，如果有10次请求同时到达，它们会依次执行，每100ms执行1个。

虽然得到执行了，但因为排队执行，延迟大大增加，在很多场景下仍然是不能接受的。

NoDelay

继续修改配置，解决Delay太久导致延迟增加的问题


limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=ip_limit burst=12 nodelay;
        proxy_pass http://login_upstream;
    }
}

nodelay 把开始执行请求的时间提前，以前是delay到从桶里漏出来才执行，现在不delay了，只要入桶就开始执行

要么立刻执行，要么被拒绝，请求不会因为限流而增加延迟了。

因为请求从桶里漏出来还是匀速的，桶的空间又是固定的，最终平均下来，还是每秒执行了5次请求，限流的目的还是达到了。

但这样也有缺点，限流是限了，但是限得不那么匀速。以上面的配置举例，如果有12个请求同时到达，那么这12个请求都能够立刻执行，然后后面的请求只能匀速进桶，100ms执行1个。如果有一段时间没有请求，桶空了，那么又可能出现并发的12个请求一起执行。

大部分情况下，这种限流不匀速，不算是大问题。不过nginx也提供了一个参数才控制并发执行也就是nodelay的请求的数量。


limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=ip_limit burst=12 delay=4;
        proxy_pass http://login_upstream;
    }
}

delay=4 从桶内第5个请求开始delay

这样通过控制delay参数的值，可以调整允许并发执行的请求的数量，使得请求变的均匀起来，在有些耗资源的服务上控制这个数量，还是有必要的。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/知新_RL/article/detail/947993