主页 / ubuntu / 问题 / 1394738
Accepted
CpnCrunch
Asked: 2022-02-25 15:05:38 +0800 CST

UFW 在启用时阻止现有的出站连接

  • 772

我遇到了一个问题，即 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

（我已经用 1.2.3.4 替换了我们的服务器 ip）。被阻止的流量是到 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 块似乎会导致任何现有打开的出站连接出现问题，这些连接正在主动发送数据。

ufw

3 个回答

  1. 对于这个：

    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 转换为启用时连接断开也存在问题。我的另一个以前的答案中提供了一些调查方法here

    对于这个：

    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 的树莓派的传出连接。

    • 0

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

    根据ufw statusThe traffic has the source-port 443 (SPT) 而不是 DPT（本来是允许的）的输出，因此它被 ufw 丢弃。

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

    • 0
  3. Best Answer

    经过进一步调查，事实证明，在启用 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。

    • 0

相关问题