☰

UFW 启用后会阻止现有的出站连接

tag-icon • tag-icon ufw
UFW 启用后会阻止现有的出站连接

我遇到了一个问题，当启用 ufw 时，它似乎会阻止端口 443 上现有的出站连接。示例：

Feb 24 17:53:00 server5 kernel: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 
Feb 24 17:33:40 server5 kernel: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0
Feb 27 00:47:07 server5 kernel: [18769144.299731] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=35.196.37.91 DST=1.2.3.4 LEN=1460 TOS=0x00 PREC=0x60 TTL=51 ID=60877 DF PROTO=TCP SPT=443 DPT=42030 WINDOW=229 RES=0x00 ACK URGP=0

尽管我已明确允许 1025-65535 之间的 UDP，但一些 UDP 数据包仍然被阻止：

Feb 24 17:52:19 server5 kernel: [18571459.414576] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=5.6.7.8 DST=1.2.3.4 LEN=69 TOS=0x00 PREC=0x00 TTL=44 ID=59557 PROTO=UDP SPT=58678 DPT=49900 LEN=49

（我已将我们的服务器 IP 替换为 1.2.3.4）。被阻止的流量是到 Google Drive 和 Vimeo 的传出 curl 连接。

以下是我的设置方法：

ufw reset
ufw default allow outgoing
ufw default deny incoming
ufw allow from 96.54.177.7 proto tcp to any port 22
ufw allow from 50.70.255.166 proto tcp to any port 22
ufw allow 443/tcp
ufw allow 80/tcp
ufw allow 25/tcp
ufw allow 587/tcp
ufw allow 1025:65535/udp

ufw 状态显示：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    99.99.99.99               
22/tcp                     ALLOW IN    99.99.99.99             
443/tcp                    ALLOW IN    Anywhere                  
80/tcp                     ALLOW IN    Anywhere                  
25/tcp                     ALLOW IN    Anywhere                  
587/tcp                    ALLOW IN    Anywhere

测试中：

  • 启用 ufw 后开始向 Vimeo 上传新文件一切正常。似乎没有任何东西被阻止。
  • 在 Vimeo 上传过程中启用 ufw 似乎会破坏它。
  • 从服务器远程登录到端口 587（邮件）到其他地方并启用 ufw 似乎不会造成任何问题。连接保持打开状态，我可以输入帮助等。
  • conntrack 从不显示出站连接，但会显示入站连接。
  • 当我在新的 ubuntu 20.04 云服务器实例上进行测试时，没有任何问题……我没有看到端口 443 被阻止的数据包，并且上传工作正常。但是在测试云服务器上，conntrack 未安装，即使在我安装了 conntrack 和 conntrackd 之后，我也看不到“conntrack -L”中列出的任何连接。

所以，我有点困惑这里到底发生了什么，我是否应该担心它。我真的不想启用 ufw，直到我完全了解它会对我的流量产生什么影响。如果 conntrack 不跟踪出站连接，它究竟如何跟踪出站连接？

我认为这里可能发生了一些事情，但我想了解为什么会看到这些。UDP 和 ACK 阻止是最令人担忧的，但它们似乎只会在启用 ufw 后几分之一秒内发生，所以我想知道 ufw 启用规则时是否有轻微的延迟。另一个（RST）可能只是由于连接被关闭。ACK 阻止似乎导致任何现有的开放出站连接在启用防火墙时主动发送数据时出现问题。

答案1

经过进一步调查，结果发现，在启用 ufw 的不到 1 秒的时间内，数据包被阻止。 “ufw enable” 命令根本不是原子性的……它是一个与 iptables 交互的 python 脚本。您可能认为它只执行一两个 iptables 命令，但这是不正确的。对“ufw enable”运行 strace 表明，在我的情况下，它实际上总共执行了 iptables 或 ip6tables 命令 358 次：

strace -f -tt ufw --force enable > /tmp/a 2>&1
root@testing:/home/ubuntu# grep exec /tmp/a|wc -l
358
root@testing:/home/ubuntu# grep exec /tmp/a|grep iptables|wc -l
135
root@testing:/home/ubuntu# grep exec /tmp/a|grep ip6tables|wc -l
134

例子：

[pid  1959] 17:13:34.241806 execve("/usr/sbin/ip6tables", ["/usr/sbin/ip6tables", "-I", "ufw6-user-limit", "-m", "limit", "--limit", "3/minute", "-j", "LOG", "--log-prefix", "[UFW LIMIT BLOCK] "], 0x7ffd5e6d3d10 /* 18 vars */ <unfinished ...>

因此，这样做的结果是，启用 ufw 可能会暂时破坏在启用 ufw 所需的时间内传输或接收数据的任何现有连接，因此请小心在实时服务器上启用 ufw。

答案2

对于这个：

Feb 24 17:53:00 server5 kernel: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0

这并不罕见。请参阅我之前的一个回答以了解更多详细信息。这里。

下一个：

Feb 24 17:33:40 server5 kernel: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08:00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0

不太清楚，但过去从 UFW 禁用转换为启用时也存在连接中断的问题。我之前的另一个回答提供了一些调查方法这里

对于这个：

conntrack doesn't ever show outbound connections, but does show inbound connections ok.

事实并非如此。以下是示例：

doug@s15:~$ sudo conntrack -L | grep 192.168.111.134
tcp      6 35972 ESTABLISHED src=192.168.111.1 dst=192.168.111.134 sport=36866 dport=22 src=192.168.111.134 dst=192.168.111.1 sport=22 dport=36866 [ASSURED] mark=0 use=1
conntrack v1.4.6 (conntrack-tools): 68 flow entries have been shown.

这是从我的主网关服务器 192.168.111.1 到树莓派 192.168.111.134 建立的传出连接。

答案3

如果仔细观察，您会发现丢弃的流量是传入流量， DST=1.2.3.4DST 代表目的地，正如您所说，1.2.3.4 是您的 IP。

根据输出，ufw status该流量的源端口是 443（SPT），而不是 DPT（这是被允许的），因此被 ufw 丢弃。

我的猜测是你在某个地方犯了一个错误（可能与网络地址转换有关），导致防火墙不具有状态。

相关内容