Nginx阻止DDoS攻击的教程收集（转）（待实践）

最新推荐文章于 2024-08-10 00:00:00 发布

angou6476

最新推荐文章于 2024-08-10 00:00:00 发布

阅读量305

点赞数

文章标签：运维后端 php

原文链接：http://www.cnblogs.com/EasonJim/p/7807729.html

版权

DDoS估计是一个非常头痛的问题。

分布式拒绝服务攻击（DDoS）指的是通过多台机器向一个服务或者网站发送大量看似合法的数据包使其网络阻塞、资源耗尽从而不能为正常用户提供正常服务的攻击手段。随着互联网带宽的增加和相关工具的不断发布，这种攻击的实施难度越来越低，有大量IDC托管机房、商业站点、游戏服务商一直饱受DDoS攻击的困扰，那么如何缓解甚至解决DDoS呢？最近Rick Nelson在Nginx的官方博客上发表了一篇文章，介绍了如何通过Nginx和Nginx Plus缓和DDoS攻击。

Rick Nelson首先介绍了DDoS攻击的一些特点,例如攻击的流量通常来源于一些固定的IP地址，每一个IP地址会创建比真实用户多得多的连接和请求；同时由于流量全部是由机器产生的，其速率要比人类用户高的多。此外，进行攻击的机器其User-Agent头也不是标准的值，Referer头有时也会被设置成能够与攻击关联起来的值。针对这些特点，Rick Nelson认为Nginx和Nginx Plus有很多能够通过调节或控制流量来应对或者减轻DDoS攻击的特性。

限制请求率

将Nginx和Nginx Plus可接受的入站请求率限制为某个适合真实用户的值。例如，通过下面的配置让一个真正的用户每两秒钟才能访问一次登录页面：

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
    ...
    location /login.html {
        limit_req zone=one;
    ...
    }
}

在该配置中，limit_req_zone指令配置了一个名为one的共享内存zone用来存储$binary_remote_addr的请求状态，location块中/login.html的limit_req指令引用了共享内存zone。

限制连接的数量

将某个客户端IP地址所能打开的连接数限制为真实用户的合理值。例如，限制每一个IP对网站/store部分打开的连接数不超过10个：

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    ...
    location /store/ {
        limit_conn addr 10;
        ...
    }
}

该配置中，limit_conn_zone指令配置了一个名为addr的共享内存zone用来存储 $binary_remote_addr的请求，location块中/store/的limit_conn指令引用了共享内存zone，并将最大连接数设置为10.

关闭慢连接

关闭那些一直保持打开同时写数据又特别频繁的连接，因为它们会降低服务器接受新连接的能力。Slowloris就是这种类型的攻击。对此，可以通过client_body_timeout和client_header_timeout指令控制请求体或者请求头的超时时间，例如，通过下面的配置将等待时间控制在5s之内：

server {
    client_body_timeout 5s;
    client_header_timeout 5s;
    ...
}

设置IP黑名单

如果能识别攻击者所使用的客户端IP地址，那么通过deny指令将其屏蔽，让Nginx和Nginx Plus拒绝来自这些地址的连接或请求。例如，通过下面的指令拒绝来自123.123.123.3、123.123.123.5和123.123.123.7的请求：

location / {
    deny 123.123.123.3;
    deny 123.123.123.5;
    deny 123.123.123.7;
    ...
}

设置IP白名单

如果允许访问的IP地址比较固定，那么通过allow和deny指令让网站或者应用程序只接受来自于某个IP地址或者某个IP地址段的请求。例如，通过下面的指令将访问限制为本地网络的一个IP段：

location / {
    allow 192.168.1.0/24;
    deny all;
    ...
}

通过缓存削减流量峰值

通过启用缓存并设置某些缓存参数让Nginx和Nginx Plus吸收攻击所产生的大部分流量峰值。例如，通过proxy_cache_use_stale指令的updating参数告诉Nginx何时需要更新过期的缓存对象，避免因重复发送更新请求对后端服务器产生压力。另外，proxy_cache_key指令定义的键通常会包含嵌入的变量，例如默认的键$scheme$proxy_host$request_uri包含了三个变量，如果它包含$query_string变量，那么攻击者可以通过发送随机的query_string值来耗尽缓存，因此，如果没有特别原因，不要在该键中使用$query_string变量。

阻塞请求

配置Nginx和Nginx Plus阻塞以下类型的请求：

以某个特定URL为目标的请求
User-Agent头中的值不在正常客户端范围之内的请求
Referer头中的值能够与攻击关联起来的请求
其他头中存在能够与攻击关联在一起的值的请求

例如，通过下面的配置阻塞以/foo.php为目标的攻击：

location /foo.php {
    deny all;
}

或者通过下面的配置阻塞已识别出的User-Agent头的值是foo或者bar的DDoS攻击：

location / {
    if ($http_user_agent ~* foo|bar) {
        return 403;
    }
    ...
}

限制对后端服务器的连接数

通常Nginx和Nginx Plus实例能够处理比后端服务器多得多的连接数，因此可以通过Nginx Plus限制到每一个后端服务器的连接数。例如，通过下面的配置限制Nginx Plus和每一台后端服务器之间建立的连接数不多于200个：

upstream website {
    server 192.168.100.1:80 max_conns=200;
    server 192.168.100.2:80 max_conns=200;
    queue 10 timeout=30s;
}

另外，Rick Nelson还提到了如何处理基于范围的攻击和如何处理高负载的问题，以及如何使用Nginx Plus Status模块发现异常的流量模式，定位DDoS攻击。

题外：

其实DDoS这种话题用Nginx不一定能解决，应该在实战中随机应变才是对的，因为DDoS往往集中在网络的第四和第七层，而且又是借助全球的肉鸡不断的发起攻击，可以说是全球顶尖的分布式来袭。只有在实战中摸清来的套路，不断的去优化网络才是真的。且Nginx只能做到第七层上，对于第四层根本没办法防止，但是也不一定是没有用的。

所以，Nginx防DDoS没有绝对，只有合理的应对。

下面是收集的教程：

http://www.infoq.com/cn/news/2016/01/Nginx-AntiDDoS（以上内容转自此篇文章）

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

http://nginx.org/en/docs/http/ngx_http_status_module.html?_ga=1.187642144.967276342.1451228467

https://www.nginx.com/blog/tuning-nginx/?_ga=1.87178896.967276342.1451228467

https://www.nginx.com/blog/nginx-protect-cve-2015-1635/?_ga=1.144784956.967276342.1451228467

http://www.freebuf.com/articles/system/92907.html

http://www.52os.net/articles/nginx-anti-ddos-setting.html

https://www.52os.net/articles/nginx-anti-ddos-setting-2.html

https://www.zhihu.com/question/19581905

https://www.v2ex.com/t/382998