我有以下IPTablesIPSet作为阻止攻击IP的规则源,但是当我在IP访问日志中向IPSet添加攻击的nginx时,仍然可以看到对IP攻击的连续访问。大约3到5分钟后,IP被阻止。

iptables

~$ sudo iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 317K packets, 230M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     106K 6004K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set Blacklist src

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set Blacklist src

Chain OUTPUT (policy ACCEPT 350K packets, 58M bytes)
num   pkts bytes target     prot opt in     out     source               destination

ipset
sudo ipset -L
Name: Blacklist
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 timeout 60
Size in memory: 13280
References: 2
Members:
xxx.xxx.xxx.xxx(attacker ip) timeout 0

我不知道为什么规则没有立即生效,这使我发疯,就像攻击者在 mock 我一样。

我使用ipset选项将iptables添加到-I规则中,该选项应将规则保持在第一位置。因此,也许Chain INPUT(policy Accept)可以解决问题?

请帮帮我,非常感谢。

BTW。

我使用Nginx+Djano/uWSGI部署我的应用程序,并使用shell脚本分析nginx日志以将邪恶的ip放入Blacklist ipset

最佳答案

防火墙规则可能不会立即对阻止流量产生影响的原因可能是由于有状态对数据包的检查。

防火墙分析行中到达的每个数据包可能效率不高,因此,出于性能原因,发生的事情是用户创建的规则通常仅适用于建立连接的初始数据包(称为TCP的SYN, (SYN + ACKACK)—随后,该连接会自动列入白名单(更精确地说,是原始规则创建的状态已被列入白名单),直到被终止(FIN)。

这里可能发生的事情是,由于nginx擅长的流水线和保持事件连接,单个连接可用于发出和处理多个独立的HTTP请求。

因此,为了解决此问题,您可以在nginx中禁用流水线和保持事件状态(这不是一个好主意,因为它会影响性能),或者删除现有列入白名单的连接,例如,使用类似的方法 tcpdrop(8) on *BSD —当然也必须有一个Linux等效工具。

但是,如果您只是一个客户端执行过多请求而导致问题,从而使后端重载,那么适当的操作方法可能是根据IP地址对客户端进行速率限制,在标准 limit-req directive of nginx的帮助下。 (但是请注意,您的某些客户可能位于运营商级NAT之后,因此,请谨慎使用限制以确保假阳性不会成为问题。)

关于security - IPTables不会立即使用ipset阻止IP,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/45396155/

10-13 06:01