这是一个创建于 2812 天前的主题，其中的信息可能已经有所发展或是发生改变。
每秒几百到几千的并发，占用好多资源
刚开始以为直接用 nginx 限制下速度就可以了和 ip
仔细一看请求的 ip 都是不一样的
有什么办法处理这个问题？
第 1 条附言 · 2017-02-24 17:44:12 +08:00
服务器被人攻击了 1 天了
心塞，应该是 cc 攻击
刚做了 2 个月有点起色了 就人攻击了
心塞，应该是 cc 攻击
刚做了 2 个月有点起色了 就人攻击了
 |
1
scloud 2017-02-23 15:49:49 +08:00  1
1.接口添加签名验证
2.代码添加访问速率检测 3.refer,cookie 等信息验证 |
 |
2
234747005 2017-02-23 15:52:57 +08:00 1
if ($cookie_say != "hbnl$remote_addr"){
add_header Set-Cookie "say=hbnl$remote_addr"; rewrite .* "$scheme://$host$uri" redirect; } |
|
3
234747005 2017-02-23 15:53:17 +08:00 1
if ($http_user_agent ~* "Netscape/*|Chrome/19/*|WordPress/*|BaiduSpider/*|Baiduspider/*|Gecko/20100101|Firefox/3") {
return 403; } |
 |
4
sampeng 2017-02-23 15:56:52 +08:00 2
楼上这个不可取。因为依然到达了程序层。
得在 nginx 层加防护。好像 iptable 就能禁止一个 ip 多次访问。 ip 再多不可能无上限，用脚本一算就知道有多少 ip 了。每个 ip 是不是只在请求这个接口，你应该有其他接口。如果一个 ip 只访问了 A 接口却没访问 B 接口。那你还不干掉他等着过年啊。 但这可能会误杀，小区宽带都是相同 ip 。 所以折中的方案是用个东西算这个 ip 是否有效请求。然后写一个黑名单， iptable 拦在外面。 这个东西是业务程序里还是直接分析 nginx 日志。就看你个人了。。 一般情况下分析 nginx 日志生成 ip 黑名单应该可以防护很大一坨恶意攻击。 另外服务器内核配置快速释放端口这样的优化，可以缓解资源被占用的情况。。每秒几百上千有点夸张了。几千个端口开着。很吃 cpu 的。。直接限制在 1000 个。其他的排队等去吧。 |
|
5
scloud 2017-02-23 16:02:44 +08:00 1
4.nginx_lua 配合 redis ，直接在 nginx 层去处理。上面 1,2,3 可以快速处理非法无效请求。后续优化可以用 4.
|
 |
6
airqj 2017-02-23 16:26:04 +08:00
|
|
7
airqj 2017-02-23 16:27:07 +08:00
直接用 iptables 封掉请求次数太多的 IP
这比在 web server 层效率高很多 |
 |
8
mhycy 2017-02-23 16:40:25 +08:00
搭车求问
在此需求场景下镜像流量应该可以实现请求审计能力且不影响主干业务的性能 不知现在有没有合适的开源解决方案？ |
 |
9
salmon5 2017-02-23 16:53:26 +08:00 1
iptables 限制？如果有正常的业务突发并发呢？真是码农思维。
业务层做判断和限制。 既然知道你的接口规范了，肯定是合法的业务接入。 |
 |
10
Felldeadbird 2017-02-23 16:53:48 +08:00 1
先看你的接口属性啊。私有的话，上动态 token ，加验证。反正增加对方的成本。在访问这些私有请求接口错误次数的，动态写入黑名单。 然后交由 nginx 和 iptables 去处理黑名单。
公开接口的话，限制单个 IP 请求次数咯。否则就是升级硬件。 |
 |
11
holyzhou 2017-02-23 16:59:54 +08:00 1
|
 |
12
donyee 2017-02-23 17:20:37 +08:00
收费，不给就统计损失 报警...
这个思路怎么样？ |
 |
13
em70 2017-02-23 17:27:35 +08:00 via Android 1
看下日志，先把异常 UA 的封了，然后接口签名加密，再写个脚本每半个小时自动打印下前 100 位的 IP 访问列表及访问数，如果超过正常值就自动防火墙黑名单
|
 |
14
fengxsong 2017-02-24 09:14:02 +08:00 1
既然是用 jtw 方式请求接口的话。。在前端 nginx 上判断有无这个 cookie 直接 return 403 就好了。。 LS 的 ngx_lua 也是一个方案，动态屏蔽这些很容易实现。
|
 |
17
realpg 2017-02-25 23:06:56 +08:00 1
最省事的办法前面顶个百度云减速， 360 网站不安全卫士之类的 CDN
|
Select Language