SSH 端口被 iptables 阻止 - 但仍可以从任何地址登录到 SSH 端口

Question 1

由于我的菜鸟名声，我需要在这里询问澄清。

您能否编辑您的问题以包含 INPUT 链默认策略？我问这个问题是因为这一行：

RETURN   tcp  --  0.0.0.0/0   0.0.0.0/0   tcp flags:0x17/0x02 limit: avg 1/sec burst 2

我不是专家，但我从未见过它在顶层使用。不过可能只有我才这么认为。iptables 手册页中关于 RETURN 的说法是：

RETURN 表示停止遍历此链并从上一个（调用）链中的下一个规则恢复。如果到达内置链的末尾或匹配了目标为 RETURN 的内置链中的规则，则链策略指定的目标将决定数据包的命运。

我有预感您的问题可能与此功能有关。

Answer

由于我的菜鸟名声，我需要在这里询问澄清。

您能否编辑您的问题以包含 INPUT 链默认策略？我问这个问题是因为这一行：

RETURN   tcp  --  0.0.0.0/0   0.0.0.0/0   tcp flags:0x17/0x02 limit: avg 1/sec burst 2

我不是专家，但我从未见过它在顶层使用。不过可能只有我才这么认为。iptables 手册页中关于 RETURN 的说法是：

RETURN 表示停止遍历此链并从上一个（调用）链中的下一个规则恢复。如果到达内置链的末尾或匹配了目标为 RETURN 的内置链中的规则，则链策略指定的目标将决定数据包的命运。

我有预感您的问题可能与此功能有关。

Question 2

根据提供的数据，我很难给出直接的答案，但我的方法是：

将 iptables 精简为仅两个规则：允许单个 IP 地址范围（您正在连接的 IP 地址范围），并拒绝其他所有 IP 地址。注意不要将自己锁定在服务器之外！拥有控制台访问权限或备份计划可能会救你一命。如果你足够自信，这里有一个如何继续的示例。谨慎行事！：

您可以发出类似以下命令：

sudo iptables-save > /tmp/original-rules.txt
sudo iptables -F 
sudo iptables -X
sudo iptables -A INPUT -s 209.xxx.xxx.1 -j ACCEPT
sudo iptables -A INPUT -j DROP

上述命令序列将保存您现有的规则，对所有链进行基本清理，向 INPUT 链添加单个 IP 地址或地址范围，并向 INPUT 链添加删除“任何”规则。

恢复原始规则可以通过以下方式实现：

sudo iptables-restore < /tmp/original-rules.txt

测试两条规则的设置：

2a. 如果有效，你就知道问题出在原始规则上。慢慢地继续添加规则并测试它们，直到你满意为止。你也可以使用日志记录了解哪条规则被匹配。

2b. 如果您的服务器在只有两条规则的情况下仍可访问，而除了您允许的 IP 地址之外，其他任何 IP 地址都无法访问您的服务器，那么您就知道这不是规则问题，而是 iptables 本身出了问题。可能是它没有正确加载，或者 iptables 的先前状态正在内存中运行。

Answer

根据提供的数据，我很难给出直接的答案，但我的方法是：

将 iptables 精简为仅两个规则：允许单个 IP 地址范围（您正在连接的 IP 地址范围），并拒绝其他所有 IP 地址。注意不要将自己锁定在服务器之外！拥有控制台访问权限或备份计划可能会救你一命。如果你足够自信，这里有一个如何继续的示例。谨慎行事！：

您可以发出类似以下命令：

sudo iptables-save > /tmp/original-rules.txt
sudo iptables -F 
sudo iptables -X
sudo iptables -A INPUT -s 209.xxx.xxx.1 -j ACCEPT
sudo iptables -A INPUT -j DROP

上述命令序列将保存您现有的规则，对所有链进行基本清理，向 INPUT 链添加单个 IP 地址或地址范围，并向 INPUT 链添加删除“任何”规则。

恢复原始规则可以通过以下方式实现：

sudo iptables-restore < /tmp/original-rules.txt

测试两条规则的设置：

2a. 如果有效，你就知道问题出在原始规则上。慢慢地继续添加规则并测试它们，直到你满意为止。你也可以使用日志记录了解哪条规则被匹配。

2b. 如果您的服务器在只有两条规则的情况下仍可访问，而除了您允许的 IP 地址之外，其他任何 IP 地址都无法访问您的服务器，那么您就知道这不是规则问题，而是 iptables 本身出了问题。可能是它没有正确加载，或者 iptables 的先前状态正在内存中运行。

Question 3

原始海报接受了我之前的回答，但这里有更深入的解释：

我进行了一些诊断和调试。这是我首先做的事情：

安装 Ubuntu 14.04 作为 VMware 虚拟机
修改 /etc/ssh/sshd_config 如下：Port 2022
重启机器
记下虚拟机 IP 地址，即 192.168.241.171

接下来，我取出您的防火墙脚本并删除了 xxx 条目。我将修改后的脚本称为“原始”脚本。

我进行了几次重启/脚本修改/脚本运行/Putty 连接循环。以下是场景和结果：

没有修改“原来的”脚本：Putty 连接到 192.168.241.171 端口 2022 是成功的
删除$APPEND -p tcp --syn -m limit --limit 1/s --limit-burst 2 -j RETURN了“原来的”脚本：Putty 连接到 192.168.241.171 端口 2022 是受阻
在此之前添加了#allow local host"：/sbin/iptables -P INPUT DROP`到“原来的”脚本：Putty 连接到 192.168.241.171 端口 2022 是受阻
在此之前已添加#allow local host"：/sbin/iptables -P INPUT ACCEPT`到“原来的”脚本：Putty 连接到 192.168.241.171 端口 2022 是成功的

我想我知道发生了什么。用户忘记将 INPUT 链默认策略设置为 DROP。一些使用 RETURN 语句阻止 syn 泛洪的示例期望将默认 INPUT 链策略设置为 DROP，而用户在没有设置策略的情况下改编了此类示例。我进一步推测防火墙脚本从未完全发挥作用，并且一直保护 sshd 免受外部用户的攻击的是非标准端口 2022（但现在坏人也在敲 2022）。

PS. 如果要更改默认策略，则应在下班后进行，以消除对人们的直接影响，然后再进行测试并适应新问题（如果有）。

Answer