☰

在 Debian 上禁止 IP 地址（或子网）（ufw 和 iptables 之后仍然连接）

tag-icon • tag-icon debian fail2ban ufw
在 Debian 上禁止 IP 地址（或子网）（ufw 和 iptables 之后仍然连接）

我知道禁止 IP 地址的主题已被多次讨论，但由于某种原因，我无法解决/识别这个问题。

我正在尝试识别 Debian 服务器上某种随机攻击的问题。我已经运行了 ufw 和 fail2ban，但攻击仍然发生，我有点不知道下一步该怎么做。

我在运行时看到了连接tcptrack -i eth0，有数百个（有时是数千个）连接，如下所示（当然，xxx.xxx.xxx.xxx是坏人IP，yyy.yyy.yyy.yyy是服务器的IP地址）：

xxx.xxx.xxx.xxx:49550     yyy.yyy.yyy.yyy:80      SYN_SENT     18s    0 B/s

我已经运行了以下操作：

ufw reject from xxx.xxx.xxx.xxx to any
iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP

尽管连接引用了端口 80（它们也出现在 443 上），但我无法在apache2日志中看到它们，所以它们似乎没有走那么远。

运行htop它似乎没有遇到任何 CPU 或 RAM 问题，它似乎只是在较低的“连接”级别上压垮了服务器。

欢迎大家提出意见。

答案1

基本上SYN_SENT是一个正常的客户端 TCP 套接字状态，在客户端发出到服务器套接字的连接后进入该状态，直到服务器确认为止，之后客户端套接字状态将继续进行ESTABLISHED。

请注意，该SYN_SENT状态不会持续很长时间。它只会持续几秒钟。如果不是 - 可能会出现问题。

无论如何，此状态表示此套接字正在等待服务器连接。此外，这很可能意味着客户端请求从未到达服务器，因为 99% 的时间都表明由于防火墙（或 fail2ban）导致某种网络阻塞。

额外的丢弃和拒绝不会改变任何东西，特别是如果 net-filter 在 INPUT 链中有其他优先级更高的规则（例如从 fail2ban 拒绝它们）。
顺便说一句，请参阅GH :: fail2ban :: 重新审视 REJECT 与 DROP了解关于两者的一些想法）。
但是tcpkill，killcx等ss -K会破坏当前状态。

另外请注意，如果您确实有数千个被阻止的连接，为了加快网络过滤器处理速度，建议使用集合而不是 iptables 规则，从而切换到iptables-ipset或nftables禁止 fail2ban 的操作。

相关内容