☰

firewall-cmd 表示没有活动的防火墙区域。为什么？

tag-icon • tag-icon debian firewalld
firewall-cmd 表示没有活动的防火墙区域。为什么？

在 Debian 9 上，我安装了firewalld（版本0.4.4.2-1）。

sudo firewall-cmd --get-active-zones显示没有输出。并echo $?显示退出状态为 0 ( EXIT_SUCCESS)。为什么？

我有一个网络接口，如（以及环回接口）eth0所示。ip linklo

我应该说我的防火墙配置出现大部分时间都在工作。 FWIW，我已将默认区域从 更改public为MyZone，定义如下：

$ sudo cat /etc/firewalld/zones/MyZone.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>My Zone</short>
  <service name="ssh"/>
  <service name="https"/>
  <!-- ... --> 
</zone>

如果我尝试使用另一台计算机进行连接，我可以访问 SSH 和 HTTPS 服务。如果我ncat -l -p 8000在服务器上运行并尝试连接ncat my-server 8000，则连接会被正确阻止。 （Ncat: No route to host. 并tcpdump显示生成了 ICMP 无法到达的回复，输入“管理员禁止”）。

为什么firewall-cmd --get-active-zonesMyZone 不显示为活动状态？

$ sudo firewall-cmd --state                                                                                                         
running
$ sudo firewall-cmd --get-active-zones
$ echo $?
0
$ sudo firewall-cmd --get-default-zone
MyZone
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:43:01:c0:ab brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.8/24 brd 172.16.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd5e:fcf3:b885:0:250:43ff:fe01:c0ab/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::250:43ff:fe01:c0ab/64 scope link
       valid_lft forever preferred_lft forever

firewalld.service不记录任何警告。

$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-01-30 13:17:31 GMT; 56min ago
     Docs: man:firewalld(1)
 Main PID: 509 (firewalld)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/firewalld.service
           └─509 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

Jan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...
Jan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.

我发现它firewalld更喜欢与 NetworkManager 一起使用。我目前没有运行 NetworkManager，听起来这有点脆弱。

https://firewalld.org/documentation/concepts.html

如果不使用 NetworkManager，则会有一些限制...如果在网络已启动后启动防火墙，则连接和手动创建的接口不会绑定到区域。

但是，自从安装以来我至少重新启动过一次firewalld。我检查了systemd服务。 firewalld.service已开始Before=network-pre.target。 networking.service已开始After=network-pre.target。我已经确认firewalld之前已启动networking.service：

$ sudo journalctl -b -u networking -u firewalld
-- Logs begin at Sat 2019-01-26 04:15:01 GMT, end at Wed 2019-01-30 14:15:33 GMT. --
Jan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...
Jan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.
Jan 30 13:17:31 brick systemd[1]: Starting Raise network interfaces...
Jan 30 13:17:37 brick systemd[1]: Started Raise network interfaces.

我没有手动重新启动网络或运行ifdown/ ifup，并且我没有运行ifplugd。内核日志（如下）表明以太网链路已启动，并且 IPv6 自启动以来一直在持续运行。

$ sudo dmesg|grep eth0
[    4.082350] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:01:c0:ab
[   47.577570] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   49.981569] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[   49.991543] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

我什至没有使用 DHCP。eth0in的配置/etc/network/interfaces是

auto eth0
iface eth0 inet static
    address 172.16.1.8
    netmask 255.255.255.0
    gateway 172.16.1.1
    dns-nameservers 172.16.1.1

答案1

firewalld 不依赖于 NetworkManager,但建议使用。

他们不是在开玩笑。

在没有 NetworkManager 的情况下，网页文档继续说您需要在两个不同位置的配置之间复制/保持一致性。

另外，这两个地方中的第一个是ifcfg网络配置系统，Debian 上不存在该系统。言外之意，网络管理器是Debian 上需要:-)。

（综合各种信息，很明显，只有在启动网络接口后/etc/firewalld/手动启动时才需要中的重复配置。这包括重新启动，尽管您通常不希望重新启动。）firewalldfirewalldfirewalld

一方面，可以公平地预期在问题中观察到的具体“主要工作”行为。根据其他文档和进一步的观察，您可以合理地预期默认区域将应用​​于您的接口。

在没有 NetworkManager 的 Debian 上，将接口分配给不同的区域可能会在正在运行的系统上工作，但在重新启动时无法工作。

您可能希望对防火墙有超过“合理的期望”。如果您可以使用“推荐”配置，则更令人放心，该配置在firewalld更改时可能会得到更好的测试，而不必依赖于这种令人困惑的行为。

我仍然对其影响感到困惑，包括对红帽系统的影响。当未能正确保存区域配置时，firewall-cmd --permanent --add-interface=...可以字面显示结果“ ”，这是非常令人困惑的！success

以下是相关引用man firewalld：

如果未使用 NetworkManager 并且在网络启动后启动了firewalld，则连接和手动创建的接口不会绑定到 ifcfg 文件中指定的区域。接口将自动由默认区域处理。 firewalld 也不会收到有关网络设备重命名的通知。如果NM_CONTROLLED=no设置了，所有这些也适用于不受 NetworkManager 控制的接口 。

您可以使用以下命令将这些接口添加到区域中

firewall-cmd [--permanent] --zone=zone --add-interface=interface

如果有 /etc/sysconfig/network-scripts/ifcfg-interface文件，firewalld 会尝试更改ZONE=zone该文件中的设置。

如果firewalld重新加载，它将恢复重新加载之前的接口绑定，以在NetworkManager不受控制的接口的情况下保持接口绑定稳定。在firewalld服务重新启动的情况下，这种机制是不可能的。

ZONE=对于 NetworkManager 不受控制的接口，必须保持ifcfg 文件中的设置与 firewalld 中的绑定一致。

作为实验，我尝试了提到的命令：

$ sudo firewall-cmd --zone=MyZone --add-interface=eth0
$ sudo firewall-cmd --get-active-zones
MyZone:
  interfaces: eth0

如果我的网络接口是在 后启动的，则此行为正是您从文档中所期望的firewalld。但是我的网络接口在 后没有启动firewalld。

该man页面听起来像是firewalld依赖于ifcfg在启动网络接口时获取回调。不过ifcfg是Red Hat的网络系统；它没有安装在我的 Debian 系统上。 Debian 软件包似乎firewalld没有提供任何等效项。因此我们降级为“接口将自动由默认区域处理”。

我跑去sudo iptables-save查看 .iptables 生成的 iptables（仅限 IPv4）规则firewalld。如果我没有手动运行的话firewall-cmd --add-interface...，就没有提及了eth0。但如果我没看错的话，规则会使用默认区域的规则来处理此类数据包，作为后备。

答案2

如果您没有将任何配置文件放入其中，/usr/lib/firewalld/zones或者/etc/firewalld/zones您没有任何配置的区域。您所拥有的只是一个通用防火墙。根据您所拥有的规则，仍然有效，只是无法从公共区域切换到私人区域或您可能已配置的任何其他区域并使规则自动更改。

此外，如果您使用 GUI 来配置防火墙，只需检查这些目录以确保您设置的设置实际到位。

如果您手动将配置文件放在那里，或者 GUI 设置管理器成功地将您配置的区域的文件放置到位，那么我不知道。

firewalld是Linux操作系统的防火墙管理工具。它通过 iptables 命令充当 Linux 内核的 netfilter 框架的前端来提供防火墙功能，充当 iptables 服务的替代方案

检查：iptables -S，那里有什么？如果列出了规则，那么它就是通用防火墙！您不需要firewalld来拥有防火墙，您只需手动编辑iptables即可。

然后安装iptables-persistent，然后在每次编辑后保存您的规则netfilter-persistent save

大多数系统上的默认策略是（PUBLIC）：

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

然后你可以用链的形式来阐述规则。

  • 句法：

    iptables -A INPUT/FORWARD/OUTPUT <interface> <port type> <state> <port> <what to do if match>

例子：（允许默认端口上的所有传入 SSH 对于安全而言不是一个好的做法）

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

相关内容